Glossary

Break-glass

An audited override that lets an authorized human force a held action through, with a recorded reason.

category ▸ Governance

audit/verify
#101hash ✓#102hash ✓#103hash ✓#104hash ✓#105hash ✓
head 0x9f3a…c1ok: true
verifyChain ▸ chained SHA-256 · signed receipts
What it means

Break-glass, in plain language.

Break-glass is the controlled escape hatch for emergencies: a way for an authorized person to override a hold and force a pending action to execute when waiting is not an option. The defining feature is not the override itself but the accountability around it — break-glass is always logged, attributed, and reason-bearing.

The name comes from the fire-alarm pull: easy to reach when you genuinely need it, impossible to use invisibly. A break-glass action that left no trace would be a backdoor; one that demands a recorded justification turns an exception into evidence.

In Cortex

How Cortex implements it.

This term isn't abstract here — it maps to a real capability in the runtime. Here is exactly how Cortex enforces or relates to it.

Governance

Cortex's break-glass force-executes a pending_approval action but requires a mandatory audited reason. It records who decided and why (decisionReason = "break-glass: …") and emits an ActionBreakGlass event, so the override is itself part of the tamper-evident trail.

Break-glass requires a platform-admin session — it is a privileged, scoped capability, not a default path — and like every other action transition, it is sealed into the Trust Ledger.

See Break-glass enforced, not just defined.

Book a walkthrough and watch the controls in this glossary return real verdicts, seal real evidence, and trace every fact back to its source.