Consider a hypothetical case. A delivery team is a few weeks from a committed date. The standard integration pattern would add work the schedule cannot absorb, so the team asks for an exception: keep one part of the design outside the standard for now, and bring it into line later. The reasoning is sound, and the review agrees. The system goes live on time. Soon after, it passes to an operations or platform team that will run it for years.
Nothing in that sequence is obviously wrong. But two decisions were made, and it is easy for only one of them to be discussed.
Two decisions that look like one
The first decision is whether the design may differ from the standard. That is the question a review is set up to answer. It weighs the deadline and the cost of doing the work properly now against the risk and cost of doing it later.
The second decision is who will carry the difference once the project ends. Once it is live, a non-standard component brings its own work. It needs its own monitoring, because the shared tooling was built around the standard. It needs its own recovery steps, because the usual runbook does not cover it. It needs people who understand it, and the people who understand it best are on a team that is about to move on. Each of these is continuing work, and none of it sits in the project plan, because the project will not be there to do it.
When the two decisions are treated as one, approving the first quietly settles the second, without asking the people it affects. The delivery team accepts the risk of the exception. The receiving team inherits the cost of living with it. The weak point in this pattern is the handover rather than the approval. The approval itself may be reasonable; the handover is where the cost can be assigned without anyone agreeing to it.
Existing guidance covers parts of this. AWS's DevOps Guidance recommends tracking temporary exceptions in a central, searchable place, recording the reasoning, who approved each one, the business use case and the anticipated duration, and assigning clear roles for the creation, review and retirement of exceptions. Microsoft's Well-Architected guidance on architecture decision records asks that each significant decision capture its context, trade-offs and implications, and cautions against hiding the consequences of a decision. Both are written for their own platforms and practices, and both are useful well beyond them. Neither, on its own, makes the team that will operate the exception a party to accepting it. That is a choice each organisation has to make deliberately.
A hypothetical example: the older interface that stayed
The example below is hypothetical. It describes a common shape of problem, not any specific organisation, system or project.
A team is migrating an application to a new platform. The platform standard is for integrations to use its supported messaging pattern. One downstream system still depends on an older scheduled file interface, and rebuilding that integration would push the migration past its deadline. The team asks to keep the older interface running on the new platform and to replace it in a later phase. The exception is approved.
On paper, the change is small. In operation, it raises questions that belong to whoever runs the platform after go-live:
- Monitoring. The platform's standard alerts watch the messaging layer. Who notices when a file arrives late, arrives twice, or does not arrive? What does healthy look like for this interface?
- Recovery. If an overnight transfer fails, can it be replayed safely, or will a replay create duplicates downstream? Is that procedure written down, and has anyone outside the project tried it?
- Support capacity. Does the receiving team have someone who understands the older format, or will each incident route back to people who have already moved to other work?
- Dependencies. Which other systems read from the same location or rely on the same schedule? If the downstream system changes its own timing, who finds out?
None of these questions argues against the exception. They describe what accepting it involves. If the receiving team can answer them, or is given the time and access to find the answers, the exception is manageable. If it cannot, the organisation has approved a design without anyone agreeing to run it.
Four questions for a consequential exception
For an exception that will outlive the project, four questions are a useful starting point.
What differs from the standard? Be specific about which control, pattern or tool does not apply and what replaces it. "Uses the older interface" tells the next team very little. "Does not use platform messaging; relies on a scheduled file transfer with no built-in retry" tells them what to watch.
Who carries the work, and from when? Name the team that will monitor, recover and support the exception after handover, and confirm that they have agreed. If the answer is simply "operations," check whether operations has seen it.
What change or failure would trigger reconsideration? Describe the conditions under which the original reasoning stops holding: a second system starting to depend on the interface, repeated failed transfers, a change in the downstream schedule, the departure of the few people who understand it. The receiving team may be the first to notice these signals, which is one more reason they need to know what the signals are.
What would it take to remove the exception? Record the work involved, the dependencies that would have to move, and who owns the exit. Check whether the later phase is funded and scheduled or is still an intention. An exception without a credible exit can become permanent without anyone deciding that it should.
The same pattern with an AI agent
This example is also hypothetical.
An organisation uses an AI agent to draft updates to records, which a person reviews and approves before they take effect. For a limited pilot, the agent receives an exception: for one narrow class of low-risk updates, it may apply the change directly, without approval.
That exception may be well reasoned. After the pilot is handed to the team that runs the process, though, someone has to carry specific work. They need to check that the information the agent relies on for that class of update is still current, and that its permissions have not widened beyond the one class that was approved. They need to investigate when an automatic update turns out to be wrong, which means being able to see what the agent did and on what basis. And they need to be able to suspend its ability to act, returning it to drafting for approval, without waiting for the pilot team to respond.
The NIST AI RMF Playbook, which is voluntary guidance, describes responsibilities of this kind for deployed AI systems: post-deployment monitoring plans that include override, incident response and recovery (MANAGE 4.1), and assigned responsibilities and mechanisms to supersede, disengage or deactivate systems that behave inconsistently with their intended use (MANAGE 2.4). The point for an exception is narrower. Those responsibilities have to be handed over explicitly, to named people, together with the exception itself.
Not every deviation deserves this
The strongest objection is practical. Small, local departures from a standard are ordinary: a different library version, a naming convention, a temporary workaround inside their own code. Asking for owners, triggers and an exit plan for each one would bury useful work under paperwork. Worse, it would teach people to stop declaring exceptions at all, which leaves an organisation knowing less than before.
The objection is right, and the answer is to be selective. A local exception that a team can absorb itself, because it builds the thing, runs it and can reverse it, needs little more than a short note. Its cost stays with the people who chose it.
The handover questions matter when an exception does at least one of three things. It crosses a boundary into systems or teams that did not choose it. It places continuing work on another team. Or it survives into operations beyond the project that justified it. Those are the exceptions where the cost moves away from the decision. This fits alongside the broader question of which decisions deserve heavy review at all; it adds a question about who holds the result afterwards.
There is one more limit worth naming. Where the team that builds a system also runs it, much of the handover problem disappears, because the cost stays with the people who chose the exception. The questions about triggers and an exit still apply. The question of who carries the work mostly answers itself.
A question for the receiving team
If you are on the team that will inherit a system, a useful question to ask before handover is a plain one: what work will this decision leave with us, and are we being given what we need to carry it?
What you need may include monitoring that covers the exception, recovery steps that someone has tested, enough knowledge to support it without calling the project team back, the access to investigate it, and the standing to reopen the decision when the signals change. If any of that is unclear, the time to say so is before the handover, while the people who approved the exception are still close enough to help.
Sources
- AWS Well-Architected DevOps Guidance — [AG.CA.3] Implement systematic exception tracking and review processes. Vendor guidance, cited for exception tracking, approval, duration, review and retirement.
- Microsoft Azure Well-Architected Framework — Maintain an architecture decision record (ADR). Vendor guidance, cited for recording significant decisions with their context, trade-offs and implications.
- NIST AI Resource Center — AI RMF Playbook: Manage. Voluntary guidance; NIST notes the AI RMF is being revised, so check the current version.