Safety Kernel

Safety Kernel and Equipment Control Commands

The safety kernel is the last check on a command before it executes on equipment. Before it is sent, a command is authorized by a clinician. The safety kernel activates the moment a human accepts the command.

Boundaries

Boundaries of responsibility

The division of responsibility boundaries between the system’s components.

This separation of responsibility is the load-bearing structure of the safety kernel. Meaning is defined outside the executing code; neither the service nor the library can become a second source of truth — they execute what has been compiled and do not decide what it means.

Classification

Command classes

Class	Colour	Description	Confirmation required
Safe	Green	The command is sent to the device without clinician authorization	None
Supervised	Yellow	Action within a pre-authorised clinical envelope	Timeout → the action executes per the clinical envelope’s rules (reversible within a set window)
High-risk	Red	Action outside the routine envelope or an irreversible change	Explicit human authorization of the command

Red-class commands are never executed autonomously, without human authorization. If the human does not respond within the timeout window, the system reverts to advisory mode and logs the event (the command is not sent to equipment for execution).

Verification

Seven pre-execution checks

Before executing any yellow or red command, the safety kernel evaluates:

1. Rule provenance — the rule that produced this recommendation is from an approved compiled bundle
2. Device identity — the target device is the one the rule was compiled for
3. Parameter envelope — the proposed parameter is within the pre-validated clinical range
4. State coherence — the current device state is consistent with the assumed pre-condition
5. Conflict check — no concurrent contradictory command is in flight for the same device
6. Audit slot — an audit event slot is available (fail-safe: no command without audit)
7. Clinician authorization — the issuing clinician’s role is authorized for this command class

Rollout

Phased rollout

The safety kernel supports six deployment phases, each gated by a separate validation milestone:

Transitions between phases require a formal sign-off from the clinical authority of the deploying institution.

Audit

Audit trail

Every command — proposed, accepted, rejected, or timed out — is recorded as durable audit material with timestamp, rule reference, device ID, clinician ID, and outcome. Audit refs are available for retrospective review through the clinical-data facade as FHIR AuditEvent resources.

Next

Documents