A scanned passport, an uploaded ID, a filled-in PDF form: each one carries facts the matter needs, locked inside an image or a binary document. Extraction reads those facts out. It runs the bytes through OCR, returns the values it found with a confidence score on each, and writes the ones it is sure of straight into the matter’s single source of truth. The ones it is not sure of are never guessed at. They are held, visibly, for a person to check. The legacy product had a single narrow passport-OCR surface; Opbox v2 generalises that into one governed extraction primitive that any document type can use.
What it does
Read typed facts out of a binary document. Point extraction at a stored file (a passport scan, an identity document, a completed form), tell it where the facts belong, and it returns the fields it could read: a name, a date of birth, a document number, an expiry. Each field comes back as a typed value, not loose text, ready to land on the matter as a fact rather than something a person has to re-key from a photocopy. This is the read-twin of document generation: generation fills a template from a matter’s facts, extraction does the reverse and pulls facts back out of a document.
A confidence score on every field, and a quality gate that acts on it. OCR is never certain, so extraction does not pretend it is. Every field carries a confidence figure, and the result is sorted against a threshold (0.7 by default, adjustable per call). A field above the line is written through the canonical fact path. A field below it is treated as doubtful and handled accordingly, so a low-confidence read can never quietly become an authoritative fact on the matter.
High-confidence facts written through the one fact path. When a field clears the threshold, extraction writes it as a real fact on the matter, through exactly the same governed path any other fact takes. The value is now part of the matter’s single source of truth: documents generated later read it, forms pre-fill from it, and it carries its own provenance back to the extraction it came from. Personal data is encrypted before it is written, with an explicit encryption scheme, so a sensitive field like a passport number never sits in a plaintext column.
Doubtful fields routed to review, never guessed. A required field that falls below the threshold is not written as a guess. It is recorded as low-confidence and routed to the review queue, on the same transaction, as a real review item in the extraction lane. A person claims it, checks the value against the source document, and resolves it. An optional field that comes back low-confidence is recorded and kept visible rather than silently dropped, so nothing the OCR saw is lost. This is the human-in-the-loop brake: the system reads what it can, and hands the rest to someone who can judge it.
A coverage report on every run, kept on the record. Each extraction writes a snapshot recording what it attempted and how it scored, on both success and partial outcomes. A partial extract (some fields written, some routed to review) is a first-class committed result, not a failure. The snapshot is audit-bearing, so there is always a defensible account of which facts came out of which document, at what confidence, and what happened to each one.
Reading the extracted facts back, with their provenance. The facts an extraction produced are readable like any other facts on the matter, but they carry the extra detail extraction needs: the OCR confidence the value was read at, and a reference to the extraction it came from. That means a reviewer or an auditor can see not just the value of a field but how sure the system was and which document and run it traces to.
How you use it
Extract from a document. Upload or select the stored file (a passport, an ID, a scanned form), point extraction at the matter or party the facts belong to, and run it. The confident fields land as facts straight away; the doubtful ones are set aside for review. You can tighten or loosen the confidence threshold for the run if a particular document type needs it.
Check what came out. List the facts on the target to see the extracted values together with their OCR confidence and the extraction each one traces back to. The high-confidence fields are already live on the matter; the rest are flagged for a human decision.
Work the review queue. Open the review queue and look at the extraction lane. Each item is a required field the OCR was not sure of. Claim it, compare the read value against the source document, and resolve it, so the doubtful read becomes either a confirmed fact or a corrected one.
Resolve a field’s current value. Ask for the resolved value of a field and you get the current answer along with where it came from, so a fact that originated from an extraction is as traceable as one entered by hand.
The kernel verbs behind it
Everything above runs through the kernel’s one front door: each call is permission-checked and audited before it executes. These are the key verbs.
doc.extract- read typed facts out of a binary document (OCR / KYC); high-confidence fields are written through the canonical fact path, required low-confidence fields are routed to review under the INV-9 quality gate.fact.list- list the facts on a target, including the OCR confidence and the source extraction for each.fact.resolve- resolve a field’s current value together with its provenance.review.list- read the review queue, including the extraction lane where low-confidence required fields wait.review.claim- claim a low-confidence extraction field to check it.review.resolve- resolve a claimed field once it has been checked against the source document.form.ingest- the related public door that takes in a completed form submission and extracts its uploads to encrypted blobs.
See the full set in the doc verb reference and the fact verb reference.