From maintenance records to operating evidence

This is the closing piece of the series that began with the asset register is not the asset system. It draws the earlier ideas into a single operating model.

Maintenance systems are very good at recording things.

Assets.

Work orders.

Inspections.

Parts.

Labour.

Failures.

Costs.

Downtime.

Schedules.

Those records matter.

Without them, maintenance becomes dependent on memory, spreadsheets, disconnected notes and individual knowledge.

But storing records is not the same as understanding the operation.

A maintenance system can contain years of history and still struggle to answer relatively simple forward-looking questions:

What is changing?

What is likely to happen next?

What resources will be required?

Which assets are creating future risk?

What will the current production plan do to maintenance demand?

Where is the budget actually heading?

What should we change now?

That suggests a broader proposition:

Maintenance information becomes more valuable when it moves from being a record of activity to being evidence about the future operating position.

Records describe what happened

A maintenance record may tell us:

Truck 047
Engine replaced
12 March
430 labour hours
$185,000 parts
36 hours downtime

That is valuable information.

It can support:

• cost reporting;
• maintenance history;
• warranty discussions;
• compliance;
• reliability analysis.

But the record becomes much more useful if the system can also interpret what it means.

For example:

Previous engine life          9,800 h
Expected engine life         12,000 h
Variance                     -2,200 h

That raises new questions.

Was the lower life caused by:

• production intensity;
• operating conditions;
• maintenance practice;
• rebuild quality;
• component quality;
• operator behaviour?

Should the next engine still be forecast at 12,000 hours?

Should the component strategy change?

The record has become evidence.

Evidence changes assumptions

This distinction is fundamental.

A record says:

This happened.

Evidence says:

This happened, and it may change what we believe about the future.

Consider a component replacement.

The transactional record may update:

component removed
component installed
work completed
cost recorded

The operating model may also need to update:

actual component life
expected future life
next intervention date
parts forecast
labour forecast
budget forecast

The work order therefore does more than close history.

It changes the future model.

The same principle applies to inspections

An inspection finding is another form of evidence.

Suppose an inspection identifies:

Moderate structural cracking

A conventional system may record the finding and create a follow-up task.

A stronger operating model may also change:

Condition Position
        ↓
Risk Position
        ↓
Inspection Frequency
        ↓
Intervention Forecast
        ↓
Budget Forecast

The finding becomes part of a decision chain.

This is particularly important for structures, roads and infrastructure where the intervention often follows condition and risk assessment rather than a simple maintenance interval.

Condition monitoring should alter the forecast

Condition-monitoring systems can generate enormous quantities of data.

Vibration.

Temperature.

Oil analysis.

Pressure.

Wear particles.

Fuel consumption.

Performance trends.

The value is not in collecting more readings.

The value is in determining when the readings should change the operating model.

For example:

Expected bearing life       2,000 h
        ↓
Vibration trend deteriorates
        ↓
Revised life estimate       1,100 h
        ↓
Next shutdown scope changes
        ↓
Bearing ordered
        ↓
Resource plan changes

The data has become operational evidence because it changed a decision.

Production data is maintenance evidence

Production information may not look like maintenance data.

But if production consumes asset life, it becomes highly relevant.

For example:

Production target increases
        ↓
Truck utilisation increases
        ↓
Component life consumed faster
        ↓
Maintenance interventions move forward

So the production forecast becomes evidence about future maintenance.

The same applies to:

• throughput;
• tonnes;
• kilometres;
• operating hours;
• load cycles;
• duty factors.

This links operations and maintenance much more closely than a traditional work-history model.

Cost is also evidence

Maintenance cost is normally viewed financially.

But cost patterns can also describe asset behaviour.

Suppose:

FY24 maintenance cost        $180k
FY25 maintenance cost        $260k
FY26 maintenance cost        $390k

That trend may indicate:

• ageing;
• repeat failures;
• declining availability;
• component strategy problems;
• inappropriate duty;
• poor maintainability.

Cost history becomes lifecycle evidence.

The question is no longer only:

How much did the asset cost?

It becomes:

What does the changing cost profile tell us about the asset’s future?

Downtime becomes evidence when context is preserved

A downtime record may say:

Asset unavailable: 8 hours

That is useful.

But the evidence becomes stronger when the system records why.

For example:

2 h diagnosis
1 h waiting labour
4 h waiting part
1 h repair

Now the organisation can distinguish:

Reliability problem
from
Resource problem
from
Supply problem

Those require different responses.

The eight-hour figure alone does not tell us enough.

Parts usage can reveal more than inventory consumption

A part issued from stores is often treated as:

Stock -1

Operationally, that transaction can also tell us:

• which asset consumed the part;
• which component failed;
• whether consumption is increasing;
• whether the repair is recurring;
• whether stocking policy is adequate;
• whether supplier performance is acceptable.

A part therefore moves through several meanings:

Inventory Item
      ↓
Material Requirement
      ↓
Work Consumption
      ↓
Asset History
      ↓
Failure Evidence
      ↓
Future Demand

The same transaction contributes to several operating models.

Maintenance history should become forecasting evidence

A large maintenance history has limited value if it remains purely retrospective.

The more useful question is:

What does our history allow us to predict?

For example:

Historical engine lives:
10,200
9,800
10,600
9,500
10,100

The original standard may have been:

12,000 hours

The system should probably no longer forecast future engines at 12,000 hours without qualification.

The history suggests otherwise.

Likewise:

Planned shutdown duration       72 h
Actual shutdown history         78 h
                                83 h
                                80 h
                                81 h

Future production plans should probably not assume 72 hours without understanding what has changed.

Historical records become planning evidence.

Evidence needs structure

Free-text notes remain useful.

Technicians, operators and inspectors frequently know things that cannot be captured easily in a fixed field.

But unstructured notes are difficult to aggregate.

Consider:

"Pump looks pretty rough. Seal leaking again."

That may contain important information.

But a more structured record could preserve:

Asset
Component
Observed condition
Failure mode
Severity
Likely cause
Recommended action

with the technician’s note retained alongside.

Structure allows the system to connect the evidence to other records.

The goal is not to eliminate narrative.

It is to prevent important operational knowledge from becoming invisible.

Evidence also needs provenance

If an operational decision is going to rely on evidence, the system should know where that evidence came from.

For example:

Remaining life estimate: 1,100 h

Derived from:
OEM baseline
Operating hours
Oil analysis
Vibration trend
Engineering adjustment

That allows the user to ask:

Why does the system believe this?

This becomes particularly important as predictive models and AI recommendations are introduced.

Recommendations should be traceable

Suppose a system recommends:

Replace the engine during the next planned shutdown.

That recommendation should be supported by visible evidence.

For example:

Remaining life               850 h
Expected usage before outage 1,100 h
Failure consequence          HIGH
Component available          YES
Workshop capacity            AVAILABLE

Now the recommendation can be challenged or accepted intelligently.

Without that evidence, the system risks becoming another opaque decision engine.

This is where an operational ledger becomes useful

The earlier idea of an operational ledger provides one possible mechanism.

Significant events could produce operational movements.

For example:

Production shift
    ↓
+ 12 operating hours
- 12 estimated life hours
+ 4,200 tonnes

A condition result might produce:

Oil analysis
    ↓
- 300 h remaining-life adjustment
+ condition risk

A work order might produce:

Engine replacement
    ↓
+ $180k actual cost
+ 430 labour hours
+ component-life reset

The ledger records what changed.

The operating position shows where the entity now stands.

Evidence can create an operational position

An asset position might combine:

Condition
Availability
Lifecycle
Maintenance Cost
Resource Exposure
Production Exposure
Risk

For example:

TRUCK 047

Condition             GREEN
Availability          GREEN
Lifecycle             RED
Maintenance Forecast  AMBER
Parts Readiness       GREEN
Production Exposure   HIGH

This is much richer than:

Asset Status = ACTIVE

or even:

Health = 76%

The position describes several dimensions of operational reality.

Position should be explainable

If lifecycle is red, the system should be able to show why.

For example:

Engine remaining life      850 h
Expected monthly usage     420 h
Next major opportunity     3 months
Expected usage to window   1,260 h

The health indicator is only a summary.

The evidence remains underneath it.

This prevents dashboards from becoming disconnected from the underlying operation.

Evidence also needs time

The current position is only one view.

Operations needs to understand direction.

For example:

Today            GREEN
30 Days          GREEN
90 Days          AMBER
12 Months        RED

A production target may be achievable today.

The lifecycle forecast may show that it cannot be sustained without additional maintenance capacity.

A current dashboard alone will not reveal that.

Operational evidence supports scenario planning

Once evidence, positions and forecasts are connected, the system can evaluate scenarios.

For example:

Current production plan

Production            10 Mt
Maintenance cost      $9.8m
Availability          87%
Major interventions      6

Higher production plan

Production            11.5 Mt
Maintenance cost      $11.2m
Availability          84%
Major interventions       9

The important feature is not just the comparison.

The system can explain why the maintenance forecast changed.

That gives management a basis for choosing between alternatives.

Evidence should support budgets

A forward-looking maintenance position may combine:

Budget
Actual
Committed
Known Planned
Forecast
Risk Allowance

This allows the organisation to distinguish:

What was approved

from:

What is now expected

The forecast can move as new evidence arrives.

For example:

Condition deterioration
        ↓
Component intervention brought forward
        ↓
Parts commitment
        ↓
Maintenance outturn increases

The budget remains financially important.

The evidence explains why reality may now differ.

Resource planning also depends on evidence

Future work creates future resource demand.

Historical work can improve the standards used to estimate that demand.

Suppose a component replacement is expected to require:

80 fitter hours

but actual history shows:

92
88
95
90

The system should probably adjust future forecasts.

Likewise, if a certain shutdown package regularly requires more crane time than planned, future readiness assumptions should change.

Evidence improves resource planning.

Different domains need different evidence models

The common principle remains:

Evidence
    ↓
Position
    ↓
Forecast
    ↓
Decision

But the evidence differs by asset domain.

Mobile plant

SMU
Production
Fuel
Condition
Component history
Work

Roads

Traffic
Condition survey
Defects
Treatment history
Weather

Structures

Inspection
Condition rating
Defects
Risk
Engineering assessment

Processing plant

Throughput
Condition
Wear
Shutdown findings
Availability

The operating framework can remain common.

The evidence model needs to reflect the asset.

This reinforces the argument against one universal workflow

If evidence differs by domain, the workflow generating decisions will also differ.

Mobile plant may move from:

Usage
→ Component Forecast
→ Work

Roads may use:

Condition
→ Treatment Program
→ Work

Structures may use:

Inspection
→ Risk
→ Intervention

Processing plant may use:

Condition
→ Shutdown Scope
→ Work Package

The work transaction can be standardised.

The evidence and decision pathways should retain domain meaning.

Operational systems should learn

The larger theme across all of these examples is learning.

A completed transaction should not merely create history.

It should have the potential to improve future assumptions.

For example:

Work completed
      ↓
Actual duration
Actual labour
Actual parts
Actual condition
Actual component life
      ↓
Update assumptions
      ↓
Improve next forecast

That creates a feedback loop.

Plan
  ↓
Operate
  ↓
Observe
  ↓
Maintain
  ↓
Learn
  ↓
Reforecast
  ↓
Plan

That loop may be a better description of a mature asset-management system than:

Raise
Schedule
Complete
Close

This is the larger CPM opportunity

For CPM and DSLCore, the opportunity may not be to build the largest collection of maintenance modules.

It may be to connect operational evidence into models that explain the current and future position of an entity.

That entity could be:

• an asset;
• a component;
• a fleet;
• a road network;
• a processing circuit;
• a shutdown;
• a workshop;
• a site.

The same underlying architecture might support:

Transactions
      ↓
Operational Evidence
      ↓
Position
      ↓
Forecast
      ↓
Decision

Different domains define different evidence, positions and decision rules.

The engine remains common.

CPM may therefore sit between systems

Many organisations already have:

ERP
CMMS
Production systems
Condition monitoring
Planning tools
Spreadsheets

There is little value in pretending these systems will simply disappear.

CPM may instead operate as a decision and interpretation layer.

For example:

ERP
 ↓
Financial actuals / commitments

CMMS
 ↓
Work history

Production
 ↓
Usage / output

Condition systems
 ↓
Asset evidence

           ↓
          CPM
           ↓
Operational Position
Forecast
Decision Support

That may be a more practical role than replacing every existing system.

The purpose is not to centralise everything

There is an important distinction.

The aim should not be:

Put every possible piece of information into CPM.

That would simply create another monolith.

The aim is:

Identify the evidence required to understand the operating position and maintain traceable links to its source.

Some information may remain in specialist systems.

CPM only needs the information required to support the domain model.

The system should preserve uncertainty

Evidence does not always produce certainty.

A life forecast may have:

Expected intervention      Q3
Confidence                 MODERATE

A condition assessment may contain:

Risk                       AMBER
Evidence quality           LOW

The system should preserve that uncertainty rather than converting every assessment into false precision.

This becomes increasingly important when predictive analytics and AI are involved.

AI should extend the evidence model, not replace it

AI can help identify:

• patterns;
• anomalies;
• likely failures;
• unusual expenditure;
• resource conflicts;
• recurring defects.

But AI recommendations should remain connected to operational evidence.

A useful relationship might be:

Evidence
    ↓
Model / Analysis
    ↓
Recommendation
    ↓
Human Decision
    ↓
Action
    ↓
Outcome
    ↓
New Evidence

The result of the decision then becomes additional evidence.

That keeps the operating model accountable.

The goal is better decisions

Ultimately, the value of maintenance data is not measured by:

Number of work orders stored

or:

Number of sensor readings collected

or even:

Number of dashboards produced

The important question is:

Did the information help the organisation make a better decision?

For example:

• intervene earlier;
• safely defer work;
• order a component before it becomes urgent;
• avoid unnecessary inventory;
• change a production plan;
• increase workshop capacity;
• replace an asset;
• revise a shutdown scope;
• identify an emerging risk.

That is when information becomes operational evidence.

A working hypothesis

The proposition is not that maintenance systems should stop recording transactions.

Reliable records remain essential.

The proposition is that records should be treated as inputs to a continuously evolving understanding of the operation.

A useful distinction may be:

Maintenance records tell us what happened.

Operating evidence helps us understand what that history means for what happens next.

That moves the system from administration toward decision support.

Bringing the series together

The earlier ideas in this series connect naturally.

The asset register should define the asset, but not be mistaken for the asset system.

The work order should organise execution, but not be mistaken for the maintenance system.

Different asset classes may need different operating workflows.

Production consumes asset life.

Maintenance budgets should reflect expected future demand.

Operational movements may justify a ledger-like structure.

Shutdowns should be treated as operating events.

Resource planning should begin before work orders exist.

Health should be represented as a multidimensional position rather than a single traffic light.

Together they suggest an architecture more like:

             OPERATING REQUIREMENT
                     ↓
                 Assets
                     ↓
        Usage / Condition / Evidence
                     ↓
              Asset Position
                     ↓
             Lifecycle Forecast
                     ↓
          Maintenance Requirement
                     ↓
      Resources / Parts / Shutdowns
                     ↓
                  Work
                     ↓
              Actual Evidence
                     ↓
              Updated Position
                     ↓
                 Forecast
                     ↓
                 Decision
                     ↓
            Operating Outcome
                     ↓
                 Evidence

The loop continues.

Questions worth testing

What information genuinely deserves to become operational evidence?

Which maintenance records should automatically alter future assumptions?

How should evidence from work, production, condition and finance be reconciled?

Where should current state end and forecast state begin?

How much decision logic should live inside the asset-management system?

Can a common evidence and position framework support very different asset domains?

How should uncertainty and confidence be represented?

Can organisations use existing ERP, CMMS and production systems while adding a richer operating-model layer above them?

And perhaps the broader question:

Are our maintenance systems primarily preserving the history of the operation, or are they using that history to improve the next decision?

The two functions are not mutually exclusive.

The opportunity may be to connect them.