What Is a Basic Risk Factor? The Tripod Beta Concept That Turns “Systemic Issue” Into a Real Fix

“There’s a systemic issue” is one of the most common conclusions in an incident report, and one of the least useful. It signals that the investigator has correctly avoided blaming an individual — which is progress — but it stops short of naming anything a department head could actually be handed as an action item. Tripod Beta’s answer to that gap is the Basic Risk Factor, or BRF: a defined set of categories that names precisely which part of an organisation’s management system failed, and therefore who owns the fix.

This article continues a series built around one real investigation — equipment, task, and setting fictionalised for confidentiality, causation chain unchanged — that surfaced findings across four of Tripod Beta’s eleven BRF categories.

What a BRF Actually Is

A Basic Risk Factor sits at the Underlying Cause level of a Tripod Beta causation chain — the layer describing a failure at the management or system level, distinct from a Precondition (a situational or psychological state) and distinct from an Immediate Cause (the specific action or inaction that directly defeated a barrier). Where a Precondition explains why an action felt reasonable to the person doing it, an Underlying Cause explains why the organisation allowed the conditions that produced that precondition to exist at all.

Tripod Beta defines eleven BRF categories: Design, Training, Hardware, Communication, Maintenance Management, Incompatible Goals, Housekeeping, Organisation, Error-Enforcing Conditions, Defences, and Procedure. Each one names a distinct type of management system failure, and — critically — each one implies a different owner for the corrective action. A Design finding goes to engineering. A Training finding goes to L&D. An Organisation finding usually goes several levels up, because it describes how a process itself is structured, not a single decision within it.

The Four That Surfaced in This Investigation

Design (DE): There was no other suitable rigging method available for installing the component at that location, and no alternative rigging tool — such as a powered hoist — available for the task. The barrier failure here wasn’t a people problem. It was baked into how the job was engineered before anyone was assigned to it.

Procedure (PR): The risk assessment’s control measures were too generic to capture what this specific task actually required — a finding this series covers in more depth in a later article, alongside a related confusion between the Risk Assessment and the Job Hazard Analysis.

Organisation and Incompatible Goals (OR/IG): The task was repeatedly treated as “light work” — both in how it was resourced and in the instructions given for it — without anyone checking whether that label matched the actual physical demands of the job.

Error-Enforcing Conditions (EC): No physical fit-for-task check existed in the job scope. Nobody verified that the person assigned to the task could actually perform it safely as described.

Why the Category Matters as Much as the Finding

Naming a BRF isn’t a labelling exercise for its own sake. It’s what makes a recommendation enforceable rather than aspirational. “Improve safety culture” is not a task anyone can complete or verify. “Add a fit-for-task physical assessment to the job-scoping process, owned by the site engineering lead, verified before the next comparable task is assigned” is a task with an owner, a scope, and a way to check it happened — and it only exists because the investigation correctly classified the finding as Error-Enforcing Conditions rather than leaving it as a vague observation about the work environment.

This is also why a causation chain can legitimately produce multiple Underlying Causes stacked under a single Precondition, or multiple BRF categories from what looks, on the surface, like one incident. A single fall can trace back to an engineering gap, a documentation gap, an organisational pattern, and a job-scoping gap simultaneously — and treating all four as one undifferentiated “systemic issue” would hand the fix to nobody in particular, which in practice means it goes to no one at all.

What Comes Next in This Series

The next several articles in this series take each of these four findings in turn, in more depth — what each one actually means in practice, why it was classified the way it was, and who the resulting recommendation should land with.

The Practical Check

For your own site’s most recent significant finding labelled “systemic” in a report, ask which of the eleven BRF categories it actually belongs to, and who that category implies should own the fix. If the answer isn’t clear, the finding probably isn’t finished yet.

Want your investigation team applying BRF classification correctly instead of defaulting to “systemic issue”? Cikgu Barrier’s Tripod Beta Incident Investigation programme covers all eleven Basic Risk Factors in depth, with the classification tests needed to apply them accurately. Available in-house and as a public workshop across Malaysia.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top