Waivers

Waivers

The mechanism that stops a standard from being either ignored or abandoned. The README calls the governance family the draconian heart, and the constraints are what make a waiver mean something.

What a waiver can do

Suppress a failing SHOULD. Nothing else.

Rule	Effect
AG-GOV-01	MUSTs are never waivable. No exception, no expiry, no approver
AG-GOV-02	Waivers expire, and the runner enforces expiry against its own clock
AG-GOV-03	A per-surface debt ceiling caps how many waivers can be active
AG-GOV-04	At Gold, each waiver is signed by an approver distinct from the author

A governance violation blocks the gate exactly as a failing MUST does. So a stale waiver does not quietly stop applying, it turns the build red.

Why each constraint exists

MUSTs are not waivable because otherwise the standard is advisory. A conformance claim where anything can be excused is a claim about paperwork.

Expiry against the runner's clock means a waiver cannot be back-dated or extended by editing a field the runner does not read. It is checked against time, not against intent.

The debt ceiling is the interesting one. It turns waivers into a finite resource: taking a new one means either fixing something or letting an old waiver expire. Without it, waivers accumulate until the gate is decorative. With it, the team has to decide what actually matters.

Approver distinct from the author at Gold is the standard separation-of-duties argument. It costs a conversation, and the conversation is the control.

What the runner does not govern

Whether your justification is true. The runner checks that a waiver exists, is in date, is within the ceiling and, at Gold, is signed by someone else. It cannot check that "this analytics endpoint is required by contract" is a fact.

That boundary is stated plainly in the README, and it is the right place to draw it. A tool that pretended to evaluate justifications would be inviting justifications written for the tool.

Using them well

Waive to schedule work, not to avoid it. A waiver with an expiry is a ticket with a deadline the build enforces. That is its best use.

Write the justification for the person who reads it in six months. Which is you, at the moment the waiver expires and the build goes red. "Pending vendor fix, ticket ABC-123" is useful; "known issue" is not.

Watch the ceiling as a health metric. A surface consistently at its debt ceiling is telling you the level or the profile is wrong for what that surface actually is. See Choosing a profile and level: the honest fix is often to declare L2 and be conformant, rather than to declare L0 and live on waivers.

Never waive AG-CSP-04. Staging report-only before enforcing is the SHOULD that protects you from the CSP that breaks production, and waiving it saves an afternoon at the cost of the outage it exists to prevent.