Operation Daybreak · Skill Map

What got built — in plain English

Daybreak is the daily ops brief for SGA's 260 dental practices. This page shows everything that runs each morning to produce it — what each piece is called, what it does, what data it touches, and how it all fits together. Architecture borrowed from the Johns Hopkins Capacity Command Center.

8 total steps in the chain 4 new skill blocks (today) 12 tiles in the catalog 260 practices in scope 5:30 AM CT daily kickoff
Phase 1 — Gather the data Phase 2 — Skill blocks (the new stuff) Phase 3 — Ship to the live site ← Back to Daybreak Brief ROD Heatmap →

The big picture in one paragraph

Every morning at 5:30 Central Time, a Windows scheduled task runs the chain. It pulls fresh practice data from Power BI, runs a rules engine that flags any practice crossing a threshold on any of 8 operational dimensions, scores every practice with a single composite "pulse" number from 0–100, then hands those results to four new specialist skills: one writes every alert into a permanent logbook, one ranks the top 10 patients per practice most likely to schedule treatment if called, one backtests whether yesterday's alerts actually moved the needle, and one paints a visual heatmap of all 260 practices grouped by Regional Ops Director. An Opus 4.7 AI then writes the daily narrative. Everything gets deployed to the live dashboard by 6:30 AM.

The whole thing is built as building blocks. Each skill lives in its own folder, runs on its own from the command line, and reads/writes through clearly-named files. Re-order them, swap one out, or add a new one by editing a single manifest file. Nothing is tangled.

Pattern source: Johns Hopkins built a 5,200 sq ft Capacity Command Center in 2016 with 24 people watching 22 wall screens displaying 13 real-time "Tiles." Each Tile is a focused operational question with six explicit properties: owner, data source, refresh cadence, threshold, response protocol, outcome metric. We translated that into 12 Tiles for dental DSO operations where 260 office managers replace the 24 hospital dispatchers and the AI replaces the co-located analyst.
1
Gather the data 5:30 AM — 6:00 AM
Pull fresh numbers from Power BI, then apply the rules. By the end of this phase we know which practices crossed a line on which dimension, by how much, and what the composite "pulse" score is for every practice on the network.
Step 1
Fetch Snapshot
Pull this morning's numbers out of Power BI into a single file. Think: the morning newspaper run — one trip, gets everything we need for the day.
What data it touches
  • Power BI dataset (production, visits, days open)
  • Practice metadata (location, region, type)
  • Today's confirmed-appointment counts
What it produces
  • One file: data/snapshot-{date}.json
  • Used by every other step downstream
Step 2
Rules Engine
Apply 8 rules ("gates") to every practice. Each rule decides if today's number crosses a red line. Also computes a single 0–100 pulse score per practice and for the whole network.
What it uses
  • This morning's snapshot
  • 8 gate definitions in framework/gates/*.yaml
  • 12-tile catalog in framework/tiles/catalog.yaml
  • Yesterday's results (for streak counting)
What it produces
  • One file per practice: runs/{date}/gates/<practice>.json
  • Top-of-list of alerts: active-alerts.json
  • Network pulse scores: pulse.json
2
Skill blocks 6:00 AM — 6:25 AM · the new stuff
Each block is a self-contained "skill." Lives in its own folder, runs on its own, has a clear job. Run them in this order each morning, but each one is editable in isolation — tomorrow you can swap the propensity model for a smarter one and nothing else has to change.
Step 3a · Skill #1
Action Ledger
Writes every flagged alert into a permanent logbook. Later, when the office manager dismisses it, acts on it, or the number naturally moves back to normal, that gets logged too. Why: tomorrow we can answer "did this alert actually matter?"
What it uses
  • Per-practice gate results from Step 2
  • Tile catalog (to map each alert to a tile ID)
What it produces
  • Single growing logbook: skills/action-ledger/data/ledger.jsonl
  • Today: 102 new alerts logged
Step 3b · Skill #2
Propensity Ranker
For every practice, picks the top 10 unscheduled treatment plans most likely to actually schedule if someone calls. Each row tells the office manager who to call, what to say, and through which channel (text vs phone).
What it uses
  • Power BI numbers (validated production measures)
  • Patient context (synthesized for now, real PMS data when wired)
  • Heuristic scoring weights in heuristic-weights.json
What it produces
  • Top 10 list per practice: runs/{date}/propensity-rankings.json
  • Also writes each recommendation into the ledger
  • Today's top hit: $6,386 expected value at Biltmore Dental
Step 3c · Skill #3
Digital Twin
Looks back at the ledger and answers: "When this tile fired in the past, did acting on it actually move the metric?" If yes → marks the tile promote. If 30+ firings show no movement → marks it retire. Keeps us from shipping tiles that don't pay.
What it uses
  • The full action ledger (all past alerts + outcomes)
  • Tile catalog (to know each tile's "success metric")
What it produces
  • Tile-by-tile lift estimate: runs/{date}/digital-twin.json
  • Each tile gets a confidence interval + a "promote / retire" badge
  • Today's biggest tile by annual lift: Staffing Coverage at $961k
Step 3d
Action Briefing (existing)
Claude Opus 4.7 reads everything above and writes the day's narrative — the headline, the top 3 things to do today, the things to watch over the next 48 hours, and how yesterday's brief closed out.
What it uses
  • Active alerts + per-practice gates
  • Propensity rankings (top-EV patients)
  • Digital-twin lift annotations
What it produces
  • The narrative JSON: runs/{date}/briefing.json
  • This is what powers the "Action Briefing" tab on the live site
Step 3e · Skill #4
ROD Heatmap
Paints a 260-cell grid — one cell per practice, grouped by Regional Ops Director. Each cell is color-coded by its pulse score so an ROD can spot in 2 seconds where to look first. Worst RODs sorted to the top.
What it uses
  • Pulse scores from Step 2
  • Per-practice gate results (for the "top flipped tile" badge)
  • Action ledger (for the open-recommendations count)
What it produces
  • A self-contained page: site-v3/rod-heatmap/index.html
  • Same data as JSON for downstream tools
  • Embedded in the main Daybreak site under the "ROD Heatmap" tab
3
Ship to the live site 6:30 AM
Mirror all the run outputs into the website folder and push to Cloudflare Pages. By 6:30 AM the live dashboard has today's brief.
Step 4
Deploy
Copy runs/{date} into the site folder, run wrangler pages deploy, refresh the live URL.
What it uses
  • Everything Phase 1 + 2 produced today
  • Cloudflare Pages credentials
What it produces

Data flow at a glance

Everything flows left → right. Each box on the left feeds the engine in the middle; the engine produces the artifacts on the right; the live site reads from the artifacts.

Inputs

Power BI datasetNet Production, Visits, Days Open, …
Practice registry260 practices, regions, RODs
8 gate definitionsYAML rules per dimension
12-tile catalogHopkins-style tile contract
Patient PMS dataSynth today → real when wired
Action ledger (history)Past alerts + outcomes

Engine & Skills

Rules EngineEvaluate gates + pulse
Action LedgerAppend today's alerts
Propensity RankerScore & rank patients
Digital TwinBacktest tile lift
Action Briefing (Opus 4.7)Write the narrative
ROD HeatmapPaint the 260-cell grid

Outputs & Live Site Tabs

Per-practice gate resultsruns/{date}/gates/*.json
Active alerts rankingactive-alerts.json → Alerts tab
Pulse hero scorepulse.json → top of every tab
Patient worklistpropensity-rankings.json → Propensity tab
Tile performancedigital-twin.json → Performance tab
Daily narrativebriefing.json → Briefing tab
ROD landing gridrod-heatmap/index.html → Heatmap tab

Why "skill blocks" and not one big program

Every skill is a folder with three things: a description (SKILL.md), a script you can run by itself, and clearly-named inputs and outputs. The chain manifest (skills/chain.yaml) lists the order they run in. That separation gives us four practical wins:

1. Edit one without touching the others. Want to tune how the propensity model picks patients? Edit one JSON file with the scoring weights. No other code changes.

2. Re-order or skip them by editing the manifest. Move the heatmap before the briefing? Swap two YAML blocks. Comment out a skill to test the chain without it.

3. Add new skills the same way. Want a "no-show predictor" tile? Build skills/no-show-predictor/, append a step block to the manifest. Plug-in pattern.

4. Debug single steps. If propensity output looks wrong, re-run just that one skill: daybreak-chain.ps1 -OnlyStep propensity. No need to re-fetch data or re-run the engine.

What today's run produced

Network pulse score (median)58.5 · orange (act today)
Practices in each pulse band3 green · 0 yellow · 2 orange · 3 red
Active alerts (3+ gates flipped)3 practices · $99,025 total daily $ at risk
Top alertBiltmore Dental · 6 gates · $43,709/day
Propensity worklist (T06 flagship)8 practices · 80 patients ranked · top hit $6,386 EV
Digital twin lift estimates4 active tiles · biggest annual lift $961k (Staffing)
Ledger entries written today102 recommendations