Features/MCP Workflows/Hazard register integrity audit

Hazard register integrity audit

The risk assessment documentation is only as good as the hazard register behind it. This follows every hazard outward, to the systems it is assigned to, the requirements that mitigate it, and the tests behind those, and reports every broken or missing link as a finding.

Read-only

The problem this solves

The usual failures are quiet ones: a hazard with a control described in the notes that never became a requirement, a requirement that mitigates a hazard but was never tested, a residual risk that was never rated, an accepted disposition with no rationale. Each one is a question from an assessor. This audit finds them first.

How it works

Every hazard followed outward to its requirements, tests and residual risk. Every broken link is a finding. Finds the control described in the notes that never became a requirement, the mitigation that was never tested, and the residual risk that was never rated, before an assessor does.

01
Read the register and everything it touches
All hazards with every field, all requirements with their verifications, assigned systems and constraints, all test cases with runs and step results, and the parts and connections.
02
Check every hazard's chain
Assignment, initial and residual severity and likelihood, mitigating requirements, whether each mitigation is assigned where the hazard is, whether each has a Passed test run, and whether the disposition is consistent with the residual risk.
03
Quote the uncovered controls
Where a hazard's description or notes mention a guard, limit, measure or check that corresponds to no mitigating requirement, the phrase is quoted and the gap named.
04
Check the reverse direction
Safety requirements that mitigate no hazard are flagged as orphans, and every requirement constraint on a model variable is evaluated against the variable's current value.
05
Rank and attach provenance
Findings ordered by the initial severity of the affected hazard, then by category, each carrying the element IDs behind it.

Where this sits in the Regulation

Regulation (EU) 2023/1230 applies from 20 January 2027, and Annex IV Part A item (b) is the risk assessment documentation this register feeds; the technical file is kept for ten years after the machine is placed on the market. This audit reads the model and reports gaps: it is a readiness check, not a conformity assessment.

Regulation (EU) 2023/1230 on EUR-Lex

The prompt

Audit the hazard register in the connected Dalus model. Do not modify the model.

Step 1. Read all hazards with every field, all requirements with type, status, verifications, assigned systems and constraints, all test cases with linked requirements, runs and step results, and all parts and connections.

Step 2. For each hazard, check:
- Has at least one assigned system or connection
- Has initial severity and likelihood
- Has residual severity and likelihood
- Has at least one mitigating requirement
- Every mitigating requirement is assigned to at least one system that is also assigned to the hazard, or to a connection between such systems; flag mismatches
- Every mitigating requirement has a test case, and at least one run with status Passed
- If disposition is "accepted", an acceptance rationale exists
- If disposition is "controlled" or "eliminated", residual risk is lower than initial risk; flag where it is not
- The description or notes mention a control, measure, guard, limit, analysis or check that does not correspond to any mitigating requirement. Quote the phrase and say no requirement covers it.

Also evaluate every requirement constraint against the current variable values and report any that fail, naming the variable, its current value, the limit and the operator.

Step 3. For each safety requirement, check that it mitigates at least one hazard. Flag safety requirements that mitigate nothing.

Step 4. For each requirement with a constraint on a model variable, evaluate the constraint against the variable's current value and report pass or fail.

Step 5. Findings, ranked by the initial severity of the affected hazard, then by category: no mitigation, uncovered control in notes, mitigation not verified, no residual assessment, disposition without rationale, system mismatch, orphan safety requirement, constraint failing.

Step 6. Provenance: element IDs behind each finding.

Output: a findings report with a summary count per category, the ranked findings, and provenance. Do not restate hazards that pass every check except in a one-line summary count.

What you get

Summary count per finding category
Ranked findings, ordered by the initial severity of the affected hazard
Quoted phrases for every control in the notes that no requirement covers
Pass or fail on every requirement constraint against the current model values
Provenance: element IDs behind each finding
Outputs are drafts for expert review. This workflow supports, and does not replace, qualified safety and certification engineering.

Common questions

When does Regulation (EU) 2023/1230 apply?
From 20 January 2027, when it replaces the Machinery Directive 2006/42/EC. The technical file it requires must be kept for ten years after the machine is placed on the market.
Is this a conformity assessment?
No. It is an integrity check of the hazard register in the model. Conformity assessment remains your CE marking procedure, with a notified body where the Regulation requires one.
Why quote the notes back at me?
Because a control that exists only as a sentence in a hazard's notes is invisible to every downstream document: it has no requirement, no test, no evidence. Quoting the phrase makes the gap concrete enough to fix in one edit.
Does it list the hazards that pass?
Only as a one-line summary count. The report is the findings, not a restatement of the register.