Thinking / System design· Part 9 of 10 in The assurance layer
An alert is not an exception-management system
Detection is only the first step. Operational exceptions need ownership, evidence, remediation, verification and closure.
- Exceptions
- Governance
- Assurance
- Operations
17 August 2026
On this page
Operational systems are good at producing alerts.
Email.
Notifications.
Red banners.
Dashboard counts.
Those mechanisms are useful for attracting attention.
They are not the same as managing an exception.
Detection is only the beginning
Suppose a reconciliation control discovers:
Licence Management reports a tenement as At Risk, while Programme Assurance reports On Track.
A notification can tell someone that the discrepancy exists.
But several questions immediately follow:
- Who owns the issue?
- How serious is it?
- When must it be addressed?
- What is the expected state?
- Which system is authoritative?
- What remediation is required?
- Has the correction actually worked?
- Who confirmed closure?
If those questions are not managed, the alert simply joins a growing pile of things people are expected to notice.
An exception should be a managed object
A useful exception record might include:
- exception code,
- control that detected it,
- affected application,
- canonical entity and key,
- expected state,
- actual state,
- severity,
- detected time,
- owner,
- due date,
- status,
- remediation notes,
- evidence,
- closure time.
The workflow could be:
Open → Acknowledged → Investigating → Remediation → Resolved → Verified → Closed
That structure matters because each stage means something different.
Resolved is not verified
This is one of the most important distinctions.
“Resolved” means someone believes the problem has been corrected.
“Verified” means the control has been rerun and the expected condition now exists.
For example:
A user corrects Programme Assurance from:
OnTrack
to:
AtRisk
The exception should not close merely because the user clicked Resolve.
The orchestrator should rerun the reconciliation.
If both systems now agree, the exception can move to Verified and then Closed.
That creates an evidence-based closure rather than an administrative one.
Exceptions need ownership
A technical integration failure and a regulatory compliance exception may require different owners.
A useful orchestrator should therefore distinguish categories such as:
- business exception,
- integration exception,
- application exception,
- infrastructure exception,
- governance exception.
The owner might be:
- exploration manager,
- tenure manager,
- finance,
- integration support,
- system administrator.
That makes escalation more meaningful.
Some exceptions can be accepted
Not every mismatch must be immediately corrected.
There may be a legitimate reason for temporary divergence.
For example, a regulator decision may have been received but not yet become effective.
An exception may therefore need an Accepted or Waived state with:
- reason,
- approver,
- expiry,
- review date.
Otherwise exception management becomes inflexible and encourages users to close issues that are not really closed.
The system should preserve exception history
Patterns matter.
If the same integration discrepancy occurs every week, each individual correction may look minor.
Collectively, they show a structural weakness.
Exception history makes it possible to ask:
- Which controls fail most often?
- Which systems generate the most stale data?
- Which exceptions repeatedly reopen?
- Where are remediation times increasing?
- Which integrations create recurring manual work?
That turns exception management into a source of improvement rather than only firefighting.
Governance should include the control itself
Controls can also become stale.
If a control no longer reflects the operating model, it can produce noise.
So the control should have:
- an owner,
- a purpose,
- a version,
- an effective date,
- a review date,
- a severity rationale.
Governance mechanisms need governance too.
Alerts inform. Exceptions govern.
The distinction is simple:
An alert says:
Look at this.
An exception says:
Something differs from the expected operating state. Here is who owns it, what must change, how it will be verified and when it can be closed.
That difference becomes important as systems become more connected.
Once operational applications, integrations, schedules and controls are all working together, the organisation starts to develop something larger than a collection of software systems.
It develops an assurance layer around the operating model itself.