Health is a position, not a traffic light

This piece follows from should operations have a ledger?. If operations can maintain a traceable position, then health is best understood as an interpretation of that position — not a single colour.

Operational dashboards like traffic lights.

Green.

Amber.

Red.

They are simple.

They are fast to read.

They help managers identify where attention may be required.

But simplicity can also hide important differences.

An asset may be mechanically healthy but financially expensive.

A fleet may be meeting production targets while consuming component life faster than expected.

A shutdown may be on budget but operationally unready.

A road network may have acceptable average condition while containing several critical defects.

A plant may show high availability while accumulating unresolved lifecycle risk.

This suggests a useful proposition:

Asset or entity health should not be treated as a single score. It should be treated as a multidimensional operational position.

A single health score is attractive

There are obvious reasons for reducing complex information to one number.

For example:

Asset Health = 82%

or:

Fleet Status = AMBER

That gives management a quick answer.

But what does 82% actually mean?

Does it represent:

• physical condition;
• availability;
• maintenance cost;
• remaining life;
• risk;
• production capability;
• backlog;
• resource readiness?

If all of these are compressed into one number, important differences may disappear.

Two assets can have the same score for very different reasons

Consider two haul trucks.

Truck A

Mechanical condition       GOOD
Availability               HIGH
Maintenance cost           HIGH
Remaining component life   LOW
Production contribution    HIGH

Truck B

Mechanical condition       POOR
Availability               LOW
Maintenance cost           LOW
Remaining component life   HIGH
Production contribution    MODERATE

A composite model could theoretically give both:

Health Score = 70%

But the management response should be completely different.

Truck A may need capital planning.

Truck B may need immediate reliability work.

The single score hides the decision context.

Health depends on what question is being asked

When someone asks:

Is this asset healthy?

they may actually be asking several different questions.

For example:

Physical health

Is the asset in good condition?

Reliability health

Is it performing consistently?

Lifecycle health

Is significant intervention approaching?

Financial health

Is cost within acceptable expectations?

Production health

Can the asset support expected production?

Resource health

Can the organisation support the required maintenance?

Risk health

Are important exposures adequately controlled?

These are related.

They are not the same.

Condition is only one dimension

Asset health is often associated most strongly with physical condition.

That is understandable.

Condition monitoring can include:

Vibration
Temperature
Oil analysis
Wear
Pressure
Inspection findings
Defects

These provide valuable evidence.

But an asset can be in acceptable physical condition and still create an operational problem.

For example:

Condition               GREEN
Remaining life           AMBER
Parts availability       RED

The asset itself is currently healthy.

The future operating position is not.

Availability is another dimension

A mechanically imperfect asset may still deliver acceptable availability.

Conversely, an asset with no obvious major defect may have poor availability because of recurring minor failures.

For example:

Condition               AMBER
Availability            GREEN

or:

Condition               GREEN
Availability            RED

Those situations should not be collapsed automatically into one indicator.

They tell different stories.

Lifecycle position matters

An asset can operate well today while approaching a major intervention.

Suppose:

Current condition            GOOD
Engine remaining life        600 h
Expected utilisation         450 h/month
Next shutdown                3 months away

The asset may appear healthy today.

Operationally, however, it may require immediate planning.

The relevant position is:

Current Health        GREEN
Lifecycle Exposure    RED

That distinction is important.

A dashboard focused only on current condition may miss the future constraint.

Production can hide deterioration

Strong production performance can also create misleading signals.

Suppose a fleet is achieving:

Production           103% of target

But this is being achieved through:

Higher utilisation
Higher payload
Reduced maintenance windows
Deferred interventions

The production position may be green.

The lifecycle position may be deteriorating.

For example:

Production            GREEN
Availability          GREEN
Lifecycle             RED
Maintenance Backlog   AMBER

If management sees only the production indicator, the system may reward short-term performance while risk accumulates underneath.

Cost can also tell the wrong story

A maintenance function can be under budget for several reasons.

Some are good.

Some are not.

For example:

Maintenance Budget    GREEN

could mean:

• work was completed efficiently;
• component lives improved;
• procurement costs fell.

Or it could mean:

• work was deferred;
• vacancies reduced labour expenditure;
• major repairs have not yet occurred;
• parts have not yet been delivered.

The same financial indicator can represent very different operating conditions.

That is why operational health needs context.

Backlog needs more than volume

Another common health measure is backlog.

For example:

Open work orders = 420

or:

Backlog = 6 weeks

Those numbers are useful.

But backlog quality matters.

Four hundred minor housekeeping jobs may be less significant than:

1 unresolved safety-critical defect

A simple volume measure can therefore be misleading.

A stronger view might distinguish:

Safety-critical backlog
Production-critical backlog
Lifecycle-critical backlog
Routine backlog
Opportunity work

The position becomes more informative.

Risk should not disappear into averages

Risk is particularly resistant to simple aggregation.

Suppose ten assets have low risk and one asset has a severe unresolved issue.

An average might suggest:

Fleet Risk = LOW

That can be dangerous.

Some conditions should operate as exceptions rather than averages.

For example:

IF any safety-critical control = FAILED
THEN overall critical-risk status = RED

regardless of the condition of other assets.

This means a health model needs both:

Aggregated Position

and:

Exception Rules

Health may be better represented as a position

Instead of:

Asset Health = 82%

a more useful representation could be:

ASSET POSITION

Condition             GREEN
Availability          GREEN
Lifecycle             AMBER
Maintenance Cost      GREEN
Resource Readiness    AMBER
Operational Risk      RED

This gives management a much clearer picture.

The organisation can still derive a headline indicator if required.

But the dimensions remain visible underneath.

Different entities need different dimensions

A haul truck does not need exactly the same health model as a road network.

Mobile plant

Useful dimensions might include:

Condition
Availability
Component Life
Maintenance Cost
Fuel / Efficiency
Backlog
Production Capacity

Roads

Network Condition
Critical Defects
Treatment Backlog
Service Level
Program Delivery
Budget Position

Structures

Condition
Structural Risk
Inspection Status
Intervention Status
Access Restrictions
Lifecycle Exposure

Processing plant

Availability
Throughput
Condition
Shutdown Exposure
Reliability
Maintenance Backlog
Production Risk

Shutdown

Scope Readiness
Schedule
Cost
Materials
Resources
Risk
Commissioning Readiness

The concept of health remains common.

The dimensions are domain-specific.

Current health and future health should be separated

Another useful distinction is between:

Current Position

and:

Forecast Position

For example:

TRUCK 047

Current Condition         GREEN
Current Availability      GREEN

Forecast 90-Day Position
Engine Life               RED
Workshop Capacity         AMBER
Parts Readiness           GREEN

This tells a more complete story.

The asset is healthy today.

It may not remain operationally healthy under the current plan.

Health should have a time horizon

The same asset may have different positions at different horizons.

For example:

Today            GREEN
30 Days          GREEN
90 Days          AMBER
12 Months        RED

Why?

Perhaps a major component intervention is approaching.

Or maintenance capacity becomes constrained.

Or a critical part has a long lead time.

A useful health model therefore needs a time dimension.

Health should be explainable

If a system displays:

Lifecycle = RED

the user should be able to ask:

Why?

The explanation might be:

Engine remaining life       600 h
Forecast utilisation        450 h/month
Next planned shutdown       3 months
Expected usage to shutdown  1,350 h

That is meaningful.

A coloured indicator without explanation is only an alert.

An explainable indicator becomes evidence.

Health should trace back to operational events

This connects closely to the operational-ledger idea.

Suppose the maintenance forecast changes from green to amber.

The system should be able to identify the movements that caused the change.

For example:

Production forecast increased
       ↓
Expected utilisation increased
       ↓
Engine intervention moved forward
       ↓
Workshop demand increased
       ↓
Resource position moved to AMBER

The health position now has traceability.

This is particularly useful when management challenges the result.

A health position can roll upward

Detailed positions can also contribute to higher-level views.

For example:

Component
    ↓
Asset
    ↓
Fleet
    ↓
Site

But roll-up rules need care.

Suppose a fleet contains:

20 assets GREEN
3 assets AMBER
1 asset RED

Should the fleet become green because most assets are healthy?

Perhaps not.

The red asset may be a production bottleneck.

The system needs to understand consequence.

So aggregation may consider:

Criticality
Production Role
Redundancy
Risk

rather than simply counting colours.

Criticality changes the meaning of health

Consider two pumps.

Both have:

Condition = RED

Pump A has full standby redundancy.

Pump B is the only operating pump in a critical circuit.

Their operational consequence is different.

So:

Condition
+
Criticality
+
Redundancy
=
Operational Exposure

That may be more useful than condition alone.

The system should distinguish health from exposure

This suggests another useful distinction.

Health

What condition is the entity in?

Exposure

What consequence does that condition create?

For example:

Condition          POOR
Redundancy         FULL
Exposure           LOW

versus:

Condition          MODERATE
Redundancy         NONE
Exposure           HIGH

The second situation may deserve more attention.

This is another reason a single health number can mislead.

Resource health should also be visible

Assets are not the only entities with health.

A workshop can have an operational position.

For example:

WORKSHOP POSITION

Labour Capacity          AMBER
Mechanical Skills        GREEN
Electrical Skills        RED
Bay Capacity             AMBER
Parts Readiness          GREEN
Backlog                  RED

That can directly affect fleet health.

Similarly, a contractor package may be:

Commercially Ready       GREEN
Mobilisation             GREEN
Site Access              RED

The organisation therefore has multiple operational entities whose health affects each other.

Health can be relational

This is an important concept.

An asset may be individually healthy but operationally exposed because of another entity.

For example:

Truck                    GREEN
Workshop Capacity        RED
Critical Spare           RED

The truck is currently fine.

But if it fails, the recovery capability is weak.

Similarly:

Crusher                  GREEN
Shutdown Readiness       RED

may create future production exposure.

Health therefore does not always belong to one isolated object.

It can emerge from relationships.

A site health view could be multidimensional

A higher-level operational view might look like:

SITE POSITION

Production             GREEN
Asset Availability     GREEN
Condition              AMBER
Lifecycle              RED
Maintenance Capacity   AMBER
Shutdown Readiness     GREEN
Budget Forecast        AMBER
Operational Risk       RED

That immediately gives management a better sense of where attention is required.

The next question is:

What is driving the red lifecycle position?

The system should allow drill-down.

Trend may matter more than current status

A static indicator can also hide direction.

Consider:

Condition = AMBER

There is a big difference between:

AMBER → improving

and:

AMBER → deteriorating quickly

A useful health model should therefore include trend.

For example:

Condition       AMBER   ↓
Availability    GREEN   →
Lifecycle       AMBER   ↓
Cost            GREEN   ↑ improving

The trend can sometimes be more important than the absolute state.

Velocity matters

Some conditions change slowly.

Others change quickly.

For example:

Remaining life declining

is expected.

But:

Vibration accelerating rapidly

may require immediate attention.

The system may therefore consider:

Current Position
+
Trend
+
Rate of Change

This becomes especially useful for condition monitoring.

Confidence should also be visible

Not every health indicator is based on equally strong evidence.

For example:

Condition: AMBER
Confidence: HIGH

because recent sensor data is available.

Another might be:

Remaining Life: AMBER
Confidence: LOW

because the forecast is based mainly on generic OEM assumptions.

That distinction can improve decision-making.

A false sense of precision is dangerous.

Health should support decisions

The purpose of the health model is not to create attractive dashboards.

It is to improve decisions.

A red lifecycle position might trigger:

Review component forecast
Check part availability
Evaluate shutdown scope
Review replacement decision

A red resource position might trigger:

Engage contractor
Move work
Add shift
Outsource rebuild

A red production exposure might trigger:

Review redundancy
Change production plan
Bring intervention forward

The indicator should lead somewhere.

Thresholds should be domain-specific

A common system may provide the mechanism:

GREEN
AMBER
RED

But the rules should come from the domain.

For example:

Engine life

GREEN   > 2,000 h
AMBER   500–2,000 h
RED     < 500 h

Shutdown readiness

GREEN   no critical blockers
AMBER   non-critical gaps
RED     one or more critical blockers

Road condition

A completely different rule set may apply.

The interface can remain consistent.

The meaning comes from metadata and domain rules.

This could work well with an operational ledger

A position model could derive health from operational movements.

For example:

Operational Events
       ↓
Current Position
       ↓
Threshold / Rule Evaluation
       ↓
Health Dimension
       ↓
Exception

This means the colour is not manually chosen.

It is derived from evidence.

That makes dashboards more trustworthy.

It could also support scenarios

Health can be evaluated under future assumptions.

For example:

CURRENT PLAN

Production             GREEN
Availability           GREEN
Lifecycle              AMBER

versus:

HIGH PRODUCTION SCENARIO

Production             GREEN
Availability           AMBER
Lifecycle              RED
Resource Capacity      RED

The organisation can see that a higher production target may create future maintenance exposure.

That is much more useful than a purely historical dashboard.

AI recommendations need this context

AI systems are increasingly being asked to identify risks and recommend actions.

A multidimensional health model can provide useful governance around those recommendations.

Instead of:

AI says Truck 047 is unhealthy.

the system could say:

Current condition       GREEN
Remaining life          RED
Production exposure     HIGH
Parts readiness         GREEN
Workshop capacity       AMBER

Then the recommendation:

Bring forward engine replacement.

has visible operational reasoning.

This is more explainable and easier to challenge.

Health should not become another opaque algorithm

There is a risk here.

A sophisticated model can become another black box.

If users cannot understand:

Health Score = 63.7

the number may create more confusion than value.

The system should preserve:

Evidence
↓
Position
↓
Rule
↓
Indicator

Users should be able to drill through each step.

Transparency is more valuable than artificial precision.

What this could mean for CPM and DSLCore

CPM could treat entity health as a derived operational position.

A common framework might support:

HealthDimension
Metric
Threshold
ExceptionRule
TrendRule
Criticality
Confidence
HealthAssessment

The domain model could define which dimensions apply.

For mobile plant:

Condition
Availability
Lifecycle
Cost
Production Exposure

For roads:

Condition
Defect Exposure
Program Delivery
Service Level
Budget

For shutdowns:

Readiness
Schedule
Resources
Materials
Cost
Production Risk

The common framework remains.

The health semantics vary by entity.

The model could distinguish several layers

A useful architecture might be:

1. EVIDENCE

   Inspection
   Condition reading
   Work history
   Production
   Cost
   Resource data


2. POSITION

   Remaining life
   Availability
   Forecast cost
   Backlog
   Resource capacity


3. HEALTH

   GREEN
   AMBER
   RED


4. EXPOSURE

   Low
   Moderate
   High
   Critical


5. DECISION

   Monitor
   Intervene
   Reschedule
   Purchase
   Replace

That is more informative than calculating health directly from raw data.

A working hypothesis

The proposition is not that traffic-light indicators are bad.

They are extremely useful for scanning complex systems.

The question is whether the traffic light should be the model or simply the presentation.

A useful distinction may be:

Health is the underlying operational position.

The traffic light is only a way of drawing attention to that position.

The system should preserve the dimensions, evidence, trends and exceptions underneath.

That allows a manager to see:

RED

and immediately ask:

Why?

The system should have an answer.

Questions worth testing

Should asset health ever be represented by a single score?

Which health dimensions are genuinely useful for different asset classes?

How should condition, lifecycle, availability, cost and production consequence interact?

Should critical exceptions override aggregate scores?

How should redundancy and asset criticality affect operational exposure?

Should future health under the current production plan be shown alongside current health?

How should trend and confidence be incorporated without making the model too complicated?

Can entity health roll reliably from components to assets, fleets, plants and sites?

And perhaps the broader question:

Are we using traffic lights to help people understand operational complexity, or using them to hide it?

The goal should not be to eliminate simple indicators.

It should be to make sure that simplicity remains connected to evidence, context and the decisions that matter.