A temporary exception reaches its end date. The migration is late, the project has closed and the person who approved the exception has left. The architecture board still has to decide whether the deviation can continue, on whose authority and under which conditions.
Fictional worked example. The people, dates and records in this case are invented.
Recover what was allowed
The organisation's architecture standard requires order reporting to use its shared event platform. Exception EX-042 allowed one existing nightly file feed to continue until 30 April while the Data Platform team completed the replacement.
The original reason was specific: turning off the file feed before the new consumer could handle order cancellations would leave Operations with incomplete reports. The exception covered that feed only. It required a daily reconciliation, an accountable service owner and a review before expiry.
The record links the original approval to those conditions. It also records who approved it at the time. Their departure does not change that history.
By the review, the delivery project has closed. Its technical lead can no longer perform the reconciliation. The Data Platform migration remains open.
Establish who can decide now
The Service Owner brings the exception to the board. They own the live feed and must carry out whatever the review decides.
The current Architecture Board Chair has authority to approve this class of exception under the CTO's delegation. The Operations Director must also agree to the reporting arrangements and any continuing operational exposure. The Data Platform Lead supplies the migration evidence and owns that dependency.
Those responsibilities are written into the review. The former project manager's name is not replaced on the original approval, and the Platform Lead's delivery estimate is not treated as permission to extend the exception.
Put the evidence beside the request
On 30 April, the board reviews a request for six more weeks.
| Evidence in the review | What it establishes |
|---|---|
| EX-042, approved version 1 | The permitted feed, original rationale, reconciliation condition and 30 April expiry. |
| Migration readiness review | The replacement still fails the order-cancellation test. The Platform Lead estimates readiness by 10 May; that date remains an estimate. |
| Reconciliation records | Two checks were missed after the project closed. Operations has since accepted the work and supplied completed checks for 28 and 29 April. |
| Continuity procedure | Operations can produce the report manually if the feed must stop. The Operations Director has reviewed that fallback. |
| Current CTO delegation | The Board Chair can approve this exception; Operations agreement is also required under this organisation's policy. |
The two missed checks stay on the record, with the Operations Director responsible for reviewing the gap. A new approval cannot turn them into checks that happened.
Record the board's actual choice
The board rejects the six-week request. The migration evidence supports a shorter review window, and Operations now has an alternative if the feed stops.
It also considers ending the feed immediately and using the manual report. Operations confirms that this is possible, but asks to retain the feed briefly while the replacement is completed.
The Chair approves EX-043 version 1, with the Operations Director's recorded agreement:
Continue the existing order-reporting file feed from 1 May through 14 May. No additional feeds or consumers are covered. The Service Owner remains accountable for the feed. Operations performs the daily reconciliation. Review migration readiness on 5 May and stop the feed if a reconciliation failure remains unresolved at the next scheduled run. Any further extension requires a new decision before 14 May.
The review minutes, item 3, identify the exact version approved, the Chair's authority and Operations' agreement.
EX-042 expires on 30 April and remains available with its original conditions. EX-043 links back to it. The migration task stays open. Nobody marks the exception remediated merely because its continuation received approval.
Close it against evidence
The Service Owner schedules the 5 May review and assigns the readiness check to the Platform Lead. If the estimate changes, that owner must bring back the changed dependency and its effect on the 14 May limit.
The replacement passes the cancellation test on 10 May. The Service Owner disables the nightly feed on 12 May, and Operations checks the resulting reports against the agreed reconciliation criteria. The Chair records closure of EX-043 on 14 May, citing the test result, the disabled-job record and Operations' confirmation. The review of the two missed checks remains a separate item until Operations records its conclusion.
The original exception, the short continuation and the closure remain separate events. The next reviewer can see why the deviation existed, why it continued and what finally ended it.
Use the case in your own review
Prepare the original permission, current evidence and proposed outcome with the decision record template. Include who owns a delayed dependency and what happens if it misses the next review.
Traceway brings rationale, human approval and links to resulting work into a shared decision record. Trace, its native AI, helps people develop the proposal and work through the alternatives; the responsible people confirm the evidence and decide. To evaluate that workflow, ask the participants to recover the earlier conditions, review the changed proposal and retrieve the version each approval covers. The approval-workflow scorecard gives you a place to record what the demonstration actually shows.