Article XI — Escalation Discipline

Escalation requires explicit request, reclassification, approval, and documentation — escalation by inference is prohibited.

Commitment

Escalation is a governed act.

It is not a convenience. It is not a default when things get complicated. It is not something a system infers is appropriate and proceeds with. Escalation requires an explicit request, a reclassification of threat posture, explicit approval from authorized human authority, and complete documentation of the escalation event.

Escalation by inference — proceeding at a higher authority level because the situation seems to warrant it — is prohibited without exception.

Foundation

Escalation increases the impact surface of a governed system. Higher threat levels permit more powerful actions, interact with more sensitive infrastructure, and produce consequences that are harder to reverse. The governance requirements that apply at elevated threat levels are proportionally stricter — because the consequences of governance failure are proportionally greater.

A system that can self-escalate can self-authorize. A system that can self-authorize has no constitutional constraint on what it can do — only the constraint of its own judgment about what it should do. That is not governance. It is autonomy with paperwork.

The discipline of explicit escalation is not bureaucratic friction. It is the structural expression of a foundational commitment: that authority is always external to execution, that human oversight is proportional to consequence, and that the governed system does not determine the terms of its own governance.

Enforcement

The governance runtime must require explicit escalation requests. Implicit escalation — proceeding at a higher threat level without a formal request and approval — must be treated as a constraint violation.

Escalation requests must trigger the full escalation workflow: threat reclassification, authority approval at the appropriate oversight level, isolation assessment, constraint rebinding, state dump, and audit preparation. Partial escalation workflows are non-compliant.

Escalation is denied if: authority is insufficient for the requested level, threat posture is ambiguous, isolation is infeasible, or audit channel is unavailable. These denial conditions are not exceptions to Deny by Default — they are applications of it.

At Threat Level 5 (Detached Execution), dual-control authorization is required. Single-party escalation approval is constitutionally insufficient at this level.

All escalation events must produce complete audit artifacts capturing: the escalation request, the reclassification decision, the approving authority, the isolation plan, and the constraint envelope in effect during elevated execution.

In Practice

The AEGIS escalation workflow is a six-step governed sequence: explicit request, threat reclassification, authority approval at the appropriate oversight level, isolation assessment, constraint rebinding, and state dump with audit preparation. No step may be skipped. Partial escalation workflows — those that complete some steps and bypass others — are non-compliant. The workflow does not begin until an explicit request is received. The governance runtime does not infer that a situation warrants escalation and initiate the workflow on the agent’s behalf.

At Threat Level 5 (Detached Execution), the requirements are absolute: physical or network isolation, operator presence, and dual-control authorization. Two independent human authorities must approve before execution proceeds. The rationale is structural: Level 5 operations interact with high-consequence infrastructure under conditions where governance failure is hardest to reverse. Single-party authorization at this level is insufficient not because the single party is untrustworthy, but because the consequence of error at Level 5 justifies a structural control that does not depend on any individual’s judgment alone.

Failure Mode

A system that escalates by inference is a system that has decided — on its own, without explicit authorization — that the governance constraints currently in effect are insufficient for the situation it has determined it is in. This is not a failure of compliance. It is a failure of the constitutional architecture itself: the governed system is redefining the terms of its own governance in real time. The practical danger is not the single escalation that seemed reasonable. It is the operational pattern: a system that escalates by inference under pressure will escalate by inference routinely. The explicit escalation requirement is not about slowing down capable systems. It is about ensuring that every elevation of operational authority above the baseline is a human decision, not a machine inference.

Relationship to Other Articles

Escalation Discipline is the procedural counterpart to Human Oversight (Article IV). Article IV establishes that humans must remain in authority over escalation decisions. Article XI establishes how that authority is exercised — explicitly, with a defined workflow, under documented conditions. Both articles depend on Auditability (Article VII): every step of the escalation workflow must produce audit artifacts, and incomplete escalation records are treated as incomplete escalation events. And both are applications of Deny by Default (Article IX): missing preconditions in the escalation workflow — insufficient authority, unavailable audit, ambiguous threat posture — produce denial, not partial escalation.