Extract text, tables and page evidence

What you get

Three layers of output, each one checkable against the original page.

• Text, page by page, with the reading order the layout stage found.
• Tables, as rows and columns rather than flattened text.
• Page evidence for every extracted field: the page number and the region it came from.

A field with no page evidence is a defect. That citation is what lets a person verify a value in seconds instead of rereading the document.

What you need

Six documents and a manifest. Mix the formats, because a set of clean digital PDFs will teach you nothing about the hard cases.

doc_id,path,page_count,doc_type
DOC-3001,contracts/msa-signed.pdf,14,contract
DOC-3002,contracts/amendment-1.pdf,3,contract
DOC-3003,invoices/inv-88214.pdf,2,invoice
DOC-3004,invoices/scan-fax.pdf,2,invoice
DOC-3005,reports/quarterly-tables.pdf,9,report
DOC-3006,contracts/locked.pdf,0,contract

Declare doc_id as your item_id_field. Document four is a low-quality scan, so it exercises the character recognition stage. Document six is password protected, so it should be refused at validation rather than returning empty pages.

Run it

1. Inspect locally: lithi inspect ./document-fixture. This reads page counts, encryption flags and whether a page carries a text layer at all.
2. Read the workflow: lithi workflow explain <workflow-id>, and read the output schema it declares.
3. Narrow the schema in your parameters. Ask for the six fields you actually need, with types, rather than everything the document might contain.
4. Quote it: lithi quote --workflow <workflow-id> --input ./document-fixture/manifest.csv. The quote states a maximum charge, and authorizes nothing.
5. Approve the quote separately, submit with lithi batch submit, then track with lithi status <job-id>.

A narrow schema is the single biggest quality lever here. A tight field list with types can be validated; a request for "key information" cannot: how output schemas are declared and validated.

Read the result

Open result-manifest.json, then check source integrity before reading any value.

provenance.json carries the input digest. Confirm it matches the snapshot you submitted, so you know which bytes were read. If your documents changed after you counted them, everything downstream is about a different set.

Then read the three cases that matter:

• Take four fields from data/part-* and open the cited page and region. The value must be visible there.
• Read the scanned invoice carefully. Recognized text should show lower lithi_confidence, and a misread digit is the failure mode to hunt for.
• Confirm the protected document is in failures/part-* with a typed code, a safe reason and a next action. An empty extraction reported as success would be far worse.

Check table structure separately from text. A table that lost a column reads plausibly and is wrong.

Where it stops

You get extracted values with citations. You do not get a legal reading, a decision, or a filing.

Nothing is written into a document management system, and no approval or payment is triggered by an extracted total. A person reviews the fields and commits them.

Recognition quality depends on the page. A faint scan will produce lower confidence and more abstentions, which is the correct behavior rather than a fault. Prepare inputs so the run reads exactly what you counted: how documents and media are accepted.