Selected as Best Overall Capstone
Harvard Medical School Executive Education, "AI in Healthcare," February 2026
The control plane between AI output and patient-impacting action.
Enforces consent, authority, and audit before every AI action executes.
AI Governance Control Layer
Required when AI influences clinical decisions under the EU AI Act. Safety OS™ bounds every AI component — from clinic, through discharge, into the home — without replacing existing systems.
Safety OS™ does not replace AI systems, EHRs, or workflows. It governs the execution path between AI output and patient-impacting action.
Safety OS™ produces the artefacts required for conformity assessment. It does not perform the assessment itself.
I'm interested in Safety OS because I'm a...
❌ No Authority Enforcement
Today's AI assistants can act beyond what clinicians have authorised — with no structural way to prevent it.
❌ No Audit Trail
When something goes wrong, there's no defensible record of what the AI did, why, or who authorised it.
❌ No Escalation Logic
AI has no built-in mechanism to escalate to a human when it encounters something beyond its capability.
Safety OS solves all three — structurally, at runtime, with full auditability.
Safety OS™ is a runtime governance kernel that enforces authority constraints, consent gates, escalation logic, and immutable audit logging below the LLM layer. It is not a policy overlay. It is the execution environment in which AI operates — or does not operate — in private human environments.
Safety OS is designed to operationalize the Physician-as-Pilot governance framework.
Safety OS operationalises the governance architecture described in the Physician-as-Pilot Framework.
The framework defines how clinical authority, escalation logic, and audit traceability must be enforced when AI systems operate in private care environments.
📄 Read the Full Governance Framework (SSRN Preprint) →We are defining the reference architecture for authority-bound AI in private environments. The operational template future regulation will formalize.
Rooted in healthcare quality, risk management, and interoperability standards.
The Safety OS is a regulatory-grade governance layer designed to ensure that all AI-mediated actions in home and humanoid care systems remain policy-constrained, auditable, and under explicit human oversight (Physician-as-Pilot). The system does not replace clinicians and does not perform autonomous medical decision-making.
Integrates with EHR systems and care team workflows. Complements existing processes.
In Safety OS™, authority state is tracked at runtime. Every interaction records who holds decision authority, whether consent gates are active, and what escalation pathways are available. This is not documented in a PDF. It is enforced in the system.
The Irreversibility Mechanism
Investors ask: "Why can't OpenAI or Apple just add logging and copy this?"
The answer is structural, not narrative. Safety OS enforces four mechanisms that cannot be retrofitted onto an LLM:
The moat is not audit logs. It is authority-constrained execution enforced below the LLM layer.
Most AI companies add safety as a policy layer after deployment. Safety OS enforces it as an execution constraint before any output is generated.
| Capability | LLM-Only System (ChatGPT + logging) |
Safety OS™ Kernel-Level Authority |
|---|---|---|
| Boundary enforcement | Probabilistic (prompt-based) | Deterministic (runtime-enforced) |
| Authority tracking | Not tracked | State variable per interaction |
| Consent enforcement | Terms of service (static) | Gated per session (dynamic) |
| Escalation logic | "Contact support" | Structured handoff with authority transfer |
| Audit trail | Application-level logs | WORM-compliant, hash-chained, exportable |
| Self-permission | Model can override own constraints | Architecturally impossible |
| Kill switch | Manual shutdown | Verified active per session |
Post-hoc policy overlays are insufficient. Governance must be enforced at the execution layer — before any output is generated.
Dialogue with clinicians, health systems, and research institutions committed to safe AI support.
REQUEST GOVERNANCE DOCUMENTATION →Design-time governance defines accountability. Safety OS™ proves it at runtime.