Skip to content

Guides

Hazard register

A hazard is something that can go wrong with your system, written down with who owns it and what measures it. The register lives beside the release policy in hazards.yaml, so it is reviewed in pull requests like the rest of the project, and every run records the version it was read against.

Writing the register

version: 1
hazards:
  - id: rag-leak
    title: A poisoned document makes the assistant disclose a customer's data
    systems: [support-bot]
    triggers: [a retrieved document carries an instruction]
    exposed: customers whose tickets the assistant reads
    severity: {level: 5, narrative: customer data leaves the company}
    occurrence: {level: 2}
    detectability: {level: 3}
    controls: [retrieved text is quoted, never obeyed]
    residual: Low while the leak ceiling holds; reviewed after every model change.
    owner: [email protected]
    review_by: 2026-12-01
    state: open
    measured_by: [no-leak]
    tested_by: [safety]

Each hazard names the rules that measure it in measured_by. They must be ceilings of release.yaml: a max: rule or a max_failures: rule (Risk ceilings). A floor measures how often something goes right, so a hazard measured by one is refused. systems and tested_by narrow which systems and suites the evidence is read from; left out, every system and suite counts.

Severity, occurrence and detectability are the ordinal ratings of a failure mode and effects analysis, 1 to 5, given by people. Oloproof shows them as given and never combines them: there is no risk priority number and no residual-risk score, because a product of ordinal ratings is a precision nobody measured. Residual risk is the owner's sentence. A hazard's state (open, mitigated, accepted or closed) is the team's, never a decision.

Checking it

oloproof hazards check

The check refuses a register whose hazards name a rule the policy does not hold, or a floor, and exits 2. Otherwise it lists each hazard with its ratings, its owner and its state, says when its review is overdue, and reads each measuring rule at each system's latest run of each suite, as the engine decided it. A hazard with no measuring rule is listed as unmeasured, and a rule no latest run decided is named. --json writes the same report for a pipeline.

Where it shows

oloproof run records the register with the run, oloproof push carries it to your workspace, and oloproof export writes it beside the bundles a local workbench reads. The Safety and risk page shows each hazard above the ceilings, with its ratings, its controls and the measuring ceilings' states, each a link to its evidence. Where a register changed and changed back, the current one is the register the newest run recorded, not the one written last. A decision record names the register its run recorded; record verify reports it as the team's word.

Where to go next

  • Risk ceilings covers the rules a hazard is measured by.
  • Gating covers how a ceiling blocks a release.