# SCRIMED Service Reliability Brief

Status: service-reliability-hardening-active
Controls: 10
Open gates: 4
Fault classes: 8
High-severity fault classes: 4
Efficiency improvements: 6
Page routes: 164
API route patterns: 439
Smoke-covered HTML routes: 76

## Boundary
SCRIMED Service Reliability maps products, services, agents, barriers, fault classes, mitigations, owners, proof routes, and retained approval boundaries into one operating lane. It strengthens execution discipline, but it does not certify security or compliance, grant legal approval, approve buyer release, bypass AAL2, authorize PHI processing, approve production connectors, guarantee reimbursement, authorize public customer claims, or authorize live clinical care.

This brief is not release approval, legal approval, security certification, HIPAA certification, FDA clearance, ONC certification, PHI processing approval, production connector approval, token authorization, public customer approval, reimbursement assurance, or live clinical authorization.

## Product And Service Controls
- Product Console and OS Hub discoverability (resolved): Route sprawl made it easy for high-value proof surfaces to become hard to find. Mitigation: Navigation Audit, Product Console, Hub, and homepage now cross-link the command surfaces and route inventory. Owner: Product Console + Release Steward Proof: /product, /hub, /navigation, /api/navigation-audit Boundary: Route discoverability is operating evidence, not protected execution proof or release approval.
- Release continuity and source-control alignment (contained): Production can drift from source control if deployments, tags, smoke proof, and no-secret boundaries are not checkpointed together. Mitigation: Release Continuity ties deployment proof, GitHub baselines, public smoke, protected fail-closed checks, and AAL2 operator limits into one lane. Owner: Release Steward Proof: /release-continuity, /api/release-continuity, /api/release-continuity/brief Boundary: Continuity proof does not mint tokens, store secrets, bypass AAL2, or approve buyer release.
- Clinical, legal, security, and approval authority (external-review-required): SCRIMED can prepare approval evidence but cannot self-certify HIPAA, SOC 2, HITRUST, FDA, ONC, legal, reimbursement, or clinical authority. Mitigation: Approvals Readiness and Boundary Resolution keep external evidence requirements, owners, workarounds, and prohibited claims visible. Owner: Founder + qualified external reviewers Proof: /approvals-readiness, /clinical-authority-readiness, /boundary-resolution, /qa-claim-guard Boundary: Qualified counsel, security assessors, regulatory experts, customer approvers, and applicable certification bodies retain authority.
- Manual AAL2 protected proof (operator-required): Public checks prove fail-closed behavior, but authenticated protected mutations require a fresh human AAL2 session. Mitigation: Manual QA Execution Console, QA Run Control, Human Run Packet, and protected workspace panels preserve no-secret human-run proof. Owner: Approved tenant-admin or pilot-lead operator Proof: /pilot-workspace/access, /qa-manual-execution-console, /qa-run-control, /qa-human-run-packet, /buyer-release-control-run Boundary: No code path may retain, print, store, or reuse bearer tokens; protected happy path proof stays human-operated.
- Buyer release and external sharing (protected-gated): Buyer-specific external sharing requires retained release decisions, named reviewer signoffs, recipient controls, authority attestations, and access-log reconciliation. Mitigation: Buyer Release Control Runbook sequences protected verifier records, packets, timeline, reconciliation, remediation, and disabled lockbox controls. Owner: Buyer Diligence + Release Steward + qualified reviewers Proof: /buyer-release-control-run, /pilot-workspace/access#buyer-release-control-verifier, /api/pilot-workspaces/{workspaceSlug}/buyer-release-control-run Boundary: Internal protected diligence can prepare evidence; external buyer sharing remains blocked until qualified release authority is retained.
- Commercial buyer path (active): Buyer value, proof routes, pricing, demos, protected evidence, and pilot intake can fragment across separate surfaces. Mitigation: Pilot Deal Room, Product Console, pricing, demos, pilot programs, and sales operations now present a continuous buyer path. Owner: Sales operations + Buyer Diligence Proof: /pilot-deal-room, /pricing, /demos, /pilots, /sales-operations Boundary: Commercial readiness does not authorize customer production activation, PHI, live clinical execution, or public customer claims.
- Agent and workflow operating system (contained): Agent execution can become unsafe if runtime, identity, audit, connector, and human-review gates are not explicit. Mitigation: Workflow contracts, deny-by-default implementation readiness, runtime safety, execution audit, and AgentOS evaluation keep execution synthetic and review-gated. Owner: AgentOS + Workflow Runtime Proof: /agents, /workflows, /workflows/contracts, /workflows/runtime-safety, /workflows/execution-audit, /evaluation Boundary: Agents cannot mutate medical records, contact patients, submit payer actions, or execute production connectors without approved gates.
- Interoperability and synthetic validation (contained): Connector confidence can be overstated if synthetic conformance and live production authorization are not separated. Mitigation: Standards registry, fixture validation, conformance evaluations, and synthetic validation keep connector readiness inspectable before live use. Owner: Interoperability Control Plane + Validation Trust Lab Proof: /interoperability, /interoperability/evaluations, /integrations, /synthetic/validation Boundary: Synthetic conformance does not approve live connectors, PHI ingestion, payer submission, EHR writeback, or partner acceptance.
- Trust, claims, and incident operations (active): Public language, trust operations, incident posture, and enterprise diligence can diverge from retained evidence. Mitigation: Trust Safety Operations, Claims Register, Enterprise Readiness, and QA Claim Guard keep evidence and claim posture aligned. Owner: Trust Safety Ops + Legal + Security + Claims Governance Proof: /trust-safety-operations, /trust-center, /claims, /qa-claim-guard Boundary: Trust operations define controls and escalation posture; managed 24/7 production coverage and certifications require approved staffing and review.
- Public market and global expansion (external-review-required): Financial, regional, procurement, reimbursement, and legal claims can outpace current evidence without external review. Mitigation: Public Market Readiness, Global Reach, and Deployment Profiles separate operating discipline from audited financial or regional approval claims. Owner: Founder + Finance + Global Partnerships + qualified regional reviewers Proof: /public-market-readiness, /global-reach, /deployment-profiles, /market-activation Boundary: These routes are readiness and operating discipline, not audited financial statements, securities material, legal advice, or regional approval.

## Fault Classes
- Route inventory drift (watch): New App Router pages or APIs added without Navigation Audit and smoke updates. Control: Navigation Audit source totals, hub route inventory, and public smoke source-count checks. Fail closed: Release steward updates inventory or keeps the route out of buyer-critical claims.
- Protected token handling (high): Attempting to automate AAL2 protected proof with retained bearer tokens. Control: Manual QA runbooks, no-secret smoke, protected fail-closed APIs, and browser-session verification. Fail closed: Reject token storage and require a fresh human AAL2 session or one-time external token disposal.
- External approval overclaim (high): Copy, buyer materials, or operator notes implying certification, legal approval, PHI authority, or live-care authority. Control: Approvals Readiness, Boundary Resolution, Claim Guard, no-authority headers, and prohibited-claim lists. Fail closed: Downgrade to readiness language and route to qualified external review.
- Dynamic route smoke gap (watch): Dynamic pages compile but are not all crawled by public smoke. Control: TypeScript, build, dynamic page inventory, and targeted smoke for buyer-critical slug routes. Fail closed: Keep canonical entry points smoked and add slug-specific smoke when needed.
- Generated cache conflict (watch): Local `.next` or quarantine output interfering with checks. Control: Generated cache cleanup before build/typecheck and generated-integrity check. Fail closed: Clean generated output and rebuild from source.
- Protected environment missing locally (watch): Local shells without Supabase/Vercel protected environment or active AAL2 session. Control: Fail-closed protected smoke, route-level no-authority headers, and operator workaround instructions. Fail closed: Treat public checks as fail-closed proof and require an approved operator for protected proof.
- PHI or live-care boundary breach (high): Inputs, artifacts, or routes attempting to store patient identifiers, clinical records, diagnosis details, or live-care actions. Control: Synthetic-only boundaries, prohibited data lists, no-PHI protected panels, intake rejection, and live-care authority headers. Fail closed: Reject or strip prohibited data and keep live-care actions blocked.
- Public distribution lockbox gap (high): Buyer proof referenced outside protected diligence before release-control chain completion. Control: Buyer Release Control Runbook, protected verifier, disabled distribution lockbox, recipient attestations, and access-log reconciliation. Fail closed: Keep distribution internal-only until retained release decisions and recipient controls exist.

## Efficiency Improvements
- One route map for every operating surface: Reduces release uncertainty and navigation search time for operators and buyers. Proof: /navigation reports page routes, API patterns, smoke pages, groups, and bottlenecks. Owner: Product Console + Release Steward
- Reliability counters inside Product Console: Lets executives see controls, fault classes, open gates, and efficiency work without reading every page. Proof: /product and /api/product/console include Service Reliability posture. Owner: Founder + Product Console
- No-authority headers on reliability APIs: Prevents a reliability route from being mistaken for approval, certification, PHI, release, or live-care authority. Proof: /api/service-reliability and /api/service-reliability/brief expose explicit no-authority headers. Owner: TrustOS + Release Steward
- Source-count smoke checks: Catches route-count drift when pages or API handlers are added. Proof: Public production smoke checks navigation counts and service reliability route/API/brief. Owner: Release Steward
- Fail-closed protected posture: Keeps protected proof blocked publicly while still allowing browser-session operator verification. Proof: Protected routes fail closed in public smoke and remain AAL2 gated. Owner: Security + Operator
- Downloadable executive brief: Turns the reliability map into a reviewable artifact for founders, operators, reviewers, and buyers. Proof: /api/service-reliability/brief Owner: Founder + Release Steward

## Next Operator Actions
- Use /service-reliability before each release to confirm every product/service barrier has an owner, proof route, and retained boundary.
- Keep Navigation Audit and public smoke source-count checks updated whenever routes or API handlers are added.
- Keep protected happy-path proof human-operated through AAL2 and never retain token values.
- Route approval, PHI, live-care, customer-proof, public-market, reimbursement, legal, and security-certification claims through qualified external review.
- Add any newly discovered fault class to this lane before expanding product claims or buyer materials.

Updated: 2026-06-23