Three parts.
One through-line.

The brief had three deliverables, but treating them as three disconnected exercises misses the point. The same business reality runs through all of them, so I let Part 1's analysis define Part 2's dashboard and Part 3's flag logic. The convergence at the end (two independent methods landing on the same 32 members) is the proof that the through-line is real, not imposed.

The messy data is the test. A clean-looking number built on silently dropped rows or zero-filled NULLs is the failure mode, so I treated cleaning as a first-class, independently re-derived deliverable. Every downstream number then traces back to a defensible call — and these two judgments are exactly what make the ED denominator 207 (not 210) and the cost averages honest on the next slide.

Silently dropping rows or zero-filling NULLs produces a clean-looking number you can't defend. Because the dataset is deliberately seeded and scored, the messy data is the test, so the right move is to surface each call in the SQL comments and let a reviewer audit it. A number I can defend beats a tidier number I can't.

I built the single-axis engagement tier they asked for first — then the data killed it: cost is flat across tiers (1.2×), so engagement volume doesn't predict cost. So I kept engagement as the reachability axis and re-tiered on the outcome: a Cost-to-Serve regression that scores any member in dollars a clinician can interrogate. The move is the point — answer the literal question, prove it's insufficient, then build the one worth acting on.

Caveats stated up front, because the method is the deliverable: R²≈0.22 on synthetic data (real HCC/ACG models reach 0.4–0.5+), and same-period ED is a concurrent feature, so production would use trailing-period features (the cleaner v2 treats risk as the leakage-free stakes axis and ED as the action trigger, which is exactly what Part 3 keys on).

One honesty note worth saying out loud: Cost-to-Serve is only the avoidable-cost leg of plan value. The HEDIS/Star quality leg can’t be built on synthetic data, it needs the plan’s real gaps-in-care, ADT, and refill feeds. I name that gap rather than fake it.

The Head of Product has one screen and 30 seconds, so the scarce resource is attention, not data. A metric earns a tile only if it sits on the path to a plan's scorecard and implies an action. Outcomes over output: I'd rather show three numbers that drive a decision than twelve that fill a grid.

Sensitivity vs. alert fatigue: hero rates move slowly, so a >5pt weekly drop is a real regression, not noise; but the ED money-metric flags amber on any rise, because under-reacting there is the expensive mistake. A data-freshness tile always sits in the corner, a stale dashboard is worse than none.

Two windows on purpose: the "engaged" hero uses 30 days (standard active window); the at-risk worklist uses a stricter 60-day "gone-dark" window. Different jobs, both labeled. And though the brief said no build was required, I shipped a self-contained HTML dashboard too, because the role's bias is to build, not just spec.

A deterministic orchestrator, not an autonomous loop: five fixed contracts mean every step logs, tests, and evaluates in isolation. "What to do next" was never the hard part here, so the loop's freedom would add risk without value.

No single signal is enough: engagement alone is flat on cost, risk alone over-flags members who are already engaged. The actionable list is the intersection of clinical risk, behavioral disengagement, and acute utilization. Percentile thresholds make it reproducible and let a medical director argue p80/p95 against a clear reference instead of a hand-picked number.

LLMs are unreliable at exact equality. The real bug, caught in testing: a note said "32 days since the claim" using the engagement field. An LLM critic asked "is the number present?" passes it. The regex guard catches it because 32 ≠ days_since_last_acute_claim. Same split as a reconciliation agent I shipped: LLM reasons, exact matching does the math, ~70% → 99.2%.

Then the eval earned its keep: QC caught two real fact-fidelity bugs the critic had been passing, a day-count on the wrong field and a "no claims" overclaim on history-only members. Both are now blocked by deterministic guards. The lesson: LLM fact-fidelity is long-tail, deterministic guards cover the known classes, an eval harness plus mandatory human review cover the unknown ones.

Silent degradation, or an agent autonomously contacting a fragile member, is the most expensive failure mode. So the footer is re-appended programmatically if dropped, a critic error becomes critic_unavailable instead of a crash or silent pass, and dry-run is the default (zero network, zero cost). The footer is a reminder; the queue is the gate. "The agent decided to contact a member" is structurally impossible. I also mirrored the whole pipeline as an importable n8n workflow (19 nodes, with a Slack send-and-wait-for-approval node, authored not run, Python is the tested source of truth) — so the same human-approval gate is expressible as a no-code workflow a non-engineer can run, not just Python. In production it runs in a BAA-covered environment on minimum-necessary fields only — no name, address, or diagnosis text.

This is the payoff of the through-line. I didn't tune one method to match the other; they were built separately, a regression in SQL and behavioral rules in Python, and they converge because they're both reading a real pattern in the data. Strong agreement is evidence the cohort is right; the 8-member disagreement is the honest edge where the two definitions differ, which is itself a useful thing to review.

The demo proves the judgment split; production needs the data and execution scaffolding so repeated runs don't re-alert the standing cohort or add load to the operational database.

The real bottleneck isn't compute. It's ground truth (no labeled "right action"), per-member context, and keeping a human in the loop affordably as volume grows. The roadmap is ordered by that list.