Home › Our work › Contract Reviewer
Our work / Contract Reviewer
Reading a purchase order the way a quality engineer does
Every purchase order from an aerospace customer carries a short list of codes that quietly change how the part must be made, inspected and documented. Missing one is expensive. We built an application that finds all of them and shows you the page it found them on.
What a quality clause actually costs you
A purchase order arrives with a line that reads, in effect, Q10E, Q20B and Q30C apply. Three short codes. Behind them sit paragraphs in a supplier quality manual that may require a first-article inspection, a certificate of conformance, source inspection before shipment, or domestic-only sourcing for a raw material. Each one moves cost, lead time or both.
Today a quality engineer reads the PO, 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 faxed PDF that nobody saw, or a clause looked up in the wrong revision.
The doctrine we built it on
Before any code was written we agreed 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 a PO that cites an older revision is still read against that older revision. Reproducibility depends on it.
The previous human review is a reference. The system reviews the PO independently first, then compares its findings against the historical checklist. That ordering is what lets the comparison mean something.
Reading the document twice
Scanned POs defeat single-method extraction, so every page is read two ways and the two readings are compared. One reader takes the text layer, or runs OCR where there is none. The second reader is a vision model that looks at the rendered page in horizontal bands, 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. Checkbox state gets the same treatment: measured by ink density against the printed square, cross-checked by the vision model, and 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 this customer and this part number in prior orders. It is a database query, deliberately, so the answer is reproducible and auditable.
What comes out
A review page for the PO: 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 form, 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 PO cites a customer 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. One customer writes Q10E, the next writes
something else entirely. 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. Federal FAR and DFARS clauses are recognised universally, and classified as
commercial terms, a distinction the paperwork itself often blurs.
How we measure it
Against a gold-standard set of POs, 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.