Safety architecture
Runtime assurance keeps capacity actions inside the envelope
Runtime assurance is a deterministic safety boundary around a proposed operating action. It evaluates the action against current constraints, evidence freshness, policy, and recovery requirements before execution. For AI data centers, the gate produces an explicit allow, repair, reject, or no-proof decision, while the planning or learning system remains advisory rather than becoming the final authority.
Definition
What it is
A runtime assurance gate is the authoritative decision layer that checks candidate actions against an independently specified dispatch envelope and records the reasons for its result.
Category boundary
What it is not
It is not a confidence score from the same model that proposed the action, nor a promise that every future condition has been predicted. A no-proof result is a valid safety outcome.
Operational significance
Why operators care
The separation lets operators use richer forecasting and optimization without making those systems the safety authority. When conditions change, the gate can repair or refuse an action and preserve a replayable explanation.
Mechanism
How the decision path works
- Step 01
Receive a candidate action and its declared assumptions.
- Step 02
Resolve current constraints, margins, telemetry validity, and recovery requirements.
- Step 03
Return allow, a bounded repair, reject, or no-proof.
- Step 04
Attach the decision trace, binding constraint, and rollback posture to the action record.
Textual diagram equivalent
Decision flow
Planner or model → candidate action → independent dispatch-envelope check → allow | repair | reject | no-proof → operator-visible trace and rollback record.
Synthetic repair trace
Visibly scoped example
Synthetic illustrative scenario—not a customer or production result. A workload shift is repaired because a cooling margin would fall below policy during the forecast window. The trace identifies the binding constraint and the smaller accepted action.
Failure and no-proof cases
- The checker shares an unexamined failure mode with the action generator.
- Constraints are incomplete, stale, or expressed in incompatible units.
- An action is allowed despite an unavailable rollback or recovery path.
Limitations
- Runtime assurance is bounded by the completeness of the explicit envelope and trusted inputs.
- It does not remove the need for protective equipment, facility procedures, or operator authority.
- A decision trace establishes what was checked, not universal safety outside that scope.
Evidence and sources
Inspect the basis, not just the answer
Local evidence objects show the GridNinja proof contract. Primary sources provide external standards and risk-management context; they do not validate GridNinja performance.
Related operator resources
Continue the proof path
- How much virtual capacity is safe, for how long, and under which evidence?Learn how a dispatch envelope constrains data center actions by electrical, thermal, reserve, workload, water, and SLA limits before execution.
- Trust starts with boundariesSee how Shadow Mode, replay, allow / repair / reject decisions, audit logs, and proof packs establish evidence before bounded autonomy.
- Inspect how claimed headroom becomes proof-adjusted capacityWalk through a synthetic virtual capacity request as runtime assurance allows, repairs, or rejects actions and records the evidence.
Proof before autonomy
Test the evidence boundary against your capacity question
Start with a Capacity Audit or read-only Shadow Mode discussion. GridNinja does not require control authority to identify where a capacity claim remains unproven.