Can an AI draft safety rules from a manual? A fair test on four regulations

In one minute

• quorum can ask an AI model to draft a rulebook from an equipment manual. The model only proposes. A person must approve.
• Every rule the model keeps has to quote the manual word for word. A rule it cannot back with a quote is thrown out.
• The draft is marked unapproved, and no chip image can be built from it until a named person signs it off.
• On four regulations the model had never seen, scored against a key written before any run, it passed 116 of 135 checks (86%).
• That says the draft is a useful first pass. It does not say a draft can go to a machine without a person, and nothing in quorum lets it.

Who this is for

This guide is for an engineer deciding whether an AI is any help in turning a manual or a regulation into safety rules. The honest answer is that it can save you the first draft, and it cannot be trusted to finish. This guide shows the test behind that claim and what the draft got wrong, so you can judge for yourself.

A rulebook is a set of rules for a small machine, written in plain words. Drafting from a manual means handing an AI model a document and asking it to propose a rulebook. Everything below is in the quorum repository, in the files named as you go.

The rules the drafter must follow

An AI that writes plausible text is not the same as an AI you can trust near a machine. quorum puts four guards around the drafting, so the output is a proposal a person can check, not an answer.

Every rule must quote the manual word for word. A rule the model keeps has to carry the exact sentence from the manual it came from. If it cannot quote the manual, the rule is dropped. This lets a reviewer check a draft against the source line by line, instead of trusting the model's summary.

The draft is marked unapproved. The draft opens with a large UNAPPROVED mark, and quorum will not build a chip image from it. After you have checked every rule against the manual, you type your name and press Approve. The every-situation check still runs. Approval skips nothing.

The review lists first everything that could stop the safe action. The safe action is the one declared as safe in the rulebook, such as shutting a pump down. The review puts those rules at the top, because a rule that wrongly blocks a shutdown is the one that can hurt someone.

Hosted models are asked to keep no copy. You can run the model on your own computer, in which case nothing leaves it. If you use a hosted service, the manual is sent to it, so quorum asks you to allow that first and asks only for providers that keep no copy and do not train on it. This is called zero-data-retention.

The fair test

An easy way to make a model look good is to tune the prompt on the same documents you then score. This test was built to avoid that. The protocol is in the quorum repository, in the eval README.

Four public-domain US federal regulations were chosen from the eCFR, with only the markup removed:

The protocol was fixed before any model saw the documents. The answer key and the scorer were committed first, and the prompt and drafting code were frozen at that commit, unchanged between runs. Each document was drafted five times, at temperature zero, with the studio's defaults and no second opinion. The model, as stated in RESULTS.md, was Claude Sonnet 5.5 through OpenRouter, using zero-data-retention providers only. Every run was scored by the draft's behaviour, not its names, so even a draft the compiler refused could still be scored.

The scores

Twenty runs in all, from RESULTS.md:

The 86% is checks passed against a key written in advance. The last column is a separate question: did the compiler accept the draft as written, with no edits. Those are different bars, and the draft clears the first far more often than the second.

What it got right

The hardest thing in these documents is telling a shutdown apart from an alarm for conditions that read almost the same. The drafter got this right on documents it had never seen. In document A, four alarm-only conditions were drafted as alarms in all 20 cases, including "reduced lubricating oil pressure" as an alarm beside "low lubricating oil pressure" as a shutdown, and "excessive speed" beside "overspeed". The conditional exception held too: with antifriction bearings fitted, low oil pressure became alarm only in all five runs. In document B, no draft ever invented a shutdown for steering gear, which the regulation forbids, in all five runs.

What it got wrong

The misses are as important as the hits, and RESULTS.md lists them plainly.

• A remote manual shutdown device was missed in document A, in 4 of 5 runs. It is a single sentence that names a device, not a condition.
• A monitoring exception was missed in document D, in 4 of 5 runs. A clause letting the belt keep running if a trained person watches it became a monitoring action, not an exception.
• The flame safety system in document C is disputable. In 2 of 5 runs the drafter treated it as alarm only. The key says the rulebook should shut down. A reader could reasonably read the clause the other way.
• Design rules were drafted as run-time rules in document A, in 3 of 5 runs. Requirements about where an exhaust or air inlet must sit became readings and alarms. Those are not conditions a running machine senses. A person must delete them.
• Document D had too many actions. The drafts declared one action per duty in the regulation, such as notify, investigate and patrol. Many could never be chosen, which is why the compiler refused 4 of 5. A regulation about what people must do is a poor fit for a rulebook about what a machine must do, and the drafter does not say so.

The compiler's refusals, and the repair

The compiler accepted 9 of 20 drafts as written. All five steering drafts in document B were refused for one reason: nothing in them could argue with any claim. A regulation with no exceptions produces exactly that, and such a rulebook cannot tell a dead sensor from a quiet machine. This is the case quorum's failed-sensor repair is for. After the repair, all five passed the compiler, with unchanged scores of 39/40. The other refusals were for unreachable actions and, in one document A run, two actions chosen at once. Those are mistakes a person must fix, and the review says where.

Two things about the scoring, reported honestly

RESULTS.md is careful about its own numbers, and so should this guide be.

One scorer bug was fixed after the runs. One check in document C was implemented more strictly than the key defines it. It was fixed to the key's own definition. Before the fix, document C scored 13/20 and the total was 112/135. The 116/135 above is after that fix.

One post-hoc reading is reported apart, and is not in the table. In three drafts of document A, the overspeed reading cites a heading instead of the two-word item, so the pre-registered rule cannot find it, and two checks fail. In all three the reading is named overspeed and does shut the turbine down. Matching by name as well raises document A to 46/50 and the total to 122/135 (90%). The table keeps the pre-registered number, and the higher one is reported separately so it cannot quietly inflate the headline.

What quorum does not do

This is one model, on four short documents, over twenty runs, scored by a key the same people wrote. It is a fairer test than the earlier ones, because the key and the code were fixed before any run. Still, the documents were chosen by the people who wrote the prompt, and a different reader would change some lines of the key.

The 86% says the drafter is a useful first pass on regulations of this kind. It does not say a draft can go to a machine without a person, and nothing in quorum lets it. A draft is a proposal. It is marked unapproved, it must pass the same every-situation check as a hand-written rulebook, and no chip image exists until a named person approves it. To see how turning worksheets into rules works, and how the checker is itself checked, the other guides carry the detail.