The operating model needs an assurance layer

Operational applications are normally designed to help work happen.

A maintenance system manages work orders.

A licence system manages obligations.

A programme system manages activities and decisions.

An ERP manages financial transactions.

A laboratory system manages samples and results.

Each application can be well designed and still provide only a partial view of the operating environment.

The missing question is:

Does the wider operating model continue to behave as intended?

Applications execute. Assurance observes relationships.

An individual application can usually govern its own rules.

It can prevent invalid fields.

It can require approvals.

It can enforce workflow transitions.

It can produce events when material states change.

But it cannot always see what happened after information left its boundary.

It may not know that:

• the downstream application never created the expected record,
• another system holds a conflicting status,
• a data feed has become stale,
• a scheduled action stopped running,
• a required review never occurred,
• or an integration is technically successful but semantically wrong.

Those are operating-model questions.

The assurance layer sits around the applications

A useful architecture begins to separate several responsibilities.

Applications

Own domain data, rules and decisions.

Canonical model

Defines shared identity and meaning.

Integration

Moves and transforms information.

Scheduling

Invokes domain actions because of time.

Events

Describe material changes.

Controls

Test whether expected states remain true.

Exceptions

Manage departures from those expectations.

Audit

Preserves what happened and why.

Together, those functions create an assurance layer.

The orchestrator becomes the control plane

An orchestrator in this model is not simply a message broker.

It is the control plane for relationships between operational systems.

It can know:

• which applications exist,
• which entities they expose,
• who owns which fields,
• which routes connect them,
• which jobs should run,
• which controls should pass,
• which exceptions remain open,
• and what happened during each cross-system transaction.

That provides a view the domain applications cannot provide individually.

The operating model becomes testable

This is perhaps the most important consequence.

A specification no longer describes only:

• fields,
• screens,
• tables,
• workflows.

It can progressively describe expectations such as:

Every active exploration programme has a current budget.

Every material funding decision has supporting evidence.

Every active campaign operates against a valid tenement.

Every replicated compliance status agrees with its authoritative source.

Every critical exception is acknowledged within the required period.

Those expectations can be tested.

The operating model becomes something the system can continuously compare with reality.

This is different from replacing existing systems

An assurance layer does not require every operational system to be rebuilt.

Existing ERP, GIS, laboratory, maintenance and regulatory systems can remain in place.

The architecture instead asks:

• What information do they own?
• What information must cross boundaries?
• What transformations are required?
• What should happen next?
• What should always remain true?
• What happens when reality diverges?

That creates a practical path for incremental improvement.

It also changes application generation

A generated application is useful.

Several generated applications working together are more interesting.

But once they share an operating environment, the generator must eventually understand more than application structure.

It must also understand:

• canonical identity,
• integration contracts,
• schedules,
• event definitions,
• ownership,
• controls,
• and deployment relationships.

That is where an application generator begins to grow into an operational framework.

The exploration example is only a case study

Exploration makes the problem visible because uncertainty, capital, evidence, compliance and time all interact.

But the same pattern appears elsewhere.

In maintenance:

• work orders,
• condition monitoring,
• inventory,
• operator systems,
• ERP.

In shipping:

• vessel operations,
• port calls,
• licences,
• cargo systems,
• compliance.

In infrastructure:

• inspections,
• risk,
• maintenance programmes,
• contractors,
• asset registers.

The question is the same:

What should be true across the operating environment, and how do we know when it stops being true?

From system of record to system of assurance

Most software discussions focus on systems of record and systems of engagement.

There is another useful category.

A system of assurance does not necessarily own the underlying work.

It provides evidence that the wider operating model remains coherent.

That means:

• information is moving,
• responsibilities are clear,
• expected actions occur,
• conflicting states are detected,
• exceptions are owned,
• and resolution is verified.

The objective is not more software.

It is a clearer relationship between what the organisation intends to happen and what is actually happening.

That may be the most useful role for an assurance layer: not to replace the operational systems, but to make the gaps between them visible and governable.