01Declare your document types once
Your vertical's taxonomy, with which types are required. A classifier tags every incoming file and routes anything uncertain to a human.
PolicyEstimatePhotoPolice_ReportProof_of_Loss · required
Document-heavy operations
Your people read documents your software should read
A claims adjuster opens five documents to fill in eight fields. A contract reviewer scans a data room against a deadline. A support agent reads six runbooks to answer a question that was already answered last March. The answer is always in there — someone just has to spend an hour finding it, and then retype it into a form.
One run over a five-document homeowner's claim: evidence pinned on the left, schema-validated output on the right, every finding carrying the document it came from — and the two required documents that never arrived, named before review starts.
Sound familiar?
Senior people doing extraction
The same handful of fields gets copied out of every file by someone you hired for judgment, not for typing. The judgment takes four minutes. Finding the numbers takes the other fifty.
Half the work is chasing what isn't there
The signed proof of loss that never arrived. The contractor's license number. Nobody notices the gap until the claim is already three days into review and the deadline moved.
Two reviewers, two answers, no trail
The same claim gets read twice and produces different conclusions. Ask either reviewer why six months later and the honest answer is that they don't remember.
Why the usual fixes don't move the number
A chatbot on your documents
It answers in paragraphs. The work is a form with fields, a decision, and a next action — so a person still reads the paragraph and retypes it into the system of record. You added a step and moved nothing. An agent that only produces prose is a chatbot; vertical software produces structured output.
OCR plus templates and regex
It works beautifully until a carrier changes a form, a vendor sends a scan instead of a PDF, or a new document type appears. Then it fails silently, which is worse than failing loudly, and an engineer owns a rules file forever.
Generic RAG over everything
Top-k retrieval optimises for the most relevant passage. It is structurally incapable of telling you what is absent — and absence is most of what review is looking for. Nothing retrieved reads the same as nothing required.
Hiring more analysts
Cost scales linearly with volume, quality varies by who picked up the file, and the knowledge of how a good review is done stays in people's heads and leaves when they do.
How we solve it
02Define the task, not the prompt
A named unit of work with a JSON Schema output contract and deterministic acceptance checks. Fails the schema, fails the run — never returned as a nice try.
findingcitationseveritycoverage: covered | excluded | review
03Every execution is a reviewable record
Evidence pinned by content hash, blueprint version, cost, and the reviewer's decision. One click turns a correction into a training example and a regression test.
content_hash: 4c1f…a90bblueprint v2.1reviewer: approved→ eval case created
What you get on every document
Structured output
Typed fields that validate against the task's schema and land in your system of record without a human retyping them.
The missing list, free
Required document types that never arrived, named before the file goes into review instead of after.
A citation per field
Every extracted value points at the document, page, or photo it came from. Verification is a click, not a re-read.
Corrections that compound
A reviewer's fix becomes a golden example and an eval case. The system gets better at your documents, not at documents in general.
