What Is the LDP Framework?

The Living, Driving, Proving (LDP) Framework is a diagnostic model for judging whether a safety management system is working in the real world. Process cycles such as PDCA describe how a system should be designed and improved. LDP asks a narrower and more awkward question: where is that system actually visible? It moves the test from what the documents say to what the operation does, which is where the difference between a compliant system and a working one becomes apparent.

Definition and Core Purpose

The LDP Framework assesses whether a safety management system functions under real operational conditions. It shifts the question from "is there a system in place?" to "is the system working, and where would we see that?"

LDP evaluates performance across three interrelated spheres:

• Living, how the system is experienced and applied by teams in day-to-day operations
• Driving, how leadership, planning and strategy give the system direction and momentum
• Proving, how the system shows results through evidence, assurance and improvement

The three are not stages and do not run in sequence. A system can be strongly driven and barely lived, or thoroughly proven on paper while the frontline works around it. Reading all three together is what makes the framework diagnostic rather than descriptive.

Living It: What the System Looks Like in Practice

A system is only meaningful if it is lived. The Living dimension examines how people engage with the system in real time, on the floor, in the field and during routine work. It looks past documentation to how procedures, controls and expectations translate into behaviour. In ISO 45001 it aligns with Clause 5.4, Consultation and Participation and Clause 8, Operational Planning and Control.

A system is lived when it shapes everyday thinking and action. Indicators include:

• Workers identifying and responding to risks without needing reminders
• Supervisors referencing controls during briefings and routine discussion
• Field-level feedback visibly changing procedures or controls
• Safe work methods applied consistently across tasks, shifts and teams
• Contractors and short-tenure workers held to the same practice as direct employees

Driving It: How Strategy and Leadership Activate the System

A system that is not actively driven will drift. The Driving dimension examines how leadership converts safety commitments into direction, resourcing and oversight, and whether safety is embedded in strategic decision-making rather than delegated as a function. It aligns with Clause 5.1, Leadership and Commitment and Clause 6, Planning.

A system is driven when leadership decisions give safety both traction and visibility. Signs include:

• OH&S objectives clearly linked to business goals and organisational risk
• Resources and accountability aligned with safety priorities at every level
• Leadership involvement in planning cycles, reviews and change decisions
• Risk-based thinking visible in strategic, project and procurement choices
• Safety appearing in decisions that were not framed as safety decisions

Proving It: What Evidence Shows the System Is Working

A system that cannot be proven cannot be improved. The Proving dimension examines whether performance is monitored, reviewed and acted on in a way that produces change. It concerns the quality of evidence rather than its volume, and aligns with Clause 9, Performance Evaluation and Clause 10, Improvement.

A system is proven when results can be tracked, analysed and acted upon. Evidence includes:

• Audits confirming controls are implemented and functioning as intended
• Performance metrics tracking both leading and lagging indicators
• Management reviews that produce decisions rather than minutes
• Corrective actions built on root cause rather than surface fixes
• A record of controls found ineffective and changed as a result

Proving the system means having the visibility to know what is working, what is changing and what still needs attention. It closes the loop and keeps the system honest.

How the Three Dimensions Map to ISO 45001

Each dimension draws on a different part of the standard, which is what allows LDP to point at a specific clause when a system is failing in a specific way.

How LDP Relates to PDCA

The LDP Framework does not replace the PDCA cycle, it makes it visible. PDCA gives a structure for planning, executing, evaluating and improving. LDP tests whether those phases are happening anywhere other than in the documentation.

Each dimension interacts with PDCA phases rather than mapping onto one:

• Living shows in Do, through how people apply practices and engage with controls. It also reaches back into Plan, as frontline insight reshapes what gets planned.
• Driving shows in Plan, through direction, resourcing and integration into strategy. It extends into Act, where leadership decides what improvement actually happens.
• Proving shows in Check, through audit, monitoring and review, then into Act as corrective action feeds back into Driving.

Used together the two form an adaptive loop. PDCA provides the structure; LDP establishes whether the structure is load-bearing.

Where LDP Breaks

A diagnostic framework has to be honest about its own failure modes, because each one turns LDP from a test into a reassurance exercise. The remedy follows each in italics.

• Proving activity instead of effect. Completed audits, delivered training and closed actions all evidence that the system operated. None of them evidences that anything changed.
  Remedy: for every measure, ask what it would read if the control had failed. One that reads the same either way is counting activity, so pair it with an outcome it should move.
• Reading one dimension for the whole. A well-driven system is mistaken for a working one, because leadership commitment is the easiest dimension to observe from the top.
  Remedy: score the three separately and never average them. The lowest dimension is the finding, so a strong Driving read beside a weak Living read is the diagnosis rather than a mixed result.
• Asking Living through documents. Interviewing the system rather than the work. What people do under observation and what they do routinely are different data.
  Remedy: take the Living read where and when the work happens, including the shifts nobody visits, and ask what people do when the control is inconvenient rather than whether they know it exists.
• Using it as an audit substitute. LDP indicates where to look. It does not establish conformity, and treating a favourable read as compliance evidence inverts its purpose.
  Remedy: keep the outputs separate. LDP findings set audit scope, audit findings feed the next LDP read, and neither belongs in the other's conclusion.
• Running it once. A single assessment produces a snapshot. Drift is the thing LDP is built to catch, and drift is only visible across repeats.
  Remedy: fix the repeat interval before the first read and hold the questions constant between rounds, because changing them makes movement unreadable.

Origins, Use Cases, and Connection to ISO 45001

The LDP Framework was developed in response to a persistent problem: systems that look sound on paper fail in practice, and the paper gives no warning. Informed by field-level audits, leadership gaps and inconsistent outcomes, it offers a way to assess whether a system is functioning where it matters, on site, in planning, and in performance.

LDP is the diagnostic framework used throughout Mission 45001, the SafetyRatios clause-by-clause examination of ISO 45001:2018, where each clause is read for where it is lived, driven and proven rather than for whether it is documented. It is most useful where:

• Controls that were properly designed are not holding in the field
• Certification and actual performance have visibly diverged
• Leadership needs to see its own role in the system rather than its oversight of it
• PDCA has been implemented as a documentation cycle and needs testing
• A system passes audit repeatedly while incident patterns stay unchanged

By focusing on what is lived, driven and proven, LDP closes the gap between system design and system reality. It turns system principles into something observable, so safety is demonstrated rather than merely documented.