Why hydrogen workflows didn't fit our refinery-targeted system — the 5 layers of mismatch + 3 paths to fix it

why_h2_didnt_fit_2026-05-14.md

Why hydrogen workflows didn't fit our system — the 5 layers

Standards are part of it but not the whole story. There are about 5 layers of mismatch; standards are layer 1.

The 5 layers (concrete examples)

Layer 1: Standards — partial fix

Refinery uses IEC 61882, API 521, NACE MR0175, ASME Sec VIII, API 571.

Hydrogen uses EIGA IGC Doc 33/14, ANSI/CSA CHMC 1, ASME B31.12, ISO 22734, NFPA 2.

Battery storage uses IEC 62933, UL 9540A.

PV uses IEC 61727, NEC 690.

We could catalog + extract clauses from these. Maybe a 1-week task. Necessary but not sufficient.

Layer 2: Workflow methodology — bigger fix

Even with the right standards loaded, our HAZOP workflow doesn't fit H₂. Here's why:

Our HAZOP applies guidewords (NO / MORE / LESS / REVERSE) to parameters (FLOW / PRESSURE / TEMPERATURE / LEVEL) at process nodes. That works for refinery streams.

For an electrolyser, the deviations that matter aren't really "more flow" — they're things like:

• Membrane current density too high
• Cell voltage out of band
• Gas crossover (O₂ in H₂ stream → flammable)
• Water purity dropping

The consequence library is also different. Refinery HAZOP worries about "loss of containment of hazardous fluid → fire / explosion / toxic release." H₂ HAZOP worries about "membrane rupture → H₂/O₂ mixing → deflagration in stack." Different mechanisms, different mitigations.

EIGA IGC Doc 33/14 exists specifically because IEC 61882 (the generic HAZOP standard) doesn't fit H₂ plants well. We'd need a workflow template that uses the EIGA framework, not the IEC 61882 one.

Layer 3: Equipment classes — partial fix in flight

Our system has 8 equipment classes (pump, compressor, vessel, shell-tube heat exchanger, air-cooled heat exchanger, column, tank, fired heater). H₂ stack needs different ones: PEM electrolyser, Li-ion BESS container, PV inverter, MEGC cylinder bundle, air-operated diaphragm pump.

This one we've started fixing — a recent PR adds the 4 H₂-stack class starters. But adding classes alone doesn't help if the workflows still expect refinery-shaped equipment.

Layer 4: Safety framework — bigger fix

Our LOPA + SIL/SIF framework is built around IEC 61511 with hydrocarbon- process IPL credits. H₂ plants do use IEC 61511, but:

• Hazard catalog is different (no API 571 damage mechanisms; hydrogen embrittlement per ANSI CHMC 1 instead)
• Typical SIL bands are lower (water-treatment + H₂ usually SIL-0 to SIL-1, not SIL-2 to SIL-3 like refinery hydrocarbon)
• BPCS-SIS independence rules apply differently when the whole package controller is vendor-supplied

Layer 5: Quality criteria — small fix

Our "what does a good HAZOP look like?" reviewer rubric is tuned to refinery expectations. A finished H₂ feasibility study has different sections, different depth, different acceptance bars. The gold examples we use as in-context exemplars are all refinery — none are hydrogen.

So how do we actually fix it?

Three sequential moves, each gets you further:

Move A: ingest the H₂ standards (~1 week)

Catalog + extract clauses from the H₂-specific standards. Solves layer 1. After this: workflows that only need standard clauses would partly work. Doesn't fix workflows that need different methodology (most of them).

Estimated impact: 0 → 1 GREEN workflow.

Move B: build domain-adapted workflow templates (~2–4 weeks per domain)

Author H₂-specific versions of:

• HAZOP (EIGA-style, electrolyser hazard catalogue)
• LOPA (lower SIL bands, vendor-package BPCS-SIS architecture)
• Materials (ANSI CHMC 1 instead of NACE MR0175)
• Relief (ISO 22734 + EIGA IGC Doc 100 instead of API 521)
• Datasheets (use the equipment-class starters)

This is the substantial work. Each new template is roughly the same scope as building a new workflow today (~1–2 weeks per).

Estimated impact: 1 → 5–7 GREEN workflows for H₂ projects.

Move C: refactor the framework so domain is a parameter (~2–3 months, structural)

Today every workflow embeds its methodology assumptions. Refactor so:

• The base workflow logic (extract → author → review → consistency-check → consolidate → assemble) stays domain-agnostic
• Each domain ships its own template + class-starter + standards-set + reviewer rubric
• A new project scaffolds with --domain=hydrogen and the right templates load automatically

This is the "build it once, support every domain" structural fix. Doesn't change whether any specific deliverable is ready today, but means we're not re-doing this work for every new domain (water treatment, district heating, biogas, carbon capture, ...).

Estimated impact: makes Move B repeatable for any domain in ~1 week instead of ~4–6 weeks per new domain.

What I'd actually recommend

1. Move A is too small to be valuable on its own. Standards loaded but no methodology adaptation = workflows still mostly RED. Don't do A in isolation.

2. Move B for one specific domain (probably H₂ since equipment-class starters already exist) gets you a second customer-ready vertical. That's a real product expansion.

3. Move C is the right long-term bet but it's structural and slower-feedback. Land it after Move B has validated that the abstraction boundary is right.

So the path is: A+B for H₂ (probably 4–6 weeks total) → measure how repeatable it is → if painful, do Move C. If Move B was easy, Move C may not be needed yet.

The shorter version for a quick share

"It's not just missing standards — the workflows themselves embed assumptions about what kind of plant they're analysing. Adding standards alone won't help. The real work is building H₂-specific workflow templates (the analysis methodology, hazard library, IPL framework). That's a 4–6 week effort per new domain. Worth doing for hydrogen because it's a growth market; worth structurally refactoring later so the next domain (district heating? biogas? carbon capture?) takes 1 week instead of 4."