Confluence hazard log mirror

The problem this solves

Outside the safety team, nobody can see the hazard picture without opening the model, so it gets summarised into a slide once a quarter. What survives that summary is a status column, and a status column cannot tell you that a residual risk figure rests on a control nobody has verified.

How it works

The hazard picture published for people outside the safety team, with implemented kept apart from verified. A visibility mirror, never the controlled safety record. Every control is reported as verified, implemented, asserted or absent, because a log where those read the same is the one that gives false comfort.

You are publishing a read-only hazard summary from the Dalus model
[model name] into Confluence, so that people outside the safety team
can see the current hazard picture without opening the model.

THIS IS A MIRROR FOR VISIBILITY, NOT THE SAFETY RECORD. State that
on the page itself. The authoritative hazard log is the model and
whatever safety record the team's process names; this page is a
published view of it at a point in time. Teams with a real safety
case have rules about where hazard data may live and what counts as
controlled, and this page must never present itself as that
artefact.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Confluence space and parent page; whether this is a first
publication or an update to an existing page; the scope (all
hazards, a subsystem, a hazard category); and whether the space is
open to everyone in the organisation, since hazard data is sometimes
restricted. Ask anything else in the same message. Then begin.

CHECK FOR AN EXISTING PAGE and update it as a new version rather
than creating a second one. Two hazard pages is worse than none.

READ THE MODEL: every hazard in scope with its description, cause,
effect, severity, likelihood, initial and residual risk,
disposition, and the safety requirements or controls that mitigate
it. For each control, read its allocation, its verification item,
and whether that verification has actually run and with what result.

STAMP AT THE TOP: model, branch, revision, date published, scope,
and a one-line statement that this is a mirror, not the controlled
safety record.

THE CENTRAL DISTINCTION, and the reason a safety engineer would
trust this page: separate controls that are IMPLEMENTED from
controls whose effectiveness has been VERIFIED. For each control
report which it is, on the evidence:
- Verified: a verification item exists, it has run, and it passed.
  Name the verification and its result.
- Implemented, not verified: the control is designed and allocated,
  but no run has happened or the result is unknown.
- Asserted: the model records the control as complete, but there is
  no verification linked to it. Say so plainly.
- Absent: the hazard has a disposition that depends on a control
  the model does not contain.
Never collapse these into a single status column. A hazard log where
implemented and verified read the same is precisely the document
that gives false comfort.

ALSO REPORT: hazards with no controls at all; hazards whose residual
risk is recorded but whose controls are unverified, since the
residual figure then rests on nothing; controls verified against an
older revision than the current design; and hazards with no
disposition. List these above the main table, because they are the
findings and the table is the reference.

THE TABLE: one row per hazard with severity, likelihood, initial
risk, residual risk, disposition, controlling requirements, and the
evidence state of each control. Landscape or a wide layout, since
hazard tables are unreadable squeezed into a narrow column. Every
hazard and requirement links back to Dalus by ID.

NEVER INVENT: no severity, likelihood or risk rating that the model
does not record, and no inferred disposition. Where a field is
empty, the page says the model does not record it. Never reproduce
rating scales or classification tables from a published standard;
where the team uses one, refer to it by name and use the team's own
recorded values.

ON REPUBLICATION, add a "what changed" section under the stamp:
hazards added, hazards whose risk rating moved, controls that gained
or lost verification, and dispositions that changed. A hazard whose
residual risk dropped since the last publication is the single most
consequential line on the page and should never be discoverable only
by diffing two tables by eye.

BEFORE PUBLISHING, show the user the findings list, the table, the
stamp and the change summary, and wait for approval. Given the
content, confirm the space's visibility is appropriate before
writing.

AFTER PUBLISHING: report the page URL, the counts by evidence state,
and the findings. Offer, do not execute: opening tasks for the
unverified controls, and republishing before the next safety review.

THIS WORKFLOW IS READ-ONLY on the model. It writes only the
Confluence page, and only after approval.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions