From documents to governed data: inside the Documents module

An invoice arriving by email, a scanned contract, a form filled in by hand: most of a company's operational data is born in documents. And in most operations, that is where it stays: someone opens the PDF, finds the amount, types it into another system and files the original away. The data exists, but nobody can prove where it came from — and once a model does that work for you, the question stops being academic.

BiVelio's Documents module targets exactly that gap: it turns unstructured business documents into validated, evidenced, actionable data inside the customer's governed operation. This article walks through the full pipeline —ingestion, OCR, extraction with evidence, human review and governed automation— and dwells on the design decision that holds it together: every extracted value must be traceable back to the document it came from.

What the Documents module is

Documents is the BiVelio module that turns unstructured business documents —invoices, contracts, forms, scanned mail— into validated, evidenced and actionable data inside the customer's governed operation.

It is not "another OCR tool." OCR produces text; an operation needs data: the amount on this invoice, the due date in this contract, the IBAN on this form — each with its provenance, ready to feed a case or a workflow. The Documents pipeline has four stages, and all four share one principle: nothing enters the operation without being able to explain itself.

1. Ingestion and OCR, with the original preserved and versioned.
2. Field-level extraction, where every value carries evidence and a confidence signal.
3. Human review of anything doubtful or conflicting, with the evidence in front of the reviewer.
4. Governed automation: validated data feeds cases and workflows under permissions, audit and human gates.

Ingestion and OCR: the original is preserved and versioned

Everything starts with the document exactly as it arrived. Documents ingests it and runs OCR on BiVelio-controlled infrastructure, and the original is preserved and versioned: it is not discarded after extraction, and it is not replaced by its transcription.

That decision is not a storage detail: it is the foundation of everything else. The original is the ultimate evidence. Every claim the system makes afterwards —"the amount is this", "the date is that"— must be pointable at that original. If the document changes (a corrected version, an annex), versioning keeps the full history: what was extracted, from which version, and when.

Field-level extraction, with evidence

This is the heart of the module. Extraction does not return a blob of text or an opaque JSON: it returns fields, and every extracted field carries three things:

• The value ("€1,240.00", "2026-09-30", an IBAN).
• An evidence locator: where in the document it came from — the region or snippet of the original that supports it, pointable and verifiable.
• A confidence signal: how much the system trusts its own reading.

The value-in-OCR gate: a model cannot invent a value

Language models have a well-known failure mode: confidently filling in what is not there. A naive extractor would accept that invented value as long as it arrived with high confidence. Documents puts a guard in the way: a value that cannot be traced back to the OCR-recognized text is rejected. The model may propose; only what exists in the document may enter. An invented value does not become operational data — it becomes a rejected field that, if needed, escalates to a person.

Why evidence beats bare confidence

A confidence percentage, on its own, is not verifiable: you can only believe it or not. Evidence changes the deal entirely.

The human review console

Not every field comes out clean, and the module is designed on that assumption. Low-confidence fields, values rejected by the value-in-OCR gate and fields that conflict with each other queue for human review in a dedicated console.

Review does not mean reading the whole document again. The reviewer sees the extracted value side by side with its evidence —the snippet of the original that supports it— and decides: confirm, correct or discard. The correction does not stay in the console: it flows back into the case record, so the operation always works with the corrected value and a trace of who corrected it.

This is the same principle we develop in Human-in-the-loop: 5 components, not an approval button: human review is not a patch for when the AI fails, but a design principle. Documents does not try to hide its doubtful cases; it is built so that they reach a person with everything needed to decide quickly.

Governed automation: from validated data to the case

Validated data sitting in a table is worth nothing. The fourth stage connects the output of Documents to the operation: validated data feeds cases and workflows, under the same rules that govern the rest of BiVelio — permissions over who sees and uses what, an audit trail of every action, and human gates on critical steps.

The result is that the data never travels alone: it travels with its evidence and inside a framework of authority. How that framework is articulated —which layer remembers, which diagnoses, which executes— is covered in A single agent fails: governed AI in 3 layers. On the product site, Documents appears as a platform solution and as the heart of the document management use case.

Limits: what Documents does not solve on its own

An honest article about document extraction has to say where automation ends. Some documents still need human eyes:

• Handwriting, where recognition remains unreliable.
• Poor scans: low resolution, stains, skewed pages.
• Ambiguous layouts, where it is not even clear which cell belongs to which concept.
• Genuinely ambiguous fields: when the document itself admits two readings, no extractor should choose for you.

The difference is not that Documents avoids these cases: it is that it is designed so that exactly these cases reach a person, with the evidence in front of them, instead of turning into silently wrong data. A system that automates everything hides its failures; a governed system routes them.

FAQ

Does Documents eliminate human review?

No, and it does not try to. It narrows review down to the fields that need it —low confidence, conflicts, values rejected by the value-in-OCR gate— and makes that review fast: the value and its evidence, side by side. Human-in-the-loop is a design principle of the module, not a plan B.

What does it mean that a value "carries evidence"?

That besides the extracted value, the system stores a locator pointing to the region or snippet of the original document it came from, together with a confidence signal. Anyone with permission can open that evidence and check the value against the original, without reprocessing anything.

What happens with a handwritten document or a bad scan?

It reaches a person. Handwriting, poor scans and ambiguous layouts remain human-review territory, and the module is designed to queue exactly those cases in the console instead of silently producing wrong data.

Where does OCR run, and what happens to the original?

Ingestion and OCR run on BiVelio-controlled infrastructure, and the original document is preserved and versioned: it is not discarded after extraction. The original is the ultimate evidence everything else points back to.

How does Documents connect to the rest of the operation?

Validated data feeds cases and workflows under permissions, an audit trail and human gates on critical steps — the same governance framework as the rest of the platform. The full architecture is in A single agent fails: governed AI in 3 layers.