Thinking
Notes on operational systems, assets and data.
Longer-form discussion of the operating concepts behind the systems we work on. Some pieces relate directly to DSLCore; others examine broader questions where the technology is only part of the answer.
Series
The operating model
A ten-part argument that moves from what an asset is — through work, lifecycle, production, budgets and shutdowns — to a connected operating model and the evidence behind it.
10 parts · Read the series →
The assurance layer
A ten-part argument that moves from exploration uncertainty and evidence — through public data, capital, decisions, application boundaries and orchestration — to an assurance layer that governs whether the operating model still behaves as intended.
10 parts · Read the series →
From exception to decision
A ten-part argument that moves from detecting a divergence — through ownership, evidence, risk, decisions, obligations, action and verification — to closure and independent assurance, tracing how an organisation governs the consequences it detects.
10 parts · Read the series →
Browse by topic
Asset and lifecycle
The asset register is not the asset system
An asset register records identity and hierarchy. An asset system should also represent operating state — usage, condition, life forecasts, maintenance demand and the economics of keeping the asset.
Production consumes asset life
Maintenance forecasting becomes more useful when production demand, utilisation and component life are treated as parts of the same model.
Implementation
Maintenance and reliability
The work order is not the maintenance system
The work order is one transaction inside a larger model of evidence, assessment, decision, execution, condition, history and future maintenance demand.
Planned does not mean ready
A work order can be planned without the labour, materials, access, permits or operating conditions required to execute it.
Maintenance budgets should describe the future, not just the past
Historical expenditure is a useful baseline, but maintenance demand comes from what assets are expected to do next — so a budget should also carry a forward view of commitments, forecast work, resource limits and expected outturn.
A shutdown is an operating event
A major shutdown is not just a large maintenance job — it is a temporary operating state where production, maintenance, contractors, procurement, isolation and commissioning converge on a constrained window, and it deserves to be modelled as a first-class operating event.
Resource planning starts before the work order
Much of tomorrow's maintenance demand is already visible in today's condition, production plan and lifecycle forecast — so labour, skills, parts, contractors and workshop capacity can be forecast and constraint-tested long before the work order exists.
Operational data
The field record is often the missing layer
The weak point is often not the dashboard or enterprise system, but the quality and structure of evidence captured where the work happens.
Build the data asset before the AI layer
AI can improve analysis and decision support, but it depends on identifiers, relationships, history, evidence and provenance that make operational records interpretable.
From maintenance records to operating evidence
Reliable records are essential, but maintenance data earns its value when history becomes evidence — inputs to a continuously evolving, explainable understanding of where each entity stands and what will happen next.
Public data is part of the investment infrastructure
Geological surveys do more than support science. They change the cost and quality of the first investment decision.
Capital should buy information, not just activity
Metres drilled, money spent and programme completion are necessary measures. They are not the same as learning.
A decision should preserve its evidence
The value of a decision record lies not only in what was decided, but in the evidence, assumptions and alternatives that existed at the time.
Evidence needs provenance, not just attachment
Evidence is more useful when we know where it came from, when it was valid, what it describes and which decisions depended upon it.
Decisions should be first-class records
Material decisions deserve their own structured history: what was decided, why, by whom, on what evidence and under what conditions.
System design
One work model may not fit every asset
Common asset, work, people and cost structures are worth sharing — but roads, structures, fixed plant and shutdowns identify, schedule and forecast work differently enough that one universal work-order workflow rarely fits them all.
Metadata before screens
A polished interface cannot compensate for a weak underlying model of the records, relationships, rules and responsibilities in an operational process.
Should operations have a ledger?
Finance preserves movements and derives a position from them. Operations accumulates hours, cost, commitments, life consumption and risk across scattered systems — a ledger-like layer could record those movements and explain where an asset, shutdown or site stands and why.
Health is a position, not a traffic light
A single health score hides more than it shows. Treating asset or entity health as a multidimensional, time-phased operational position — condition, lifecycle, cost, production exposure, resource readiness, risk — keeps the traffic light connected to evidence and decisions.
Not all uncertainty can be removed
Exploration will always involve geological uncertainty. The more useful question is which other uncertainties can be reduced, exposed or governed.
One application should not have to understand everything
Related business questions do not automatically belong in the same application. Boundaries can improve clarity, ownership and implementation.
Shared meaning matters more than a shared database
Independent systems can cooperate without sharing tables if they agree on identity, semantics and authority.
The difficult part is often between the systems
A system can be healthy while the operating environment is wrong. Some failures exist only in the relationships between applications.
An event tells you what happened. What detects what didn't?
Event-driven systems are good at reacting to change. Operational assurance also needs to detect absence, staleness and missing consequences.
An alert is not an exception-management system
Detection is only the first step. Operational exceptions need ownership, evidence, remediation, verification and closure.
The operating model needs an assurance layer
Applications execute work. An assurance layer asks whether the wider operating environment continues to behave as intended.
Detection is not governance
Finding that something has diverged from the expected state is important. Governance begins when the organisation decides what that divergence means and what should happen next.
The system that detects the exception may not own the problem
Technical, operational, commercial and compliance exceptions can originate in one system while responsibility for understanding and resolving them belongs somewhere else.
Risk is not alert severity
Severity helps systems prioritise attention. Risk requires context, consequence, likelihood, controls, uncertainty and exposure.
A decision can create an obligation
Obligations do not come only from legislation and contracts. Management decisions, risk acceptances and temporary approvals can create them too.
An obligation is not a task
Tasks describe work. Obligations describe required states or outcomes. Completing the work does not necessarily mean the requirement has been satisfied.
Completed is not the same as effective
Work can be finished without restoring the control, reducing the risk or achieving the outcome that justified the work.
Closure should require evidence
Closing an exception should be the result of demonstrated conditions, not simply an administrative change of status.
Audit should be independent of execution
Doing the work, governing the response and independently assuring that both were effective are related responsibilities, but they are not the same responsibility.