One case record in. A panel of outcome models out. Deployed inside your walls.

Typical engagements

Diagram description: inside the hospital tenancy boundary, Epic reporting databases feed the hoopcare-connect container, which writes to a FHIR staging store (Medplum with PostgreSQL) and to Parquet files; the hoopcare-engine scores case records and returns results to score consumers (HL7v2 or FHIR write-back to Epic, patient lists, the clinician console, and Parquet export). An optional hoopcare-reader LLM sidecar reads notes locally. The only connection crossing the boundary is optional TLS license traffic to the Hoopcare license service, which carries no PHI.

All images are signed (cosign) and ship with SBOMs; the public verification identity is published at GA. Verify signatures before first run; see §12.

Bill of materials by deployment mode

Per-component digests, ports, data classification, volumes, backup requirements, health endpoints, and HA behavior ship in the release manifest with each build (planned diligence artifact, §18).

Feature tiers

Every model is trained at nested feature tiers defined in a governed feature manifest — 2,198 candidate features, each carrying per-tier inclusion flags and a keep / coalesce / drop decision with rationale (139 candidates are excluded outright for leakage or validity). You pick a tier per deployment. Acceptable completeness varies by endpoint, tier, and site — the runtime validates inputs and returns machine-readable valid / degraded / out-of-scope / abstained states rather than silently coping (§4).

Managed-platform (~1,358 features) and payer/claims (~1,454) tier variants also exist — ask us. The Super Light field list is published in §4; the full governed manifest is shared on demand under NDA.

Model catalog

*Preliminary internal development estimates from an unlocked analysis (temporal-holdout design, ≈300k cases, 2024+) — not final, externally validated, partner-authorized, or approved for citation or decision-making. Signed, versioned model cards (mapped to TRIPOD+AI and ONC predictive-DSI source attributes, with event counts, CIs, calibration, and subgroups) replace this table at release. Rare outcomes are reported with AUPRC against a prevalence baseline. Additional endpoints (pneumonia, sepsis/septic-shock NSQIP-style, and others) and the full benchmark tables vs. ASA-PS, RCRI, POSPOM, and ARISCAT are available on demand under partner agreement. Tiers: Standard = EHR Standard (~1,357 features) · Advanced = EHR Advanced (~1,421) · Max = full manifest (~2,011). ± LLM: the Hybrid notes-analysis layer can be enabled per endpoint at that tier; its incremental value is evaluated per site. Super Light web variants exist for every endpoint; expect reduced discrimination at 21 fields (per-tier metrics on request). Endpoints marked directive provide a specific care recommendation and carry a separate intended-use and regulatory review track (§14) before any production display — see the FDA CDS guidance on directive outputs.

Output contract

Classifiers return an isotonic-calibrated probability, a five-level risk tier, a binary flag at the site-configured operating point, and the top contributing factors. Regressors return a point estimate with an 80% interval. The global 0–100 score is a composite index, not a probability — a composite ranking over the outcome panel; its component weighting, tier derivation, stability across specialties, and the meaning of a point difference will be specified in its model card. Per-outcome probabilities are the model-specific evaluation outputs. Every response carries the exact model + calibration version for audit.

{
  "case_id": "SC-2026-091441",
  "record_version": "sha256:9f31…",
  "scored_at": "2026-09-12T02:14:07Z",
  "results": [
    { "model": "risk-score-global", "version": "0.9.0+cal.2026Q3",
      "score": 65, "tier": "high", "top_drivers": [
        "composite_acuity_additive", "primary_procedure", "heart_failure_90d"] },
    { "model": "mortality-30d", "version": "0.9.0+cal.2026Q3",
      "probability": 0.041, "tier": "high", "flag": true,
      "operating_point": "youden_0.82" },
    { "model": "los-total-icu", "version": "0.9.0+cal.2026Q3",
      "los_days": 4.2, "icu_days": 0.3, "interval80": [2.1, 7.9] }
  ],
  "warnings": ["labs.bnp missing — treated as informative missingness"]
}

The operating_point shown is an example, not a clinical policy — production thresholds are selected against an explicit local harm/benefit and capacity review and approved by your governance (§13).

Every model reads the Hoopcare CaseRecord, a versioned JSON document keyed one-per-scheduled-procedure. In a standard deployment you never build it yourself — hoopcare-connect assembles it from Clarity/Caboodle (§5). Sites integrating from a data lake or another EHR can post it directly.

{
  "schema": "hoopcare.case-record/1.0",
  "case_id": "SC-2026-091441",
  "scheduled_start": "2026-09-14T07:30:00-05:00",
  "patient":   { "age": 67, "sex": "F", "bmi": 31.2 },
  "procedure": { "code": "27447", "system": "CPT", "urgency": "elective",
                 "service": "orthopedics", "setting": "inpatient" },
  "anesthesia":{ "planned_type": "general" },
  "labs":   [ { "loinc": "718-7",  "value": 11.9, "unit": "g/dL", "observed": "2026-09-01" },
              { "loinc": "2160-0", "value": 1.4,  "unit": "mg/dL","observed": "2026-09-01" } ],
  "vitals": { "hr": 78, "sbp": 141, "dbp": 82, "spo2": 96, "observed": "2026-09-01" },
  "medications": [ { "rxnorm": "197361", "class": "beta_blocker", "active": true } ],
  "diagnoses":   [ { "icd10": "I50.32", "recorded": "2025-11-02" } ],
  "ecg":    { "qtc": 452, "qrs": 96, "pr": 168, "rate": 78, "observed": "2026-08-30" },
  "prior_utilization": { "surgeries_5y": 2, "admissions_1y": 1, "icu_1y": 0 },
  "notes":  [ { "type": "H&P", "authored_at": "2026-09-01T09:12:00-05:00", "text": "…" } ]
}

The notes array applies to the Hybrid tier only; note availability is governed by the authoring/signing instant relative to the feature cutoff (date-only values are treated conservatively). The example is valid JSON as shown.

Super Light tier — the complete 21-field list

This is the entire input for the no-EHR tier (web calculator / manual entry) — designed for rapid structured entry from a verified source. Completion time and inter-rater reliability remain to be established in usability testing.

Feature counts by tier and source category

Counts from the July 2026 governed manifest (2,198 candidates; 139 excluded for leakage or validity). Lean tiers use canonical coalesced concepts in place of raw source fields; Max uses the raw sources directly — which is why the canonical row shrinks as tiers grow. The full manifest — definitions, units, windows, expected missingness, and the per-feature keep/coalesce/drop rationale — is available on demand under NDA.

The connector reads from a Clarity replica or Caboodle using a read-only service account (db_datareader on ~40 named tables/views — your DBA reviews and approves every query in the mapping workbook before anything runs). Prospective deployments can instead — or additionally — use Epic's FHIR R4 APIs (SMART Backend Services with private-key JWT and resource-specific scopes — e.g. system/Observation.read, system/Condition.read — never a blanket wildcard) for incremental refresh, mirroring the published UCLA pathway: bulk features on a fixed cadence, case list on a fast cadence.

Source table map

*Exact table names vary by Epic version and site build — the mapping workbook we ship is a starting point your Clarity team adapts, not a hard dependency. Sites on Cerner/Oracle Health or a lakehouse (Databricks, Snowflake) integrate via the FHIR bulk path or direct CaseRecord posts — ask us.

Refresh cadence & write-back

The 6-h feature / 15-min case-list cadence and HL7 flag + dynamic patient list pattern follow the implementation prospectively validated at UCLA (Wingert et al., BJA 2026, §18) — an architectural precedent for the integration shape, not evidence for Hoopcare's models. Scores are re-sent only when the value changes (~10 messages/day at a large center).

The connector stages everything as FHIR R4 resources in an embedded, self-hostable FHIR server built on Medplum (Apache-2.0 open source; the hosted edition of the same stack is ONC-certified, HITRUST e1 and SOC 2 Type II audited). It is the same three-service footprint everywhere — server, PostgreSQL, Redis — deployed by our Compose/Helm bundles inside your tenancy, with open-source code available for your team’s inspection (inspection is not a security review or a support commitment; Medplum support terms are separate). Scoring inputs and outputs are therefore ordinary FHIR resources your analysts can query directly, not a proprietary schema. Third-party certifications apply only to the named vendor's product, service, and audit scope — they do not confer certification on Hoopcare or on a customer-operated self-hosted deployment.

Resource & terminology bindings

Event-driven scoring & HL7v2 connectivity

• Three trigger patterns — matched to what your EHR supports. (1) Warehouse polling: scheduled Clarity/Caboodle delta queries (the §5 cadence) — works everywhere, latency = the polling interval. (2) FHIR Subscription: a criteria-based Subscription on ServiceRequest/Appointment fires scoring on change — the event-driven pattern Medplum documents; requires a FHIR endpoint that supports it. (3) HL7v2 events: SIU/ADT feeds through the agent listener. Sites typically combine one event pattern with a reconciliation poll for missed events; per-pattern prerequisites, latency targets, and replay behavior ship in the integration guide (planned artifact, §18).
• HL7v2 without firewall holes. In agent mode the connector listens for HL7v2 over MLLP (SIU schedules, ORU results, ADT) inside your network and, in hybrid topology, maintains only an outbound TLS WebSocket — no inbound rules, no VPN — the on-prem agent pattern documented by Medplum for exactly this "legacy interfaces live inside the hospital" problem. On-prem topology needs no tunnel at all.
• Standard APIs on top. The staging store speaks plain FHIR REST (and the scoring API of §8 sits beside it), so your integration engine, Power BI, or research data lake can consume scores as RiskAssessment searches rather than a custom export.

Three deployment topologies

A field-level egress inventory per topology (purpose, destination, region, encryption, retention, deletion, subprocessors, disable switch) is a planned diligence artifact (§18). Payer configurations are not evaluation-ready: a separate payer guide — data contract, claims-only evidence, and permitted uses that exclude coverage, payment, and prior-authorization decisions — is planned.

Scores are pushed and displayed through standard mechanisms only — every interface still requires site configuration and lifecycle maintenance. Clinical display and write-back are future production modes, subject to the intended-use and regulatory classification in §14 — evaluation deployments keep scores in the console. Your interface analyst picks per system:

1. HL7v2 ORU push — a results message carrying the risk tier and score; lands as a flowsheet/result field. A widely supported interface pattern — exact message profile, display location, acknowledgement behavior, and product/version compatibility require site verification.
2. FHIR write — RiskAssessment / Flag / Observation created via the EHR's FHIR R4 API where write scopes are enabled.
3. SMART on FHIR panel — our embedded app launches with patient context inside the preop workspace and renders the full panel (score, drivers, trend) without leaving the chart.
4. CDS Hooks card — a patient-view / order-select card for in-workflow nudges where the EHR supports the hook.

Effort guide: an ORU interface is standard interface-analyst work (days); SMART/Marketplace app enablement follows each vendor's app-review timeline (weeks, once per organization). Display is configuration — the score payload and the audit trail (§6) are identical on every path. Conformance status: every row is a standards-based design; none is yet vendor-program listed, lab-verified, or backed by a production reference. A per-EHR compatibility matrix (product/version, scopes, write support, limitations, verification date) is a planned artifact (§18).

# OAuth2 client-credentials (or mTLS) — tokens minted by your IdP or the bundled issuer
curl -s https://hoopcare.internal.yourhospital.org/v1/score \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d @case-record.json | jq '.results[] | {model, probability, tier}'

Rate limits default to 50 req/s interactive per node (far above clinical need — see §11); batch jobs run under per-tenant concurrency and daily-volume quotas, contract-configurable. Scoring accepts an Idempotency-Key header; errors use RFC 9457 application/problem+json with correlation IDs and never carry PHI or stack traces; responses carry a status of valid · degraded · stale · out_of_scope · abstained · failed plus prediction-index and feature-cutoff timestamps — full semantics — including per-operation OAuth scopes, tenant-scoped job authorization, payload and note-size caps, safe batch storage references, and machine-readable status_reasons codes — are in the OpenAPI file. All calls are written to the tamper-evident audit log (§14).

# single-node evaluation / retro (after Marketplace subscribe or registry access)
aws ec2 run-instances --instance-type m6i.2xlarge --image-id ami-<al2023> …
cosign verify registry.hoopcare.com/engine:<preview-build> --certificate-identity-regexp hoopcare
docker compose -f hoopcare-compose.yaml up -d

helm install hoopcare oci://registry.hoopcare.com/charts/platform \
  --version <contracted-preview-version> --namespace hoopcare --create-namespace \
  --set license.mode=online --set connect.source=caboodle

Network requirements

Egress presets

DNS names, ports, payload schemas, size caps, certificate validation, proxy support, retry behavior, and no-PHI log evidence ship in the egress inventory (planned diligence artifact, §18). The preset applies across normal, failure, update, and support modes.

• Database: PostgreSQL 15+ — bundled container for pilots; your managed instance (RDS / Azure Database / Cloud SQL) for production. ~50 GB covers a 1M-case feature store.
• Storage planning: structured features ≈ 2 KB/case (1.25M cases ≈ 2.5 GB Parquet); cached preop note text for Hybrid ≈ 70 KB/case (1.25M ≈ 90 GB raw, ~25 GB compressed — retro Hybrid only).
• HA production: 2× STANDARD nodes behind your load balancer; the engine is stateless, so failover is connection-level. RPO for the feature store follows your Postgres backup policy.
• Indicative cloud cost (list price, region-dependent, excludes Hoopcare license): STANDARD 24/7 ≈ $250–350/mo; STANDARD in a 4 h nightly window ≈ $50–80/mo; BATCH for a one-week retro ≈ $150–300 total; GPU ≈ $2–4/hr only while Hybrid retro runs.

Throughput planning figures

Worked examples

• Retrospective, 1.25M cases, structured EHR tiers: historical extract 1–3 days elapsed (DBA-paced, off-hours against the replica) → assembly + scoring ≈ 24–30 h on one BATCH node, or overnight on four. Plan < 1 week wall-clock, dominated by extract review, not compute.
• Retrospective, Hybrid tier: full-history LLM review of 1.25M charts is GPU-weeks — by design we instead run Hybrid on a stratified subsample (e.g., 100k cases ≈ 4–5 days on one GPU), which is statistically sufficient to demonstrate the LLM layer's incremental AUPRC/NRI on your population.
• Prospective, ~350 cases/day health system: nightly full rescore of the 7-day schedule (~3–5k case-scorings) completes in < 10 minutes on STANDARD; 6-hourly incremental refreshes take ~1 minute. Daily volume uses under 1% of a single node's capacity.

Operating windows — the engine runs when you say it runs

Licensing is per scored case (retro) or per annual surgical volume band (prospective) — never per node or per hour, so right-sizing and windowing your infrastructure never conflicts with the license. Runtime scheduling is a first-class config (schedule.window in the Helm values / compose env).

1. 01

   Agreements & site survey week 0

   BAA, DUA/research agreement for retro, and license order form. You return a one-page site survey (Epic version, Clarity vs Caboodle, cloud target, network policy) that fixes the deployment profile and final sizing.

2. 02

   Provision & verify day 1 · ~2 h

   Stand up the VM/namespace, pull images from the Marketplace or registry.hoopcare.com, verify signatures and SBOMs with cosign.

3. 03

   License & doctor day 1 · ~30 min

   hoopcare license apply <key-or-sealed-file> binds the encrypted model bundle to this node, then hoopcare doctor checks resources, clock, connectivity, and bundle integrity.

4. 04

   Synthetic smoke test day 1 · ~15 min

   The image ships with 1,000 synthetic cases. hoopcare smoke scores them and asserts against golden outputs — your proof the engine is healthy before any PHI is touched. First real score target: < 1 day from VM availability.

5. 05

   Source mapping weeks 1–2 · DBA 3–5 days

   Adapt the Clarity/Caboodle mapping workbook (§5) with your Clarity team; every SQL statement is plain text for review. hoopcare map validate dry-runs row counts per table without moving data.

6. 06

   Data-quality gate week 3

   hoopcare validate --sample 50k produces the QC report: completeness vs expected missingness bands, unit and range checks, temporal sanity. The engine refuses a production run while red checks remain — fail-closed by design.

7. 07

   Dry run, then full run weeks 3–4

   hoopcare backfill --since 2019 --dry-sample 10k, joint review, then the full retro (§11 worked example) or the start of the prospective silent window.

8. 08

   Review & next phase weeks 4–6

   Metrics workshop on the retro report (§13), then decision to proceed to silent pilot or production wiring (HL7/FHIR write-back + Epic patient list with your interface analyst).

# day one, end to end
cosign verify registry.hoopcare.com/engine:<preview-build> …
docker compose -f hoopcare-compose.yaml up -d
hoopcare license apply HOOP-XXXX-XXXX
hoopcare doctor          # resources · clock · bundle integrity · endpoints
hoopcare smoke           # 1,000 synthetic cases vs golden outputs
# integration phase
hoopcare map validate --source caboodle
hoopcare validate --sample 50k
hoopcare backfill --since 2019-01-01

The program answers one question with your data: how do the models perform on our population, against the tools we use today? Your team keeps full control — the outcome labels are built locally by your analysts from our open, reviewable SQL label pack, so the evaluation is auditable end-to-end (vendor-provided tooling is auditable, not automatically independent — your team reviews and can replace any of it). Each engagement runs under a pre-specified protocol signed before scoring: frozen cohort and label definitions, chart-review label validation on a sample, locked model + threshold versions, a statistical analysis plan with minimum event counts, and predefined go / recalibrate / no-go acceptance gates per model.

1. 01

   Scope week 0

   Pick the cohort window (typically 3–7 years), populations (all-comers and/or NSQIP-eligible), and endpoints. Your institution — with its IRB, privacy, and compliance leadership — determines whether the activity is research, quality improvement, or operations before any data processing begins; the platform runs on identified or de-identified extracts equally well.

2. 02

   Extract & label weeks 1–3

   Historical extract per §5; your analysts run the label-builder SQL pack (creatinine trajectories for AKI, ventilation hours, unplanned ICU transfers, disposition/death, coded events) and keep the labels.

3. 03

   Score week 4

   Structured tiers over the full cohort (< 1 week wall-clock at 1M+ cases, §11); Hybrid on a stratified subsample if licensed.

4. 04

   Evaluate weeks 4–5

   The bundled evaluation notebook (source-available, Apache-2.0) joins scores to your labels and produces per-outcome AUROC/AUPRC with bootstrap CIs, calibration curves, decision-curve analysis, and head-to-head comparisons vs ASA-PS, RCRI, POSPOM, ARISCAT computed on the same cases — plus the subgroup-fairness report (sex, age, race & ethnicity, specialty, urgency).

5. 05

   Joint review week 6

   Metrics workshop; decision on silent pilot. If the site wishes to publish, we support co-authored external-validation manuscripts — your cohort, your labels, TRIPOD+AI reporting.

The controls below are design commitments at prototype maturity; each will carry its own state (planned / implemented / internally verified / independently assessed) with linked evidence in the trust center (planned artifact, §18).

• HIPAA. Standard BAA available for execution where Hoopcare acts as a business associate — the role varies by topology, and a counsel-reviewed role table per topology is a planned artifact. In the closed topology PHI is processed only inside your environment; no PHI in logs, telemetry, or license traffic (logging schema and redaction tests are part of the trust-center evidence). Optional telemetry is aggregate-only and off by default.
• Encryption. TLS 1.2+ in transit (mTLS optional); AES-256 at rest via your cloud KMS / disk encryption; model bundle separately encrypted (§15).
• Identity. Console SSO via your OIDC/SAML IdP; API via OAuth2 client-credentials or mTLS; RBAC with least-privilege roles (viewer / analyst / operator / admin). EHR-side connections use SMART on FHIR: EHR launch with scoped user context for the embedded panel, and SMART Backend Services (asymmetric private-key JWT per the SMART profile, resource-specific least-privilege scopes per endpoint — never a blanket wildcard) for machine-to-machine access; no shared secrets in interface configs.
• Fine-grained FHIR access control. The staging store enforces FHIR AccessPolicies: per-resource-type CRUD rules, criteria-based filtering, field-level hiddenFields/readonlyFields, and patient-compartment scoping — so an integration account can read exactly the resources it scores and nothing else (least privilege by construction, not by convention).
• Prediction traceability. Every score writes a FHIR Provenance (model + calibration version, input-bundle hash) and AuditEvent (who/what/when) alongside the RiskAssessment — your compliance team can reconstruct any prediction end-to-end from standard resources.
• Hybrid-topology minimization. When scoring runs in the single-tenant enclave (§6), identifiers are tokenized and dates offset before egress, note text never leaves your network, and the re-identification map stays on your side of the boundary.
• LLM isolation & retention. The chart-review LLM (MedGemma) is served locally with no internet egress in the closed topology. Extractions carry verbatim evidence spans so every LLM-derived feature is reviewable against the source note — evidence spans are note-derived PHI and, like the note cache, are stored inside your environment under the site-configured retention and deletion policy. A per-data-class storage/retention table (source text, prompt buffers, features, evidence spans, queue payloads, logs, backups) is a planned trust-center artifact; until it ships, treat retention as site policy, not "zero".
• Audit. Tamper-evident (hash-chained) audit log of every scoring call, config change, and data access; exportable to your SIEM (syslog/CEF).
• Assurance — stated precisely. SOC 2 Type II audit in progress (report shared under NDA when issued, with exact system and period scope); first third-party penetration test scheduled before GA (attestation with assessor, date, and scope to follow); signed containers + SBOMs per release with the public verification identity published at GA; CVE patch target — critical ≤ 7 days. Each control is tracked in the trust center as planned, implemented, internally verified, or independently assessed (planned artifact, §18).
• Regulatory posture. This preview describes research-evaluation functionality only. The current build is not FDA-cleared and is not authorized for clinical decision-making, site-of-service determination, benefit/coverage, payment, or prior-authorization decisions; institutions must not expose scores to end users or act on them outside an approved protocol and contract. Separate counsel-approved intended-use statements are in progress for (1) retrospective research, (2) silent prospective evaluation, (3) clinical decision support if and when authorized, and (4) payer/care management — assessed against the FDA CDS guidance criteria (including independent-review-basis expectations for directive outputs such as ASC eligibility or a prophylaxis flag). Future clinical display would run as passive risk presentation under institutional governance, following the UCLA precedent (§18).

Hospitals reasonably ask how an on-prem deployment coexists with vendor IP. The answer is an appliance model: model weights are never delivered in readable form, and never leave Hoopcare in the clear.

• Encrypted at rest, decrypted only in memory. Models ship inside the engine image as an AES-256-GCM encrypted bundle. Keys are released per-node by the license service (or embedded in a sealed offline license for air-gap) and bound to the node identity; decryption happens in engine memory at startup. No plaintext model file ever exists on your disk, and there is no pickle/ONNX artifact to lift.
• No export surface. The API exposes predictions, calibrated probabilities, and top-k grouped drivers — not raw margins, trees, or embeddings. There is no model-download or introspection endpoint; bulk scoring is licensed and audited, which also bounds extraction-style querying.
• Signed & sealed. Containers are cosign-signed; the engine refuses tampered bundles; licenses are node-locked with quarterly re-key (air-gap sites get renewed sealed bundles on the same cadence).
• Contractual layer. The license prohibits reverse engineering, weight extraction, and training surrogate models on outputs ("distillation"), with audit rights — standard terms your counsel will recognize from other clinical-software appliances.
• What you can audit — everything that matters clinically: per-model TRIPOD+AI cards, full metric reproduction on your own labels (§13), the source-available evaluation notebook and label-builder SQL, per-prediction drivers, SBOMs, and the complete audit log. You verify behavior, not weights — the same posture as any other regulated clinical software you run.

• Monitoring. Prometheus metrics on every component; bundled Grafana dashboards (scoring latency, job throughput, extract freshness, QC status). Alerts fail loudly: a stale extract or failed refresh marks affected scores stale in every consumer rather than serving silently old risk.
• Drift surveillance. Population-drift and calibration-drift monitors run continuously against the expected distributions from your own retro baseline; alarms open a support case automatically (published experience shows calibration drift, not discrimination, is what degrades first).
• Model updates. Semantic versioning per model; quarterly recalibration (+cal.2026Q4). New versions run in shadow mode against live traffic, and are promoted only after the side-by-side report clears your governance. Rollback is one config change — previous bundles stay installed.
• Platform updates. Monthly container releases; security patches out-of-band. Air-gapped sites get quarterly offline bundles.
• Support targets. P1 (scoring down) 4-hour response 24/7 · P2 next business day · named TAM for the first 90 days; a status page and release-notes feed accompany production service. These are targets — contractual SLAs and service credits are set at GA.
• Model-change protocol. Major/minor/patch definitions, required evidence, whether local re-evaluation is triggered, shadow duration and acceptance criteria, customer approval windows, rollback, and version display in the EHR — governed per the NIST AI RMF lifecycle (govern / map / measure / manage). Published with the trust center (§18). Calibration cannot be monitored in real time before outcomes mature, so monitoring distinguishes leading indicators (population drift, missingness) from delayed outcome-based checks.
• Release qualification. Every release must pass, on the exact tagged build: golden-fixture scoring parity, per-outcome metric regression gates (AUROC/AUPRC/calibration within tolerance of the validation baseline), leakage audit re-run, input-schema compatibility check, container signing + SBOM, and a fail-closed readiness decision. A skipped gate blocks the release.