Findings must become concrete design or procedure changes

What it is

An actionable investigation recommendation maps an identified failure mechanism to a defined change in interface, equipment, procedure, resources, or governance, with a verification criterion attached. Whether a recommendation is actionable comes down to one concrete test: does it point to a specific action whose completion can be checked afterward — modify one interface, add one interlock, revise one procedure clause — rather than vague wording like "raise awareness," "be more careful," or "increase a sense of responsibility," none of which changes a system condition or can be verified as actually carried out.

Why it happens

An abstract finding is easy for every department to agree with, but it cannot be assigned to a designer and it cannot be tested for completion — "raise awareness" never says who changed what, when, or how, so there is nothing checkable at the end. A concrete change is different: it removes an inducement, increases detectability, or restores a barrier, and it genuinely changes what the next person in the same situation can see and choose. When a recommendation has no causal fit to the mechanism it targets, training gets used to compensate for an interface that should have been fixed instead, and a new warning just adds to alarm load — the underlying problem does not go away, it just changes form.

There is also an organizational reason vague recommendations keep recurring: they are cheap to write and easy for report review to accept as "addressed," letting a case close without committing engineering resources, while a concrete design or procedure change usually needs cross-department coordination, budget, and a formal change-management process — much more resistance to push through. Both kinds of recommendation look equally "done" on the page, but the organizational cost behind them is wildly unequal, and that asymmetry is itself what keeps vague recommendations around.

Studying it

Map each recommendation from mechanism to intervention to measure, and assess actionability, the control-hierarchy level of the intervention, and its effect after implementation; compare candidate interventions under realistic pressure to see whether error paths and side effects actually changed. One concrete way to classify a backlog: sort past recommendations into concrete versus vague by whether a matching acceptance record or change ticket can be found, and report the ratio. On-time closure rate alone is not a quality measure — a high closure rate just means the administrative process moved fast, not that a system condition actually changed.

Where it stops holding

Investigators may not have the authority to specify one particular engineering solution; a more realistic approach is to define the required safety function and the evidence needed to confirm it, leaving the engineering implementation to a qualified group. A temporary measure can reduce risk right away, but it needs an expiry date and a transition into a permanent design — "temporary" should not become the default state indefinitely. Procedure change is not a universal remedy either: if the underlying failure mechanism is an unreliable piece of equipment or an unusable interface, simply demanding stricter adherence to procedure just pushes a system-level defect down onto the operator, and it will fail again the same way. Whether a soft-sounding recommendation counts as vague is not about how strict it sounds — it is about whether it can be verified: "notify other units running the same equipment model of this issue" is concrete if it names a recipient and a deadline, and does not become vague just because it involves no hardware change.

Applying it

• Attach a completion criterion to every recommendation, one that can be checked at closure against a ticket number, an acceptance record, or a test result — not a summary sentence.
• Prefer hazard elimination or engineering control first, then warnings, procedures, and training; when training really is the only option, require a verifiable behavioral measure (a field audit of compliant operation, for instance) rather than an attendance count.
• Test the proposed intervention under normal, abnormal, and time-pressured work, and check whether it shifted the burden onto another role or another step in the process.
• Send vague recommendations back at closure review and require a concretized version — or, when concreteness is genuinely blocked by resources or technical constraints, record that constraint explicitly instead of hiding the impossibility behind soft wording.

Related

• Same group: Y7.05.1 Investigation should identify systemic causes rather than blame individuals · Y7.05.2 Missing feedback loops cause accidents to recur · Y7.05.4 Investigation must be independent of routine management
• Nearby: Y7.06 Human-factors verification and validation · Y5.01 Operating procedures
• Search terms: actionable recommendation · hierarchy of controls · effectiveness verification