From HAZOP, LOPA and FMEA worksheets to rules a machine can run

In one minute

• Plants already keep safety worksheets: HAZOP, LOPA and FMEA. They record what can go wrong, but a machine cannot run a spreadsheet.
• quorum imports these worksheets into a draft rulebook, carrying each row through with the document it came from.
• It flags a protection that only looks independent: a safeguard that names the same instrument as the cause it guards against.
• A draft is never finished. The importer fills in what the worksheet states, marks the rest as to-do, and the compiler refuses the draft until a person completes it.
• The honest limits: the shared-cause check matches on instrument tags only, and an FMEA risk score does not become a rule, though severity does.

Who this is for

This guide is for the engineer who has done the safety studies and has the paperwork to show for it. You ran the HAZOP. You have the LOPA and the FMEA. Now you want the rules a machine follows to agree with the analysis you already did, instead of being written again from scratch and drifting from it.

What each worksheet is, in plain words

The three worksheets ask three different questions about a plant.

A HAZOP, a hazard and operability study, walks through a plant one part at a time. For each part the team applies guide words to a process parameter: high level, no flow, low pressure. For each deviation they write down the cause, the consequence, and the safeguards in place. It is a structured way of asking "what if this goes wrong, and what catches it."

A LOPA, a layer of protection analysis, is about counting. It takes a hazard and lists the independent layers of protection standing between the cause and the consequence, and does the arithmetic to check that enough protection exists. Each layer is supposed to be independent of the others and of the cause.

An FMEA, a failure modes and effects analysis, goes component by component. For each way a component can fail it records the effect, and often three scores: severity, occurrence and detection, multiplied into a risk priority number, or RPN.

All three end as rows in a document. None of them is something a machine can run. That is the gap quorum's importers cross.

What the importers do

quorum ships three importers, listed in the README's "Everything it does": hazop2cb, lopa2cb and fmea2cb. Each reads a worksheet and produces a draft rulebook, carrying through the source document so every rule can be traced back to the row it came from.

The HAZOP importer is the most developed. The quorum safety case, in docs/claims.tsv, describes it under HAZOP-1: hazop2cb reads an IEC 61882 worksheet, folds duplicate deviations into readings, and reports two things from the safeguards column. First, deviations with no protection at all. Second, deviations whose safeguard names the same instrument as the cause. The import fixtures live under casebook/fmea/; a search for HAZOP worksheets there turns up files such as hazop_worksheet.csv and a published hospital-oxygen study, hazop_oxygen_psa.csv.

The importers do not invent a finished rulebook. They extract what the worksheet actually states and leave the rest for a person. That restraint is the point of the next two sections.

The protection that only looks independent

The most useful thing the HAZOP importer finds is a protection that is not as independent as the worksheet makes it look. Here is a real row from the import fixture casebook/fmea/hazop_worksheet.csv:

The cause is that the level instrument LT-101 has failed. The safeguard, had there been one, would have had to rely on a reading. If it relied on LT-101, the very instrument that failed, it would be no protection at all. A row-by-row reading of the worksheet can miss this, because the cause and the safeguard sit in different columns and a tired eye reads each on its own.

The importer catches it by comparing the instrument tags. The safety case describes this as the shared-cause, or common-cause, detector. It finds the same tag, such as LT-101, appearing as both the cause and the safeguard. When a safeguard depends on the same instrument that fails, the protection and the hazard share a single point of failure. The safeguard is one layer wearing two hats.

The same idea appears in quorum's own pump rulebook. When cbc validates it, the protection-layer report notes that every route to the safe action runs through one accelerometer: one instrument, four diagnoses. That is the kind of thing a LOPA is meant to question, surfaced automatically.

The honest limit of the shared-cause check

This detector is useful, and it is important to be clear about what it cannot do. The safety case states the limit plainly under HAZOP-1: the common-cause detector is instrument-tag matching. It finds LT-101 written in both columns. It cannot find a shared power supply, a shared input card, shared control logic, or a shared calibration.

So the importer narrows the search for the engineer; it does not end it. It catches the shared instrument you wrote down. The shared cause you did not write down is still yours to find.

Why a draft is refused until it is finished

A worksheet records what fails. It does not record what would explain a reading away. The quorum safety case makes this the reason a draft is refused, under COMP-14: an FMEA can be imported into a draft, and the draft is refused until a human supplies the defeaters, with the report saying that nothing in it is defeasible.

That word, defeasible, is the heart of it. A rule is defeasible when something can argue against it: a benign explanation, a reason to doubt an instrument, a more serious conclusion. A worksheet row gives you the fault but not the argument against it. A rulebook made only of worksheet rows is a pile of hard rules with nothing to challenge them, which is a decision tree, not a reasoned judgement.

So the importer writes the draft, marks the missing pieces as to-do, and the compiler refuses to turn it into a chip image until the engineer has filled them in. The safety case notes that the importer cannot infer the defeaters itself, because an FMEA does not record them. That part is the engineer's contribution, and the refusal is what forces it to happen rather than being quietly skipped.

Why RPN does not translate, but severity does

An FMEA's headline number is the RPN, severity times occurrence times detection. It is tempting to carry it straight into the rules. quorum does not, and the README's "Honest limits" explains why. Severity translates, through quorum's preference ordering, because it describes how bad an outcome is for the one machine in front of you. Occurrence and detection do not translate: they are population statistics, how often a type of part fails across many machines, and they have no meaning for the single machine a device is attached to.

So the importer carries severity across and leaves RPN behind. A number that mixes a population failure rate into a decision about your machine would be worse than no number. This is a case of the tool declining to do something that looks convenient because it would not be sound.

Learning a first rulebook from records

There is a fourth path, and the README is careful about it. quorum can learn a first rulebook from past labelled records, under "Learning a casebook from records." It uses a method called AA-CBR on quorum's own solver, and writes out an ordinary rulebook that then takes the same full check as a hand-written one.

The honest part is the result. The README reports four pre-registered tests. Adding learning to an incomplete rulebook raised accuracy on average every time, but all four tests returned "not shown" against the bar set in advance, because learning gains nothing when the missing knowledge is redundant or cannot be expressed in the readings. The README's own summary is the one to keep: the case for learning in quorum is that it writes reviewable rulebooks faster and adds exceptions to rules a person reviewed. It is not that it is a better classifier. A learned rulebook is a draft to review, like any other.

What quorum does not do

The importers read what a worksheet says. They cannot judge whether the worksheet is right. If a safeguard named in a cell is uncalibrated, bypassed, or wired to a failed card, the worksheet looks the same, and the import looks the same.

They also cannot invent the missing argument. The draft is deliberately refused until a person supplies the benign explanations and the doubts, because those are the engineering judgement a worksheet does not contain. And once the draft is finished, it still has to pass the full check and, after that, the loop check on the real machine. The README notes no plant has done that last step yet. The importer gets you from a spreadsheet to a reviewable draft honestly. It does not get you to a running machine on its own. For what happens after the draft, see checking every situation and commissioning.