/omen

HAZOP Methodology Reference

Purpose: HAZOP (Hazard and Operability study, IEC 61882) is a systematic deviation analysis originally from process safety. At each process node, a facilitated team walks a matrix of Parameters × Guidewords, asking "what if this parameter deviates from design intent in this way?" — producing a catalogue of deviations, causes, consequences, existing safeguards, and recommended actions. HAZOP adapts cleanly to software systems where nodes become integration boundaries, parameters become throughput / latency / ordering / volume, and guidewords flex to data-flow deviations.

Scope Boundary

• omen hazop: node-by-node parameter × guideword deviation study. Systematic, team-facilitated, report-driven. Best for data pipelines, message brokers, control flows, integration boundaries.
• omen mode / premortem (elsewhere): FMEA / pre-mortem — broader and less structured than HAZOP. Use HAZOP when the system is a clearly decomposable flow; use FMEA when modes cut across many components.
• omen faulttree (elsewhere): deductive analysis of one undesired outcome. Complementary — HAZOP deviations often seed fault-tree top events.
• siege concurrency (elsewhere): concurrency and async edge cases. A HAZOP on a message broker surfaces "REVERSE flow" and "AS WELL AS" deviations that siege concurrency then investigates at runtime.
• STPA (elsewhere in literature): Systems-Theoretic Process Analysis — better than HAZOP for software-heavy, tightly-coupled control systems with emergent behavior. When control loops dominate, prefer STPA.
• Magi (elsewhere): trade-off arbitration when HAZOP recommendations compete.

Workflow

1. PREP          assemble design intent: architecture diagram, data contract,
                 SLO / SLA targets, operational envelope.
2. NODES         decompose the system into study nodes: each node is a
                 pipe/queue/call/stream with explicit inputs and outputs.
3. PARAMETERS    pick the parameter set that governs the node's design intent
                 (see Parameter Mapping below).
4. GUIDEWORDS    apply the guideword set to each parameter at each node.
5. DEVIATION     for each (node, parameter, guideword) cell, state the
                 deviation in one sentence. Skip meaningless cells.
6. C-C-S-A       for each kept deviation, record:
                   - Cause(s)
                   - Consequence(s)
                   - Safeguards (existing)
                   - Action(s) recommended (owner + by-when)
7. RECONVENE     review deviations crossing node boundaries; close the loop.
8. REPORT        publish HAZOP worksheet; escalate critical deviations to
                 `faulttree` (deep dive) and `bowtie` (stakeholder view).

Parameter Mapping (process → software)

Guideword Set

Keep the EARLY/LATE/BEFORE/AFTER extensions for any system with temporal semantics — they catch ordering bugs that NO/MORE/LESS miss.

Parameter × Guideword Grid (example)

Node: Kafka topic orders.v1 — producer → broker → consumer.

A meaningful HAZOP produces 20-80 deviation rows per node for non-trivial systems. Cells that are "N/A / not credible" should be marked explicitly rather than erased — the blank cell is indistinguishable from an oversight in review.

Study Team Composition

Minimum team of four, ideally five to seven:

A HAZOP without an operator is a design review; a HAZOP without a facilitator drifts. Sessions cap at 3 hours — longer and the team misses deviations.

Report Template

HAZOP Study: <system / release>
Date: <yyyy-mm-dd>   Facilitator: <name>   Attendees: <roles>

Design intent reference: <link>
Node list: <N1, N2, …>

Per-node worksheets: (Parameter / Guideword / Deviation / Cause /
Consequence / Safeguard / Action / Owner / Due)

Cross-node observations: <deviations that traverse nodes>
Escalations: <deviations handed to faulttree / bowtie / sentinel>
Action tracker: <open / closed / deferred, owner, due>
Next review: <date>

HAZOP vs STPA

Rule of thumb: if the architecture diagram looks like a DAG of flows, start with HAZOP. If it looks like a controller with feedback, start with STPA.

Anti-Patterns

• Running HAZOP without a design-intent document — deviations have nothing to deviate from.
• Skipping "N/A" cells instead of marking them — review cannot distinguish skip from miss.
• Letting the designer facilitate — they will unconsciously defend rather than challenge.
• Collapsing Consequence and Safeguard into one column — loses the gap between "what would happen" and "what stops it today".
• Leaving actions without owner + due date — the worksheet becomes a museum piece.
• Using HAZOP where STPA fits better (tight control loops, emergent hazards).
• Running a 6-hour marathon session — quality collapses after hour three; split across days.

Handoff

• To faulttree: deviations with severe consequences become top events for deductive analysis.
• To bowtie: each critical deviation maps to a threat on the bowtie left side with its safeguards as preventive barriers.
• To Triage: HAZOP actions for runtime deviations seed runbook entries.
• To Beacon: deviations detectable only via telemetry define new SLIs and alerts.
• To Radar: each kept deviation row becomes a test scenario candidate.
• To Sentinel / Breach: deviations with adversarial causes escalate to security review.
• To Magi: when two safeguard actions compete for the same budget, hand the deviation rows + cost to Magi for trade-off arbitration.