How to manage exceptions to architectural decisions

What should an architectural exception record contain?

An exception record should answer six questions: which decision is being bypassed, where does the bypass apply, why is it necessary, who accepted the risk, what compensating controls exist, and when does the exception expire? Keep the scope as narrow as possible by repository, service, path, capability or environment. Link the exception to the original decision so a reviewer sees the default before reading the deviation.

Do not use an exception to hide a superseded decision or a missing owner. If the default no longer reflects reality, update or supersede the decision through the normal review path. Exceptions are for bounded cases where the default remains valid elsewhere.

• Require an approver who owns the governing decision.
• Set an expiry date and a renewal owner.
• Describe compensating controls and their evidence.
• Make expired exceptions visible in CI and review dashboards.

How should an exception move back to the default?

Treat expiry as a decision point, not a calendar detail. Before the date arrives, the owner should either remove the workaround, renew it with a new justification, or supersede the original rule if its assumptions changed. The resulting record should link the implementation change and checks that demonstrate closure. This prevents a temporary legacy constraint from becoming invisible infrastructure.

For agents, the important rule is simple: an active exception may narrow a decision’s applicability, but it must never be inferred from an old comment or a disabled check.

What does a reviewable exception look like?

A reviewer should be able to decide whether an exception is safe without opening a private chat thread. Put the default decision first, then state the exact deviation, scope, reason, owner, approver, compensating controls and expiry. If the exception exists because a legacy system cannot satisfy the default, name the missing capability and the migration or reconciliation work that reduces the risk. Link evidence for the control rather than describing it as a future intention.

The exception should narrow authority, not erase it. An agent may retrieve an active exception for the matching path, but it should still cite the governing decision and the exception ID. When the exception expires, the normal check should fail or the review should become visible. This makes temporary delivery pressure a managed state rather than a hidden fork of the architecture.

• Default decision and exact scope of the deviation.
• Named owner, approver and expiry date.
• Compensating controls with evidence links.
• Closure, renewal or supersession path.

Who owns an exception after approval?

The approver accepts the deviation; the named exception owner remains responsible for closing it. That owner should track the implementation work, compensating controls, evidence links and expiry date, while the decision owner confirms that the default rule still makes sense. Separating those roles prevents an architecture group from approving a workaround and then assuming that another team will remove it.

Make the lifecycle visible wherever the decision is retrieved or enforced. An active exception may narrow a check for the exact repository and path, but it should not suppress the governing decision or hide the normal remediation. As the expiry approaches, route a review to the owner. Closure should link the change and passing check; renewal should explain the remaining constraint; supersession should update the default through normal review.

• Exception owner distinct from approver where practical.
• Compensating controls and evidence kept current.
• Expiry reminders visible in retrieval and CI.
• Closure, renewal or supersession linked to the outcome.

Exceptions are part of the control model

Real systems contain legacy constraints, migrations and emergency trade-offs. Pretending that exceptions do not exist drives them into ignored warnings, blanket suppressions or undocumented comments. Once hidden, a temporary deviation can outlive the people who understood its risk.

An exception does not change the governing decision. It grants a narrow deviation under stated conditions. If exceptions become the normal path, the decision itself may need review.

Record the minimum defensible evidence

The exception should answer who accepted which risk for what scope and until when. Link it to the original decision so a reviewer can understand the default rule and the reason for deviating.

• Decision ID and exception ID.
• Repository, path, service or environment scope.
• Justification and alternatives considered.
• Owner, required approver and approval evidence.
• Expiry or explicit review date.
• Compensating controls and removal plan.

Make CI matching exact

An enforcement check should suppress a finding only when the exception is active and its declared scope matches the violation. Avoid repository-wide waiver tokens for path-specific problems. Report the exception ID and expiry beside the waived result so the risk stays visible.

AsDecided supports explicit decision lifecycle and scoped deterministic enforcement; teams designing exception automation should keep the exception record in the same reviewed workflow. Do not infer approval from an agent's explanation.

Close the lifecycle

Notify owners before expiry, fail or escalate after expiry according to risk, and preserve the historical record after closure. Track repeated and long-lived exceptions as signals that a rule is impractical, enforcement scope is wrong or migration work lacks ownership.

id: EXC-0091
decision: ADR-0042
scope: src/events/legacyPublisher.ts
expires: 2026-11-30
controls:
  - reconciliation job
  - publish-failure alert