Decisions should be first-class records

Information systems are very good at recording transactions.

A work order was completed.

A permit was approved.

A purchase was authorised.

An incident was closed.

A risk was reviewed.

An action was assigned.

But the decision sitting behind those transactions can be surprisingly difficult to find.

Six months later, the organisation may know what happened.

It may be much less clear why.

Approval is not always the decision

Consider this record:

Status: Approved

It tells us that an approval occurred.

It does not tell us what was actually approved.

The meaningful decision might have been:

Continue operating V-102 for a maximum of fourteen days, subject to pressure being limited to 70%, inspection every twelve hours and replacement before 14 September.

That is a much richer organisational record.

It states:

• the outcome,
• the boundary of the approval,
• the conditions,
• and the period for which the decision remains valid.

Those details should not have to be reconstructed from an email attachment or meeting minute.

A decision has structure

A useful decision record may include:

• subject,
• question being decided,
• outcome,
• decision authority,
• decision date,
• supporting evidence,
• assessment,
• alternatives considered,
• rationale,
• conditions,
• effective date,
• expiry,
• review date,
• and expected consequence.

For example:

Decision: Continue degraded operation Asset: V-102 Basis: Engineering assessment EA-219 Residual risk: Medium Authority: Asset Manager Conditions: pressure ≤70%; inspection every 12 hours Expiry: 14 September 2026

The exact structure will vary by domain.

But the principle is general:

A material decision should be identifiable as a decision.

Decision authority matters

A technically reasonable decision can still represent poor governance if it is made by someone without the required authority.

The system therefore needs to distinguish between:

• who prepared the assessment,
• who recommended the outcome,
• who owns the issue,
• and who has authority to decide.

That authority may come from:

• organisational role,
• delegation,
• monetary limit,
• risk threshold,
• licence responsibility,
• technical authority,
• or a formal approval matrix.

Representing the decision without representing authority leaves an important part of the governance chain implicit.

Decisions often have conditions

Many material decisions are not simply:

Yes.

or:

No.

They are:

Yes, provided that…

Those conditions matter.

A decision to continue operation may require additional inspection.

A commercial decision may require legal review before contract execution.

A regulator response may require certain evidence before submission.

A capital approval may be conditional on another milestone being reached.

Those conditions are not explanatory notes.

They become part of what the organisation is now expected to do.

That means they need to be observable.

If a condition stops being true, the decision may need to be reviewed.

Decisions can expire

Temporary approvals are particularly important.

Organisations regularly accept a position for:

• seven days,
• one shift,
• until repair,
• until the next inspection,
• until new evidence arrives,
• until a regulator responds.

If the system records only:

Approved

it can easily hide the temporary nature of the decision.

A better model includes:

Effective from Effective until Review required Conditions

Once the expiry is reached, the decision should not silently remain current.

The expired decision may itself create an exception.

That creates an important governance loop:

Decision → Condition → Control → Exception → New decision

The system starts to test whether the assumptions behind previous decisions remain valid.

Decision history creates organisational memory

Once decisions become structured records, patterns become visible.

The organisation can ask:

• Which deviations are repeatedly accepted?
• Which temporary approvals are continually extended?
• Which risks recur?
• Which assumptions most often prove wrong?
• Which evidence normally changes the decision?
• Which decisions consistently create follow-up actions?
• Which business areas accept the most exceptions?

That does not mean decision-making should become automated.

It means previous reasoning becomes available to future decision-makers.

A decision history can reveal that what looks like an isolated exception is actually a recurring operating practice.

That can be much more important than the individual case.

A decision is more than a record of consent

The objective is not to create another approval database.

It is to preserve the point at which the organisation took a position.

What did we know?

What uncertainty remained?

What did we decide?

Who had authority?

What conditions applied?

How long did the decision remain valid?

Those questions create continuity between evidence and action.

They also expose something else.

Decisions do not merely conclude governance processes.

They often create new requirements.

If management approves continued operation subject to inspection every twelve hours, that inspection is no longer merely a good idea.

It is something the organisation has committed itself to doing.

In other words, a decision can create an obligation.