---
title: "Exceptions"
description: "Record a limited exception when a project cannot use a required control or when another design has a measured advantage."
url: "https://architecture.mnppi.org/governance/exceptions/"
status: "Current"
last_updated: "2026-07-23"
---

# Exceptions

**Standard details**

- Status: Current
- Reviewed: July 23, 2026
- Cadence: Review at each exception date

An exception keeps the standard honest.
It is better than a hidden difference between policy and production.

## Required record

Each exception must include:

- The affected project and control.
- One named owner.
- The technical or business reason.
- The limited scope.
- The added risk.
- A compensating control when one is necessary.
- The rollback or transition plan.
- The review date.
- An expiration date or a permanent decision.

## Decision test

Approve an exception when:

- The standard cannot support a necessary result.
- Another design has a measured advantage.
- The exception has a clear owner.
- The project can operate and recover safely.
- The exception does not silently weaken an unrelated control.

Do not approve an exception only to avoid 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 can include repository names, risks, dates, and recovery details.
The public standard can include a general lesson after the 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.