The only real check was one person's memory
A job gets sold on one document and bought on a stack of others. Somebody then has to confirm that the two describe the same job, before anything is made and while it is still cheap to be wrong.
On the engagement described here, that reconciliation carried real money and the only thing making it reliable was one person who had done it long enough to see what was wrong. The knowledge was not in a manual and it was not in their software. It was in one head, and until now it had never needed to be anywhere else.
That is the shape most of these enquiries arrive in. Not “we want AI”. Closer to: the checking works, it works because of one person, and it does not survive that person being busy, on leave, or gone.
The condition worth testing before anyone quotes you
The documents here were already digital, already structured the same way each time, and already checked by a person against a consistent standard. Those three things are what made the work possible. Where the check is genuinely improvised each time, there is nothing for a system to learn from, and the answer is that it is not ready, not that it needs a bigger model.
Twenty-seven rules, and every one arrived as a correction
Getting that knowledge out of one head took six weeks, and it did not arrive as a list. Nobody can write down what they know by being asked to. It arrived as arguments about specific findings.
The reviewer would be shown something the checks had flagged, and would write back explaining why it was not a problem. Each of those replies became a rule. There are twenty-seven of them. A sample, because the specifics are the whole point:
- A single frame part can serve two desk positions, so a count that looks short is not short.
- Drawings three months old and stamped PRELIMINARY are normal on a live job. Flagging them is noise, not diligence.
- Orders raised against the firm's own install team do not need checking at all.
- Arithmetic errors on an order are real, and nobody acts on them, because the sign-off that would catch them happens somewhere else entirely.
The last one is the most useful sentence on this page. A finding can be completely correct and still worth nothing, because being right is not the same as being worth somebody's attention. No model works that out on its own. It is a fact about how that business is run, and the only way in is to be told.
The traffic ran the other way too. One check nobody had thought to ask for turned out to matter more than most of the ones that had been: nothing compared an order's required-by date against the install date. On one real job, two orders were due to arrive after the install, one of them by a month.
Image not yet supplied
The rules table as the reviewer sees it: twenty-seven rows, each one readable, with the finding it was written against. The readable-by-the-client part is the point, so do not crop it to a developer view. Must be anonymised: no client or supplier name, no job number, no figure.
The model reads the documents. A person still decides.
What runs today reads the uploaded documents, applies the checks, and writes what it finds into a list with a severity against each item. A person works that list. Nothing is approved, rejected or sent by the system.
The layer that could judge is switched off
There is a second layer that reviews a whole job at once rather than checking line against line. It has never been allowed to decide anything. It has run in shadow mode since July 2026, where its output is recorded and measured and nobody sees it as a finding, and the numbers below are why.
An override annotates. It does not silence.
When a reviewer overrules a finding about a physical limit, the check is not switched off for that job or any other. It fires again on every future job and the override is attached to it as a note. The reason is simple: the condition that made the check fire once is usually still true, and a check that can be permanently dismissed by whoever is in a hurry stops being a check within about a month.
The override log is insert-only and carries a tamper-evidence hash. Entries can be added and cannot be quietly revised. That is worth having for a reason that has nothing to do with distrusting anybody: when a job goes wrong six months later, the question is always what was known at the time.
Alongside it sits an admin page listing what the checks are known to miss, kept deliberately visible rather than filed. Two people hold logins to any of it.
Image not yet supplied
A single finding as the reviewer receives it: the severity, the two document values that disagree, and the rule that produced it. One finding at full size, not a list view. Must be anonymised: no client, supplier or job identifier, and no figure.
Its first confident findings were wrong
Three failures, and each one has a different lesson in it. They are here at the same length as everything above, because a page that showed only the working half would be the kind of page this site exists to argue against.
It was confident, and it did not understand the drawing
A height mismatch was rated critical. The sold document gave a height of 1350. The orders gave 650 and 740. Nothing was wrong with any of them. Heights on the sold document are measured from the finished floor and accumulate up the assembly, while an order states only its own component, so the same object is described by different numbers in the two places and always will be.
The client found that one, not us. Their reviewer wrote back and explained it. The same class of error recurred twice more. A base recorded at 450 across was flagged critical twice; it is a 390 drum with a 450 lip, and both numbers are correct measurements of different parts of the same object. A page we called a duplication was deliberate, re-attached so the powder coater could identify the parts.
It stopped early and the output looked finished
The whole-job layer hit its output limit part-way through and returned a partial list of findings that read exactly like a complete one. Nothing in what it produced said it had stopped. There is no way to see that by reading the output, which is the entire problem.
It was caught by a check that re-runs the whole thing against jobs the reviewer had already marked, and compares the two. Recall came back at two of nine. After the fix, measured recall on a real job was twenty-two per cent, with seven false positives. That is why the layer is still in shadow mode, and it is the number we would want a buyer to ask us for.
For weeks the demonstration and the production system were different things
For several weeks the automatic path from upload to review was a stub that logged and did nothing. The client did not notice, because a person was running the checks by hand and the findings arrived as usual. Ours, entirely: the thing being shown and the thing running in production were not the same thing, and only one person knew.
Image not yet supplied
An override recorded against a finding: the note, the reviewer, and the same check still firing on a later job. Two rows if necessary to show the recurrence, since the recurrence is the point. Must be anonymised: substitute the names and job identifiers.
What we cannot tell you about the quoting week
The brief for this page asked what changed about the quoting week, in hours a reader would recognise. We do not have that number. We have not measured the time this takes before and after, on this job or any other, and an estimate assembled now would be a guess wearing a measurement's clothes.
What that leaves is a page that can tell you what this system gets wrong more precisely than what it gets right. For a sales page that is the wrong way round. For a decision it is the right way round, which is why it is the shape we chose.
The same discipline applied to the platform underneath it, including the parts of that we have not finished, is on the security page and is worth reading before you decide anything.
Ask us this, and ask anyone else the same thing
Not whether the system finds errors. Ask what it got wrong, who found out, and what happens now when it is wrong again. A supplier who cannot answer the third part has either not run anything in production or is not telling you about it.