Skip to content

MERIDIAN - Last 1 Health Intelligence Layer

Specification v0.1

Confidential - Last 1 Enterprises trade secret

Status: ACTIVE PARALLEL TRACK. Name: Meridian. Nested, not standalone: a capability inside last.vet and last1.app / Onset (meridian.last1.app-style surfaces). No standalone domain purchases. One sentence: Meridian is the intelligence layer of the coordination layer - it reads what the ecosystem uniquely holds (the consented cross-provider record, the loop events, the verified outcomes) and returns understanding: to the veteran first, then the provider, then the org.

THE MOAT THESIS (why Meridian is defensible and a bolted-on chatbot is not)

The model is not the moat. Anyone can call a foundation model. The moat is the stack only this ecosystem can assemble: 1. The substrate - consented, verified, two-source health-coordination data (loop ledger + records + outcomes). Cannot be bought or scraped; only accumulated by doing the work. 2. The grounding architecture - Meridian answers ONLY from the individual's consented record and the ecosystem's verified data, with citations. Proprietary. 3. The guardrail + evaluation stack - the definition and proof of "safe" for veteran health AI. Proprietary, and itself a regulatory/partnership asset. 4. The specialized models - small, from-scratch, trained on ecosystem data (outcome prediction, care-gap detection, priority ranking, matching). Where the patents live. 5. The return path - Meridian's outputs go to the person first (their own record, explained). Structural differentiation no org-centric AI can copy without inverting who it serves.

ARCHITECTURE (two-layer model strategy)

Language layer - leased physics, IP-clean: - Open-weights base model under Apache 2.0 license only (Mistral / Qwen-class). NOT Llama-licensed models (restrictions). License file archived with counsel. - Self-hosted for anything touching PHI - weights run on our infrastructure; data never leaves. (Dev/M0 may use API models on SYNTHETIC data only.) - Fine-tunes and adapters produced later on ecosystem data are proprietary weights. - The base model is a SWAPPABLE COMPONENT behind an internal interface (MeridianModelProvider). Nothing above the interface knows which model runs.

Specialized layer - owned intelligence, from scratch: - Small purpose-built models, trained from scratch on ecosystem data as it accumulates: outcome prediction (loop → likely delta), care-gap detection, coordination-priority ranking, care matching (MATR-sibling methods). - These are the patent candidates and the true from-scratch IP - feasible at this scale, novel as methods, un-replicable without the data.

Proprietary system components (all trade-secret from day one): - Orchestration layer (routing between retrieval, models, guardrails) - Grounding/RAG over consented FHIR + loop ledger (consent-scoped retrieval - the retriever itself enforces the grant; a query can never see what consent doesn't cover) - Guardrail stack (below) - Evaluation harness + red-team suite (below)

HARD RULES (non-negotiable, enforced in code and evals)

  1. No diagnosis. No treatment recommendations. Meridian explains, summarizes, navigates, and drafts - it never tells anyone what condition they have or what treatment to pursue. (Keeps CDS/FDA posture clean; same line as Onset's intended-use question - HL reviews Meridian's claims language too.)
  2. Grounding-only with citations. Every factual statement about a person's health traces to a specific element of their record or ledger. No general medical knowledge presented as fact about the individual. Ungroundable question → says so.
  3. Consent-scoped retrieval. Meridian sees exactly what the active grant covers. Part 2 data respected. Revocation applies to Meridian instantly.
  4. Crisis is not Meridian's job. Any distress signal → the crisis protocol verbatim (988/VCL, one tap). Meridian never counsels, never assesses risk, never delays the handoff. This is tested in the red-team suite, permanently.
  5. Two-data-plane applies. Meridian never trains on identified data. Training pipelines consume de-identified data only (HIPAA de-identification standard), and only after that pipeline is counsel-approved. Until then: SYNTHETIC ONLY.
  6. Disclosure. Every Meridian surface says it's AI, says what it can't do, and shows its citations. The veteran can always see why it said what it said.
  7. PHI hosting gate. No real veteran data touches Meridian until: self-hosted weights + infrastructure BAA posture resolved (rides the Railway/BAA decision).

M-GATES (parallel lane, tied to main-gate data availability)

M0 - the system, on synthetic (NOW). Build: MeridianModelProvider interface · consent-scoped RAG over VA sandbox FHIR (synthetic personas) · guardrail stack v1 · evaluation harness + red-team set (the deliverable that defines "safe") · internal dev surface only. Exit: Meridian(dev) explains a synthetic veteran's record end-to-end with 100% grounding-citation rate on the eval set and zero rule-1/rule-4 violations on the red-team suite. No veteran-facing anything.

M1 - care-navigation explainer (with Gate 1). Veteran-facing, feature-flagged, behind the M0 safety bar: "explain my record," "help me prepare for this appointment," "what does this result mean in plain language" (grounded definitions, not diagnosis). Rides the Radio Check clock like everything else.

M2 - coordination intelligence (with Gate 2). Provider side: drafts the coordination note from the record (anti-double-entry, delivered by AI) · flags gaps (unclosed loops, missed follow-ups, cross-provider conflicts) as ITEMS FOR HUMAN REVIEW, never auto-actions.

M3 - outcome intelligence + owned weights (post-Gate 2). Fine-tune on de-identified ecosystem data → proprietary adapters/weights · specialized models begin training (outcome prediction first - it feeds the funder reports and the last1.org standard) · civilian deployment (last1.app / Onset) of the same engine minus VA plumbing.

IP TREATMENT PER COMPONENT

Component Instrument
Orchestration, RAG, guardrails, eval harness Trade secret (designate now)
Fine-tuned weights/adapters Trade secret + contractual
Specialized models (methods) Patent candidates (provisionals when built)
Consent-scoped retrieval method Possible method patent - WS/HL opinion
Base model Apache 2.0 - license archived, no claim

OPEN DESIGN QUESTIONS (the hand-in-hand list - work these with Claude, in order)

  1. Backbone selection: which Apache 2.0 model family, what size, hosted where (the self-hosting infra decision rides the BAA/hosting item).
  2. Retrieval shape: raw FHIR → structured intermediate summary → retrieval, or direct FHIR retrieval; how loop-ledger events join the record in one index.
  3. The eval bar - DECIDED: see MERIDIAN_EVAL_SPEC.md (suites A/B/C, thresholds, sign-off). M0 harness builds in private repo last1-meridian per MERIDIAN_M0_KICKOFF.md.
  4. Surface form at M1: chat, or structured cards on the existing IA (lean: cards first - "explain this record section" - chat is scope gravity).
  5. Memory: does Meridian remember across sessions, and where does that live under two-data-plane.
  6. Civilian variant boundaries: what Onset's Meridian can say (wellness framing - ties to the FDA intended-use answer).

NAMING LOCK (September 2026 - do not overload "M1")

Name Meaning
M0 Eval harness + crisis wiring on synthetic (done)
M1 Care-navigation explainer only ("explain my record," appointment prep, plain language). Prompt/RAG iteration lifts Suite A/B for the explainer. Not the matcher.
M2 / M3 Coordination intelligence / outcome intelligence (unchanged above)
Matcher-0 Net-new care matcher (the moat): veteran profile/needs → care matched to this veteran + provider request templates. Parallel build to M1. Not an M1 iteration.
Service Matches iOS/API presentation of matcher output (or honest preview). Not the matcher itself.

m1_eligible (safety go-live, one gate): clinical advisor formal sign-off on the crisis blocklist/triggers (crisis.blocklist_advisor_signed) plus the eval bar. One clinical signature gates any live Meridian intelligence to real veterans (explainer or matcher). Favorable review ≠ signed sign-off. Synthetic build and dashboard preview proceed without it.

SERVICE MATCHES + MATCHER-0 (iOS dashboard - September 2026 addendum)

Decision: LastVet iOS Home exposes Service Matches as a primary dashboard section: the matcher presentation layer for veteran-facing coordinated care. This is a conscious pull-forward of matcher output onto the beneficiary read surface. Matching intelligence is built as Matcher-0 in Meridian (consent-scoped), not by iterating the M1 explainer.

  • Service Matches = matched care cards on the coordination dashboard (provider/org intro + request template presentation).
  • Matcher-0 = the net-new matcher that produces those cards (synthetic first; live only after m1_eligible + PHI hosting).
  • M1 care-navigation explainer = a separate surface later (chat or structured cards elsewhere in IA). Do not conflate explainer UI with Service Matches. Do not call matching "M1."

THE ARC consent rule (hard - core property of Matcher-0): Meridian matches and presents provider request templates. Meridian never authors grant scope on its own judgment. The veteran approves or edits before any share. Enforced in code when Matcher-0 is built (no path writes grant scope without veteran action). Go-live of real matches to real veterans remains gated on clinical sign-off (m1_eligible); the dashboard section may ship earlier with honest preview copy.

Matcher-0 Gate 2.1 lock (2026-09-10)

  1. Matcher only attaches provider-authored templates (authoredBy: provider, scopeSource: provider_template). Never synthesizes scope.
  2. requiresVeteranApproval: true is a literal in the type on every match.
  3. No API path creates/activates a grant from matcher output without explicit veteran approve/edit.
  4. !m1_eligible ⇒ response mode: preview with honest notice (not fake live).
  5. Shared safety foundation: crisis_gate and safety_refusal_gate fire on matcher surfaces/interactions as well as the explainer. All Meridian surfaces share the same deterministic safety short-circuits; the matcher is not a bypass.

Cross-track API contract: lastvet-gates/docs/architecture/SERVICE_MATCHES_API_CONTRACT.md (GET /api/veteran/me/service-matches).

Matcher-0 Deepen (D1–D4, synthetic) - locked

Architecture: Deterministic multi-signal ranker over a real provider catalog. Not LLM-picks-matches. Same veteran + grant + NeedProfile → same matches (reproducible, auditable). Intelligence ranks; it does not decide what to share (ARC-safe by architecture).

Gate Status
D1 Provider catalog + NeedProfile fixtures; match(persona, grant, needs, m1_eligible) → ServiceMatchesResponse
D2 NeedSignal extraction from bootstrap chunks + declared needs; cited rationales
D3 Suite M (~28 cases) + deterministic graders (meridian-eval run-matcher)
D4 last.vet-api wires the same ranking engine (synthetic); no hardcoded match ranks
D5 PARKED: LLM rationale polish + vector RAG - only if Suite M shows bootstrap insufficient

Lane-priority policy: NOT hardcoded. Rank by signal strength only (neutral across lanes). Deliberate priority (e.g. MH before career, acute before aspirational) is a Ryan + Mic care judgment - see fixtures/matcher/MATCHER_LANE_PRIORITY.md.

Still blocked for live: Gate 2.4 (Mic signature / m1_eligible, PHI hosting, HL on Arc).

Matcher-0 eval substrate: VA-shaped synthetic test patients

Differentiated personas (not identical PTSD clones):

Persona Record-signal lane Provenance
persona_alpha mental_health (PTSD / PHQ-9 / sertraline); honest Part 2 cond-sud source: va_shaped_synthetic
persona_bravo housing (SDOH shelter / housing instability) source: va_shaped_synthetic
persona_charlie career (unemployment / vocational) source: va_shaped_synthetic

Suite M record-diversity cases (M-070+) assert different top matches/citations from record signals with empty NeedProfiles. Not live PHI.

Demo-0 (Service Matches visible) — locked

Read-only iOS vertical: Home Service Matches loads GET /veteran/me/service-matches. Ranked cards + citations + provider templates. Unmissable synthetic labeling (banner + SYNTHETIC badges + API previewNotice). CTA disabled (Review later). No share POST. No live-mode claim.

GUARDRAILS ON THE WORK ITSELF

  • M0 never blocks Gate 0 close, the sprint, or the ED track. It is the parallel lane.
  • No veteran-facing Meridian before M0 exit criteria + clinical advisor review.
  • Synthetic data only until the PHI hosting gate clears.
  • The everything-app rule applies to AI hardest of all: Meridian does the three capabilities in this spec. Feature requests beyond them go to PARKED.