A complaint with no protocol match became a reviewable encounter, and three weeks later a one-off visit converted to a membership. The safety screen handled the high-risk questions, the AI handled the rest of the interview, the clinician made every decision, and the record continued to be used after the visit ended.
Two journeys run on the same machine — switch Journey in the top bar: the known patient (record continuity, human-confirmed writes) and the net-new DTC visitor (guest session, trust-sequenced asks, identity at prescribing, consent as claims).
I've built both parts of this before. The claim record with source tracking is live at my current company as a read-only brief inside existing tools; the AI gateway under it runs in production today. The next tabs cover how the same components apply
Everything you just clicked in the demo — the receipts, the floors, the retraction, the role-filtered views — falls out of one design decision: the record is not a form, it's an append-only graph of claims. Intake writes claims. Protocols write claims. Imports, devices and clinicians write claims. Serving is a resolver over that graph, and the resolver is where clinical policy lives.
What is being asserted, against a governed field catalog. allergy = "None · negative test 2025"
STATED (the patient said it) > OBSERVED (the system watched it happen) > REPORTED (a third party or document said it) > INFERRED (a model derived it). Class outranks confidence: a stated fact beats a confident guess.
Who asserted it — a named, versioned producer. protocol_screen_v18, intake_extractor_v2, clinician·S.Okafor. Producers are either versioned models with evals attached, or named people.
Confidence is set by the producer; the floor is set by us per field. Below the floor a claim is served as a labeled hint, never as the answer.
observed_at vs recorded_at. "The fall was two weeks ago, we learned today." Clinical reasoning needs event time; audit needs record time. Conflating them corrupts both.
A dereferenceable receipt — the verbatim span, the screen run, the imported document — plus a per-claim audience list (clinician / patient / RCM / health-system partner).
| Field family | Floor | Behavior below the floor |
|---|---|---|
| Allergy add / remove | 0.97 + human confirm | Old value keeps serving, flagged; the change waits in the clinician's queue. You saw this happen live: Maya's penicillin correction held at 0.93 until Dr. Okafor confirmed it. |
| Red-flag fields | protocol-only | No model may produce these fields at all. red_flag_screen accepts writes only from the versioned protocol engine — the disposition gate reads that producer, no other. This is the decade-old expert system, promoted to a first-class producer rather than replaced. |
| Medications | 0.90 | Served as a hint pending reconciliation. |
| History, social, context | 0.60 | Served with class and confidence visible; the clinician always sees the label. |
Review boards ask for structural guarantees, not assurances about model behavior — for example, that a hallucinated allergy removal cannot reach the chart, because the write path for that field requires a human confirm. Floors implement that policy as configuration the system enforces.
Nothing is ever deleted. A correction is a new claim; a retraction is a tombstone that points at what it retracts. That gives us three things clinical AI needs: replayability — we can reconstruct exactly what any surface served at any moment, what the model saw, and what the clinician saw, in order; audit response — an AI-review board's evidence package is a query over this data rather than a manual reconstruction; and training data at no extra cost — every clinician confirm, edit and override is a graded label against the producer that made the claim.
The protocol engine (deterministic, versioned — its verdicts are claims too) · intake extractors · EHR/CCDA imports · device readings · clinician notes and confirms · scheduling and RCM events. New producer = a registry row with an eval, not a schema migration.
AI Intake assembles its per-turn context from the graph (the record is the memory — no hidden model state). Clinician review, scheduling, coding and billing read the same resolved views with role-scoped visibility. Documentation and next-best-action are new consumers of the same graph, not new pipelines — that's how one foundation carries the adjacent surfaces.
Acquisitions plug in the same way: each acquired stack becomes a producer (its data, claimed and receipted) and a consumer (its surfaces, reading resolved views) long before anyone replatforms anything. The graph is the consolidation layer — more in tab ⑤.
Models will keep changing under us; the architecture should treat them as swappable. The durable assets are the record (tab ②), the harness around the model, the eval infrastructure that makes change safe, and the gateway (tab ④) that enforces policy. Here is where the hard bets go over 12–24 months.
Frontier API models for conversational reasoning turns; small, fast, cheap models for extraction, tagging and classification (most tokens by volume); fine-tunes only where an eval proves the lift. Model choice is a config row per use case, never code — switching to a better model is a configuration change plus an eval run.
Each use case declares its model and an explicit fallback chain (capped attempts, never a mid-stream switch). Circuit breakers per provider, health-probed. Patient-facing latency budgets drive the split: fast models in the loop, big models where reasoning earns the wait.
Keep an open-weights / dedicated-capacity lane warm for workloads where data residency, cost-at-scale, or health-system contracts demand it. In my prior build, on-prem GPU boxes registered as another provider row behind the gateway — same policy, same audit, no application changes. Having this lane also strengthens our position in model-vendor negotiations.
Extraction and coding taggers (high volume, narrow, label-rich from clinician edits) — yes, early. The conversational intake model — only when evals show frontier models plateau on our rubrics. Never fine-tune what a floor or a protocol should enforce instead.
Red-flag screens are protocol-owned: verbatim, versioned, logged as runs. The model can hand the conversation to the screen; it cannot answer for it. Disposition gates read protocol-produced fields only.
Context is assembled per turn from resolved claims — no hidden conversation state, no model "remembering" wrong. Every token the model saw is reconstructable, which is what makes incidents debuggable and audits answerable.
Models emit claims against the field catalog and are validated before anything lands. Free text lives in evidence spans, in the patient's own words. An invalid or fabricated output fails validation and never reaches the chart.
This is my answer to "how do you make an LLM safe at clinical stakes": the safety guarantees come from the surrounding system — deterministic screens, floors, validation, gated dispositions — not from the model itself. Our decade of protocol encounters supplies those deterministic components, which is an asset competitors don't have.
| Layer | What it is | Gate |
|---|---|---|
| Golden sets | Mined from historical protocol encounters — a decade of rules-based intakes is a large labeled corpus specific to us. De-identified, versioned, owned like code. | CI: no regression on safety-critical slices. |
| Clinician rubrics | Clinicians author the grading criteria (completeness, pertinent negatives, escalation correctness); model-graded at scale, clinician-audited on samples. SMEs stay load-bearing here permanently. | Release: rubric scores at or above current champion. |
| Shadow mode | AI Intake runs silently alongside live protocol intakes; diffs scored nightly against the rules engine as the baseline, with results published internally. | Expansion: win-rate threshold per complaint family before AI takes real traffic for it. |
| Online monitors | Escalation precision/recall, contradiction rate vs the record, re-ask rate, completion rate, clinician edit rate per producer — live, per model version, from the audit stream. | Runtime: breach pages a human and can trip the killswitch (tab ④). |
Every clinician confirm, edit, override and disposition is a labeled example, attributed to the producer that made the claim — captured during normal work, with no separate labeling effort. Outcome joins (disposition → resolution → any bounce-back) grade the whole chain, not just single turns. Within a year this produces two datasets that improve with volume: calibration curves per producer (whether 0.85 from the extractor is actually 85%) and complaint-family win rates vs the protocol baseline — which is the evidence health-system AI-review boards ask for.
The record · the gateway · shadow-mode evals · extraction fine-tunes · replayability end to end.
Documentation and next-best-action as new consumers of the graph · coding models feeding RCM with receipts · event-driven intake (the record notices, like the demo's opening signal).
Autonomous disposition · voice-first intake at scale · agent-to-agent care coordination. Real, but they depend on the safety layers above — sequence them after the foundation is stable.
Every LLM call in the company — intake, documentation, coding, internal tools, engineers' coding agents — goes through one OpenAI-compatible endpoint, and policy is enforced at the door: budgets, rate limits, PHI, model allowlists, an in-flight killswitch, and a 7-year audit record for every request and every admin action. This is not a proposal. I designed and shipped this system; the gateway and its admin plane run in production at my current company today, with an agents plane behind it in dev. For us it's an adaptation, not an invention.
Open streaming responses get a terminal event within ~1s at key, use-case or service-line scope — three redundant layers, so it works even if the cache tier is down. The killswitch can be demonstrated live to a review board.
A catalog in the database, a two-tier allowlist, and an automated verifier probe before any model goes live. A new provider — including on-prem hardware — is a database row, not a deploy.
Policy rolls up key → use case → service line; first trip wins. A misbehaving workload trips its own breaker and budget, never another team's. PHI exceptions require a signed waiver — a named person and a ticket — enforced by a database constraint.
| Level | At the Company | What hangs on it |
|---|---|---|
| Service line | A clinical or business area — AI Intake, documentation, RCM, internal eng | Budget, rate limit, killswitch, model allowlist |
| Use case | One approved purpose within it — e.g. "chronic-cough intake, beta" | Most policy: PHI mode, fallback chain, allowlists, the attached eval artifact and approval record — the unit an AI-review board approves is the unit the gateway enforces |
| Key | One credential, one purpose | Expiry, inference caps, capability flags; hashed at rest, fail-closed |
One idea applied twice: policy at the door for model traffic, and the same door under every agent. Infrastructure denies agents direct model access — their execution role can't invoke a model except through the gateway, each deploy gets a fresh key scoped to its own use case, and every token lands on its own budget line. An agent can't overspend, can't touch a disallowed model, can't call an unattached tool, and can be killed mid-stream — with zero policy code written by the team that built it. As our engineers reshape around agentic development, this is what keeps the inflection safe: the agents building the product live under the same governance as the product.
Keys, models, providers, agents and tools are GUI actions on runtime data — no infra tickets. Engineers connect their coding agents through the same door with copy-paste configs. Clinical-ops staff get a plain-language studio for drafting agents, with honest failure modes and explicit deploys — nothing fakes success.
The platform's policy applies to the platform itself: in my current deployment, our own drafting model's traffic was once PII-blocked by the gateway, root-caused from the audit log in minutes, fixed, and verified the same day. The same enforcement applied to our internal traffic as to any other caller — a concrete example of policy running as a system rather than a document.
| Capability | Status in my current deployment | For Us |
|---|---|---|
| Model gateway + full policy pipeline | Production | Adapt PHI posture to HIPAA/BAA lanes; point existing beta traffic at it in month one (tab ⑤) |
| Admin plane, SSO, audit UI | Production | Becomes the shared console across acquired stacks — one place to see every model call in the company |
| Agents plane · lifecycle, per-agent keys, run ledger | Dev · promotion is rollout, not build | Hosts documentation and NBA agents as they arrive |
| Eval gates wired to use-case rows | Designed | Build here first — this is the company-specific piece, and it's what makes approvals enforceable |
Build-vs-buy note: gateway products exist and are worth evaluating honestly. My bar: does it give us fail-closed PHI enforcement, a mid-stream killswitch, eval-artifact-per-use-case, and a 7-year audit we own? If a vendor clears that bar faster than adapting a system I've already built, we buy. My expectation is a thin build on open standards — and the OpenAI-compatible surface keeps the decision reversible either way.
AI Intake is the first consumer of something bigger: a clinical context engine that marries two kinds of intelligence on one record — clinical (what's true about the patient's health, governed by protocols, floors and evals) and intent & engagement (what the patient needs next, when they'll respond, what they're ready for). These are usually built as two separate systems: a clinical record with no engagement capability, and a marketing/CRM system with no clinical grounding. The demo's epilogue — the automated follow-up and the membership offer assembled from her own record — required both to be on one graph.
Protocol verdicts, screen runs, extracted HPI, med and allergy claims, outcomes, imaging results. Producers: the rules engine, intake models, clinicians, imports. Floors and human-confirm writes govern serving. Consumers: intake, clinician review, documentation, next-best-action, coding.
The interaction log as first-class data: sessions, channels, response times, follow-up behavior, conversion moments, drop-offs. Producers: cadence and channel models, engagement scorers. Consumers: acquisition, activation, follow-up timing, membership conversion, retention.
The combination matters in both directions. Clinical claims give engagement a legitimate trigger — the follow-up in the demo fired because an episode was unresolved, not because a marketing calendar said so, which is why patients experience it as care rather than marketing. Engagement claims make clinical outreach effective — knowing Maya responds in-app in the evenings is the difference between a follow-up she sees and one she doesn't. Both kinds of claims use the same envelope, audit, and gateway, so growth automation runs under the same governance as clinical AI: every proactive touch traces to a specific claim, and every claim shows its source.
Every DTC ad, search result and partner link lands on Start a visit — a guest session where the record begins at claim #1. The first interaction is a real triage question, not an account-creation form. Identity is collected progressively, only when the care requires it (payment, a prescription, a chart). Moving sign-up after the first useful interaction is the main conversion-rate lever.
The same identity resolution you saw in the xref card runs in reverse for strangers: a guest who later verifies gets their session claims merged into a fresh chart — nothing re-asked, nothing lost, no duplicate. If they turn out to be a health-system member, the record joins them to that relationship instead of competing with it. One machine serves DTC, provider group, and B2B without three codebases.
Acquisition channel is stored as a claim, so outcome joins flow back to the ad: which channels produce patients who complete intake, resolve well, and subscribe — versus channels that produce sessions only. Growth can then optimize CAC against LTV with clinical outcomes included. This reporting is a query over the record; few DTC health companies have the data structure to produce it.
A stranger at 11 PM will not hand a med list to a website. The intake earns each disclosure: a useful answer before any personal question, each sensitive ask paired with its reason at the moment it matters (allergies when prescribing is on the table), identity requested last — only when the pharmacy requires it — and consent recorded as claims, so "no marketing" is enforced everywhere and never re-asked. Declines are recorded and respected; that restraint is itself what earns the next disclosure.
The conversion from a one-off urgent-care visit to a membership depends on the record staying useful after the visit, which is what the demo's epilogue shows:
| Moment | What the brain does | Why it converts |
|---|---|---|
| Resolution follow-up | Unresolved episode + elapsed time fires an outcome check (approved rule, clinician-sponsored) | The first concrete evidence of ongoing care after payment — and the same message produces the outcome label that grades every model in the chain. |
| The offer at demonstrated value | Membership pitch assembled from her claims — asthma action plan, evening same-night visits, refills before she needs them — each line with a receipt | The pitch is credible because it visibly reflects her actual record, and it arrives immediately after she experienced the product working. |
| Member life | The nurture pattern, clinically governed: refill anticipation, seasonal checks against her history, annual reconciliation, "the record noticed" moments | Retention depends on the record continuing to produce useful, correctly-timed touches; members who repeatedly experience that have less reason to switch to a competitor. |
Metrics this adds to the scorecard: visit→membership conversion, time-to-first-proactive-touch, member retention and engagement half-life, proactive-touch acceptance rate (the consent-and-taste signal), CAC payback by channel with outcome joins.
Durable advantage comes from assets that improve with use and can't be purchased directly. We have four, and this architecture connects them:
1 · The protocol corpus. A decade of clinically-safe encounters is simultaneously the safety harness (deterministic screens), the eval baseline (the system to beat, honestly), and the labeled dataset (golden sets). AI-intake startups have models; they do not have this, and they cannot generate it retroactively.
2 · The record. Every encounter deepens it, and a deeper record improves the next encounter, follow-up and conversion. That is a per-patient switching cost that grows with tenure, and it is built from verifiable data rather than brand affinity.
3 · Governance as a differentiator in sales. Health-system AI-review boards are a hard gate for most vendors; with the use-case registry, eval artifacts, killswitch and 7-year replay, we can answer their requirements with a live demonstration. B2B trust and DTC growth run on the same infrastructure.
4 · The two-sided loop. More encounters improve both the clinical and engagement models, which improves outcomes and conversion, which produces more members, more health-system volume, and more encounters. EHR incumbents hold records but don't run the engagement loop; DTC telehealth runs engagement but lacks the clinical layer and the protocol asset; point solutions have neither. The advantage comes from combining the two on one architecture — which is why it belongs to the CTO function.
Tabs ①–⑤ describe where the technology goes. This tab covers execution, grounded in the current reality: an early-beta AI product, a portfolio of acquired stacks, NewCo roughly doubling the engineering org, and teams whose views I haven't heard yet. The plan front-loads in-person time and quick wins, defers structural moves until they're informed, and requires every consolidation item to map to a growth opportunity.
People. On-site with every team, on their turf — not a roadshow of all-hands but working sessions: sit clinician review shifts, read the protocol engine's source with its authors, pair on the AI Intake beta. Skip-levels with senior ICs and specifically with long-tenured people — they hold the load-bearing context, and I want an early, honest read on retention: who's a flight risk, what scope/growth/comp would keep them, and a quiet retention plan for the top of that list before any org conversation starts.
Quick hands-on wins. Two or three small, visible, finished things in the first month: push back on at least one requirement that's inflating scope (a new CTO who says "no, and here's the smaller version" early establishes that requirements get scrutiny); pick one long-standing tech-debt irritant the teams name — build times, flaky CI, an on-call pain — and fix it; unblock one decision that has been circling. Key hires: searches take 90+ days, so the first reqs open in week two — my starting bets are a data-platform lead and an eval/AI-quality lead, revised as I learn.
NewCo, part one. The acquisition roughly doubles engineering, so a real slice of the first 60 days is the mapping: skills, stacks, ownership, on-call reality, who their load-bearing people are. Month one is inventory and relationships — no mapping decisions yet, stated openly so nobody reorgs themselves preemptively.
Measurement pilot. Stand the eval harness over existing AI Intake beta traffic — replay, score, publish the first scorecard. Zero product change, instant credibility, and the baseline for everything after. Leave alone: the protocol engine and clinician review workflow. Intervene immediately only if I find ungoverned LLM traffic or PHI side doors — that's a week-one gateway fix, not a memo.
Budget. Full view of run-rate: cloud and vendor spend, model spend (the gateway makes it visible per use case from day one), headcount plan by team, and the acquired entities' cost bases. Goal: find the 10–15% that funds the AI investment below without a new ask.
Near-term org optimization — a view, not yet an announcement. Cross-team map of duplicated effort across acquired stacks, product-specific evolution opportunities (what each product line needs next and whether its current team shape can deliver it), and the draft target structure. NewCo, part two: a preliminary recommendation on if/how their teams map across the broader org — including the honest option that some deliberately don't merge yet.
AI investment, concretely. Resource the two platform teams that make everything else compound: a Data Platform team (the record, pipelines, eval datasets) and an AI Gateway team (the door, policy, eval wiring). Seed agentic builds inside product teams — agent capacity through the gateway per team, not a central AI silo that becomes a bottleneck.
AI-native PDLC end to end — by 60, deliberately not 30. Spec → agent-implemented → eval-gated → human-reviewed, adopted team by team starting with two volunteers. It takes time for a team to genuinely change its habits; forcing it in month one produces surface-level adoption without real change. By day 60 the first teams run it for real and publish what changed.
Product pilots continue: gateway v0 in front of existing LLM traffic (two-line client change), shadow mode on one high-volume complaint family, read-only intake brief with volunteer clinicians.
Stakeholder alignment. Across business partners — clinical leadership, growth, finance, the health-system customer teams — on the longer-term roadmap: build / buy / integrate calls per major capability, tech-stack investments, and the consolidation sequence. Socialized 1:1 before any big meeting; decision memos with the options we didn't pick.
Growth-mapped consolidation memo. Every tech-debt and consolidation item justified by the growth opportunity or risk it unlocks — revenue, conversion, safety, velocity — with the explicit rule that anything we can't map, we don't do yet (detail below).
Org announced with the strategy — structure, the NewCo mapping decision, and retention moves executed together, so people hear decisions directly rather than through rumor. Eval gates land in CI; governance package v1 goes through a real customer review board; board readout: scorecard, risk register, year-one commitments with leading indicators.
Owns the record (tab ②), ingestion from every acquired stack, eval datasets and the outcome joins, and the synthetic-data capability — tonic.ai-style tooling for de-identified, realistic test data that bootstraps new environments and lets us develop against PHI-shaped data without PHI.
Owns the door (tab ④): policy pipeline, model catalog and routing, killswitch, audit, the agents plane, and the eval-gate wiring into CI. Small, senior, infrastructure-minded — this team's output determines every other team's delivery speed and is central to what review boards evaluate.
Key workflows — intake, clinician review, scheduling, RCM — get teams that own the workflow across product lines, even where that means holding multiple stacks and repositories during consolidation. The alternative — teams per codebase — hard-codes the acquisition boundaries into the org. These teams are responsible for reducing the number of stacks they hold over time, but their ownership is defined by the workflow, not the repository.
Every product team builds with agents through the gateway — coding agents on the engineering side, candidate agentic features on the product side — rather than routing all "AI work" through a central group. The platform teams make it safe; the product teams make it useful. The talent bar shifts toward specifying and verifying work, and the long-tenured domain holders — protocol authors, clinical reviewers, workflow experts — become more important, not less: their judgment defines the standards agents are graded against. That is also the substance of the retention case we make to them.
Every consolidation or tech-debt item carries the growth opportunity it unlocks: a conversion path it speeds up, a health-system deal it de-risks, a launch it makes possible, an on-call burden it retires. If we can't name the unlock, it stays on the backlog. Sequence: (1) LLM traffic through the gateway — days; (2) data in as claims, surfaces read resolved views — weeks; (3) replatform only where the mapped growth pays for it. Integration work capped per team per quarter, tracked on the public scorecard.
Before any stack migrates, we use Cursor-class agentic coding tools to generate characterization test harnesses over the legacy system's real behavior — the tests document what the old system actually does, then gate the new one against it, so migrations provably don't lose quality. Paired with synthetic patient data (tonic.ai or similar) for realistic end-to-end tests and environment bootstrapping without touching PHI. Agents make exhaustive test harnesses cheap to produce, which materially lowers the cost and risk of replatforming — and it's a practical early use of agentic tooling.
AI Intake graduates from beta on evidence: shadow-mode win rates per complaint family, published internally, gating each expansion. The fallback lane (no protocol match) becomes a strength customers cite — and the DTC funnel lands in a conversation, with visit→membership conversion on the scorecard from day one.
Every LLM call in the company flows through the gateway; the claim record serves a read-only brief inside clinician review. Two acquired platforms connected as producers/consumers — before any replatform.
A health-system AI-review board walks through a live approval: the use-case row, its eval artifact, the killswitch, a replayed encounter. At least one deal closes with this as a cited factor.
| KPI | Type | Why this one |
|---|---|---|
| Eval coverage of live AI surface area (% of traffic behind a gate) | Leading | Predicts whether change stays safe as velocity rises |
| Shadow-mode win rate vs protocol baseline, per complaint family | Leading | The honest scoreboard; gates expansion |
| Escalation precision / recall · clinician edit rate per producer | Leading | Clinical safety and quality, measured continuously — the board metrics |
| Agentic PDLC adoption · characterization-test coverage on migrating stacks | Leading | The org transformation and migration safety, made measurable |
| Intake completion rate · time from intake to clinician decision | Lagging | Patient experience and clinician throughput |
| Protocol-fallback conversion (complaints served that rules alone couldn't) | Lagging | The breadth AI actually adds — the business case for AI Intake |
| Clean-claim rate & coding accuracy downstream · cost per encounter | Lagging | Proves intake quality where finance feels it; funds the roadmap |
| Visit→membership conversion · member retention · CAC payback by channel (outcome-joined) | Lagging | Measures the transaction-to-membership conversion loop (tab ⑤) |
| Regrettable attrition among senior / long-tenured engineers | Lagging | A transformation that loses its context-holders has failed regardless of what velocity metrics show |
| Policy language | Operating mechanism |
|---|---|
| "Approved uses of AI" | A gateway use-case row: model allowlist, PHI mode, budget, attached eval artifact + named approver. Unapproved = no key = no tokens. Default-deny. |
| "Human in the loop" | Serving floors + confirm-writes (the allergy beat in the demo) + the review queue. The chart's write path structurally requires a person for high-stakes fields. |
| "Continuous monitoring" | Online monitors per producer and model version, from the audit stream; breach pages a human and can trip the killswitch. |
| "Incident response" | Mid-stream killswitch (~1s) + full replay of any encounter: what the model saw, what it said, and what every surface served. Postmortems reference the complete request record. |
| "Board / customer review" | The evidence package is a query over the 7-year audit record rather than a manual reconstruction. It can be demonstrated live in sales cycles. |
Build vs buy: buy models (frontier APIs, plural), rent infrastructure, buy tooling where it's commodity (agentic coding tools, synthetic data, observability) — but build the record, the harness, and the eval corpus. Those three compound with our clinical history and can't be bought. Gateway and eval vendors get an honest bake-off against the bar in tab ④; the OpenAI-compatible abstraction keeps every buy decision reversible. Build/buy/integrate calls per major capability land in the day-90 roadmap alignment.
Partners I'd over-invest in early: the CMO and clinical leadership (co-own the rubrics and the scorecard), compliance/security (co-design the gateway's PHI posture rather than reviewing it after), RCM operations (coding accuracy is where intake quality becomes revenue), growth (the tab-⑤ funnel is a joint product), and the health-system customer teams (their review boards are our proving ground). Trade-offs stay visible through two artifacts: the internal scorecard and one-page decision memos that record the options we didn't pick — so disagreements surface at decision time rather than months later.