Read once. Every question after is a lookup.

Talonic accepts 25+ file formats through three processing paths. Plain-text formats (TXT, MD, HTML, XML, JSON, EML, CSV) are read directly with no model call. Image formats (PNG, JPG, GIF, WEBP) go to vision. Document formats (PDF, DOCX, PPTX, XLSX, MSG, BMP) run through the OCR path and emerge as structured Markdown; when a page carries complex image assets such as printed curves, it is routed to the vision model that benchmarks best for that asset. ZIP archives unpack recursively, and the folder structure is preserved as a source_file_path field on every document inside. SHA-256 deduplication runs at upload, so the same file never enters the system twice.

Every document is classified against a 529-type ontology, in German, English, French and Spanish at production quality: a German Arbeitsvertrag and an English Employment Contract resolve to the same canonical type. Your own document types overlay the ontology, so every document is classified on both axes. Anything that matches nothing lands in Unclassified rather than failing.

Every field found in every document resolves into one canonical registry, the Schema Graph. The Registry is discovered from the documents first; schemas are mapped later for a specific workflow, system or application. Fields sit in three tiers by frequency. Tier 1 is core: universal across many document types, the most reliable. Tier 2 is established, promoted from Tier 3 after meeting frequency thresholds. Tier 3 is emerging: newly discovered, a candidate for promotion as more documents arrive.

Fields with the same meaning cluster automatically. Vendor Name, Supplier Name and Company Name resolve to one canonical concept, with the source variants kept as aliases. As the same concept is read from many documents, Talonic synthesises a master instruction for it: a reusable directive that captures the best way to read that field. Master instructions improve every subsequent run.

This is why one read serves every later question. The database holds what the documents say, not what the first asker requested. GETEC needed 75 fields; the first five thousand documents yielded 1,042,665 source observations organised into 52,937 concepts, and the full estate is roughly ten times that size. In a schema-first extraction project that surplus is discarded. Here it is the asset.

A spec defines the shape of an output. Two kinds exist. Generated specs are produced automatically per document type from Tier 1 and Tier 2 concepts. Your own templates target a system: a vendor contract template shaped for Ivalua, a lane template shaped for TMW, a contract dataset shaped for Microsoft Dynamics.

Templates carry a workshop. Live is the published version, read-only. Workshop is the mutable draft. Version history is the full timeline with diff summaries. Promoting a draft surfaces breaking changes, field removals and type changes, before they ship. A test extraction runs the draft against a sample and shows draft against live side by side, so the impact of a change is visible before publish.

Every field supports format constraints (regex), modifiers (date and number formatting, value mapping, truncation), constraints (required, enum, length, cross-field expressions), bypass strategies (constant value, deterministic ID, reference-table lookup), and manual instructions that override the master instruction. Coherence rules can be proposed by the system after a job completes. Nothing proposed goes live without a person approving it.

Phase 1 fills cells straight from the database: no model call, no credits. Phase 2 reasons. Phase 3 validates. Phase 4 fills the gaps. Once a cell reaches 0.7 confidence, no later phase overwrites it. Every cell exposes its phase, confidence and reasoning through the API, so agents and downstream systems decide what to trust on their own terms.

A job runs through four phases. Each phase fills more cells in the output grid. Earlier phases produce values that protect themselves from being overwritten by later, less certain ones.

Phase 1 · Resolve. The fastest phase. Cells fill from existing graph matches with zero AI calls: direct registry transfer, fuzzy name matching, concept-synonym expansion (supplier to vendor.company_name), reference-table lookups, description scans. Values are normalised at transfer: dates to YYYY/MM/DD, numbers to two decimals, strings trimmed. Registry-resolved cells are metered at zero.

Phase 2 · Agent. An agent reviews the gap pattern in the grid and produces a typed strategy: compute (calculate from existing values through a safe expression evaluator, never eval()), transfer (copy from a semantically equivalent field), extract (re-read the source with specific instructions, batched five at a time), skip (with its reasoning).

Phase 3 · Validation. Cross-field sanity checks: date ordering, amount against term, lookup failures, low-confidence outliers, unexpected empty fields. Flags are informational. They never block output, and they order the review queue.

Phase 4 · Targeted re-read. For each empty or low-confidence cell, the system re-reads the original document with the specific field instruction and the whole grid as context. It regularly catches values the earlier phases missed.

The confidence gate. Once a cell is filled with confidence at or above 0.7, no later phase can overwrite it. A 0.95-confidence reference lookup in Phase 1 is never replaced by a 0.65-confidence extraction in Phase 4. The earliest reliable answer wins.

A rule starts as a sentence. Somebody types what they mean, in their own words: a term that ends before it begins, a renewal with no notice period, an agreed contribution with no amount against it. Talonic compiles the sentence into a check with a named subject, the fields it reads and the condition that fails. The sentence stays. It is what a reviewer reads when the check fires.

Each rule declares its effect. Hold, and the record stops and waits for a person. Flag, and the value travels into the delivered data with a mark on it. Record, and the outcome exists only in the ledger. A rule returns one of four things: passed, failed, not applicable, or indeterminate when an input it needed was missing. A missing input is never counted as a pass or a fail.

Approval gates are threshold rules per spec: minimum confidence, validation pass rate, field coverage. Results that meet every threshold approve themselves and trigger delivery. Results that do not go to a review queue, where a held record arrives with the rule, the sentence its author wrote, the value that failed and the page it came from. The same result.approved signal fires on either path, so downstream systems never know which one a record took.

Golden samples, reference sets with known-correct values, power benchmark runs. Every run is scored per field by an AI judge, with a person able to override. This is how Bridgeway got a measurement instead of a promise: 96 percent against the legacy OCR incumbent’s 78, on the same hand-labelled documents, scored the same way.

Identity, transaction and reference keys link related documents into cases. The system finds them. You review them. The unit of work is not the document. It is the case.

Most enterprise workflows do not run on single documents. They run on bundles. A vendor onboarding is a contract plus a W-9 plus an insurance certificate plus a banking form. A shipment is a bill of lading plus a customs declaration plus a packing list. A contract is often six documents: the frame agreement, the amendments, and the letters that supersede them.

Talonic identifies shared entities across documents (names, contract numbers, project codes, transaction references) and groups related documents into cases. Link keys are classified as Identity (entity names), Transaction (numbers) or Reference (other shared IDs). Entities present in more than 30 percent of documents are excluded from case formation, so a common bank or a common city never links everything to everything.

Each case shows the documents involved, the shared entities that connected them, the evidence chain (which fields produced which connections), a timeline, and an AI narration of what the case appears to be. Case templates are discovered after three or more cases form around the same document-type pattern.

Reading tells you what is in the document. Matching tells you what to do with it. Talonic matches extracted data against reference datasets: your carrier list, your vendor master, your chart of accounts, your open loads.

Four strategies combine into weighted scores. exact is a case-insensitive string match. fuzzy is token-based similarity with a configurable threshold. date_range matches dates within a tolerance window. numeric_range matches numbers within a percentage or absolute tolerance. The system can propose a strategy from the spec and the reference structure, and a person confirms it.

Results show the top five candidates per document with field-level evidence: which strategies fired, what each contributed, where the score came from. A reference table with a properly loaded vendor list typically returns 90 to 100 percent accurate matches in a single run. Bridgeway runs this against seven to ten thousand open loads, and the system abstains when it is not sure.

Signal, binding, resolver, serializer, connector. Every attempt logged. Every failure replayable. Append-only history, idempotency keys on the wire, a dead-letter queue you can drain. Deliver into Dynamics, Ivalua, Salesforce, a warehouse, or straight into an agent’s working memory: same typed pipeline, same signing, same replay.

Output flows through a five-stage delivery pipeline. Every stage is typed and observable.

Signal. A producer emits a typed event, document.extracted, result.approved, run.structuring.completed, into the outbox. Producers are stateless. They only publish.

Binding. A poller drains the outbox and matches each event against active bindings. A binding joins a signal filter to a deliverable type, a destination and a serializer. The binding picker validates that all four form a compatible triangle at create time, so misconfigurations fail loudly instead of silently.

Resolver. The deliverable resolver loads the actual payload (document metadata, a record snapshot, an extraction run) at delivery time, using only entity IDs from the signal. Stateless lookup at each delivery, so no cached payload goes stale.

Serializer. Encodes the payload as json, ndjson, csv, csv_file, xlsx, rows, graph, raw, md or txt. An optional field_map renames fields, drops fields or injects static values without writing code.

Connector. Ships the encoded bytes through the TransportWrapper: SSRF guard, payload cap, rate limit, retry ladder. The default ladder is seven attempts over about ten hours (0s, 30s, 2min, 8min, 30min, 2h, 8h), overridable per binding. Webhooks are signed with HMAC-SHA256 and carry an idempotency key, an attempt counter and an event ID in their headers. The destination catalogue covers webhook, SFTP, Amazon S3, Azure Blob, Google Drive, Google Sheets, OneDrive, SharePoint, Gmail and Outlook.

Every attempt logs to delivery_items. Terminal failures escalate to delivery_dead_letter. Both are replayable; a replay enqueues a fresh attempt with a new idempotency key. The history log is strictly append-only.

Retrieval re-reads the corpus on every question, re-spends the tokens, and can answer differently tomorrow. A database answers once, the same way, with a line number.

Three ways in. POST /v1/documents/filter returns typed rows over materialised field values with no model call. POST /v1/ask takes a natural-language question, plans over the field plane, runs read-only SQL over the extracted cells, reads a missing field at query time if it has to, and grounds every load-bearing claim in an exact source span. The MCP server hands the same surface to Claude, Cursor or any MCP client.

A scope on every ask compiles into a bound SQL predicate applied on every retrieval plane: these documents, this spec, this pipeline, nothing else. That is the primitive the agents in the next section are built on.

Give an agent exactly this: these contracts, this reference table, nothing else. It queries the database, every read is logged, every answer carries its source. You decide what it sees. You can prove what it saw.

Three run on customer estates today. Each reads only what it was granted, decides by rules a person wrote in their own words, and writes every decision to a record nobody can edit. Status is the product’s own vocabulary, four words and no adjectives: running, shadow run, on request, authored.

371 endpoints across 46 namespaces: one typed REST surface for production integrations and agent access alike. Every primitive on this page has endpoints. /v1/extract for synchronous and asynchronous reads, /v1/ask for cited answers, /v1/documents/filter for typed rows, /v1/schemas for specs, /v1/structuring/gates for approval gates, /v1/cases, /v1/matching, /v1/data-products, /v1/delivery for the full delivery surface, and /v1/credits for cost.

API keys are prefixed tlnc_, passed as Authorization: Bearer, and SHA-256 hashed at rest; the full key is shown once, at creation. Six scopes: extract, read, write and operations by default, billing and delivery added explicitly. A request outside a key’s scope returns 403 with insufficient_scope and the scope it needed. List endpoints paginate by cursor. Every write endpoint honours an Idempotency-Key.

The same surface ships as a Node SDK and as an MCP server: eleven tools and two resources, listed on the official MCP Registry, running locally over stdio or hosted at mcp.talonic.com with OAuth, so Claude.ai needs no key at all. Every response carries typed fields, confidence and provenance, and every synchronous read returns its cost in headers.

We are slower out of the gate than parsing-first vendors and not always the cheapest per page. On one-question-per-document numeric reading, structure-first and retrieval tie in our own runs, and the benchmark page says so. What you get for the slower start is a system that compounds, audits, validates and delivers, instead of one that returns text and stops.

If you want the fastest path from PDF to JSON with no notion of a database or compounding, Reducto is excellent. If you want the database underneath your enterprise document workflow, that is us.