A decision can create an obligation

When organisations think about obligations, they often think first about external requirements.

Legislation.

Regulations.

Licence conditions.

Permits.

Contracts.

Regulator directions.

Those are important sources of obligation.

They are also only part of the picture.

Organisations continuously create obligations through their own decisions.

External obligations have identifiable sources

A legal obligation register might represent a chain such as:

Legislation → Requirement → Obligation

or:

Contract → Clause → Commitment

or:

Licence → Condition → Reporting requirement

That source matters.

It tells the organisation why the obligation exists.

It may also determine:

• who is accountable,
• what evidence is required,
• when performance is due,
• and what happens if the obligation is not satisfied.

That is one reason obligations deserve to exist separately from tasks.

But the same principle applies to internally created requirements.

Decisions can bind future behaviour

Suppose management decides:

Continue operating degraded equipment for fourteen days.

The approval has conditions:

• operate below 70% pressure,
• inspect every twelve hours,
• review status daily,
• shut down if leakage is detected,
• complete replacement before expiry.

Those conditions are now commitments.

The organisation has made its acceptance of the risk dependent upon them.

From a governance perspective, they behave like obligations.

Their source is simply different.

Instead of:

Licence condition LC-07

the source might be:

Decision D-441

That provenance is useful because it allows somebody later to ask:

Why are we required to inspect this every twelve hours?

The answer should not depend on somebody remembering a meeting.

Obligations have many sources

A broader obligation model might include:

Legislation Regulation Licence Permit Contract Regulator direction Internal standard Management decision Risk acceptance Temporary approval Audit commitment

This does not mean they all have the same legal standing.

They clearly do not.

It means they share an operational characteristic:

Something is expected to be done or remain true.

The source determines the authority behind that expectation.

Obligation provenance should remain visible

Every significant obligation should be able to answer:

Why must we do this?

For example:

Obligation: inspect every 12 hours Source: Decision D-441 Reason: temporary operation with primary barrier impaired Effective: 31 August Expires: 14 September

Or:

Obligation: submit annual monitoring report Source: Licence Condition LC-07 Due: 30 September Evidence required: approved submission and regulator receipt

This creates traceability between requirement and execution.

It also allows the organisation to distinguish between:

• externally imposed obligations,
• internally imposed controls,
• temporary conditions,
• and ongoing operating requirements.

Legal and operational obligations can meet

This is where specialised legal and operational applications become more interesting together.

A licence might require:

Maintain groundwater monitoring in accordance with the approved programme.

That requirement may become:

Licence condition → Compliance obligation → Sampling programme → Field activity → Laboratory result → Review → Regulatory submission

No single application needs to own the entire chain.

The Legal Obligation Register can own the authoritative interpretation of the obligation.

An environmental application can own the sampling programme.

A laboratory system can own the result.

The Orchestrator can move and reconcile information.

The Governance & Assurance layer can ask:

Is the obligation currently being discharged?

That separation preserves domain focus while still providing a whole-of-organisation view.

Obligations can generate controls

Once an obligation is structured, parts of it become testable.

For example:

Every active temporary operating approval must have a current inspection.

or:

Every licence reporting obligation must have a submission before its due date.

or:

Every accepted high-risk exception must have a valid decision authority and review date.

These are not necessarily workflows.

They are expected states.

That means the assurance layer can test them.

If the expected condition stops being true, a new exception appears.

Again, the governance model becomes a loop.

The Orchestrator connects; governance accounts

This gives us a useful division of responsibility.

The legal application asks:

What are we required to do?

The operational application asks:

What work is happening?

The Orchestrator asks:

Is the information moving and are the expected relationships present?

The governance layer asks:

Can we demonstrate that the obligation is being satisfied?

Those are different questions.

Keeping them separate avoids building another monolith.

It also allows existing enterprise systems to remain part of the architecture.

An ERP can still own purchases.

A CMMS can still own maintenance work.

A document system can still own documents.

Governance does not need to replace them.

It needs to understand enough of their evidence to determine whether accountable requirements are being met.

An obligation is not the same as the work used to satisfy it

Once an obligation exists, organisations naturally create tasks.

Inspect the equipment.

Collect the sample.

Prepare the report.

Update the procedure.

Submit the notice.

That is necessary.

But a subtle problem appears.

The task describes what somebody must do.

The obligation describes what must ultimately be true.

Those are related concepts.

They are not identical.