Data Foundation, Governance & MLOps Lifecycle — the brain's safe substrate¶

Date: 2026-06-04 · KB doc 05 · Owner: Director of Pharmacy Operations Purpose: Design the data + governance + model-lifecycle foundation that lets all five engines (Balance Meter · Smart Scheduling · Med-Input Intelligence · Refill · Triage) share one safe data substrate, work correctly at ~6M users, and improve over time without breaking — while staying in the consumer-wellness lane and architected to cross into reimbursable RPM/SaMD later without a re-architecture.

Companion docs: _RESEARCH_PLAN.md (this KB's plan), KB 01_Knowledge_Layer, 02_Retrieval, 03_Guardrails, 04_Scale_Infrastructure. Extends: the Smart Scheduling KB04 pattern (RAG over a pharmacist-curated drug-KB behind a deterministic safety rail + a learn→validate→sign-off→gated-deploy loop) and the Medication Intelligence Engine's medication-object contract — and turns both into a platform.

Reader's takeaway in one line: Stand up one canonical data model on an event-streaming backbone with FHIR as the interchange and the medication-object + provenance model as the shared contract; de-identify at the boundary so operational-PHI never reaches the learning store; run a versioned, gated MLOps lifecycle (feature store → retraining → off-policy eval → micro-randomized/A-B trials → canary + auto-rollback, against a never-touched holdout); and wire FDA GMLP + a Predetermined Change Control Plan (PCCP) in from day one so a wellness model can become a SaMD later — with a clinical sign-off gate that no model can bypass: no model writes clinical content.

Wellness-lane guardrail (applies to every section): The platform learns from behavior and de-identified clinical data; it never generates dosing advice or drug-drug-interaction logic from a model. Every clinical-affecting fact is served from the curated KB verbatim or routed to a pharmacist (KB04 §2; KB03). The data/MLOps machinery below exists to make that line enforceable and auditable at scale, not to relax it.

0 · The five decisions this doc locks¶

#	Decision	Sets the foundation for
D1	One canonical event-streaming backbone (Kafka-class log + schema registry) is the system of record for cross-engine data; engines integrate by publishing/subscribing to versioned events, not by calling each other's databases.	Shared data; replay; new-engine onboarding with zero source changes
D2	FHIR R4 / US Core is the interchange contract; the medication-object + Provenance is the shared clinical record, with provenance weight `self ×0.5 → pharmacist-verified ×1.0` materialized as a first-class, queryable field.	Interoperability; the med-object contract; SaMD-readiness
D3	De-identify at the boundary. Operational-PHI lives in a HIPAA-controlled store; a de-identification gateway (Safe Harbor by default, Expert Determination for richer learning sets) is the only path into the learning lake. The learning store never holds raw PHI.	The entire PHI/HIPAA posture; consent enforcement
D4	A gated MLOps lifecycle — feature store → versioned datasets/models → off-policy eval → MRT/A-B → canary + auto-rollback — measured against a never-touched holdout, with drift detection triggering the loop.	The "improve over time without breaking" requirement
D5	GMLP + PCCP from day one, with a clinical sign-off gate embedded as a required, non-skippable step for any clinical-affecting change.	Regulated-ready posture; the human gate; total-product-lifecycle compliance

1 · The data foundation — canonical model + streaming backbone¶

1.1 The problem at 6M users¶

Five engines that each own their own database and call each other synchronously become an N² mesh of brittle, PHI-leaking integrations. The fix the industry settled on is an event-driven backbone: a durable, ordered log where every meaningful state change becomes an event other systems subscribe to. Adding a new consumer (a sixth engine, an analytics job, the de-id gateway) requires zero changes to the source — the backbone is already there and the new system simply subscribes [1][2]. Change-Data-Capture (CDC) turns each engine's database into an event source, so every INSERT/UPDATE/DELETE becomes an event downstream consumers can replay [3].

   ENGINES (publishers + subscribers)
   Balance Meter · Smart Scheduling · Med-Input · Refill · Triage
        │  publish versioned events          ▲  subscribe (grounded reads)
        ▼                                     │
 ┌───────────────────────────────────────────────────────────────┐
 │  EVENT BACKBONE  (Kafka-class log + Schema Registry)           │
 │  topics: medication.* · adherence.* · fallrisk.* · refill.*    │
 │  · consent.* · clinical_signoff.*    (all versioned, ordered)  │
 └───────────────┬───────────────────────────────┬───────────────┘
   operational    │                               │  governed copy
   read models    ▼                               ▼
 ┌───────────────────────────┐        ┌──────────────────────────┐
 │ OPERATIONAL PHI STORE     │  ───▶  │ DE-IDENTIFICATION GATEWAY │
 │ FHIR-shaped, HIPAA-ctrl'd │        │ (§2) Safe Harbor / Expert │
 │ system-of-record per user │        └────────────┬─────────────┘
 └───────────────────────────┘                     ▼
                                       ┌──────────────────────────┐
                                       │ LEARNING LAKE (no PHI)    │
                                       │ → Feature Store → MLOps(§3)│
                                       └──────────────────────────┘

1.2 The canonical data model — FHIR as the interchange¶

FHIR R4, profiled to US Core, is the clinical interchange contract [4][5]. This is not academic: US Core defines the minimum-expectation profiles for medications, observations, and patients that every interoperable US system already speaks, which is the literal definition of "architected to cross into reimbursable RPM/SaMD without a rebuild."

Medications are carried as MedicationRequest (the US Core primary resource for "all medications" / "all active medications" — a single query suffices), with Medication, MedicationDispense as supporting resources. US Core deprecated the requirement for MedicationStatement in R4 [4][5].
RxNorm is the mandatory coding system for medications (extensible binding to RxNorm "Clinical Drug"), with NDC permitted as optional supplementary coding [5]. This is what KB01's knowledge layer and the OpenFDA enrichment join on.
Wearable / Balance-Meter signals map to FHIR Observation; refill events to MedicationDispense; triage outputs to Communication/Flag — keeping every engine's output in one ontology.

Internal vs. interchange: we run a lean internal canonical model for hot paths (low-latency, denormalized read models per engine — KB04), and materialize FHIR at the interchange boundary (exports, partner integrations, the SaMD evidence trail). FHIR-everywhere-internally is too heavy for 6M-user hot loops; FHIR-at-the-boundary gives interoperability without the latency tax.

1.3 The medication-object + provenance model — the shared contract¶

This is the single most load-bearing contract in the platform and it already exists in the Med-Intelligence Engine plan; the data foundation's job is to make provenance a first-class, queryable, event-carried field, not a comment.

FHIR gives us two attribution mechanisms that map directly onto our self ×0.5 → pharmacist-verified ×1.0 model: - MedicationRequest.reported[x] — SHALL be set to mark a record as secondary/self-reported rather than authoritative source-of-truth [4]. This is our self ×0.5 state. - MedicationRequest.requester — identifies who entered/prescribed it (patient/related-person for self-entry) [4]. - The FHIR Provenance resource — wraps any resource with Provenance.agent (who), Provenance.recorded (when), Provenance.entity (derived-from), and Provenance.activity — the standard, queryable record of origin and chain of custody [6]. This is where the ×1.0 pharmacist-verification event is stamped: a clinical_signoff event (§5) writes a Provenance linking the medication-object to the verifying pharmacist's identity and timestamp.

The contract, concretely: every medication-object carries provenance.weight ∈ {0.5, 1.0}, provenance.source, provenance.verified_by, provenance.recorded_at, and a provenance_event_id pointing at the immutable backbone event that set it. Downstream engines (Refill anticipation, Triage) read the weight and degrade gracefully on 0.5 data — e.g., a refill prediction on self-reported-only data is flagged lower-confidence; a pharmacist-verified object unlocks higher-stakes automation. The weight is the trust signal the whole brain shares.

1.4 A versioned event taxonomy¶

Events are contracts; uncontrolled events are the new N² mesh. Adopt a schema registry with enforced compatibility [1][7].

Convention	Rule
Naming	`domain.entity.action.vN` — e.g. `medication.object.verified.v1`, `adherence.dose.confirmed.v2`, `fallrisk.score.updated.v1`, `consent.scope.revoked.v1`.
Schema	Avro/Protobuf in a Schema Registry; producers/consumers validate against it before publish/consume [1][3].
Compatibility	Backward-compatible by default (add optional fields; never remove/repurpose). Breaking change = new major version (`.v2`) running in parallel; old version timeboxed-deprecated with a documented sunset [7][8].
Envelope	Every event carries `event_id`, `occurred_at`, `producer`, `schema_version`, `consent_context`, `provenance_ref`, `correlation_id`. The `consent_context` travels with the data so the de-id gateway and every consumer can enforce purpose-limitation (§2.4) at read time.
Replay & audit	The log is the immutable audit trail — required for both HIPAA accounting-of-disclosures and the FDA total-product-lifecycle record. Replay lets us rebuild any read model or re-derive any training set deterministically (reproducibility, §3.3).

2 · PHI / HIPAA — operational-PHI vs. de-identified learning data¶

The governing principle: operational-PHI and learning-data are two physically separate planes, joined only by a de-identification gateway. The brain learns on de-identified data; it operates on PHI. They never mix.

2.1 Two classes of data, two regimes¶

Plane	What's in it	Regime
Operational PHI	The live system-of-record: identified user, their meds, doses, fall scores, refills. Drives reminders, confirmations, the user's own view.	Full HIPAA Privacy + Security Rule; minimum-necessary; access-controlled; consent-gated.
De-identified learning data	Row-level features stripped of identifiers, used to train/evaluate models and populate the feature store.	Not PHI once properly de-identified per 45 CFR §164.514(a)–(c) [9][10] — falls outside HIPAA's use/disclosure restrictions, which is exactly what makes a learning platform tractable.

This split is already our house rule (memory: Data Artifact Classification — raw de-identified row-level data stays local; aggregate derivatives are governed separately). This doc makes it an architectural boundary, not a filing convention.

2.2 De-identify at the boundary — the gateway¶

The de-id gateway is the only write-path from the PHI plane into the learning lake. Nothing reaches the feature store or any training job with identifiers attached. Two methods, both standard, chosen by need:

(a) Safe Harbor — the default. Remove all 18 identifiers enumerated in 45 CFR §164.514(b)(2) and hold no actual knowledge the residual could re-identify someone [9][10][11]:

1 Names · 2 Geographic subdivisions smaller than a state (ZIP truncated to first 3 digits, zeroed if the 3-digit area has <20,000 people) · 3 All date elements except year (and ages >89 aggregated to "90+") · 4 Telephone numbers · 5 Fax numbers · 6 Email addresses · 7 Social Security numbers · 8 Medical record numbers · 9 Health-plan beneficiary numbers · 10 Account numbers · 11 Certificate/license numbers · 12 Vehicle identifiers/serials incl. plates · 13 Device identifiers/serials · 14 URLs · 15 IP addresses · 16 Biometric identifiers (finger/voice prints) · 17 Full-face photos & comparable images · 18 Any other unique identifying number, characteristic, or code. [9][10][11]

For Rx360 specifically: wearable device serial numbers (#13) and biometrics (#16) are live risks — the Balance Meter runs on a serialized wearable and ingests gait/voice-class signals. The gateway must strip device serials and prevent raw biometric templates from ever entering the learning plane; only derived, non-reversible features pass.

(b) Expert Determination — for richer learning sets. When Safe Harbor strips signal we genuinely need (e.g., finer geography for regional fall-risk, finer dates for temporal adherence modeling), a qualified statistical expert applies accepted statistical/scientific principles and documents that re-identification risk is "very small" for the anticipated recipient — alone or combined with reasonably available data — and retains the methods/justification for audit [9][10][12]. HIPAA does not numerically define "very small"; the expert sets it contextually [12]. Recommendation: stand up Safe Harbor first (deterministic, no dependency); commission Expert Determination only for the specific richer feature sets a model demonstrably needs, with documented sign-off.

(c) Limited Data Set — the middle option for internal analytics. A Limited Data Set (164.514(e)) may retain dates and city/state/ZIP but still strips direct identifiers, and requires a Data Use Agreement [10]. Useful for governed internal analytics; not a substitute for de-identification into the learning plane.

Never-mix rule (engineering invariant): A re-identification key (the mapping from a de-identified record back to a user) — if one is kept at all for Expert-Determination linkage — lives only in the PHI plane, in a separate vault, never co-resident with the learning lake, never shipped to a training job. Most learning paths should keep no key at all (irreversible de-id).

Wellness data at 6M-user scale demands consent that is specific, revocable, and provably enforced — the GDPR standard and increasingly the HIPAA-aligned expectation [13][14].

Model it as FHIR Consent. FHIR's Consent resource records per-purpose, per-recipient, per-data-category directives — letting a user consent to reminders but not research, or share refills but not fall-scores [13][14]. Sensitive categories get extra protection by design.
Granular scopes map to our event taxonomy: consent.scope.{operational, learning, research, caregiver_circle, partner_share}. The learning scope is the gate the de-id gateway checks: no learning-scope consent → the user's data never enters even the de-identified lake.
Revocable, with propagation. Each grant/revocation/expiry is a time-stamped event on the consent.* topic [14]. Revocation must propagate: future data stops flowing immediately; already-de-identified-and-aggregated data that is no longer PHI generally need not be unwound (it is no longer the user's identifiable data), but any retained re-identification key is destroyed on revocation, and consent state is re-checked at every read. The known hard problem — cross-system revocation propagation and verifiable consent provenance — is solved by the backbone: consent is an event every consumer subscribes to, not a flag each system re-implements [14].
Purpose limitation & data minimization travel in the envelope. Because every event carries consent_context, a consumer that lacks the purpose simply cannot read the field — minimum-necessary becomes a property of the platform, not a policy memo.

2.4 Security (HIPAA Security Rule baseline)¶

Encryption in transit and at rest on both planes; role-/attribute-based access control with minimum-necessary scoping; immutable audit logging (the backbone log doubles as the accounting-of-disclosures trail); key management with the re-id vault isolated; and "good software engineering and security practices" as an explicit, audited control — which is also GMLP Principle 2 (§4), so we get HIPAA and FDA credit for one program [15][16].

3 · MLOps / model lifecycle for a learning system¶

The platform must improve continuously and never ship a regression into a clinical-adjacent path. That tension is resolved by a gated pipeline where every stage is automated but the clinical-affecting promotion step is human-gated (§5).

 de-id LAKE ─▶ FEATURE STORE ─▶ TRAIN/RETRAIN ─▶ OFFLINE EVAL ─▶ MRT / A-B ─▶ CANARY ─▶ FULL
   (no PHI)     (no skew)        (versioned)     (off-policy +    (online,    (5% + auto-  (100%)
                                                  HOLDOUT)         causal)      rollback)
        ▲                                                                          │
        └────────────────────── DRIFT DETECTION triggers retrain ◀────────────────┘
                         CLINICAL SIGN-OFF GATE (§5) sits before any clinical-affecting promotion

3.1 Feature store — kill training/serving skew¶

A feature store is the centralized, versioned repository that serves the same feature computation to training and to live inference, which is the canonical defense against training-serving skew (the silent killer where a model is great offline and wrong in production because the features differ) [17][18]. It also prevents redundant feature engineering and lets engines discover/share features (the Balance Meter's gait features, Smart Scheduling's adherence features) [17]. Features are computed once, from the de-identified lake, versioned, and read identically online and offline.

3.2 Training / retraining pipelines¶

Automated, reproducible, triggered (a) on drift (§3.6), (b) on schedule, or (c) on a curated new-data threshold [19]. Each run is a tracked experiment: data version + code version + config + resulting model are bound together.

3.3 Versioning — "version everything" is non-negotiable¶

Reproducibility and rollback require versioning code (Git), data (DVC-class dataset versioning), and models (a registry like MLflow) — explicitly called the non-negotiable baseline of mature MLOps [18][19]. Because the backbone log is replayable (§1.4), any training set is deterministically re-derivable from (event-log-offset-range + de-id-config-version + feature-version) — a stronger reproducibility guarantee than snapshotting, and exactly the provenance an FDA submission wants.

3.4 The never-touched holdout¶

Keep a holdout test set "in a vault," used exactly once before a release decision. The strong statistical guarantee of an unbiased performance estimate holds only if the model in no way depends on prior evaluations against that set — the moment you tune against the holdout, it silently becomes a validation set and the estimate is optimistic [20][21]. Discipline: the platform enforces a partition of the de-identified population that the feature store and training jobs cannot read; it is queried only by the release-gate evaluator, logged, and rotated on a schedule that itself never leaks into training. This is our defense against the slow performance-inflation that test-set reuse causes [21].

3.5 Off-policy evaluation + online causal trials¶

Two distinct jobs:

Off-policy evaluation (OPE) — before any traffic. For the personalization layers that are policies (the contextual-bandit nudge timing in Smart Scheduling, KB04 §1.4; refill anticipation), we must estimate a new policy's value from data logged under the old policy, without deploying it. Use doubly-robust (DR) estimators — they combine a direct-method model with an inverse-propensity-weighting correction to get IPW's low bias and DM's low variance [22][23]. OPE is the cheap, safe pre-filter: a candidate policy that looks worse off-policy never reaches users.
Micro-Randomized Trials (MRT) — the gold standard for the live causal question. Our nudge/JITAI engines are exactly the use case MRTs were invented for: randomize each user, at each decision point, hundreds–thousands of times over the study, to estimate the causal, time-varying, context-dependent effect of an intervention option [24][25][26]. MRT (HeartSteps, etc.) is how you learn whether and when a nudge actually causes a confirmed dose — the reward KB04 already defines as confirmation, not "message sent." For non-policy supervised models (adherence-risk scoring), standard A/B testing / shadow deployment on the holdout-validated model is sufficient [19].

Pairing: OPE pre-screens → MRT/A-B confirms causally online → only then promote. This is the rigorous form of KB04's learn→validate steps.

3.6 Drift detection — the loop's trigger¶

Monitor input-feature drift and prediction drift continuously with PSI and KS-test-class methods; when drift exceeds a threshold, automatically trigger retraining → offline eval → staged canary [19][27]. Drift is the signal that "the brain's view of the world has aged" — at 6M users with a senior population, distributions shift (seasonality, cohort changes, new drug formularies). Drift detection closes the learn loop without a human having to notice.

3.7 Canary deploy + automatic rollback¶

Never flip 100% of traffic. Route a small slice (~5%) to the candidate, measure live performance against the incumbent, and auto-rollback on regression [19][27][28]. Shadow mode (candidate scores live traffic but its outputs are not served) is the even-safer first step for clinical-adjacent models. Failure-detection + automatic rollback is also a named control in a PCCP modification protocol (§4) — another HIPAA/FDA two-for-one.

3.8 Lifecycle scorecard¶

Stage	Mechanism	What it buys	Source
Feature parity	Feature store	No train/serve skew; feature reuse	[17][18]
Reproducibility	Version code+data+model; replayable log	Rollback; FDA-grade provenance	[18][19]
Honest metrics	Never-touched holdout (use-once)	Unbiased performance estimate	[20][21]
Pre-deploy policy check	Doubly-robust OPE	Kill bad policies before any user sees them	[22][23]
Online causal proof	Micro-randomized trial	Does the nudge cause the outcome, and when	[24][25][26]
Staleness trigger	PSI/KS drift detection → auto-retrain	Loop closes without human noticing	[19][27]
Safe release	Canary + shadow + auto-rollback	Bad model affects ~5%, then none	[19][27][28]

4 · Regulated-ready posture — GMLP + PCCP wired in from day one¶

We are wellness today; the architecture must let a model become reimbursable RPM/SaMD later without a rebuild. The cost of readiness is near-zero if we adopt the two FDA frameworks as engineering practice now, not as a future scramble.

4.1 GMLP — the 10 guiding principles, as platform controls¶

The Good Machine Learning Practice guiding principles — first issued jointly by FDA, Health Canada, and the UK MHRA (Oct 2021) and finalized by IMDRF (Jan 2025) — are non-binding but the de facto expectation in any AI-device submission and lifecycle record [15][16][29]. They map almost one-to-one onto controls this doc already specifies:

#	GMLP principle [15][16]	Where we satisfy it
1	Multi-disciplinary expertise across the lifecycle	Pharmacist + ML + product in the sign-off gate (§5)
2	Good software-engineering and security practices	§2.4 — shared HIPAA Security control
3	Representative data for the intended population	De-id lake sampled for our senior cohort; bias checks
4	Independence of training and test data	Never-touched holdout partition (§3.4)
5	Best-available reference datasets	RxNorm/OpenFDA/curated KB as ground truth (KB01)
6	Model design fits the data & intended use; manage overfitting	OPE + holdout discipline (§3)
7	Focus on human-AI team performance	Confirmation-as-reward + the human gate (KB04; §5)
8	Test under clinically relevant conditions	MRT in-the-wild + canary on live traffic (§3)
9	Clear, accessible info for users (transparency)	Provenance weight surfaced; model cards; labeling
10	Monitor deployed models & manage re-training risk	Drift detection + canary + auto-rollback (§3.6–3.7)

GMLP frames all of this under the Total Product Lifecycle (TPLC) — premarket evidence + continuous post-market monitoring as one program [15][16].

4.2 PCCP — pre-authorize the learning so improvement isn't a re-submission¶

A Predetermined Change Control Plan is the legal mechanism that lets an AI device update itself within pre-agreed bounds without a new marketing submission for each change — the entire reason a learning system is regulatorily viable. PCCP authority is statutory: Section 515C of the FD&C Act, added by FDORA (Dec 2022); FDA's final guidance issued Dec 2024 (with the implementing AI-device-software-functions lifecycle guidance in Jan 2025) [30][31][32]. A PCCP has three required sections [30][31]:

Description of Modifications — exactly which changes are pre-authorized (retraining on new data, threshold/parameter updates, feature changes) and their expected performance impact, with quantified bounds and whether deployment is automatic/manual.
Modification Protocol — how each change is developed, validated, and released: data-management procedures, pre-deployment test protocols with acceptance criteria, real-world monitoring, and failure-detection + automatic-rollback mechanisms. Our §3 pipeline is, almost verbatim, a modification protocol.
Impact Assessment — effects on safety/effectiveness, false-positive/negative consequences, risk-benefit per ISO 14971, and post-market surveillance.

Hard boundary: PCCP modifications must stay within the original intended use; any change to intended use / indications requires new regulatory review [30][31][32]. For us this maps cleanly: retraining the adherence-risk model on fresh data = inside a PCCP; turning a nudge engine into a dosing recommender = a new intended use = forbidden in the wellness lane anyway.

The payoff: if we build the §3 lifecycle as if it were a PCCP modification protocol now, the day we choose to file for SaMD, the "how we change the model safely" section is already written, validated, and logged. That is the literal meaning of "ready to cross over without a re-architecture."

5 · The human / clinical sign-off gate — embedded, non-skippable¶

This is the load-bearing safety invariant and it predates this doc (KB04's …→clinical-sign-off→gated-deploy). The data foundation's contribution is to make the gate a required state transition in the pipeline and an immutable event on the backbone — impossible to route around.

The rule, stated absolutely: No model writes clinical content, and no clinical-affecting change deploys without a pharmacist/clinician approval recorded as a signed event. This satisfies GMLP #1 and #7 (multi-disciplinary, human-AI team) [15][16] and is the operational form of the wellness-lane guardrail.

Mechanics: - Classify every candidate change as clinical-affecting or not. A copy tweak to a reminder's tone is not clinical-affecting; a change to which drug-class tolerance window drives a nudge, or to a refill-anticipation threshold that could delay a refill, is. The classifier is conservative: ambiguous → clinical-affecting. - Clinical-affecting changes hard-stop at the gate between offline-eval and canary (§3 diagram). The pipeline cannot promote without a clinical_signoff.approved.vN event signed by a credentialed pharmacist, carrying the model version, dataset version, eval results, and the holdout report. - The sign-off is provenance. The same event that approves a deploy also stamps the FHIR Provenance record (§1.3) — so the chain "this medication-object behavior was approved by pharmacist X on date Y against model version Z" is queryable forever [6]. Pharmacist-verification of a user's med-object (×1.0) and pharmacist-approval of a model change use the same provenance machinery. - No model authors clinical facts. Clinical content is served from the curated KB verbatim or escalated to a human (KB03/KB04). The model's job is to route, time, and prioritize — never to originate a clinical statement. The gate enforces that any output that could be read as clinical advice traces to a human-curated source.

 OFFLINE EVAL ──▶ [is change clinical-affecting?] ──no──▶ CANARY
                            │ yes
                            ▼
              CLINICAL SIGN-OFF GATE (pharmacist)
              ├─ reviews: model+data version, eval, holdout report
              ├─ emits clinical_signoff.approved.vN  (signed, immutable)
              └─ stamps FHIR Provenance ──▶ then CANARY (§3.7)
                            │ reject
                            ▼  back to TRAIN with documented reason

6 · How this extends what we already have¶

We already have (pattern)	This doc makes it (platform)
RAG over a pharmacist-curated drug-KB behind a deterministic rail (KB04)	The rail's data now flows on a governed backbone; clinical facts stay model-free by architecture
`learn → validate → clinical-sign-off → gated-deploy` loop	A concrete MLOps pipeline (§3) with the sign-off gate as a non-skippable, event-logged state transition (§5)
Medication-object + provenance (`self ×0.5 → pharmacist ×1.0`)	Provenance as a first-class FHIR-backed, event-carried, queryable contract every engine reads (§1.3)
House rule: de-identified row-level data stays separate (memory)	An architectural boundary — the de-id gateway is the only path into the learning plane (§2)
Wellness-lane posture	GMLP + PCCP wired in so the same platform crosses to SaMD without a rebuild (§4)

The one-sentence foundation: one canonical FHIR-shaped model on a versioned event backbone; PHI and learning data split by a de-identification gateway; a gated, drift-triggered MLOps lifecycle measured against a vaulted holdout; GMLP+PCCP and a non-skippable clinical sign-off gate baked in — so the brain works safely at 6M users and improves without ever crossing the clinical line.