diff --git a/context/current-state.md b/context/current-state.md
index 0852dfe..52161b0 100644
--- a/context/current-state.md
+++ b/context/current-state.md
@@ -1,38 +1,37 @@
 # current-state
 
-ACTIVE: Claude Code built Phase 2 (verified). Pi applied trust fixes, wrote Phase 4 spec, completed Shield competitor recon.
-NEXT:  Pi designs Shield architecture (standalone compliance product). Claude Code on website review + whitepaper (agent-ready scan done: Level 4 / 64; Pi handoff at signal/docs/agent-ready-ecosystem-handoff-2026-06-22.md) + Phase 2 verification.
+ACTIVE: Readiness-model redesign locked + design brief written for Pi. Client supplies plan type (Signal never determines payer/eligibility/coverage); cite-the-basis; patient/CoverageLine/Shipment data model; required-vs-supplied verdict (no false green). cto-architect review folded in.
+NEXT: Pi produces the build design from `docs/readiness-model-brief-2026-06-23.md`; then Claude builds (sequence: rename coverage->readiness, rules-to-config, patient/line/shipment grouping + verdict, device-keyed override+recompute, require-plan-type + client mapping + remove guesser, frontend nesting). RECONCILE: 2026-06-23 call says the anonymous patient ID should be rotating (not static) - tension with the persistent worklist keyed on patient_id; Pi to address.
 
-## Decisions (last 5)
+## Decisions (last 6)
 
-- 2026-06-22: TRUST FIXES APPLIED by Pi — privacy-policy.md: 7yr→6yr retention (45 CFR §164.530(j)), false BAA claim replaced with live posture. Doc-only, no redeploy.
+- 2026-06-23: Readiness model redesign. Signal never determines/guesses payer plan type, eligibility, or coverage; client supplies plan type as a required mapped field; every determination cites the rule + client input. Worklist = one record per patient UUID with per-device CoverageLines; verdict from required-vs-supplied (Clear to Ship earned by positive evidence, never by absent data). MA "bug" = delete the name-guesser. "coverage" code renamed to "readiness". Brief: docs/readiness-model-brief-2026-06-23.md. KG: plan_type_policy, scope_exclusion, determination_explainability.
+- 2026-06-23: Shield architecture designed by Pi (standalone compliance product, tiered deployment, security, scalability, AI Consent Addendum focus). Ready for Claude Code build or further refinement.
+- 2026-06-23: DNSSEC verified live (DS propagated to public resolvers, ad flag set = chain validating). Website agent-files: staged compliance/factual fixes in local repo, NOT deployed: removed outreach wording, banned >25% stat, exposed pricing; fixed SWO term to Standard Written Order; refreshed learn-signal SKILL.md digest in agent-skills index. Prose rewrites + v0.2.0 field polish route to lead-content / deferred (agentskills.io schema URL unreachable).
+- 2026-06-23: Pi drafted strategic plans for "Signal AIOS" (productizing Shield's compliance architecture for Signal clients) and an "Automated Blog" for STTIL Solutions website (AI/SEO optimized, leveraging research agents and TriLane). Awaiting Granola call notes for refinement and Claude Code's recommendations.
 - 2026-06-22: Phase 4 (support bot foundation) spec written by Pi — gen-api-ref.py + manual cross-reference. Ready for Claude Code build.
-- 2026-06-22: Shield competitor recon complete — Dash ComplyOps ($250/mo), Vanta/Drata/Secureframe ($7.5K-$100K+/yr). Shield positioned as standalone compliance (not DMEPOS). TriLane insights planted + corrected.
-- 2026-06-22: Build Spec Phase 2 built (Claude Code). navaigate-session-brain now auto-writes current-state.md (Step 3B) + extracts research insights to TriLane (Step 3C). POST contract verified vs router source.
-- 2026-06-22: Clerk prod migration COMPLETE — frontend (pk_live on Vercel) + backend (CLERK_JWKS_URL → clerk.sttilsolutions.com on Railway) both deployed.
-- 2026-06-21: Subagent cost guardrails installed — all 8 builtin subagents default to deepseek/deepseek-v4-flash with 2-5 min hard timeouts.
-- 2026-06-21: Audit logger trust fix committed + pushed (Supabase client detection, error wrapping). Cascade test assertion corrected.
+- 2026-06-22: Build Spec Phase 2 built (Claude Code). navaigate-session-brain now auto-writes current-state.md (Step 3B) + extracts research insights to TriLane (Step 3C). Clerk prod migration COMPLETE (pk_live on Vercel + JWKS on Railway).
 
 ## Open Threads (max 5)
 
+- READINESS MODEL REDESIGN (2026-06-23): design brief for Pi at `docs/readiness-model-brief-2026-06-23.md` (folds in cto-architect review). Pi produces the build design; then Claude builds. Supersedes the piecemeal 3-blockers framing. KG added: plan_type_policy, scope_exclusion, determination_explainability.
+- TODAY'S CALL shared for Pi (2026-06-23, AI OS / API-first w/ Fred, Daniel, Andres): notes at `STTIL-Vault/Projects/Meetings/2026-06-23-AI operating system design and API-first architecture with Fred, Daniel, and Andres.md` (also auto-flows to TriLane sessions ws 3446107c-..., Pi reaches over HTTP at 127.0.0.1:8000). Signal-relevant: new federal EO tightens AI + identifiable health data; rotating anonymous patient ID (NOT static) - reconcile vs persistence keyed on patient_id; Validated Cloud HIPAA host; local on-client inference option; API-first connectors to Brightree/NikoHealth.
 - LabABLE Meeting Fri 2026-06-26 1:30 PM — /pilot-prep (deferred).
-- Build Spec Phase 2 BUILT — auto-write + insight extraction in session brain. Live write-path pending Pi verification at next wrap-up.
-- Build Spec Phase 4 spec written by Pi (gen-api-ref.py + manual cross-ref). Ready for Claude Code build.
-- Shield architecture: Pi designing now. Competitor recon done (Dash ComplyOps, Vanta/Drata/Secureframe tiers).
-- 3 validation product blockers: MA misclassification, duplicate patient_id, doc-status override (Claude Code on these).
+- Website copy: brief lead-content for human-page rewrites (extract "eligibility"/"coverage" language, stat consistency), run copy-review, then commit + deploy the staged agent-file fixes. Retention 6-year doc fix (2 stale "7 year" lines). BAA privacy wording attorney-gated.
+- Build Spec Phase 4 (support bot foundation) spec by Pi - ready for Claude Code build.
 
 ## Stack
 
-- Signal: PHI contained in `patient_id` field (name, MRN, account #s) — requires tokenization.
+- Signal: PHI contained in `patient_id` field (name, MRN, account #s) — requires tokenization (2026-06-23 call: rotating anonymous ID, not static UUID).
 - Model for Pi: `deepseek/deepseek-v4-flash` (cheap, high-thinking). Subagents also default to this model.
 - Signal-api: Railway (signal-api-production-91c2)
 - Signal-ui: Vercel (signal-ui-xi.vercel.app)
 - Supabase: itmospnregdyiatbbdwl (JWT key)
-- TriLane: localhost:8000 (signal/sessions/scale-software workspaces)
+- TriLane: localhost:8000 (signal/sessions/scale-software workspaces). Non-MCP agents (Pi) reach it over HTTP at `127.0.0.1:8000` — full contract (search via branch-scoped retrieval, memory read/write, live branch ids) in `trilane/TRILANE_HTTP_API.md`. Verified live 2026-06-23.
 - Clerk: production key deployed to Vercel + Railway. Frontend auth via `clerk.sttilsolutions.com` (verified). Google OAuth configured.
 
 ## Tip
 
-TriLane Memory now has the `research_insight` category live + 1 planted insight (CGM-to-pharmacy, salience 1.0) in the Signal workspace. Session summaries no longer leak into the Signal workspace; they live in the Sessions workspace.
+TriLane Memory has the `research_insight` category live in the Signal workspace. Session summaries live in the Sessions workspace (auto-flow), not Signal. Meeting/Granola notes also land in the Sessions workspace; Pi can query them over HTTP.
 
-## Updated: 2026-06-22 (Claude Code: Phase 2 built + verified. Pi: trust fixes applied, Phase 4 spec'd, Shield recon done. Next: Shield architecture design.)
+## Updated: 2026-06-23 (Claude Code + Kisa: locked the readiness-model redesign via brainstorming + cto-architect review; wrote the design brief for Pi at docs/readiness-model-brief-2026-06-23.md; added KG facts plan_type_policy/scope_exclusion/determination_explainability; shared today's AI-OS call notes for Pi; flagged the rotating-ID vs persistence tension. Next: Pi designs the build, then Claude builds.)
diff --git a/docs/agent-ready-ecosystem-handoff-2026-06-22.md b/docs/agent-ready-ecosystem-handoff-2026-06-22.md
new file mode 100644
index 0000000..b77fe9c
--- /dev/null
+++ b/docs/agent-ready-ecosystem-handoff-2026-06-22.md
@@ -0,0 +1,88 @@
+# Agent-Ready Ecosystem: Handoff to Pi for Spec Design
+
+**Date:** 2026-06-22
+**From:** Claude Code (analysis + live scan)
+**To:** Pi (design the integration spec); Claude Code builds after
+**Related:** `STTIL-Vault/Projects/2026-06-22-website-sttil-vs-signal-whitepaper.md` (copy audit, same project)
+
+## Goal (Kisa's words, paraphrased)
+
+Prepare sttilsolutions.com for where the agent web is going. Not necessarily ahead of the curve, but at minimum keeping pace as standards change in real time. The agent-readiness concept came from a coach call within the last month. Kisa has delegated the technical decisions, so this brief includes recommended defaults for each open question.
+
+## Governing doctrine (non-negotiable)
+
+Implement only what genuinely applies, and everything published must be REAL and resolvable. Never publish a card, endpoint, or metadata file for infrastructure that does not exist. Scanners penalize broken or faked artefacts, and faking it is dishonest. Honesty is also the better score strategy.
+
+## Live scan result (Cloudflare "Is Your Site Agent-Ready?", 2026-06-22)
+
+**Overall: 64 / 100, Level 4 "Agent-Integrated"** (Level 5 "Agent-Native" is the ceiling).
+
+| Category | Score | Pass/Total | Notes |
+|---|---|---|---|
+| Content Accessibility | 100 | 1/1 | Markdown negotiation works on the homepage |
+| Bot Access Control | 100 | 2/2 | AI bot rules + Content-Signal directives present for GPTBot, ClaudeBot, PerplexityBot, etc. |
+| Discoverability | 75 | 3/4 | robots.txt, sitemap.xml, Link headers all valid. Miss: DNS-AID records exist but DNSSEC not validated |
+| API, Auth, MCP & Skill | 43 | 3/7 | Pass: API Catalog, Agent Skills index, WebMCP (2 tools detected). Fail: OAuth/OIDC discovery, OAuth Protected Resource, MCP Server Card, A2A Agent Card |
+| Commerce | n/a | not checked | Correct, no store |
+
+## What is already solid (do NOT rebuild)
+
+The agent-ready plumbing is well-built and honest, not slopped in:
+
+- `robots.txt` with Content Signals, `sitemap.xml`, `llms.txt`, `llms-full.txt`, `index.md` all live with correct content-types.
+- RFC 8288 `Link:` header on the homepage with 5 valid relations (describedby, alternate, agent-skills, api-catalog, author). This is the hardest part to get right and it passes.
+- Markdown content negotiation on `/` (Accept: text/markdown returns markdown).
+- `.well-known/api-catalog` (valid linkset) and `.well-known/agent-skills/index.json` (2 skills) resolve.
+- `webmcp.js` is honest progressive enhancement: feature-detects `navigator.modelContext`, registers silently, never throws into the page, and its `request_walkthrough` tool opens the real demo form. The scanner confirmed 2 WebMCP tools detected.
+- MCP Server Card and A2A Card return 404, which is the correct, honest state today (no real endpoint behind them yet).
+
+## The core insight: the weak category is the unbuilt tiers
+
+The "API, Auth, MCP & Skill" category scores 43 because all four failures describe a real protected API or agent endpoint that does not exist yet. They map exactly onto the product tier model:
+
+| Tier | Product | Agent-ready artefact that becomes honest to publish |
+|---|---|---|
+| 1 | Worklist (CSV only) | Already covered by discovery + content + WebMCP request_walkthrough |
+| 2 | Connected (API) | OAuth/OIDC discovery, OAuth Protected Resource, MCP Server Card pointing at the real Signal API |
+| 3 | Intelligence (compliant support bot) | A2A Agent Card and/or an MCP server exposing the bot, once built and compliance-cleared |
+
+So the path from Level 4 to Level 5 is to build the real tiers and publish the matching cards when each ships. No faking. The product roadmap and the agent-readiness roadmap are the same roadmap.
+
+## The content-governance problem (cross-reference the copy whitepaper)
+
+The plumbing is good, but the CONTENT flowing through the agent files is stale and is not fed from a single source of truth, so it has drifted from the human pages. Agents quote these files verbatim:
+
+- `llms.txt`: "patients needing outreach" (violates the rule that Signal never conducts outreach).
+- `llms-full.txt`: banned "over 25% denied first pass" stat, SWO mis-defined as "Statement of Medical Necessity" (should be Standard Written Order), and exposed pricing ($149-199/mo) that appears nowhere on the visible site.
+- Agent Skills index: the 2 skills are detected but report "0 with valid v0.2.0 fields" — the entries need updating to the v0.2.0 schema.
+
+**Recommended architecture (the real "integrate into the ecosystem" answer):** one canonical fact source (brand architecture, locked stats, scope language, tier definitions) that generates or feeds BOTH the human HTML and the agent-readable files, so they can never disagree again.
+
+## Open design decisions (with recommended defaults, since Kisa delegated)
+
+1. **Agents act vs read.** WebMCP is already live and lets an agent open the walkthrough form. Recommendation: keep it, ensure the submitted data routes compliantly (no PHI), and add a `join_pilot` action only after the pilot intake is defined.
+2. **Single canonical fact source.** Recommendation: yes. Build it. It is the highest-leverage fix and prevents future drift.
+3. **What is safe to broadcast to agents.** Recommendation: remove pricing and any unverified stat from the agent files until there is a deliberate decision to make pricing public. Keep the credential-led founder framing.
+4. **Real MCP/A2A endpoint.** Recommendation: do NOT publish cards now. Design them as part of the Tier 2 API build so they point at a real endpoint. Honest-by-default.
+5. **Version control + deploy path.** The site has no git repo and serves from the VPS via Caddy; the `Link:` header lives in Caddy config. Recommendation: put the site under Forgejo before systematic edits, so every change is tracked and reversible. Confirm Caddy ownership of the header.
+6. **Scope.** This scan and plan cover sttilsolutions.com (marketing). signal.sttilsolutions.com and the Vercel app are separate surfaces, treat later.
+
+## Quick wins available now (no new product needed)
+
+- **Enable DNSSEC** on Cloudflare for sttilsolutions.com. DNS-AID records already exist; DNSSEC takes Discoverability from 3/4 to 4/4. Registrar/Cloudflare-side toggle.
+- **Update the 2 Agent Skills to the v0.2.0 schema** so they validate.
+- **Fix the agent-file content** (outreach wording, banned stat, SWO definition, pricing) in the same pass as the copy whitepaper.
+
+## Roadmap items (rise with the real product)
+
+- Tier 2 API ships, then publish OAuth/OIDC discovery + OAuth Protected Resource + MCP Server Card against it.
+- Tier 3 compliant support bot ships, then expose it via an A2A Agent Card or MCP server.
+
+## Compliance gate (hard requirement)
+
+The Tier 3 support bot touches AI behavior and bot functionality. It MUST pass `sttil-compliance-check` before any build. Kisa has stated the bot must be verifiably compliant, and the existing PHI architecture (patient_id only, no names/DOB/SSN) is the foundation that makes that achievable.
+
+## Build and verify protocol
+
+- Build agent-ready changes against a preview/staging surface first, never straight to the live site.
+- Verify by re-running the Cloudflare scan and the direct curl probes, confirm the level moved and nothing regressed, then deploy.
diff --git a/docs/readiness-model-brief-2026-06-23.md b/docs/readiness-model-brief-2026-06-23.md
new file mode 100644
index 0000000..a84602b
--- /dev/null
+++ b/docs/readiness-model-brief-2026-06-23.md
@@ -0,0 +1,89 @@
+# Signal Readiness Model — Design Brief for Pi
+
+**Date:** 2026-06-23
+**Status:** Design input for Pi. Pi produces the build design; then Claude builds.
+**Inputs:** Session 2026-06-23 product decisions + end-to-end simulation + independent cto-architect review (folded in).
+
+## 1. What Signal is
+DMEPOS CGM documentation-readiness tracker. CSV in produces a per-patient stoplight worklist flagging documentation gaps before claim/PA submission. Signal identifies; supplier staff act. No PHI beyond a client-supplied patient_id (random UUID). Stack: FastAPI (Railway) + Supabase + Vite/React (Vercel) + Clerk.
+
+## 2. Locked product decisions (authoritative; in the knowledge graph)
+1. Signal NEVER determines, guesses, or extrapolates the payer plan type. Client supplies plan type as a REQUIRED mapped field. Missing means "plan type needed", grade what we can, never guess.
+2. Signal does NOT determine eligibility or coverage. Remove that language from content. Rename "coverage" code to "readiness".
+3. Every determination CITES its basis: the rule that fired + the client-supplied input.
+4. Worklist unit = ONE record per patient UUID; all open items grouped; device detail nested.
+5. Multi-device is real (Dexcom CGM + Omnipod pump). CGM-only graded now; non-CGM preserved/displayed but NOT graded; other DMEPOS categories later.
+6. Monthly resupplies = separate dates of service, NOT duplicates. True duplicate = same patient + same device + same date of service.
+7. Validated PA-vs-claim: visit, SWO, PECOS, diagnosis are claim/coverage requirements (universal per LCD L33822). PA is the only prior-auth item, payer-dependent. Medicare FFS requires no PA. Medicaid heaviest (initial + renewal). Medicaid uses STATE enrollment, not PECOS.
+
+## 3. Recommended data model (5 entities, from the architecture review)
+Smallest model that satisfies the locked decisions.
+
+- **Patient (rollup unit):** patient_id (client UUID, only identifier, hashed in logs), org_id, coverage_lines[], rollup_status (DERIVED, never stored as truth).
+- **CoverageLine (the gradeable unit, the keystone):** key (patient_id, device_type, plan_id). plan_type REQUIRED + client-supplied/mapped: medicare | medicare_advantage | medicaid | commercial | UNKNOWN. gradeable:bool (true only for CGM this phase; pumps/other = false). shipments[], doc_items[], line_status (derived), timing_flag (existing CoverageFlag, per line).
+- **Shipment (history under a line):** key (patient_id, device_type, date_of_service). quantity, component, order_number, hcpcs. is_current:bool (exactly one per line = latest DOS).
+- **DocItem (one of the 5, per line):** doc_type (swo|visit|pecos|pa|diagnosis), required_state (REQUIRED|NOT_REQUIRED|NOT_EVALUATED, computed from plan_type+rules), input_state (SUPPLIED|ABSENT), value, source (csv|staff_override|computed), citation.
+- **Override (staff action, persisted):** key (org_id, patient_hash, device_type, doc_type). status, status_date, expiry_date, confirmed_by, confirmed_at.
+
+plan_type lives on CoverageLine, NOT Patient. Grade at the line; display rolls up to the patient. (Checked against per-patient-single-plan: dual-eligible and multi-device patients would mis-grade, credibility-ending in a documentation tool. One extra grouping key, not a new subsystem.)
+
+## 4. The verdict rule (kills the false green)
+Separate two axes the current code conflates into one string:
+- required_state: does this plan need this item? (from plan_type + rules, independent of CSV contents)
+- input_state: did the client supply data? (SUPPLIED | ABSENT)
+
+Per DocItem:
+- NOT_REQUIRED + any input -> satisfied (green-eligible)
+- REQUIRED + SUPPLIED + good -> satisfied
+- REQUIRED + SUPPLIED + bad -> gap (At Risk / Action Needed)
+- REQUIRED + ABSENT -> NOT_EVALUATED, blocks green, never satisfied
+
+Rule: a line is "Clear to Ship" only if EVERY required item is satisfied. One required-but-absent item forces at least Action Needed. Green is earned by positive evidence on every required item, never granted by absence of contradicting evidence.
+
+plan_type = UNKNOWN: cannot compute required_state, so the line is "Plan Type Needed" and structurally cannot be green. Still grade the universal items that do not depend on plan (SWO, visit, diagnosis per LCD L33822); PECOS and PA sit NOT_EVALUATED.
+
+Patient rollup: light = worst gradeable line. Hard floor: any gradeable line in "Plan Type Needed" caps the patient no greener than Action Needed. Severity: Plan Type Needed / At Risk > Action Needed > On Track > Clear to Ship. Ungraded non-CGM lines excluded from the light and tab counts. Tabs count patients, not rows.
+
+## 5. Cascade with citation
+Cascade entry = flat typed record (not a plain string, not event sourcing):
+- doc_type, severity (blocker|alert = Type A/B), reason, rule_id (names a key in payer_rules.json), client_input ("you marked plan type = Medicaid"), requirement, basis, rules_version.
+Display string is RENDERED from these fields, not stored as prose.
+Prerequisite: rules become addressable data. Move the _PECOS_REQUIRED / _PA_REQUIRED / _PA_NOT_REQUIRED logic OUT of Python sets and INTO payer_rules.json with stable rule IDs, so the citation points at the same data that drove the decision. Also fixes a latent bug: the Python sets and the JSON can currently disagree.
+
+## 6. Override + recompute + rollup
+- Override keyed (org_id, patient_hash, device_type, doc_type). Frontend cache keyed `${patient_id}:${device_type}`. Without device_type an override leaks across a patient's devices (present bug).
+- Scope: VISIT is patient-scoped (the visit is the person; fans out to all that patient's gradeable lines). SWO / PA / diagnosis / PECOS are line-scoped. Current code treats everything as patient-scoped, which is why confirm-visit works and doc-status leaks.
+- Recompute returns { line: updated line, rollup: new patient status }. Recompute the overridden line, then re-roll-up the patient. No full batch rebuild per click.
+
+## 7. Dedup / aggregation
+- Group by patient UUID; keep per-device detail.
+- True-duplicate key = (patient_id, device_type, date_of_service). SMALL OPEN DECISION: the current code's dedup key also includes order_number. If DOS-level dedup is the contract, drop order_number from the key and keep it as a displayed attribute. Recommended default: drop it, treat same patient+device+DOS as one, keep latest. Pi/Kisa to confirm.
+- Split-shipment tiebreaker: same patient+device+DOS with different quantities is not a duplicate; define (sum quantities, or order by ingestion).
+- Grade the CURRENT shipment only (latest DOS per line); keep prior shipments as collapsed history. Today calculate runs per record, so 6 months of history = 6 worklist lines (the row-vs-patient bug).
+
+## 8. Live bugs in the current code (this pass exists to fix these)
+- Worklist is ROW-keyed, not patient-keyed end to end (rowKey = patient_id + index; localDocStates keyed by bare patient_id; one result per shipment). Decisions 4/5/6 assume a patient-grouped model the code does not implement. This is the core work.
+- Plan-type GUESSING is still live: _normalize_payer keyword-matches the payer name, and a `default` payer config + raw-string fallback can grade an unknown plan and show green. Both violate decision #1. Consume the client-mapped plan_type field; use the payer NAME only for display; route unmatched/unknown to "Plan Type Needed", not `default`. Remove the default grade path.
+- Override leak across a patient's devices (see section 6).
+
+## 9. The 5 tracked items + rules engine
+doc_state_machine.py grades SWO, qualifying visit (6-month), PECOS (Medicare/MA only), PA (MA/Medicaid/Commercial; not Medicare FFS), diagnosis. Rules in payer_rules.json. Medicaid uses state enrollment not PECOS; the Medicaid state-enrollment item is DEFERRED for the pilot (PECOS shows N/A for Medicaid), documented as a known gap, not an omission.
+
+## 10. YAGNI / pilot scope (hold the line)
+- Grade CGM only; non-CGM lines exist + display but gradeable=false. No multi-category grading.
+- Six-field flat cascade entry; no event sourcing, no per-entry history (the audit log exists).
+- No Medicaid state-enrollment item this phase.
+- Override scope = the two facts staff change: visit (patient-scoped) + SWO/PA (line-scoped). No general override framework.
+- Recompute returns {line, rollup}; no full re-batch per click.
+
+## 11. Original blockers + trust fixes (mapping)
+- Blocker 1 (MA misclassification) -> DELETE the name-guesser + require plan type + remove `default` grade path.
+- Blocker 2 (duplicate patient_id) -> patient-grouped aggregation with per-device detail + DOS-level dedup.
+- Blocker 3 (override does not recompute) -> device-keyed override + recompute + re-roll-up; persist override on next upload.
+- Trust: retention 6 years (fix 2 stale "7 year" lines); privacy BAA wording attorney-gated (not built by us); audit-log persistence to DB (verify; part of override path).
+
+## 12. Proposed build sequence (after Pi's design)
+Rename coverage->readiness -> extract rules to addressable config (IDs) -> patient/line/shipment grouping + required-vs-input verdict -> device-keyed override + recompute + rollup -> require-plan-type + client value-mapping + remove guesser/default -> frontend nesting + "plan type needed" state. code-auditor reviews each before it ships.
+
+## 13. The ask for Pi
+Take a stab at the build design from this model. Resolve the small dedup order_number decision (section 7), the frontend nesting/UX for patient -> device -> doc plus the "plan type needed" state, and the client plan-type value-mapping UX at import. Keep it pilot-scoped. Hand back; then Claude builds.