Home › Our work › Contract Reviewer
Our work / Contract Reviewer
Reading a purchase order the way a quality engineer does
Purchase orders in regulated manufacturing carry a short list of codes that quietly change how the part must be made, inspected and documented. Missing one is expensive. We build applications that find all of them and show you the page they were found on.
What a quality clause actually costs you
A purchase order arrives with a line saying, in effect, that three short clause codes apply. Behind them sit paragraphs in a supplier quality manual that may require a first-article inspection, a certificate of conformance, inspection before shipment, or a restriction on where a raw material may come from. Each one moves cost, lead time or both.
Today a quality engineer reads the order, looks each code up in the customer’s manual, decides whether it covers the whole order or one line item, and fills in a review checklist by hand. It is careful work done under time pressure, on scanned documents, against manuals that get revised quietly. The usual failure is a code on page two of a poor scan that nobody saw, or a clause looked up in the wrong revision.
The doctrine we build it on
Before any code is written we agree a set of rules the system is forbidden to break. They are unusual for an AI product, and they are the reason a quality department will accept the output.
The customer’s document is authoritative. Every clause keeps its exact wording, verified as a literal substring of the page it was read from, alongside a separate plain-English interpretation. The interpretation can be wrong and can be corrected. The source text stays untouched.
No requirement without evidence. Each one carries the document, its revision, the page number and the excerpt. The reviewer clicks a requirement and lands on the rendered page it came from.
Revisions stay separate. A newer revision supersedes the older one for lookups, and an order that cites an older revision is still read against that older revision. Reproducibility depends on it.
A previous human review is a reference, not an input. The system reviews the order independently first, then compares its findings against the earlier checklist. That ordering is what lets the comparison mean something.
Reading the document twice
Scanned orders defeat any single method of extraction, so every page is read two ways and the two readings are compared. One reader works from the text. The second looks at the page as an image, which is how it picks up what text extraction loses: a hand-ticked checkbox, a stamp, a code written into a table cell, a note in the margin.
Where the two readers agree, confidence is high and it is recorded as such. Where they disagree, the disagreement itself is surfaced to the reviewer rather than resolved silently. Checkbox state gets the same treatment, and is flagged whenever the two readings differ.
Routine, unusual, or new
Knowing that a clause applies is half the answer. The other half is whether it is normal for this customer and this part. A clause that shows up on every order is a process you already run. A clause that has never appeared before on this part is the one that deserves a second look before the order is accepted.
The system computes that from history, by counting how often the code has appeared for that customer and that part in prior orders. It is a database query, deliberately, so the answer is reproducible and auditable.
What comes out
A review page for the order: the line items, a summary of findings in plain language, an explicit exceptions section, and the full requirement list with scope, routine status, source document, revision, section and page for each. Alongside it, the customer’s own contract-review checklist, pre-filled from the review, with every pre-filled tick explaining on hover where it came from. Initials, dates and signatures are left blank, because a person signs the review.
It also names what it could not check. If the order cites a document that has never been uploaded, that is reported as a gap, so the buyer can be asked for it.
Built to take a second customer
Clause-code formats are a house style: every customer writes them their own way. The system reads each customer’s own documents, works out the shape their codes take, and then verifies that shape deterministically. Adding a customer is a configuration exercise rather than a rebuild. Standard contract clauses that appear industry-wide are recognised as such and classified as commercial terms, a distinction the paperwork itself often blurs.
How we measure it
Against a gold-standard set of orders, we measure clause recall, clause precision, applicability accuracy, source accuracy (right document, right revision, right page) and, above all, the false-confidence rate: how often the system stated something confidently and was wrong. That last number is the one we optimise against hardest, because in a quality function a confident wrong answer costs more than a blank.