Operating model

People check the result, and the pipeline does the reading.

This page shows who does what around {{product.name}}. The roles come from how the product runs. [Replace: confirm them against how your team will operate it.]

Book a session See how it is built

Reading is fast, so trust has to come from the evidence.

A model can read a scan in seconds. A team relies on it only if it can check each value. {{product.name}} keeps the proof beside the answer.

{{product.name}} narrows the gap by putting the source pixels next to each value. The chart is illustrative, not measured.

Three shifts change how document work is checked.

Keying values from scansChecking values against the page

Trusting a confident answerSeeing where the answer was found

Re-reading whole documentsChecking the fields the pipeline could not find

The reviewer stays in charge of the result.

{{product.name}} proposes values and shows the evidence. A person decides whether to rely on them.

Open a document and see its fields beside the page.
Click a value to see the box it came from.
Look harder where grounding is weak or missing.
Remember that confidence means grounding only, not correctness.

Six habits keep the results trustworthy.

Point, do not assert.

Every field carries a page and a box. A value that cannot be found is recorded as not found.

Measure before you claim.

Both modes are scored on the same 158 real documents.

Say what is unvalidated.

Bundle splitting has no score of its own, so check splits by eye.

Record failures.

Unparseable model JSON is stored as a failed outcome and is never resampled.

Publish the score you have.

The last measured field-F1 was 0.312 on an earlier checkpoint, and every result carries a low-quality warning until that is re-measured.

Make operations explicit.

Start, stop and release of the GPU are separate commands, so nothing is left running by accident.

Four groups share the work around {{product.name}}.

Owner

The owner decides which document types go live and which mode is the default. [Replace: the owning team.]

Review

Reviewers click a value and check it against the ink on the page.

Intake and operations

Submitters upload scans. Operators run the stack, watch the queue and decide when to restart the model server.

Evaluation

The team measures field-F1 on a real 158-document set and re-tests the model as new checkpoints arrive.

Each role has a clear job.

Using {{product.name}}

PersonSubmitter

Uploads PDFs or page images and watches the job progress.

PersonReviewer

Checks each value against the box on the page.

PersonOwner

[Replace: who owns the product and what they decide.]

Running {{product.name}}

PersonOperator

Starts and stops the stack, watches queue depth and GPU memory, and decides when to restart the model server.

SystemPipeline workers

Render, OCR, extract and ground each job without human input.

Improving {{product.name}}

PersonEvaluator

Runs the 158-document evaluation and compares the two modes.

PersonDeveloper

Maintains the field contract for 13 document types and the grounding stage.

SystemModel server

Holds one model at a time and cannot serve both modes together.

Getting started

Three steps take you from a demo to a measured run.

Step 1 Try the interface.
The interface runs on built-in sample data with no backend, so you can see a field linked to its box.
Step 2 Run the stack.
Bootstrap a GPU server and start the fine-tuned model.
Step 3 Check the timing.
Reproduce the end-to-end run with the e2e script and read the result for yourself.

The queue scales out, and the GPU sets the limit.

Claiming uses SKIP LOCKED, so more workers can join the queue.
Up to four documents in a bundle are extracted at once, so a bundle costs about its slowest document.
One GPU holds one model, so keep the model server resident between runs.

Talk to the team about your documents.

Tell us which document types you process and we will show you what {{product.name}} returns.

Book a session