The shortlist of probable next features, ranked by WSJF (Weighted Shortest Job First). This is the gate between a raw idea (ideas.md, loose brainstorm) and a specced feature (backlog/). An entry earns a place here once it passes the threshold "yes, that's a probable feature worth scoring" — not every brainstorm, just the ones real enough to analyze. The board reads this file and renders the top-ranked entries as the "Next up" panel (scripts/build_board.py→docs/board.html), so upcoming work stays in view while you work the current phase. Re-rank freely during idea development; ranking is cheap and the order is advisory, not a commitment — something new can always jump the queue.
v8 CLOSED (2026-07-04, tag v8.0 — the last integer version): the demo, made real — the Review Cockpit (8-1) + benefit depth (8-2) + clinical persona (8-3) + board-in-Evidence (8-4), 4/4 ~19 pts. Closed with two workflow-contract migrations (three-part version scheme + build-report-in-doc). See the v8→0.9 briefing. 0.9 committed (2026-07-04 — the FIRST three-part-scheme version): version numbers are nowinitiative.version.feature(e.g.0.9.1). Initiative 0 = "everything so far" (build the platform + make it demoable — v1 through the whole 0.x arc); the digit only flips to 1.0 at the next deliberate pivot to a genuinely new direction (defined when you reach it, not on a schedule). 0.9's theme: "the board replaces VS Code" (a theme within the 0.x arc). 0.9.1 board contract catch-up (M — nativeI.V.Fparsing, fixing the LIVErelease/0.9blindness + reading reports from feature docs) + 0.9.2 git-status view (M — branches/worktrees/pending changes; the #1 VS-Code replacement) + 0.9.3 review queue (M — the assistant puts docs in front of Dan to read in-board; the keystone). ~15 pts, allbuild_board.py(no-dbt, fast-review), all parallelizable. A version about the board, built + reviewed THROUGH the board (peak dogfood).
_The live, forward-looking funnel — a sorted INDEX of links + WSJF, descending. Every candidate is a FILE (roadmap-as-files, 0.10.1): the Candidate cell is a markdown link to the candidate's single home — candidates/feature_*.md before it's specced, backlog/ / completed/ after it graduates. The fat prose lives in that file now; the Notes cell is just a one-line hook. Click a row (or its board card) → its file opens in the preview pane. Only uncommitted/in-flight candidates live here; delivered features move to the Delivered ledger at the bottom (full history in completed/ + briefings/ + decision_log.md). Scores are sticky — set at entry, re-scored only at a version seam or on request; cleanup reorganizes + prunes, it does NOT re-score. The board's Next-up panel re-sorts by WSJF at render time._
| Candidate | V | TC | RR | Size | WSJF | Ver | Notes |
|---|---|---|---|---|---|---|---|
Review Cockpit — two-pane feature board [demo][meta][tooling][from:v7-rail-playtest] | 6 | 3 | 4 | 8 | 1.6 | v8 ✅ | v8 8-1 — master-detail cockpit; read any spec/wireframe/diagram without the file system. |
Persona: clinical / provider (exam-room) screen [demo][persona][from:reserve] | 6 | 2 | 3 | 2 | 5.5 | v8 ✅ | v8 8-3 — 2nd persona; the exam-room reskin (wireframe-gate's first use). |
Board-in-Evidence — embed the cockpit in the deployed dashboard [demo][tooling][depends:8-1] | 5 | 2 | 2 | 2 | 4.5 | v8 ✅ | v8 8-4 — the interactive cockpit now ships on the public Vercel URL. |
Board contract catch-up — native I.V.F parsing + build-report-in-doc [meta][board][init:1] | 6 | 4 | 4 | 5 | 2.8 | 0.9 ✅ | 0.9.1 — native initiative.version.feature parsing + reports read from the feature doc. |
Git-status view — branches, worktrees, pending changes [meta][board][init:1] | 6 | 3 | 4 | 5 | 2.6 | 0.9 ✅ | 0.9.2 — the git state Dan opens VS Code for; overview-only, the #1 VS-Code reflex. |
Review queue — flag a doc in-session, read it in the board [meta][board][init:1] | 6 | 3 | 3 | 5 | 2.4 | 0.9 ✅ | 0.9.3 — the assistant puts docs in front of Dan in the detail pane; stop hunting for files. |
Roadmap-as-files — every candidate a file, everything clickable-to-preview [meta][board][0.x] | 6 | 4 | 4 | 8 | 1.8 | 0.10 ✅ | 0.10.1 keystone — every candidate a file; roadmap = index of links + WSJF; every card clickable → preview. |
Detail-pane extensions — every doc type loadable + dynamic-surface navigation [meta][board][0.x][depends:0.10.1] | 6 | 3 | 3 | 5 | 2.4 | 0.11 | ABSORBED into 0.11 (reading-first layout) — one-click-to-anything becomes the new layout's organizing principle; resolution logic transfers, render sites redesigned. Brief: reading_first_layout. |
Snowflake parity match-contract [platform][from:snowflake-port] | 5 | 1 | 4 | 5 | 2.0 | — | T0/T1/T2 parity comparison of duckdb_ref. vs snowflake_native. — only if parity proof is wanted. |
Premium billing — rule + models [claims] | 5 | 1 | 4 | 5 | 2.0 | — | The other classic payer lifecycle + OP4 collision-prone ID; a demo-reserve depth candidate. |
Clinical breadth + small audit fixes [audit-finding:S2,S6,S7] | 4 | 1 | 3 | 5 | 1.6 | — | The smaller structural clinical-audit findings (S2/S6/S7) — slice per demand. |
Benefit-content buildout — copays/deductibles/coverage rules per plan+network [benefits][depth][v8-target] | 7 | 1 | 4 | 8 | 1.5 | v8 ✅ | v8 8-2 — cost-sharing by segment on the existing benefit sat; the Tier-2 depth. |
Capitation + provider agreements tranche [facets-depth] | 4 | 1 | 2 | 5 | 1.4 | — | First slice of the payer_source_expansion list; deferred — add FACETS depth only on demand. |
Subgroup hierarchy + class rating [facets-depth] | 3 | 1 | 2 | 5 | 1.2 | — | Same deferred tranche; lowest value until a use case demands it. |
Network zip/in-area rules + benefit rule engine [facets-depth][umbrella] | 3 | 1 | 2 | 8 | 0.8 | — | The heaviest FACETS machinery; an umbrella — scores low by design, would need slicing. |
WSJF = Cost of Delay ÷ Job Size, where Cost of Delay = Value + Time-Criticality + Risk-reduction/Opportunity-enablement. Higher = do sooner.
| Term | What it asks (for this project) | Scale |
|---|---|---|
| Value (V) | How much does this advance the platform or its work-transfer purpose (the method proving ground for BCI-shaped work — transferable capability is real value here)? | 1–10 |
| Time-Criticality (TC) | Does value decay if delayed? Does something downstream wait on it? (Mostly low for a solo testbed — few hard deadlines.) | 1–10 |
| Risk/Enablement (RR) | Does it reduce a risk, prove a pattern, or unblock later work (e.g. the generator unblocks every data-hungry feature)? | 1–10 |
| Job Size (Size) | Effort. Reuses est_autonomy: S = 2, M = 5, L = 8. | 2/5/8 |
WSJF = (V + TC + RR) / Size. Scores are recommended by /score-idea (an agent researches the idea + proposes the score with per-term reasoning), so this stays low-friction — you react to a recommendation instead of scoring by hand. Sanity-check the ranking against gut; where they disagree is where the fluency gets built. Scores are sticky — set once at entry, re-ranked only on request or at the version seam (the ranking is advisory, so staleness is cheap).
[demo] — the standing pool, stocked by FUNNEL STAGEWhy this exists. HDP may be demoed to BCI's Director of AI & Innovation (the AI-orchestrated engineering workflow — see the demo brief in../docs/decision_log.md). The demo walks the funnel — it takes an idea → grounds it → readies it → hands it to an agent → verifies → ships. So the reserve must stock features at the funnel stages the demo demonstrates, not just by audience tier. A living reserve, kept topped up like the board itself. The rule (restructured 2026-07-04, Dan — stock by STAGE): keep, at all times, in EACH of two buckets: - ≥2 READY TO GROUND — ideas/discovery docs rich enough to ground live on camera (verify the sources/data exist, resolve the shape). Demos the "idea → grounded feature" move — the front of the funnel. - ≥2 READY TO HAND OFF —backlog/specs, agent-ready, that can be built live by an agent during the demo. Demos the "ready spec → built + verified + shipped" move — the back of the funnel. A single demo pulls one from each bucket: ground one idea (front), hand off one spec (back) — so the room sees the whole pipeline move, not just a build. The relatable bar (what earns a[demo]flag, Dan 2026-07-04): prefer features that (a) add a visible dashboard payoff (a screen/stat the room SEES appear), (b) map to a recognizable workplace moment (a rep on a call, a check-in desk, a nurse reviewing history — the relatability hook), and (c) carry a real number to VERIFY live (a count/ reconciliation you check against the vault on camera — the rigor beat). The best demo features hit all three; a depth feature may lean (c), a persona lean (a)+(b). The convention: demo-candidate rows carry a[demo]tag + a stage marker —[demo:ground](ready-to-ground) or[demo:handoff](ready-to-hand-off). Pulling one into a real version = mark itvN, then backfill its bucket at that version's close. A[demo:ground]feature that gets specced GRADUATES to[demo:handoff](it moved down the funnel) — backfill a fresh idea behind it. If a reserve feature becomes platform- load-bearing, promote it and replace it. Deliberately optional slices, tier-tagged[visible]/[depth]so a demo still covers the audience mix.
Current reserve (by funnel stage):
| Stage | Feature | Tier | Relatable hook (a/b/c) | State |
|---|---|---|---|---|
| ~~Ready to hand off~~ | ~~Persona: clinical / provider screen~~ | [visible] | (a)(b) — "the nurse in the exam room" | PULLED into v8 (8-3) 2026-07-04 — specced with a wireframe. Backfill the hand-off bucket. |
| Ready to hand off | Persona: front-desk / receptionist screen (eligibility + copay + PCP reskin) | [visible] | (a)(b) — "at check-in" | grounded; cheap reskin like 7-2 |
| Ready to ground | COB dashboard stat + ma_s_member_cob navigation (vault→consumption) | [depth] | (c) — count members w/ other coverage, verify vs the ma_sat | ma_sat built (6-1), unshown — groundable live |
| Ready to ground | person_events coverage band (temporal-overlap join vs the eligibility spine) | [depth] | (c) — the temporal-overlap join, verifiable | grounded concept; needs the discovery pass on camera |
| Ready to ground | Premium billing — rule + models + generator (net-new payer lifecycle) | [depth] | (c) — "builds real DV2.0 from nothing" | the deepest/riskiest; strongest Tier-2 depth proof |
As of 2026-07-04: 2 ready-to-hand-off + 3 ready-to-ground → both buckets healthy (≥2 each). Gap to watch: the two hand-off personas are grounded but not yet specced to backlog/ — to be truly "ready to hand off" one should get a spec cut (like 7-2 did) so it's genuinely agent-ready on demo day. Cut one persona spec before the first demo. Note the relatable-bar skew: the hand-off bucket is persona-heavy (visible), the ground bucket is depth-heavy — good, because grounding-live suits a depth feature (there's real analysis to show) and handing-off-live suits a cheap visible reskin (low risk, fast payoff). Topping up both buckets is close-ritual step 8.
_Shipped features — one line each, newest version first. The DURABLE record is completed/feature_*.md (build history), briefings/vN_to_vN+1.md (the retros), and docs/decision_log.md (the why). This ledger is just the at-a-glance trace; it is NOT the live funnel. WSJF shown is the score at delivery._
| Ver | WSJF | Feature | Where the history lives |
|---|---|---|---|
| v7 | 6.0 | Persona: member-call (CSR) screen | completed/feature_persona_member_call.md |
| v7 | 2.8 | Coverage span realism (segment-typed spans) | completed/feature_coverage_span_realism.md |
| v7 | 2.0 | Board Demo Rail (the board IS the demo) | completed/feature_board_demo_rail.md |
| v6 | 2.0 | Member satellite trio (COB/disability/exchange) | completed/feature_member_satellite_trio.md |
| v6 | 1.8 | person_360 deepening (person_events timeline) | completed/feature_person_360_deepening.md |
| v5 | 2.6 | Fix S8 — in-network determination altitude inversion | completed/feature_in_network_gold_relocation.md |
| v5 | 2.4 | Single-source provider resolution (S9) | completed/feature_single_source_provider_resolution.md |
| v4 | 5.0 | Public Vercel deploy (the live URL) | completed/feature_vercel_deploy.md |
| v4 | 3.4 | Snowflake dual-target port (green build on a trial) | completed/feature_snowflake_port.md |
| v4 | 3.0 | Provider disambiguator (city on cs_provider_same_as) | completed/feature_provider_disambiguator.md |
| v3 | 2.8 | Distill the payer layer into specs/ | completed/feature_payer_distillation.md |
| v3 | 2.6 | Generator realism pass (date-align + span caps) | completed/feature_generator_realism.md |
| v3 | 2.0 | Finish the #30 gold rewire (+ S2 s_encounter) | completed/feature_gold_rewire.md |
| v2 | 3.2 | Claims business rules (lifecycle + rules-vs-SQL) | completed/feature_claims_business_rules.md |
| v2 | 2.6 | Evidence dashboard buildout | completed/feature_evidence_dashboard.md |
| v2 | 2.5 | Clinical audit (52 models, specs/ populated) | completed/feature_clinical_audit.md |
| v2 | 2.4 | Synthetic data generator (the unified factory) | completed/feature_synthetic_data_generator.md |
The director's view — where the project is, at a glance. Hybrid document: the prose and diagrams are authored by hand (refreshed at version seams); the marked blocks are GENERATED byscripts/build_board.pywhenever a feature'sstatus:changes — it refreshes only the GENERATED blocks and leaves the authored sections alone. Do not hand-edit inside the GENERATED markers.
HDP is a payer/clinical analytical data platform on synthetic, PHI-free data — Dan's learning vehicle for AI-leveraged workflows and the methodology testbed for the BCI migration, built solo/AI-leveraged as a DV2.0 + Kimball estate on a DuckDB + dbt + Evidence stack. Where it is now: the platform is live and public (a Vercel dashboard since v4), Snowflake-portable (a green dual-target build), and its own build board has become a Review Cockpit — the current 0.x arc is "the board replaces VS Code." In flight: 0.10 (the roadmap-as-files keystone — every candidate is a file, the roadmap is a sorted index of links + WSJF, and every board card is clickable → opens its file in the preview pane). Scroll down for the version-by-version detail; the links below are the "where did I put everything" map.
Deployed / external
https://healthcare-data-platform.vercel.app/ (the v4 ship — Evidence static build; deployed 2026-07-03 from main @ v4.0)
vercel.com dashboard → the healthcare-data-platform project (builds, logs, domains)
once wired to the deploy)
snowflake_native.* schemas; the v4 port target — see completed/feature_snowflake_port.md for the connection details)
danbrickey/healthcare-data-platformIn-repo navigation
docs/board.html (open in a browser; Kanban /Roadmap / Status / Bugs / Decisions / Cockpit / Git / Review tabs)
implementation/roadmap.md (WSJF-ranked candidates — now an index of links; /score-idea recommends scores)
implementation/ (ideas → roadmap →candidates → discovery → backlog → completed)
specs/ (by medallion layer)LEARNING.md (the true apex:AI workflows first; learning wins ties)
architecture/ (winning statement →standards)
business-rules/ (platform-agnosticsemantics)
implementation/briefings/0_9_to_0_10.md
cd evidence && npx evidence devA payer/clinical analytical data platform on synthetic, PHI-free data — the methodology testbed where the gazetteer-matured solo/AI-leveraged, spec-driven workflow runs against work-shaped data (claims, membership, eligibility, providers). DV2.0 integration + Kimball consumption on a 4-layer medallion (bronze → silver raw vault → gold business vault/dimensional → platinum info marts), DuckDB + dbt + automate_dv + Evidence.
v1 (the re-foundation) shipped the four-folder structure + five payer features — "both sides of the patient experience" (the same resolved person's clinical encounter beside the payer claim).
v2 shipped (4/4, 26 pts) — the point-ceiling experiment: the clinical audit, the claims lifecycle rule + validation pass, the Evidence payer dashboard, and the synthetic generator. It proved version size can push ~2× the cadence when reviews stay bounded.
v3 is CLOSED (3/3, ~18 pts) — the lighter version shipped cleaner than v2. The deliberate counterweight to v2's heavy run: one review-heavy feature + two light, sequenced solo-then-parallel. Delivered: the gold rewire (closed the audit's S1+S2 — the clinical facts now read the vault, not staging; dim_condition/dim_medication + s_encounter built), the payer distillation (the rebuild-from truth is finally platform-complete — 120/120 models in specs/), and the generator realism pass (the dashboard's 85%-unknown reframed into a story-shaped split). Findings: S1/S2 resolved; S8 (an in-network altitude inversion) and the provider-MDM ambiguity surfaced and routed. The 3-3 escalation became a feature (the "unidentifiable-provider" bucket now tells the MDM-discipline story). See the v3→v4 briefing for the retro (incl. the refined model-tier finding).
v4 is CLOSED (3/3, ~12 pts) — "Take it out the door": the platform is now provable on real infrastructure, at a public URL. The lightest version yet. Delivered: the provider disambiguator (city-key drove determined claims 24.9% → 54.6%, so the network story leads with in/out; closed S9's rule-drift finding), the Snowflake dual-target port (the milestone — the full 120-model estate built 761/761 green on a live trial, byte-identical models, zero forks, row-count parity confirmed; experiment[1] of the migration-test thesis and the most BCI-transferable proof on the board), and the public Vercel deploy (the committed-cache build path → the dashboard live + interactive at https://healthcare-data-platform.vercel.app/). Findings: the launch-location bug is CLOSED (4-recurrence harness issue, fixed at the source); a stale-seed cache bug caught at review (root cause: seeding a worktree from the stale main-tree DB — logged as a standing rule). See the v4→v5 briefing for the retro.
v5 is CLOSED (2/2, ~7 pts) — "Keep it honest": paid down the layering debt the audits found. The smallest version yet, deliberately. Delivered: S8 (5-1 — the in-network determination relocated from platinum to a gold cs_claim_network_status, fixing the medallion inversion; byte-identical output, 0-diff on all 3 consumers) + S9 (5-2 — the provider match rule single-sourced into match_rules.py with a drift guard the generator runs at startup, so it refuses to run on drift; byte-identical regen). Findings: the before/after data diff is now the standing check for pure-refactor work; a drift guard must be adversarially tested (broke it on purpose at review); the roadmap Ver column drift is fixed + baked into the close ritual. See the v5→v6 briefing.
v6 is CLOSED (2/2, ~10 pts) — "Both sides, deeper": capability/breadth on the honest platform. Delivered: the member satellite trio (6-1 — disability + exchange plain sats + COB ma_sat on h_member, with an additive generator increment; the RNG-cascade risk solved by construction via independent per-family seeds) + person_360 deepening (6-2 — the person_events dated-events mart + Evidence timeline; closed the 2-4 anti-pattern by putting the resolution join in the mart, not the app). HDP's first true parallel-build-agents run — both features built concurrently in separate worktrees, merged clean. See the v6→v7 briefing.
v7 is CLOSED (3/3, ~15 pts) — "Demoable dashboards": the demo, shipped. v7 built HDP's demo capability by being a worked example of the demo it enables. Delivered: 7-1 Board Demo Rail (the demo folded INTO the board — a right-edge talk rail + present mode + 2 structural diagrams + 6 live panels reading real board data, so the demo can't drift; the rail is a feature the workflow shipped, proving the method by being a product of it) + 7-2 persona member-call (CSR) screen (a zero-new-model reskin of person_360 + person_events into a "rep on the phone" view — the visible-payoff headliner; fictional "Anchor Health Cooperative") + 7-3 coverage span realism (segment-typed enrollment spans — surfaced by playing 7-2, which showed absurd 200+ member-months; fixed to avg 302→63mo, Medicare age-anchored). The artifact-as-muse loop fired twice: playing the persona screen surfaced 7-3, and using the rail surfaced its own v8 evolution. The demo reserve was restructured by funnel stage (ground + hand-off buckets). See the v7→v8 briefing.
v8 is CLOSED (4/4, ~19 pts) — "The demo, made real": the board becomes a review cockpit + two workflow upgrades. Delivered: 8-1 Review Cockpit (the feature board is now a two-pane master-detail cockpit — click a card, read its spec/wireframe/diagram in a sticky detail pane; 3 funnel-derived lanes; pop-out talk-track; the scroll-jump fixed; read any spec without the file system. Built to a LOCKED Claude Design handoff — the design-tool→build pipeline's first use) + 8-2 benefit-content buildout (cost-sharing by segment on the existing benefit sat — the Tier-2 depth) + 8-3 clinical persona (the exam-room reskin — the wireframe-gate's first use) + 8-4 board-in-Evidence (the interactive cockpit now ships on the public Vercel URL). This close carried two workflow-contract migrations: the two-level version scheme (<initiative>.<version> — the next version is 0.9; history stays v1–v8; initiative 1 = "the board replaces VS Code") and build-report-in-doc (the report moves into the feature doc, the JSON dropped). Dogfooding the cockpit surfaced the v3 "replace VS Code" initiative. See the v8→0.9 briefing.
0.9 is CLOSED (3/3, ~15 pts) — the FIRST three-part-scheme version; "the board replaces VS Code" begins. The first slice of the 0.x arc, all build_board.py. Delivered: 0.9.1 board contract catch-up (native initiative.version.feature parsing — fixed the LIVE release/0.9 blindness — + reading build reports from feature docs; the first feature to dogfood + self-host the build-report-in-doc contract) + 0.9.2 git-status view (a 7th board view: branches/worktrees/ pending changes — the #1 VS-Code reflex, overview-only) + 0.9.3 review queue (the keystone: the assistant flags a doc → a board panel → read it in the detail pane; no file-hunting). The build-report-in-doc contract proved out — reports read from the repo, no paste. The parallel-merge lesson: 0.9.2 + 0.9.3's parallel run hit the first genuine interleaved-code conflict — "keep both" is a hypothesis to TEST, and generated files get regenerated, not merge-marker-resolved. See the 0.9→0.10 briefing.
_No version in flight — all phased features are delivered. Scope the next version to begin a new cycle._
synthetic sources (synthea · enrollment · provider · claims · benefit · network) → 1_bronze_data_lake (rename/cast; stg_<source>__<entity>) → 2_silver_raw_vault (staging → hubs / links / satellites; automate_dv) → 3_gold_business_vault (same-as links · PIT · dims · facts) → 4_platinum_info_mart (person_360 · claim_network_status · summaries) → evidence/ (the app — dials only, zero business logic)
Business logic lives in gold only; all hashing via automate_dv.hash(); source-neutral business keys (OP4 claims exception: source-qualified); models never read upstream out of order.
v1 Lay the foundation ✓ structure rebuilt, both sides of the house
(re-foundation · 5 payer features · clinical + claims)
v2 Prove the method ✓ audit → rules → generator → dashboard, end to end
(4/4, the 26pt point-ceiling run)
v3 Make it true ✓ gaps closed, specs distilled, data made realistic
(gold rewire S1+S2 · payer distillation · generator realism — 3/3, ~18pt)
v4 Take it out the door ✓ the network story, made portable and public
(disambiguator · snowflake port · Vercel deploy — 3/3, ~12pt · LIVE)
v5 Keep it honest ✓ paid down the layering debt the audits found
(S8 in-network gold relocation · S9 single-source resolution — 2/2, ~7pt)
v6 Both sides, deeper ✓ capability/breadth on the honest platform (first parallel run)
(member sat trio · person_360 dated-events timeline — 2/2, ~10pt)
v7 Demoable dashboards ✓ the demo, shipped (the board demos itself + the artifact-as-muse loop)
(board demo rail · persona CSR screen · coverage span realism — 3/3, ~15pt)
v8 The demo, made real ✓ the board becomes a review cockpit + 2 workflow upgrades
(Review Cockpit · benefit buildout · clinical persona · board-in-Evidence — 4/4, ~19pt)
─── version scheme → initiative.version.feature (e.g. 0.9.1) · history v1–v8 · init 0 = "everything so far" ───
0.9 The board replaces VS Code ✓ scheme catch-up + git-status view + review queue (3/3, ~15pt)
0.10 (scope at the 0.9 close) ◀ more of the 0.x arc — detail-pane extensions · quick-links · status/decisions cleanup
Phase 0.10.1 — 1/1 features delivered (100%)
Phase 0.9.3 — 1/1 features delivered (100%)
Phase 0.9.2 — 1/1 features delivered (100%)
Phase 0.9.1 — 1/1 features delivered (100%)
Phase 8-4 — 1/1 features delivered (100%)
Phase 8-3 — 1/1 features delivered (100%)
Phase 8-2 — 1/1 delivered (100%): Benefit-content buildout
Phase 8-1 — 1/1 delivered (100%): Review Cockpit
Phase 7-3 — 1/1 delivered (100%): Coverage span realism
Phase 7-2 — 1/1 delivered (100%): Persona dashboard
Phase 7-1 — 1/1 delivered (100%): Board Demo Rail
Phase 6-2 — 1/1 delivered (100%): person_360 Deepening
Phase 6-1 — 1/1 delivered (100%): Member Satellite Trio
Phase 5-2 — 1/1 delivered (100%): Single-Source Provider Resolution
Phase 5-1 — 1/1 delivered (100%): In-Network Determination
Phase 4-3 — 1/1 delivered (100%): Public Vercel Deploy
Phase 4-2 — 1/1 delivered (100%): Snowflake Dual-Target Port
Phase 4-1 — 1/1 delivered (100%): Provider Disambiguator
Phase 3-3 — 1/1 delivered (100%): Generator Realism Pass
Phase 3-2 — 1/1 delivered (100%): Payer Layer Distillation
Phase 3-1 — 1/1 delivered (100%): Gold Rewire
Phase 2-4 — 1/1 delivered (100%): Evidence Dashboard Buildout
Phase 2-3 — 1/1 delivered (100%): Synthetic Data Generator
Phase 2-2 — 1/1 delivered (100%): Claims Business Rules
Phase 2-1 — 1/1 delivered (100%): Clinical Audit
Phase 1-5 — 1/1 delivered (100%): Member-Month Fact
Phase 1-4 — 1/1 delivered (100%): Eligibility Spine
Phase 1-3 — 1/1 delivered (100%): Claims Source
Phase 1-2 — 1/1 delivered (100%): Provider Source
Phase 1-1 — 1/1 delivered (100%): Enrollment Member Source
| Feature | Phase | Purpose | Status |
|---|---|---|---|
| Detail-pane extensions — every doc type loadable + dynamic surfaces (decisions/streams/git) navigate to their related detail | 0.11.x | Complete the 'one click to anything relevant' capability. 0.10.1 made specs/candidates/queued-docs clickable-to-pane; 0.10.2 (a) widens the loadable doc set to ANY repo markdown (briefings, architecture, business-rules, decision_log, ideas), and (b) makes the board's DYNAMIC surfaces navigate to their related detail — a Decision → the feature it's about; a Cockpit stream / Git branch → the spec that branch builds. So from anywhere on the board, one click gets Dan to the relevant detail in the preview pane. | ▫ planned |
| Roadmap-as-files — every candidate a file, roadmap = sorted index of links, everything clickable-to-preview (+ STATUS re-entry restructure) | Phase 0.10.1 | Make every roadmap candidate a file so everything on the roadmap/Kanban is clickable → opens in the board's preview pane. The roadmap becomes a sorted INDEX of links + WSJF (not a monolith of prose); each candidate has one home from roadmap-entry onward, accreting detail through the funnel. The decision-support keystone: click any candidate → see everything we have on it, assess where it's at. Folds in a light STATUS.md restructure (exec summary + links on top) for re-entry. | ✅ done |
| Review queue — flag a doc in-session, read it in the board (stop hunting for files) | Phase 0.9.3 | The keystone 'stop hunting for files' interaction: when Dan says 'I want to review X' in-session, the assistant adds it to a queue file (review_queue.md) the board reads; it shows as a Review Queue panel; Dan clicks → reads the doc in the detail pane/overlay → it's off his plate. Instead of Dan hunting for a file the assistant mentioned, the assistant PUTS IT IN FRONT OF HIM on the board. | ✅ done |
| Git-status view — branches, worktrees, and pending changes in the board | Phase 0.9.2 | A board view showing the git state Dan currently opens VS Code for: open branches (feature/release/main), active worktrees, and staged/uncommitted/unpushed changes per branch. The #1 reason he drops into VS Code — surfacing it in the board removes it. Extends the existing Cockpit git-derivation machinery. | ✅ done |
| Board contract catch-up — native initiative.version.feature parsing + build-report-in-doc parsing | Phase 0.9.1 | Make build_board.py's CODE match the two workflow contracts adopted at the v8 close: (1) the three-part version scheme initiative.version.feature (e.g. 0.9.1) — the board currently has release/v\d+ + integer assumptions baked deep and is ALREADY blind to release/0.9; (2) the build report now lives IN the feature doc (a ## Build Report section), not a separate JSON — the board must read reports from the doc. Closes the temporary docs-say-0.9-but-board-says-integer inconsistency. | ✅ done |
| Board-in-Evidence — embed the interactive Review Cockpit inside the deployed dashboard | Phase 8-4 | Surface the feature board (the 8-1 Review Cockpit) INSIDE the deployed Evidence dashboard via an iframe — so the interactive cockpit shows up on the public Vercel URL alongside the data pages. A frozen-per-deploy snapshot (it doesn't live-update between deploys — expected + fine for a demo). Its own small feature, sequenced AFTER 8-1 (embed the NEW cockpit, not the old board). | ✅ done |
| Persona dashboard — the clinical / provider (exam-room) screen | Phase 8-3 | A second role-based persona: the clinical / provider 'exam room' screen — what a nurse or provider reviews about a patient before/during a visit. A plain reskin of the EXISTING person_360 + person_events marts (like 7-2), but framed CLINICALLY (conditions, medications, encounter history) rather than payer-side. A NEW visual archetype → carries a low-fi wireframe (per the wireframe gate). Independent of 8-1/8-2 — parallelizable. Also tops up the demo reserve's hand-off bucket with an agent-ready spec. | ✅ done |
| Benefit-content buildout — copays / deductibles / OOP-max / coverage rules per plan | Phase 8-2 | Give benefit packages real BENEFIT CONTENT. Today s_benefit_package carries only structural fields (product_category, plan_id, product_id, name, LOB) — no copay, deductible, out-of-pocket max, or in-vs-out-of-network coverage. 'Let me pull up your plan's benefits' is THE other CSR call move, and the data doesn't exist. Add benefit-content fields to the generator + vault + a consumption surface the persona/dashboard reads. The Tier-2 engineering-depth demo: builds real DV2.0 benefit structure on synthetic data. | ✅ done |
| Review Cockpit — the two-pane feature board (master-detail: cards → detail pane, spec-reading in-board, pop-out talk-track) | Phase 8-1 | Evolve the feature board into a two-pane REVIEW COCKPIT: a persistent scoreboard + version history (upper-left), a large detail pane (upper-right) that shows whatever was last selected — a feature's Markdown spec (incl. ASCII wireframes), or a diagram — and the Kanban below (three funnel-derived lanes). Click a card → its spec loads in the detail pane (board stays put); detail buttons load diagrams into the same pane; the pane expands to a full-board overlay (icon-only); the talk-track pops out to a separate chrome-less window; the scroll-jump-on-refresh bug is fixed. Read any spec/wireframe/diagram without the file system. Built to a LOCKED Claude Design handoff. | ✅ done |
| Coverage span realism — segment-typed enrollment spans + split over-long histories | Phase 7-3 | Make member coverage spans behaviorally realistic. Today one continuous eligibility span is capped at 40 years (MAX_ELIGIBILITY_SPAN_YEARS) — still far too long: many members show 200+ member-months (17+ yrs) or up to ~480 (40 yrs) with one plan, which never happens. Real spans follow employment (commercial ≈ 2–10 yrs, most <7) and age-eligibility (Medicare 65→, Medicaid churny) patterns; when a person changes employers they become a DIFFERENT member. Draw span lengths by segment type, and split an over-long source history into sequential shorter memberships. | ✅ done |
| Persona dashboard — the member-call (CSR) screen | Phase 7-2 | A role-based reskin of the EXISTING person_360 + person_events data into a customer-service / member-call screen — the 'rep on the phone' view. Zero new dbt models: it reframes marts v6 already shipped into a screen anyone recognizes. The Tier-1 visible-payoff demo feature — the headliner the room SEES appear. | ✅ done |
| Board Demo Rail — the board IS the demo (a right-edge talk-track surface, live-data diagrams) | Phase 7-1 | Make the feature board itself demo-ready by construction: a collapsible right-edge 'talk rail' (beats + downtime menu + a LIVE panel set that reads real board data) + a full-screen present mode, generated by build_board.py so it's always current and zero-maintenance. The demo is a view of the board, which is a view of the specs — same non-staleness guarantee, all the way down. The rail is ALSO exhibit A: it's a feature the workflow shipped, so it proves the method by being a product of it. | ✅ done |
| person_360 Deepening — the dated-events timeline (both sides, chronologically) | Phase 6-2 | Add the dated clinical-vs-claims timeline the person_360 page wants but can't build: a person-grain, time-keyed events mart (encounters + claims for one resolved person) so the dashboard can show a real chronological both-sides story + a person-picker. The dashboard payoff of the breadth version. | ✅ done |
| Member Satellite Trio — COB / disability / exchange (breadth: the member's other dimensions) | Phase 6-1 | Add three member-level attribute dimensions the platform doesn't carry yet — coordination-of-benefits (COB), disability status, and exchange enrollment — each as a satellite on the existing h_member, with the generator increment to emit them. Breadth: makes the member entity richer, and gives the dashboard more of the member story to show. | ✅ done |
| Single-Source Provider Resolution — kill the dbt-vs-generator match duplication (S9) | Phase 5-2 | Fix S9: the provider same-as match rule lives in TWO drifted places — cs_provider_same_as.sql (a DAG leaf) and scripts/synth/resolvers.py (stamps what the dashboard reads). 4-1 caught them at 4-tuple vs 3-tuple. Make one the single source of truth so the rule can't drift again. | ✅ done |
| In-Network Determination — relocate to gold (fix the S8 altitude inversion) | Phase 5-1 | Fix S8: the in-network determination logic lives in platinum (claim_network_status) but gold (fct_member_month) reads it — a medallion inversion. Relocate the determination into a gold computed satellite (cs_claim_network_status); make the platinum mart a thin passthrough. Byte-identical output — a layering fix, not a logic change. | ✅ done |
| Public Vercel Deploy — the live dashboard URL (deploy-last, version ship step) | Phase 4-3 | Publish the now-presentable dashboard to a live public Vercel URL — the portfolio payoff of the dashboard-then-publish thread. The version-closing ship step (4-0-shaped): built last, after the disambiguator makes the network story lead. | ✅ done |
| Snowflake Dual-Target Port — green build on a live trial | Phase 4-2 | Prove the whole platform builds green on Snowflake (not just DuckDB) — the single most BCI-transferable capability: byte-identical dbt models running on both targets, verified on a live trial. The second run of the migration-test experiment. | ✅ done |
| Provider Disambiguator — add city to the same-as key so ambiguous duplicates resolve | Phase 4-1 | Make the network story lead: resolve the ~55% of claims stuck as 'unidentifiable-provider' by adding a disambiguator (city) to cs_provider_same_as, so in/out becomes the dominant determination instead of the largest bucket being 'can't tell'. | ✅ done |
| Generator Realism Pass — align date ranges + cap longitudinal spans | Phase 3-3 | Make the synthetic data feel real: align claim service dates to eligibility/network coverage so in-network determination actually discriminates, and cap per-member spans/volumes to human-plausible ranges — the fix for the dashboard's 85%-unknown. | ✅ done |
| Payer Layer Distillation — populate specs/ for the payer spine (the payer analog of the clinical audit) | Phase 3-2 | Complete the rebuild-from truth: fold the v1 payer/membership/claims spine + the v2 lifecycle/generator additions into the by-layer specs/ docs, so specs/ covers the whole platform, not just the clinical half. | ✅ done |
| Gold Rewire — dims + fact repoint at the vault/PIT (finish #30, close S1+S2) | Phase 3-1 | Close the audit's headline divergence: the clinical facts read staging views, not the raw vault, so the #30 concept-hub rework's structures are DAG leaves. Build the concept dimensions, add the missing encounter sat, and repoint all three facts at the vault + PIT. | ✅ done |
| Evidence Dashboard Buildout — the payer story on the app surface | Phase 2-4 | Give the platform a showable face: surface the v1 payer payoffs (person_360 both-sides, member-month coverage, claims + in-network) as Evidence pages instead of one clinical index. | ✅ done |
| Synthetic Data Generator — the unified, referentially-consistent payer data factory (A3/R4) | Phase 2-3 | Consolidate the four ad-hoc generate_*.py scripts into one unified, deterministic generator with guaranteed referential integrity — the work-transferable synthetic-data-sandbox capability, and the unlock for scaling the payer side. | ✅ done |
| Claims Business Rules — the claim lifecycle rule + the rules-vs-SQL validation pass | Phase 2-2 | State the claim lifecycle semantics (adjudication before payment) as a platform-agnostic rule, and run the first deliberate validation of the delivered v1 SQL against the full business-rules layer — proving the rules are a working contract, not decoration. | ✅ done |
| Clinical Audit — audit the ~45-model Synthea build, populate specs/, seed business-rules/clinical/ | Phase 2-1 | Graduate the clinical foundation onto the new method: audit every clinical model against the operating principles, distill the rebuild-from specs, and re-establish a green baseline before the platform grows further. | ✅ done |
| Member-Month Fact — the payer periodic snapshot (coverage + claim + network) | Phase 1-5 | The phase capstone: fct_member_month — one row per member per eligible month, carrying their coverage (benefit package + network) and that month's claim + in-network activity. Plus a light person_360 enrichment. Closes the payer-source expansion (step 4). | ✅ done |
| Eligibility Spine — benefit package, network, eligibility + in-network determination | Phase 1-4 | Stand up the member→eligibility→benefit→network→provider spine (the load-bearing chain, FACETS complexity cut hard per D-D), seeded from Synthea payers + coverage transitions, and demonstrate IN-NETWORK DETERMINATION on the committed claims — the payer's core adjudication question. | ✅ done |
| Claims Source — claim header/line/diagnosis RV + the claim↔encounter bridge | Phase 1-3 | Stand up a synthetic payer claims source seeded from Synthea encounters, integrate it to member (shared key), provider (same-as), and encounter (the bridge), and surface clinical + claims side by side on person_360 — the marquee 'both sides of the patient experience' payoff. | ✅ done |
| Provider Source — clinical provider RV + payer directory + same-as (provider MDM) | Phase 1-2 | Stand up the clinical provider raw vault and a synthetic payer provider directory, and resolve them in the business vault — provider MDM, the second same-as bridge. | ✅ done |
| Enrollment Member Source — first alien-source integration | Phase 1-1 | Bring a payer enrollment source in beside the Synthea clinical data and resolve identities in the business vault — the DV2.0 integration story, shown side by side. | ✅ done |
implementation/bugs.mdimplementation/bugs.md.[mine] rows + “Open in my head” lines from in-flight specs[mine] rows + “Open in my head” lines in in-flight specs.## Build Report · legacy JSON fallback · newest first_current_version_branch() resolves release/0.9 (not the stale release/v8) — verified live in this worktreevN) then 0.9 (native, ordinal 9) with no gapsCommitted lane holds 0.9.1/0.9.2/0.9.3 (matched off roadmap.md's plain "0.9" Ver cells) with marks 0.9.1/0.9.2/0.9.3load_verify() parses this doc's own ## Build Report section on regen (dogfood round-trip) while all 21 pre-0.9.1 features still surface via the legacy JSON fallback (no double-count)python scripts/build_board.py runs clean and all 6 views (Kanban/Roadmap/Status/Bugs/Decisions/Cockpit) render with no raw Python tuple leaking into the HTML/JSON outputgit worktree list / git branch -vv exactly (spot-checked every ahead/behind count via git rev-list --count)git status --porcelain in all 4 worktrees after fixing a _git() leading-space strip bugrelease/0.9 resolves via the existing _current_version_branch() (0.9.1's regex fix, already on this branch)python scripts/build_board.py runs clean, all 6 prior views (Kanban/Roadmap/Status/Bugs/Decisions/Cockpit) still present + renderingimplementation/review_queue.md created as the register (D1/D6 — ## Queue table: ID/Added/Doc/Why flagged/Status, mirroring bugs.md's ## Bugs/## Fixed split so a reviewed row moves to ## Reviewed rather than getting deleted)v8_to_0_9.md briefing) per the DoD. python scripts/build_board.py runs clean and reports "2 doc(s) in review queue". Verified live in a browser (Playwright against a local static server serving the worktree's docs/): the "Review Queue" tab renders with badge count 2feature_review_queue.md row AND the v8_to_0_9.md briefing row both load their markdown into the detail pane (confirming D4 — an arbitrary non-spec doc renders, not just backlog/completed specs), with the pane title correctly reading "Review · <doc's frontmatter title>localStorage['hdpReviewHidden'] and the panel "Hide reviewed (session)" toggle persists to localStorage['hdpReviewHideToggle'] — confirmed both survive a view-switch away-and-back (fresh template clone + bindReviewQueue() re-reads localStorage each render) and that toggling is idempotent (single click hides/unhides, no duplicate-listener drift). No code path writes review_queue.md from the board (D3) — the file is edited only by the assistant, never the client JS. All 6 pre-existing views (Kanban/Roadmap/Status/Bugs/Decisions/Cockpit) still render with no console errors (checked via Playwright after every tab switch).candidates/feature_*.md file (body = their prior Notes prose + light frontmatter): snowflake_parity_match_contract, premium_billing, clinical_breadth_audit_fixes, capitation_provider_agreements, subgroup_hierarchy_class_rating, network_rule_engine. roadmap.md's ## Ranked candidates table now links every Candidate cell (Name)load_roadmap() (extended with _split_candidate_cell) parses all 14 rows with the WSJF/Ver/V/TC/RR/Size columns intact and WSJF still sorting descending (5.5→0.8) — the D2 tripwire held. load_candidate_specs() embeds the 6 candidate files into the SAME D.specs/D.meta dicts the 8-1 embed + 0.9.3 arbitrary-doc path use (keyed by file stem, phase:"candidate"), merged in build_once()build_lanes() resolves each row's card id DIRECTLY from its link (falling back to fuzzy match for legacy un-linked rows) so EVERY card is clickable. Verified in the built cockpit-data JSON: all 6 Ready-lane cards + the 1 Committed card resolve to embedded docs (clickable=True)feature_premium_billing whose 1756-char rendered body is in D.specs (DoD's named test). STATUS.md restructured (D5): a new AUTHORED:exec_summary block (a 2–4-sentence exec summary) + a reworked AUTHORED:links block leading with the 5 required links (live app URL, Vercel deploy page, danbrickey.dev placeholder, Snowflake instance, GitHub repo), then the existing detail — all 3 GENERATED marker pairs (inflight/done/roadmap) untouched, write_status_md refreshed 3 blocks with no raise. python scripts/build_board.py runs clean (exit 0, no embed-cap warnings)release/vN branch exists. The cockpit derives streams from git history; it lights up when a feature branch is in flight.[mine] rows + “Open in my head” lines from in-flight specs[mine] rows + “Open in my head” lines in in-flight specs.implementation/review_queue.md