An event tells you what happened. What detects what didn't?

Event-driven architecture is powerful because it lets systems react to change.

A licence becomes at risk.

A decision is approved.

An assay result arrives.

A work order closes.

An event is emitted and another process responds.

But there is a class of operational problem that event-driven systems do not naturally detect:

nothing happened.

Absence can be significant

Consider several examples.

An assay batch is submitted.

The expected result never arrives.

An investment opportunity is approved.

The downstream programme is never created.

A daily ERP feed normally updates expenditure.

It silently stops.

A high-risk finding is raised.

The required review never occurs.

A licence status changes.

The downstream programme system never receives the update.

In each case, there may be no failure event.

The problem is the absence of an expected event, record or state.

“No error” does not mean “correct”

This is an important governance distinction.

A system can report:

• no failed jobs,
• no database errors,
• no API failures,
• no unhandled exceptions,

and still be operationally wrong.

Technical health tells us whether the machinery is running.

Operational assurance asks whether the expected business state exists.

Those are different questions.

Expected state needs to be explicit

To detect absence, the organisation first has to define what it expects.

For example:

Every approved exploration opportunity must have a corresponding Programme Assurance project within 24 hours.

or:

Every active tenement must have a current compliance status less than 24 hours old in Programme Assurance.

or:

Every assay batch should receive results within the agreed turnaround period unless an exception is recorded.

These statements can become controls.

They allow the system to ask proactively:

Is reality still consistent with the operating model?

Several control types emerge

An assurance layer can test different kinds of expectations.

Existence

Something must exist.

Active project → current budget required.

Absence

Something must not exist.

Closed project → no active campaigns.

Freshness

Information must be recent enough.

Finance data → less than 24 hours old.

Reconciliation

Two systems must agree.

Licence status in Programme Assurance must match Licence Management.

Sequence

One thing must precede another.

Funding approval before mobilisation.

Timeliness

A required action must occur within a defined period.

Critical exception acknowledged within four hours.

These controls are not replacements for application business rules.

They are independent checks on whether the wider operating environment remains coherent.

Reconciliation is particularly powerful

Finance has used reconciliation for a long time.

Operational systems could use more of it.

If one system is authoritative for a value and another carries a replicated copy, the orchestrator can periodically compare them.

That catches:

• missed events,
• failed updates,
• manual changes,
• stale copies,
• partial migrations,
• transformation errors.

A route may have succeeded last week and failed silently yesterday.

Reconciliation detects the resulting divergence.

This changes the role of the orchestrator

The orchestrator is no longer only:

a mechanism for moving JSON from A to B.

It becomes:

a mechanism for testing whether the relationships between systems still behave as intended.

That is a more interesting capability.

It also creates a new object that needs to be managed properly.

When a control fails, the result should not simply be another alert.

It should become a governed exception.