The model gets a verdict field and the person gets a signature field, and they never merge
The business had to check 362 pricing rules before trusting the system to quote with them. Their own rules, imported from their own spreadsheet, but repaired in places and rewritten in notation everywhere, so somebody who knows the trade had to look at each one and say yes.
Three hundred and sixty-two of anything, reviewed by the owner of a working fabrication business between other jobs, does not get reviewed. It gets started and abandoned around item forty.
The problem is not that they cannot judge a rule. They can, faster than I can. The problem is that there is no order to work in and no way to see progress, so the task has no shape.
What the screen actually shows
Each rule is presented on its own, with three things.
The rule itself — its steps, in order, with the expressions as written, and the material slots it draws on.
A sample price, computed by evaluating the rule against a set of representative dimensions and sensible default materials. Not a real quote. A plausible instance, so the reviewer sees a number rather than algebra.
And the review state: whether a person has signed this one off, and separately, what an automated pass thought of it.
The sample price is the part that makes review possible at all. A fabricator reading an expression has to simulate it mentally to know whether it is right. A fabricator reading a price for a 48-inch item in a common grade knows immediately whether the number is in the right region, because pricing that item is what they do all day. Give the domain expert an output in the units they think in, not an input in the units you think in.
The representative dimensions are a fixed table of plausible values per known dimension code — a typical length, breadth and height, typical shelf and bowl and door sizes, sensible counts for things counted — with a neutral fallback for anything unrecognised. It is entirely made up, and that is fine, because its only job is to produce a number a human can react to.
Two fields, not one
The automated verdict is stored in its own fields: a status, notes explaining the status, the sample price it saw, and the time it ran.
The human sign-off is a separate field, set by a separate action.
They never merge, and nothing derives one from the other. A rule that the automated pass marked verified is not signed off. A rule a human signed off does not become automatically verified.
This is the whole design decision, and it is worth being blunt about why it matters. The moment a model’s verdict can satisfy the same field a person’s signature satisfies, you have a system where nobody can tell, six months later, which of your 362 pricing rules were actually looked at by somebody who knows the business. That question will be asked, on the day a price is wrong, and “the system reviewed them” is not an answer anyone accepts.
Two columns also means you can measure the thing that decides whether the automation is worth having: how many rules it flagged, against how many a person then agreed with.
What the verdict is for
It is for ordering.
The list can be filtered to the flagged ones. That is the actual product feature — not “the AI checked your formulas”, but “start with these forty”. It converts an unordered pile of 362 into a short queue and a long tail, and a short queue is a task somebody finishes.
It changes no price. It writes nothing to a rule. It cannot mark anything as approved. Its entire authority is over the order in which a human looks at things, and that is a category of authority where being wrong is cheap: a false flag costs one unnecessary look, and a missed problem is no worse than the situation without any automation, which was no review at all.
Give a model authority over attention, not over outcomes. The failure mode of misplaced attention is wasted time. The failure mode of a wrong outcome in a pricing system is an invoice.
Fix it where you found it
The other thing that mattered was the workflow around a flag, which is easy to get wrong by building a review screen and an editing screen that do not know about each other.
The rule editor was made embeddable, so it opens directly inside the verification screen as a full editing surface with its own test facility. A reviewer who spots a problem edits the rule and tests it there, and on save the verification view re-synchronises so the reviewer sees the state they have just created.
Without that, a flagged rule means leaving the review, navigating to the editor, finding the rule again, fixing it, and coming back to a list that has lost its place. That friction is what stops people at item forty, not the difficulty of judging a formula.
Where this is weaker than it looks
The sample price is computed on invented dimensions. For most rules that is a fair test. For a rule whose behaviour changes with size — and some of them branch on width — a single representative instance exercises one branch and says nothing about the others. A rule can look perfectly sensible at the sample size and be wrong at every other size.
And the value of the automated pass depends entirely on its flag rate. Flag a tenth and it is a queue. Flag half and it is the original problem with extra steps. That ratio is a property of the data and the prompt, not something the design guarantees, so it has to be watched rather than assumed.
Neither of those undermines the structure. Both mean the structure is doing less than a reader might assume from the words “AI verification”, and it is better to say so.
The rule
When you put a model in front of a body of work a human must approve, give it a column of its own, never the approval column. Let it decide what gets looked at first and nothing else.
Then show the human an output they can judge in their own domain — a price, a rendering, a result — rather than the artefact that produced it, and put the means to fix it on the same screen. Review tools fail on friction far more often than on judgement.