Reference build · Evidence-first document AI

Document extraction where every retained value points back to the source.

A working reference for extracting delivery notes and work orders into a closed schema while preserving exact evidence, deterministic checks, and human approval before export.

FieldDoc comparing a source delivery note with extracted fields and exact evidence
Working reference using fictional document content; proposed values remain subject to human review.
Proof type
Reference build
Audience
Agencies and operations teams evaluating document workflows
Timeline
Reference build reviewed in July 2026; no client rollout or processing-volume result is claimed.
Last reviewed

01 / Buyer and problem

The system had one clear job—and explicit limits.

Document models can return plausible fields that are absent, ambiguous, or inconsistent with the source. A usable workflow needs to preserve the original, remove unsupported values, surface deterministic conflicts, and block export until review.

Who this helps

The reference is designed for document processes where a proposed value must remain traceable to the original and a person owns final approval.

Exact role

Designed and implemented as a working reference build, including the Astro review interface, same-origin API contract, closed-schema extraction, server-side evidence validation, deterministic checks, local fallback, and tests.

Constraints

  • Treat the document as untrusted input and never follow instructions embedded inside it.
  • Require each populated field to retain an exact source excerpt; clear values that cannot be located.
  • Validate one closed schema, cap input at 8,000 characters, and keep API credentials server-side.
  • Keep line items in review and block approved export until the person compares the proposal with the source.

Scope

  • Delivery-note and work-order intake
  • Closed-schema model output
  • Exact-substring evidence validation
  • Deterministic totals and duplicate checks
  • Hostile-instruction handling
  • Human review and reviewed JSON export

02 / Architecture

A visible path from input to controlled result.

  1. 01

    Bounded intake

    Same-origin, content-type, length, rate, and consent checks guard the request.

  2. 02

    Closed extraction

    The model can propose only the declared document, field, line-item, warning, and summary structure.

  3. 03

    Evidence post-validator

    Unsupported values are cleared instead of being completed by inference.

  4. 04

    Deterministic rules

    Totals, duplicates, type conflicts, and injection-like content are handled outside the model.

  5. 05

    Human-controlled export

    Reviewed JSON stays locked until every retained value keeps evidence and the person confirms comparison.

03 / Delivery process

The work, in the order it became verifiable.

  1. 01

    Confirm bounded processing

    The person removes unnecessary sensitive data, confirms one-time processing, and submits a length-limited document.

  2. 02

    Extract to one schema

    The server treats the document as untrusted content and requests a constrained structured proposal.

  3. 03

    Validate exact evidence

    A post-validator clears populated values that cannot point to a literal excerpt in the submitted source.

  4. 04

    Apply deterministic checks

    Totals, currency conflicts, duplicate input, document type, and hostile instructions produce visible rules-based warnings.

  5. 05

    Review before export

    The person compares and corrects the proposal; unsupported edits remove evidence and keep approval locked.

04 / Decisions and tradeoffs

The useful part is why the boundary exists.

01

Treat model output as a proposal

A structured response is not evidence that a value exists in the source.

Tradeoff
The workflow requires review and may clear fields a person could otherwise infer.
02

Keep validation deterministic where rules are available

Arithmetic, exact evidence, type headers, and duplicates can be inspected without another model judgment.

Tradeoff
Rules must be maintained as supported document formats evolve.
03

Require explicit processing consent in the reference

The interface makes the external processing boundary visible before text reaches the project API.

Tradeoff
The extra step adds friction and is not a substitute for a complete production privacy review.

05 / Evidence

What can be inspected—and what cannot be claimed.

Input boundary
8,000 characters

The interface and project API document the maximum submitted text length.

Prepared tests
3 document scenarios

The public reference includes a clean note, an ambiguous work order, and a hostile-instruction sample.

Evidence contract
Exact source excerpt

A populated field without matching literal evidence is cleared or returned to review.

Commercial result
Not claimed

No accuracy rate, processing-time reduction, cost saving, document volume, or client outcome is presented.

06 / Outcome and handoff

A working document-review reference that keeps source text, proposed fields, exact evidence, warnings, corrections, and approval in one inspectable flow.

Services connected to this work

Technologies used

  • Astro
  • TypeScript
  • Node.js
  • OpenAI API
  • Zod
  • Deterministic validation
  • Playwright

Evaluating document automation?

Start with the evidence and approval contract.

Bring one de-identified document shape, the fields that matter, and the errors a reviewer must be able to catch.

Book a 20-minute fit call