The system that detects the exception may not own the problem

An exception has to appear somewhere.

A historian detects a limit excursion.

An integrity application records a failed inspection.

A contract system identifies a notice deadline.

A licence system finds an overdue obligation.

An Orchestrator discovers that two applications disagree.

It is tempting to let the application that discovered the problem manage the whole response.

Sometimes that is appropriate.

Often it is not.

The source of detection tells us where the exception became visible.

It does not necessarily tell us who owns its consequences.

Exceptions originate everywhere

Consider a few examples.

An API reports:

Payload rejected.

A process historian reports:

Temperature outside integrity operating window.

A maintenance system reports:

Safety-critical work overdue.

A legal system reports:

Contractual notice due tomorrow.

A compliance system reports:

Licence obligation overdue.

An Orchestrator reports:

Authoritative and replicated statuses disagree.

All six are exceptions.

But they represent very different problems.

The API error may belong to integration support.

The operating excursion may require engineering assessment.

The overdue work may affect operations.

The contractual notice may belong to legal or commercial management.

The licence obligation may involve operations, environment and legal.

The inconsistent statuses may first require the Orchestrator to establish which source is authoritative.

A common exception mechanism may help detect and route these conditions.

It should not make them all the same kind of problem.

Detection source is not ownership

Suppose an Orchestrator finds the following combination:

Work permit: ACTIVE Required barrier: IMPAIRED

The Orchestrator can identify the contradiction because it can see both states.

That does not mean the Orchestrator should decide whether the work can continue.

The decision may require knowledge of:

• the type of work,
• the purpose of the barrier,
• alternative controls,
• the current operating condition,
• the risk assessment,
• and the authority required to approve a deviation.

Those responsibilities belong in the appropriate operational and governance domains.

The Orchestrator has done something valuable.

It has exposed a relationship that neither system could see by itself.

Its next job is to move the issue to the right place with enough information for somebody else to act.

Exceptions should describe what they affect

A useful exception model may need categories such as:

• integration,
• application,
• operational,
• safety,
• asset integrity,
• environmental,
• compliance,
• commercial,
• financial,
• governance.

These categories are not necessarily mutually exclusive.

A failed environmental monitoring activity might be:

• operational because required work was not performed,
• compliance-related because a licence condition is affected,
• governance-related because an escalation deadline has expired.

That matters because the consequences determine ownership and authority.

If exceptions are classified only according to the application that generated them, much of this meaning is lost.

A better principle is:

Classify an exception according to the expectation or obligation that has been affected, not only according to where the exception was detected.

Owner, assessor and decision authority may be different people

Organisations often assign one owner to an issue.

That can hide several different responsibilities.

For a material exception, we may need to distinguish:

Owner ≠ Assessor ≠ Decision authority ≠ Verifier

An integrity engineer might assess the technical condition.

An operations manager might own the response.

An asset manager might have authority to approve continued operation.

An independent engineer might be required to verify restoration.

Legal might advise whether a regulator must be notified.

Those are different roles.

Representing them explicitly is more useful than placing a single name in an Owner field.

It also allows the system to ask better questions.

Has the technical assessment been completed?

Has the authorised decision-maker approved the operating position?

Has independent verification occurred?

Those questions are difficult to answer when all accountability has been reduced to one workflow owner.

Cross-domain problems support specialised applications

This also reinforces the argument for application boundaries.

An asset integrity application should understand integrity.

It should not have to become a contract management system.

A legal obligation register should understand the source and meaning of obligations.

It should not have to understand every piece of process equipment.

A permit application should understand control of work.

It should not have to implement corporate risk acceptance.

The governance layer can connect these responsibilities without forcing them into one application.

That creates a more useful architecture:

Domain applications own their facts and rules. The Orchestrator moves and tests information between them. Governance owns the accountable response when the consequence crosses those boundaries.

Separation is therefore not simply a technical preference.

It protects authority and meaning.

Ownership can also move

The appropriate owner may change during the life of an exception.

A technical team may initially investigate the condition.

Once the consequence is understood, management may need to decide whether the resulting risk is acceptable.

If a statutory obligation is affected, legal or compliance may become involved.

Once remedial work begins, responsibility may move again.

The exception therefore has a history of accountability, not merely a current owner.

That history can matter later.

Who knew?

Who assessed?

Who decided?

Who was responsible for the response?

Who confirmed that the matter could be closed?

Those are governance questions as much as workflow questions.

The exception needs to travel with enough context

Once the system that detects an exception is no longer assumed to own it, the next design question becomes important.

What should travel with the exception?

A short description may be enough to attract attention:

Inspection limit exceeded.

But it is rarely enough to support a material decision.

The receiving organisation needs to understand:

• what was observed,
• where it came from,
• when it was true,
• which requirement it affects,
• and how reliable the information is.

In other words, the exception needs evidence.

And evidence becomes much more useful when it retains its provenance.