Case Study

Ops Command Center

ReactViteJavaScript RBACCampaign TemplatesDesign Tokens ● Live Demo
Launch Live Demo ↗
Ops Command Center — RBAC-scoped readiness overview
2
Live operations
4
Campaign templates
6 → 1
Teams per campaign

The Problem

Complex, multi-stakeholder implementations — an EHR go-live, an acquisition onboarding, a compliance cycle — fail in the seams: hundreds of departments, facilities, roles, and training tracks that all have to hit ready at the same time, tracked in spreadsheets nobody trusts.

Ops Command Center is an LMS-shaped, campaign-configurable operations command center for exactly that coordination. Users, courses, completions, and roles are the substrate; templates configure the same engine into fundamentally different operations; and the campaign is the unit of configuration — the real go-live behind this product ran six teams each owning different launch criteria, while a compliance cycle runs on one. The flagship workflow, Epic Go-Live Readiness, is a direct descendant of the 2015 Montefiore Hospital go-live and the scheduling system built for it — rebuilt as a product pattern rather than a one-off tool, and no longer the only operation running.

A Decade in the Making

The seed was that 2015 Epic go-live at Montefiore, where I built an Access-based scheduling system that cut instructor scheduling from three hours to forty-five minutes. It did exactly what that go-live needed — the extras I had in mind were polish to smooth the process further, not gaps in what shipped.

A decade later, a recent Epic go-live at Penn Medicine's Doylestown Hospital — supported via Penn's SAP LMS (Knowledge Link) — surfaced the coordination problems that scheduling tool never had to solve at scale: cross-department readiness, role-scoped visibility, and exception triage across facilities. Those needs are what pushed the idea from that single tool into a configurable platform. Same instinct as 2015 — fully realized a decade later, expanded by what a fresh go-live actually demanded.

One Engine, Two Live Operations

The adaptability claim is demonstrated, not asserted — the demo runs two genuinely different operations from the same engine, and you can walk between them:

  • Epic Go-Live Readiness — the flagship: an executive command center counting down to go-live, a launch gate with owned and signed-off criteria, department and facility scorecards, a training matrix, and a governed exception queue worked to zero.
  • Annual Compliance Cycle — same engine, different shape: the campaign counts down to a deadline, tracks per-assignee completion, and runs the compliance signature rule — an assignee past a configured time-in-course threshold without completing is flagged stuck and escalated into the same queue. A stuck learner is a rescue; a never-started one is a nudge. The system knows the difference.
  • Scenario packs are the front door — each pack names its demo campaign and opens it live; packs still on the roadmap say so honestly instead of faking a door.

The Campaign Is the Unit of Configuration

  • Switching campaigns changes the home's shape, not just its numbers — an executive command center, an analyst's import-and-reconciliation home, a team follow-up home, a compliance completion watch: each campaign declares its own.
  • Terminology follows the template — one campaign reaches go-live, another a cutover, another a deadline, across every scoped screen.
  • Teams are the activation model — the go-live campaign runs six owning teams, each with its own focus, lead, criteria, and live blocker rollup; the compliance cycle runs one. The platform bends to each campaign's real structure.
  • Creating a campaign instantiates its template — scoring thresholds, starter requirements, default reports, and the launch-gate sections all seed from the chosen template, and the new campaign opens in that template's home layout. Nothing arrives pre-approved.

Governed by Design

  • Deterministic, explainable readiness scoring — adjust a weight on the scoring screen and the number recomputes live from the same formula the dashboard uses, with every driver shown. Go/no-go is never a black box.
  • Import → reconcile → resolve — paste a messy roster CSV: sensitive columns are masked, bad rows flagged, and applying it creates the valid learners and raises reconciliation exceptions — the campaign's risk count moves live on every surface.
  • Approve before write-back — nothing reaches a system of record without a reviewer approving the staged payload. The AI layer is suggestion-only: it cites the exact records it used, carries a confidence, and cannot mutate anything.
  • RBAC read-scope, actually enforced — switching persona changes what you can reach, not just what you see; out-of-scope deep links fall back instead of rendering admin surfaces.
  • Provisioning is governed too — invite people with a named role and explicit campaign access, see the exact grant before it exists, and queue it for acceptance; invites are staged, revocable, and nothing is ever silently created.

Session logistics carry the 2015 lineage forward under the same governance: schedule creation and instructor assignment are deterministic — constraint rules, not model guesswork — with agentic assistance only where it earns its place, and always behind human review. Approved schedules reach the system of record by governed write-back, export-for-import, or manual entry where that's the operational reality. The demo monitors the result: capacity, conflicts, and trainer coverage.

The Platform Pattern

Campaign Template Epic Go-Live (live) · Compliance Cycle (live) Acquisition Onboarding (planning) · Enablement (concept) ↓ Campaign the unit of configuration — terminology, scoring profile, launch-gate criteria, home layout, teams ↓ Command Layer RBAC read-scope · deterministic readiness scoring exception queue · escalation timeline · stuck detection ↓ Governance approve-before-write-back · suggestion-only AI a human reviews every mutation path ↓ Data Layer import/validation pipeline · derived KPIs (figures computed from records, never hand-typed) + an integration layer to the systems of record

Built Like a Product

The demo ships behind a real gate suite: 44 unit tests including structural invariants (every displayed aggregate must derive from the records — a hand-typed count fails the build; every stuck assignee must have an open exception; a scenario pack must open a campaign running its own template), 21 end-to-end journeys (template instantiation, pack navigation, per-campaign shapes, RBAC deep-link guards), and white-glove, mobile, and viewport sweeps across 19 screen sizes. The phone is a deliberately scoped companion: monitoring and triage travel — the queue, readiness, alerts — while approvals, imports, scoring, and configuration render a purposeful desk-only state on the phone rather than handing thumb-sized authority over systems of record. Access is scoped by surface the same way it is scoped by role.

Access: the live demo is a frontend-only showcase on mock data — the cockpit, not the engine. The production data layer, integrations, and orchestration logic are private and available to discuss in a working session.
← Grant Tracker All projects →