Module 02 · reading the paperwork
Extract
Any document in, typed fields out — with a pointer to where each fact came from.
Priya uploaded four documents: her RC, the policy, the garage estimate, the invoice. To a human reviewer that’s twenty minutes of squinting. Extract’s job is to make the paperwork machine-readable in seconds — not by "understanding documents" in the abstract, but by answering exactly the questions the pack’s schema asks.
What we're going to build
Schema-driven extraction
The pack defines document schemas — the entities and fields that matter (policy number, dates, line items, amounts). Extract returns only what the schema asks for. A health pack asks different questions of different documents; the engine does not change.
Model bindings via the gateway
OCR and vision-language models are commodities we route to through the Model Gateway — swappable, versioned, benchmarked per pack. We do not marry a vendor.
Confidence + provenance per field
Every extracted field carries a confidence score and a source span — the exact region of the page it came from. Provenance is what makes a downstream fraud flag defensible.
Structured-table handling
Estimates and invoices are line-item tables; totals must reconcile with their rows. Table extraction is a first-class capability, not an afterthought — one of our moat checks ("estimate total differs from its line items") depends on it.
Correction loop
When a human fixes a field in the Review Console, the correction is stored as a label against that document type and model version. Extraction accuracy is designed to be measured and published per pack (Phase 2+).
For engineers & architectsimplementation notes
- Schemas are JSON Schema-ish pack artifacts, versioned in the Pack Registry; an extraction result is invalid unless it validates against the schema version it claims.
- All model calls go through the Model Gateway with a per-pack binding (model, prompt, fallback chain); swapping vendors is a binding change plus an eval run, not a deploy.
- Source spans are stored as page + bounding-box against the content-addressed artifact — the Review Console renders corrections directly on the page image.
- Failure modes: low-confidence fields degrade to
needs_review signals rather than guesses; table reconciliation mismatches emit their own signal (Detect feeds on it).
Open questions — for the room
- First document set: RC + policy + estimate + invoice — is FIR in or out for Phase 1?
- OCR vendor vs VLM-first: which is primary, which is fallback?
- Handwriting: how common is it in our pilot insurers’ paperwork, and do we defer it?
- Correction UX: who at the client corrects fields — their ops team or ours during pilots?