Exceptions

Status

Current

Reviewed

September 28, 2026

Cadence

Review at each exception date

Exceptions prevent silent drift. A written exception is better than a quiet deviation.

If a Worker project cannot use Workers Builds yet, or must keep a long-lived runner, write that down with an owner and a review date. Do not leave it as tribal knowledge.

A supported-majors exception also lives in supported-majors.json with owner, reason, created, and expires. Expiry is at most 90 days and renewable once. An expired or missing-expiry row is a finding.

A Wrangler hold outside the transitional whitelist is an exception. BotMail, FedRAMP-critical Workers, and other named production exclusions stay on their own tracks until an explicit waiver. They are not silent cf migrate candidates.

Required record

Each exception must include:

• Affected project and control
• One named owner
• Technical or business reason
• Limited scope
• Added risk
• Compensating control when needed
• Rollback or transition plan
• Review date
• Expiration date or a permanent decision

Decision test

Approve an exception when:

• The standard cannot support a required outcome
• Another design has a proven advantage
• The exception has a clear owner
• The project can operate and recover safely
• The exception does not weaken an unrelated control

Do not approve an exception only to pass a failed check. Fix the change, or update the standard when the rule is wrong.

Public and private information

This site publishes the exception process. It does not publish private exception records.

The internal record may include repository names, risks, dates, and recovery details. The public standard may include a general lesson after review.

End states

At the review date, choose one result:

1. Remove the exception and return to the standard.
2. Extend the exception with new evidence and a new date.
3. Make the exception permanent for the named project.
4. Update the organization standard because the exception proved a better default.