AI Foundation — validated against 2026–27 state-of-the-art (and the KB/graph storage answer)¶

Date: 2026-06-04 · Owner: Gene · Purpose: pressure-test our AI foundation (KB 01–05 + synthesis) against how a top-tier AI architect builds at scale in 2026–27 — and answer "how should the KB and the graph be held." Portability note: this foundation is vertical-agnostic — a generic healthcare-AI platform (knowledge layer · retrieval · guardrails · data backbone · serving). Swap the engines and it applies equally to a telehealth vertical. Saved here as a reusable reference.

Verdict: the bones are right and current. The big bets — a compound (not single-model) system, hybrid retrieval, a deterministic-gated safety boundary, on-device + cloud, knowledge-as-data, provenance, GMLP/PCCP — are exactly what 2026–27 SOTA prescribes. But a frontier architect would push us on four upgrades (§3). Fold those in and the answer to "is this how the best would build it?" is yes.

1 · Where we're already aligned with 2026–27 SOTA (the big bets, confirmed)¶

Our decision	2026–27 SOTA says	Verdict
Compound system (knowledge + retrieval + rails + engines), orchestration-heavy	Agentic/compound systems are the dominant 2026 pattern; "a weaker model with strong orchestration beats a stronger model with poor orchestration."	✅ on-trend
Hybrid retrieval — structured → vector → GraphRAG (fixed trust order)	"The best production architecture is not pure Vector RAG or pure GraphRAG. It is hybrid." Buyer intent for hybrid retrieval tripled (10%→33%) in Q1 2026.	✅ exactly right
Graph = property graph (Neptune/Neo4j); vector = Qdrant/Milvus/pgvector	Neo4j + GenAI ecosystem = the production-grade graph choice; Pinecone/Weaviate/Qdrant/Milvus lead vector.	✅ correct stack
Deterministic clinical-line rail wrapping a probabilistic brain (defense-in-depth)	Guardrails + offensive-security + audit logs + defensive validation are the named best practices.	✅ correct posture
On-device + cloud, cache-as-cost, observability, GMLP/PCCP	Matches scale + governance SOTA.	✅ correct

Bottom line: nothing in the foundation is wrong or dated. It's a strong 2025-grade architecture.

2 · The KB + graph storage answer (your direct question — sharpened by the research)¶

A frontier 2026–27 architect would not treat the KB and the graph as two hand-maintained stores. The pattern is one source of truth, many indexes, one access protocol:

Hold the KB (and the canonical clinical data) as versioned, governed data in a LAKEHOUSE — Apache Iceberg tables (queryable by Snowflake/Trino/Spark/Athena). The lakehouse is the single source of truth; security, lineage, and governance live there once and are reused as shared services (the 2026 "metadata/semantic layer" pattern). The curated-KB rows (versioned, author≠approver, clinical-line-flagged) are Iceberg tables — knowledge-as-data, exactly as KB01 said, now with a concrete home.
Hold the graph as a PROJECTION of that canonical data, not a competing truth. A property graph (Neptune/Neo4j) materializes the clinical ontology (drug↔class↔interaction↔FRID) + the live member/event graph, kept in sync via the event backbone (KB05's Kafka log). So the graph is an index for multi-hop reasoning, derived — never a second source you must reconcile. (Graph-on-lakehouse engines, e.g., Neptune Analytics, avoid a separate ETL'd store entirely.)
The vector store is also a projection/index over the same canonical data (embeddings of KB rows + docs).
Expose all of it through ONE protocol — MCP (Model Context Protocol) (§3.3), so every engine queries the knowledge the same way and governance isn't re-implemented per engine.
Cost-efficient GraphRAG: use LazyGraphRAG-style variants (Microsoft) — ~0.1% of full GraphRAG indexing cost, ~700× lower query cost for global queries — so the graph is affordable at 6M scale.

One line: the lakehouse is the truth; the graph and the vector index are projections of it; MCP is the one door in. That's the 2026–27 way to hold the KB + graph — and it's a refinement of, not a contradiction to, KB01.

3 · The four upgrades a frontier 2026–27 architect would add¶

Frame it as "context engineering," not just RAG. SOTA: context engineering is replacing prompt engineering as the central discipline — a model's intelligence is increasingly set by the quality of assembled context. Reframe our knowledge+retrieval+memory layer as a context-engineering layer whose job is to assemble exactly the right grounded context per decision. (RAG isn't "dead" — it's subsumed into context engineering.)
Make retrieval agentic + add a per-member MEMORY layer. SOTA: agentic RAG (retrieve → judge sufficiency → find gaps → pull more → synthesize → adapt) improves faithfulness ~42% vs single-step; and agent memory (short- + long-term, per user) is now standard. This is the highest-value upgrade for us — a per-member longitudinal memory is literally our "longitudinal baselines = the moat" thesis, made architectural. Our hybrid retrieval becomes the tool an agentic-retrieval loop calls, with a memory store on top.
Wire the interfaces with MCP (Model Context Protocol). SOTA: MCP is the industry standard for AI↔tool/data connectivity ("USB-C for AI") — ~97M monthly SDK downloads, backed by Anthropic/OpenAI/Google/Microsoft/AWS. KB01's "one API contract to the knowledge layer" should be an MCP server (the knowledge layer, the rails, the tools all exposed via MCP) — so engines plug in via the standard, not bespoke APIs, and it scales/horizontally-loads cleanly (the 2026 stateless-MCP roadmap).
Treat evals as the spec (eval-driven development). SOTA: retrieval-optimization + evaluation are now top investment lines. We have RAGAS + a clinician gold set + rail-escape-rate (KB02/03/05) — elevate them to the central artifact: every engine change is gated by an eval suite, and the clinician gold set is the contract.

None of these invalidate the foundation — they sharpen it. With them: context-engineering layer (frame) → agentic retrieval + per-member memory (the brain's recall) → over a lakehouse-held KB + graph projections (storage) → exposed via MCP (interface) → behind the deterministic pharmacist-gated rail (safety) → on the on-device+cloud serving tier (scale) → eval-gated (quality).

4 · The honest "is this the best way?" answer¶

Architecture/safety posture: yes — the deterministic-gated, pharmacist-in-the-loop, knowledge-as-data, provenance-first design is better than the typical 2026 build (most teams ship probabilistic-only guardrails; ours is correctly defense-in-depth for a clinical-adjacent product).
Storage: upgrade to the lakehouse-as-truth + graph/vector-as-projections + MCP pattern (§2) — that's the frontier answer and it's a clean refinement of what we have.
Recall: upgrade to agentic retrieval + per-member memory + context-engineering framing (§3.1–3.2) — this is where we'd otherwise lag a top 2026–27 team.

5 · Reuse for the Generation Pharmacy telehealth vertical¶

This foundation is engine-agnostic: a telehealth vertical would swap the five wellness engines for telehealth ones (visit intake, triage, e-prescribing, follow-up, care navigation) and reuse the same knowledge layer, context-engineering/retrieval, deterministic guardrails, data backbone, serving tier, and governance unchanged. The four upgrades (§3) apply identically. If it's superior to the current telehealth-vertical approach, this KB + synthesis + this validation are the portable blueprint to lift over. (Kept in the Rx360 working folder; no cross-context Drive access — lift the files where you want them.)