Skip to content

AI Foundation — KB Synthesis (the brain, decided)

Date: 2026-06-04 · Owner: Gene · Input to: the AI Foundation Architecture spec. What this is: the load-bearing decisions from the five KB docs (01 knowledge · 02 retrieval · 03 guardrails · 04 scale · 05 data/governance), distilled into the foundation we build on — so the five engines plug into one brain instead of growing five half-brains.

✓ Validated against 2026–27 SOTA (_SOTA_VALIDATION_2026.md): the bones are right + current; four frontier upgrades to fold in — context-engineering framing · agentic retrieval + per-member memory · MCP interfaces · lakehouse-held KB with graph/vector as projections.

The one thesis all five docs converge on, independently: the brain is probabilistic; the boundary is deterministic and clinical-gated. A pharmacist-curated knowledge layer feeds grounded retrieval; an LLM reasons; but a deterministic, fail-closed rail with a pharmacist-in-the-loop wraps every member-facing output. That single pattern is what drives clinical-line leakage to a bounded, measured ~zero — enforced by the fail-closed output-schema allow-list + default-deny (not lexicon completeness) — turning it from a statistical hope into an engineered, auditable boundary, and it's the answer to "will the brain work properly."

A · The 12 load-bearing decisions (the foundation, locked-in-principle)

Knowledge — what the brain knows 1. One shared knowledge layer, two parts: a curated KB + a Knowledge Graph. KG = a property graph (Amazon Neptune or Neo4j) of drug/class/FRID/interaction/member/event nodes anchored to RxNorm/RxClass/SNOMED/ATC; RDF/triple-store only for the terminology spine. (KB01) 2. Knowledge is data, not code. The curated-KB row is versioned, author≠approver, effective-dated, clinical-line-flagged, updated through a no-code-release lifecycle (OHDSI/ATHENA + FHIR PlanDefinition pattern). Pharmacy owns it; every fact is traceable. (KB01 — exactly the "rules-as-config" the med-engine audit demanded.) 3. One API contract to the knowledge layer, returning a provenance envelope on every response — so all five engines query the same brain the same way. (KB01)

Retrieval — how it recalls the right fact 4. Hybrid retrieval in a fixed trust order: structured/deterministic lookup FIRST (RxNorm/RxClass/NDC/KB tables) → vector/semantic → GraphRAG (multi-hop polypharmacy), query-routed. Don't let the vector store answer what a table can answer deterministically. (KB02) 5. A deterministic rule check wraps every model output — grounded RAG still hallucinates at single-digit rates, and single-digit ≠ zero at 6M users. Grounding (Self-RAG/CRAG/citation-enforcement) lowers the rate; the rail makes it zero. (KB02 + KB03 — the same conclusion from two directions.) 6. Vector stack: start pgvector → graduate to Qdrant/Milvus; HNSW; hybrid BM25 + vector + RRF + rerank. Eval with RAGAS + a clinician gold set + the rail escape-rate. (KB02)

Guardrails — how we guarantee it never goes off-script 7. Defense in depth with heterogeneous failure — probabilistic "speed bumps" (Llama Guard 3 + OpenAI moderation + Guardrails-AI validators, orchestrated by NeMo Guardrails' 5-rail taxonomy) plus the deterministic clinical-line "blast door." They must fail differently; stacking homogeneous checks just multiplies the same failure. (KB03) 8. The deterministic clinical-line rail is terminal and fail-closed — non-ML lexicon/pattern + allow-listed schema (reminder | confirmation | insight); on any match / low-confidence / schema-violation / timeout or error → block + route to the pharmacist queue. Default state = "do not emit." It IS the FDA wellness-vs-SaMD boundary enforcer; the pharmacist queue is the architectural HCP-in-the-loop. (KB03 — directly extends our existing rail.) 9. Two hard rules from the failure cases: (a) don't stream member-facing clinical-adjacent output — buffer fully, gate before the first token reaches the member (streaming can leak before the rail fires); (b) HITL/approval enforced in code outside the agent's reach (Copilot CVE: an agent rewrote its own approval settings) + a circuit breaker on fleet-wide actions (CrowdStrike: one bad signal bricked 8.5M machines). Treat OCR'd Rx text as untrusted (injection vector). (KB03)

Scale + Data — how it runs for 6M and improves safely 10. Three-tier hybrid by time-criticality × data-sensitivity: on-device (TinyML ~7 ms, offline scheduling, on-device Rx OCR) for the time-critical/PHI path → BAA-covered private-cloud tier (Apple Private-Compute pattern) for escalations → cloud back-of-house for training, the versioned RAG/KB, batch. Routing = sensitivity > complexity > confidence-cascade. (KB04) 11. Caching is a financial requirement, not an optimization — semantic cache (~40–68% hit) + prefix cache (~90% cost cut) + vLLM continuous batching (2–24×) + a self-hosted gateway/router (40–70% savings) are what make 6M users affordable. Deterministic offline fallback + quality circuit-breakers keep it reliable when the model/network is down. (KB04) 12. One canonical data backbone + a clinical-gated learning loop. A Kafka-class event-streaming log + schema registry as system-of-record; FHIR R4/US-Core interchange; the medication-object + FHIR Provenance (self ×0.5 → pharmacist ×1.0) as the shared contract, first-class queryable; operational vs learning planes physically split by a de-identification gateway (Safe Harbor default); GMLP + PCCP built-in so wellness→SaMD needs no re-architecture; and a non-skippable, event-logged pharmacist sign-off gate — no model writes clinical content. (KB05)

B · The brain, consolidated (one architecture)

ENGINES ──ask(grounded)──►  RETRIEVAL (02): structured→vector→GraphRAG, fixed trust order
        ◄──fact+provenance──        │  grounded (Self-RAG/CRAG)
                                     ▼
                       KNOWLEDGE LAYER (01): curated KB + KG (property graph),
                                     │       knowledge-as-data, one API + provenance envelope
ENGINES ──act(gated)────►  GUARDIAN RAILS (03): NeMo orchestrator → Presidio PHI-redaction
                                     │  → Llama-Guard/moderation/validators (speed bumps)
                                     ▼  → ► DETERMINISTIC CLINICAL-LINE RAIL ◄ the blast door
                                          fail-closed → pharmacist (HCP) queue  |  else emit {reminder|confirmation|insight}
        ┌──────────────────────────── runs on ────────────────────────────┐
        │ SCALE (04): on-device(TinyML/offline) → BAA private-cloud → cloud │
        │   vLLM batching · semantic+prefix cache · self-host gateway · RLS │
        │ DATA/GOV (05): Kafka log + schema registry · FHIR · de-ID gateway │
        │   provenance contract · MLOps (holdout/MRT/drift) · GMLP+PCCP     │
        │   · non-skippable pharmacist sign-off gate                        │
        └──────────────────────────────────────────────────────────────────┘

C · Build order (foundation-first — same discipline as the engine plan)

  1. The shared contract + knowledge layer — the medication-object/FHIR contract (already Phase 0 of the engine plan) + the curated-KB schema + the KG. Everything grounds here.
  2. The event backbone + de-ID gateway — the Kafka-class log, the schema registry, the operational/learning split. You can't learn from data you can't legally use.
  3. The deterministic clinical-line rail — built before any model can emit to a member. Rail before you generate.
  4. Retrieval — structured-first hybrid RAG over the knowledge layer, grounded.
  5. The probabilistic guardrails (NeMo + classifiers + validators) around the model.
  6. The serving/scale tier — on-device-first, cache-heavy, with offline fallback.
  7. The learning loop — MLOps with the pharmacist sign-off gate + holdout/MRT/drift.

Rule of thumb: ground before you generate · rail before you emit · de-identify before you learn · pharmacist-gate before any clinical-affecting change · cache before you scale.

D · What this changes / how it feeds the engines

  • The five engines stop reinventing the brain. Balance Meter, Smart Scheduling, Med-Input Intelligence, Refill, and Triage all plug into the same knowledge layer, retrieval, rails, data backbone, and serving tier.
  • The med-object contract (engine Phase 0) is the first concrete artifact of this foundation — it's the shared contract decision #12 names.
  • The deterministic rail unifies three things we'd been treating separately: the scheduling safety rail (KB04-SmartSched), the med-input guardrails, and the wellness/SaMD boundary — they're one rail, platform-wide.
  • It's regulated-ready by construction (GMLP + PCCP + the de-ID gateway), so the wellness→reimbursable-SaMD ramp (the acquisition story) needs no rebuild.

E · Open questions for the room

  1. Build vs buy the orchestration (NeMo Guardrails) and the graph DB (Neptune vs Neo4j) — and the LLM (self-hosted Llama-class for PHI vs API behind redaction).
  2. Where the on-device/cloud line sits per engine (the routing policy) — and the minimum offline-deterministic behavior.
  3. Who owns the platform vs the engines — this foundation needs a clear owner (a platform/infra lead) so it doesn't fragment.
  4. Sequencing vs the engine builds — do we stand up the foundation (contract + rail + backbone) before Phase 1 of the Medication Intelligence Engine, or in parallel? (rec: contract + rail first; they gate everything.)

F · KB contents

Doc Status Sources
01_Knowledge_Layer_KB_KG.md ✅ 28
02_Retrieval_RAG_GraphRAG.md ✅ ~45
03_Guardrails_Safety_Layer.md ✅ ~130 cites
04_Scale_Infrastructure_6M.md ✅ 35
05_Data_Governance_MLOps.md ✅ 33
_KB_SYNTHESIS.md (this) ✅ —

Next: turn this into the AI Foundation Architecture spec (the doc the Medication Intelligence Engine plan and every engine builds on); the shared medication-object/FHIR contract is the first piece to lock.