Documentation
Data handling
The first question anyone should ask a document-extraction vendor is: what happens to my documents? This page is the whole answer.
Processing-only by default
A document you send to inspect, extract or extract_tables is processed in memory and the result is returned inline. Source bytes are never written to storage — not to disk, not to object storage, not to logs. When a page is rasterized for OCR, the page images live in memory for the duration of the request and are discarded with it.
There is one deliberate, opt-in exception: a debug retention window you can enable per account (24 or 72 hours; the default is off). It stores the result JSON of your extractions — never the source document — so you can debug a pipeline, and stored copies are aged out automatically. The setting fails closed: if it can't be read, no retention happens.
create_pdf is stored on your account so you can re-download it — that's your output document, not an input you entrusted to us.Confidence is grounded, never self-reported
Every populated field in an extraction result carries a confidence score and the page it was found on. That score is computed by Inkrun from where and how the value was found in the document — the strength of the rule that matched, or verification of a model's answer against the document's actual text. It is never a model's self-reported confidence.
- A field that cannot be grounded in the document is
nullplus a warning — never a plausible guess. - OCR-read values can't be verified against extracted text (there is none), so they are labelled
method: "ocr"and their confidence is capped at 0.8 — your pipeline can always tell a pixel-read value from a text-verified one.
No training on your documents
Inkrun does not train models — ours or anyone else's — on customer documents, and has no pipeline that could. For the extraction tiers that call an external model (below), every request is sent with the provider's data-collection opt-out and zero-data-retention routing preference — unconditional, on every call, not a plan feature. Those flags are a routing instruction our provider (OpenRouter) applies when selecting upstream models; we state that plainly rather than dressing a routing request up as a physical guarantee about third-party hardware.
What each tier sends where
| Tier | What leaves Inkrun's servers | To whom | When |
|---|---|---|---|
| Deterministic | Nothing. Positioned-text rules run entirely in-process. | — | Always the first tier. |
| Model | Extracted text and layout for the fields being escalated — never your file's bytes. | A model provider, routed via OpenRouter with data_collection: "deny" and ZDR preference on every request. | Only for fields the deterministic tier could not ground. |
| OCR | Rasterized images of scanned pages only (a page with a text layer is never drawn) — never the original file. | A vision model, routed the same way with the same flags. | Only when you explicitly pass ocr_fallback: true — an absent flag can never escalate or be charged. |
Escalation is also visible after the fact: the envelope's extraction_method names the highest tier that ran, each field's method names the tier that produced it, and credits_charged reflects only the tier actually used.
EU processing
EU-resident processing is coming on a higher tier. We're not announcing a date, and until it ships no Inkrun tier makes a data-residency promise.
Where these promises live
Each commitment above is an engineering requirement in Inkrun's codebase, not marketing copy layered over it: processing-only ingestion and the bounded opt-in debug window, grounded confidence assembly and the OCR confidence cap, and the retention flags attached to every upstream model call. If a future change ever relaxed one of them, the change would be visible in the product's behaviour described on the extraction reference — this page and the API documentation describe the same code.