Chapter 22. Escalation and Exceptions

What happens when something does not fit, and how to keep exceptions from becoming permanent.

22.1 The escalation model

Table 59.

22.2 Making escalation usable

Escalation paths fail in predictable ways, and each has a straightforward counter.

No defined arrival state. An escalation that lands in a body’s general queue is a delay, not a decision. Escalations should arrive with the decision required stated explicitly and the evidence attached.

No timeliness enforcement. A path with a stated window and no consequence for exceeding it drifts. [Practice recommendation] Report breached escalation windows as a governance metric, not as an individual performance matter.

Escalation as punishment. Where escalating is treated as a failure by the escalating team, people stop doing it. Escalation should be routine and unremarkable, and the bodies should say so.

22.3 The TG0 bypass path

One escalation deserves explanation because it closes a gap the framework’s own design left open.

TG0 is the initiative qualification checkpoint in the transformation lifecycle (Chapter 23). Nothing in the checkpoint itself prevents an initiative from bypassing it — a team can simply start building.

Detection is retroactive and telemetry-based: the Control Plane finds an architecture or AI System repository entry with no corresponding TG0 record. Response authority sits with the ARB, which has cross-functional standing that neither portfolio nor the AI Governance Body holds alone. Disputes go to the Enterprise Governance Sponsor.

This is worth implementing early, because it is the only mechanism catching work that entered the estate without entering governance, and that work is disproportionately likely to be poorly governed.

22.4 Exception governance

An exception is a recorded, time-boxed decision to proceed without meeting a requirement. It is a legitimate mechanism, and a framework without one accumulates silent non-compliance instead.

Every exception requires four things: the specific requirement being excepted; a stated justification; a compensating control where one exists; and a hard expiry date.

Every exception is time-boxed to a maximum of 90 days, regardless of tier. Tier 4 exceptions have no renewal path at all: at expiry the system returns through full G3 re-authorization instead of receiving a renewed exception.

Keeping exceptions honest

Three mechanisms, in increasing order of importance.

A single register. Exceptions recorded in team-local documents are invisible. One register, one format.

Visible aggregate reporting. Exception volume appears in portfolio health reporting as “initiatives operating under exception.” Exception count is a governance signal; hiding it converts workarounds into invisible accumulated risk.

Expiry that actually fires. [Practice recommendation] Automate expiry notification to the approving authority, not only to the requester. An exception whose expiry is known only to the team benefiting from it will be renewed by inattention.

When to grant, and when to say no

An exception is appropriate where the requirement is genuinely inapplicable to the case, or where the risk it addresses is covered by a different control. It is not appropriate as a substitute for doing the work, and the tell is the justification: “we do not have time to produce the lineage record” is not a justification, while “this system’s grounding source is a public reference corpus with no classification applicable under our scheme” is.

Where a team repeatedly requests the same exception, the requirement is probably wrong or the pattern library is missing something. [Practice recommendation] Review recurring exception types quarterly as candidates for either a framework variation or a new reference pattern. Repeated exceptions are design feedback, not compliance failures.