Safety case readiness

The problem this solves

A hazard log where implemented and verified read the same is precisely the document that gives false comfort. The residual risk figure is the number quoted in reviews, and it can rest on controls whose evidence nobody has rechecked since the design moved.

How it works

What the safety argument rests on, sorted into verified, implemented, asserted and absent, before any ticket is filed. An internal readiness check, not a safety assessment. Separating asserted from verified is the whole point: a hazard log where the two read the same is the document that gives false comfort.

You are assessing what the safety argument in the Dalus model
[model name] currently rests on, and only then proposing Linear
issues for the gaps. The order matters: this is an evidence
assessment with ticket-filing at the end, not a ticket generator with
a preamble. A list of forty issues teaches a team to ignore the
label; a clear statement of what is asserted rather than demonstrated
gets acted on.

WHAT THIS IS AND IS NOT. This is an internal readiness check. It is
not a safety assessment, it does not certify anything, and whether
the evidence is adequate is the judgment of the people accountable
for the safety case. Say so in the report.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Linear team issues should go to; the scope, meaning all hazards, a
subsystem, or a hazard category; and whether a previous run exists to
compare against. Ask anything else in the same message. Then begin.

READ THE MODEL: every hazard in scope with its description, cause,
effect, severity, likelihood, initial and residual risk, and
disposition; the safety requirements and controls mitigating each;
the elements those controls are allocated to; the verification items
covering the controls, whether they have run, with what result, and
against which configuration.

CLASSIFY EVERY CONTROL INTO ONE OF FOUR STATES, and never collapse
them into a single status column:
- VERIFIED: a verification exists, it has run, it passed. Name it
  and give the date and configuration.
- IMPLEMENTED, NOT VERIFIED: designed and allocated, no run has
  happened or the result is unknown.
- ASSERTED: the model records the control as complete, but nothing
  is linked to demonstrate it. Say so plainly.
- ABSENT: the disposition depends on a control the model does not
  contain.
A hazard log where implemented and verified read the same is
precisely the document that gives false comfort, and separating them
is the entire value of this workflow.

THEN REPORT, in this order, before any issue is proposed:
1. Hazards with no controls at all.
2. Catastrophic or critical hazards still dispositioned unacceptable
   or unresolved. THESE ARE NOT TICKETS. A design decision does not
   belong in a backlog, and filing it as one is how it gets
   deprioritised behind ordinary work. List them separately, name
   what decision is outstanding, and say explicitly that no issues
   were created for them.
3. Hazards whose residual risk is recorded but whose controls are
   unverified, since the residual figure then rests on nothing.
4. Controls verified against an older configuration than the current
   design.
5. Hazards with no disposition.
6. The four-state counts across the whole scope, so the shape of the
   argument is visible in one number set.

THE DELTA, if a previous run exists: controls that gained
verification, dispositions that changed, hazards added, and any
residual risk that moved. A residual risk that dropped is the most
consequential line in a safety review and must never be discoverable
only by comparing two tables by eye.

ONLY THEN, PROPOSE ISSUES, gated. One per control in the
implemented-not-verified and asserted states, each describing the
control, the hazard it mitigates, how it is meant to be verified, and
what evidence is missing. Skip anything dispositioned accepted or
eliminated. Skip everything in category 2 above. Group where several
controls share one verification activity, since a team of twelve does
not need three issues for one test. Show every draft and wait for
approval. No assignees, no estimates.

AFTER CREATING: report the issue identifiers, what was deliberately
not filed and why, and the state of the argument in one plain
paragraph. Offer, do not execute: publishing the hazard summary for
the wider team, and re-running before the next review.

THIS WORKFLOW IS READ-ONLY on the model. It creates Linear issues
only after approval.

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

What you get

Common questions