One contract is six documents. GETEC has fifty thousand of them. Read once. Queried by every department since.

One shot, not two passes.

The raw PDF goes into the model together with the schema prompt, and markdown is produced in parallel for everything downstream. There is no layout pass in front of the read and no second pass behind it. Around that single read sit the things that make an archive tractable: classification at ingest, a generated document summary, byte-identical deduplication that links a duplicate to its original rather than blocking it, and a merge step for documents that arrived split. Both sides of this engagement arrived at the one-shot argument independently, which is worth saying because it is the decision everything else rests on.

Routing runs on the customer’s own ontology, not on the archive’s metadata.

Rules are driven by document type, and the customer’s own type ontology is auto-matched to Talonic’s at ingest. So the type that routes a document is the one the read assigns it, on both ontologies at once. The document type hand-entered into the source system over many years was ruled out as a routing signal before a document was read, for the reasons in section 02, and nothing downstream was allowed to depend on it.

The read captures more than the schema asks for, and that is a measurement rather than a claim.

In the Milestone 1 batch, capture averaged 123 fields per document, median 70, against a delivered schema of 75 fields per contract dataset. The surplus is not rhetorical. It is the average.

Average captured per document in the Milestone 1 batch, July 2026, against a delivered schema of 75 fields per contract dataset. Per document and per contract are different denominators, and a contract is about six documents. Those two numbers do not divide into each other.

Open capture is a decision, not a model behaviour.

Nothing about a model makes it reach past the brief on its own. The fields nobody asked for are captured because somebody decided they would be, and they are stored in a parallel structure rather than in the governed set. That means a field can be captured specifically because a later question is foreseeable but unaskable now. Operating electricity, the field that records who carries the operating-electricity cost, is the clearest example: a system given no instruction is unlikely to find it, so it was named and added to the capture set.

The one-shot requirement came from both sides.

Extracting to one department’s schema means extracting again when the next department arrives, and paying twice. So the read is exhaustive and the delivery is selective. Talonic wanted it because re-reading is waste, and the customer wanted it because management funds one read, not four.

A second schema is what stops the first department’s contract from blocking everyone else.

The business acceptance owner’s field set is the governed core that goes into Dynamics, and every change to it is a negotiation. If every new department had to widen that set, expansion would stall. So a second schema holds the non-governed fields in a parallel structure, and a new department adds what it needs without renegotiating the first department’s contract. It is an organisational decision expressed as a data model, and it is the most interesting decision on this page.

The proof that it works.

The second department in was asset management, and it did not ask for more fields of the same kind. It asked for images, schematics, technical diagrams, delivery and performance boundaries, measurement concepts, and free-text search across the estate. The Milestone 1 batch had already handled 1,514 schematic drawings and 1,116 technical diagrams, so the request was substantially already in the estate, because the first read had not been scoped to the first schema.

Technical drawings sit outside the 75-field delivered schema by design: they were descoped from the first step and held in the read.

Observations become concepts.

Read from the live tenant on 26 August 2026, 1,042,665 source observations resolve into 52,937 reusable concepts. The mechanism is the product’s own: observations with similar meaning cluster automatically using embeddings, and as the same thing is read out of many documents the system synthesises a master extraction instruction for it, a reusable directive that captures the best way to read it and improves accuracy on every subsequent run. Repetition is what makes cross-document comparison possible. Nothing is held here for its own sake: what is held is what makes a question across a whole estate answerable at all.

Three tiers, in the product’s published vocabulary.

Tier 1 Core are universal across many document types and the most reliable. Tier 2 Established were promoted out of Tier 3 after meeting frequency thresholds. Tier 3 Emerging are newly discovered, and are candidates for promotion as more data arrives. 19,169 of the 52,937 reusable concepts are established across tiers 1 and 2, and that subset is the one worth a number, because generated schemas are produced from Tier 1 and Tier 2 registry fields. The thresholds are the product’s own; this page describes the promotion mechanism.

The registry is still learning, in public.

The tenant’s own momentum feed records a concept named elevation.313_20 promoted from Tier 3 to Tier 2, four days before this reading, marked CONCEPT STRENGTHENED. That is a machine-generated key out of this estate crossing a threshold. It is the promotion rule firing on real data, in a live tenant, four days before we looked.

Cost allocation that is contested by nature.

Who bears the operating-electricity cost under the contract is a genuinely contested term in energy contracting. It was added to the capture set deliberately, on the reasoning that a system given no instruction is unlikely to find it, which is the same decision section 03 describes as open capture. It is in the read now, so operations and technical can ask it of the estate rather than of a filing cabinet.

An entitlement with no system that executes it.

This one is structural rather than per contract. The price adjustment is defined in the contract, and the system where it would be actioned is a different system from the one holding the contract data, so the terms and the billed values have never been in the same place. The registry is the first place they meet. Asset management is where the gap shows. Price management is where the tasks would be built.

Escalation entitlement, released from inventory.

Price adjustment clauses carry formulas, parameters, base values and annual index factors. Those fields were already being captured and held back from the delivered dataset a month before anyone framed an entitlement use case. The same fields were then queried and resolved into the full formula. Money Found was not a new capability. It was the release of inventory that already existed.