Watch a document get read, checked and routed

Your document does not leave your device

Everything above runs in your browser. The file is never uploaded, never stored, never sent to us and never sent to a model. Close the tab and it is gone. That is not only a privacy courtesy — it is the point being demonstrated: document intelligence does not have to mean handing your files to somebody, and for tender, legal and financial work it frequently must not.

What it is doing

Five stages, which is how a real document pipeline is built:

• Read — text is pulled from the PDF with its layout preserved well enough that labels stay attached to their values. Line structure is what makes the next stage possible.
• Classify — the document is matched against known types by the vocabulary that only appears in each one. The sandbox shows you which words it matched on, so a wrong classification is explainable rather than mysterious.
• Extract — fields are found by label first, by pattern second, and by proximity last. Every value carries how it was found, because that is what determines whether it can be trusted without a person looking.
• Validate — totals are checked, dates are compared against today, required fields are tested for presence. Anything missing or ambiguous is raised rather than filled in.
• Route — explicit rules decide where the document goes next, and every rule that fired is listed. No hidden logic, no black box.

Why the guardrails are the interesting part

Any demo can show a value being pulled out of a PDF. The question that decides whether a system is usable is what it does when it is not sure — and the honest answer is that it should say so, stop, and hand the case to a person. A tender with no readable submission deadline is not a document to process on a best guess; an invoice with no purchase order reference cannot be matched automatically no matter how confident the extraction looks.

That is why this sandbox shows you the confidence on every field, flags anything found by pattern alone, and routes to human review rather than inventing a value. A system that always returns an answer is easier to demonstrate and considerably more expensive to own.

What this sandbox deliberately does not do

• No OCR. Scanned PDFs and photographs contain no text to read. A production system runs OCR first; that needs a server, which would mean uploading your file, which is exactly what this demonstration avoids.
• No language model. The extraction here is deterministic — labels, patterns, proximity, validation. That is the layer that sits underneath a production system and decides what a model is given in the first place. Getting it right is most of the work.
• Generic document types. It knows tenders, invoices, purchase orders, contracts and CVs. A real deployment is trained on your documents, your vocabulary and your exceptions, which is why it performs very differently.
• No memory. Nothing is stored, so nothing is learned. A production system improves from corrections, which is a large part of why it gets better after launch.

What a production version adds

• OCR for scans and photographs, with the original page position kept for every extracted value so anyone can see where it came from.
• A language model for the judgements that patterns cannot make: is this clause unusual, does this scope match what we do, which of these three dates is the one that matters.
• Retrieval over your own history, so a new tender is compared against what you bid last time and what you won.
• Your document types, your fields, and per-field accuracy targets agreed in writing before the build.
• Roles, ownership and approval steps, with a full audit trail of who saw what and who decided.
• Integration with wherever the work actually lives — CRM, portal, shared drive, finance system.

If this is close to a problem you have

Bring twenty real documents, including the awkward ones. That sample tells us more in an afternoon than a month of requirements workshops, and it is the honest way to find out whether this works on your material before anybody commits to a build. Start there, or try the scoping estimator to get an indicative plan you can forward.