Extraction and annotations

Here is the pattern that decides the token bill.

A document enters the enterprise. Team A's agent reads it to classify it. Team B's agent reads it to pull out the parties and dates. Team C's copilot summarizes it to answer a question. Team D's workflow reads it again the next day to answer a slightly different question and summarizes it again. The same document has now been read by a model four times, at full length, producing four overlapping and slightly inconsistent derived artifacts that live in four places and are discoverable by nobody.

The alternative is that the pipeline extracts the durable, reusable signals once at ingestion and stores them as annotations on the canonical document, where any consumer can read them for free.

Which signals are durable enough to be worth extracting up front? The ones that many consumers need and that do not depend on the question being asked: document type and domain classification; the entities that appear (organizations, people, products, identifiers, amounts, jurisdictions, dates and what kind of date each one is); the effective and expiry dates; the relationships stated between entities; a summary at document and section level; key phrases; a sensitivity classification; and a small set of answer-ready snippets for the questions this document type is always asked.

Store them on the document, versioned with it, with the extractor name and version and a confidence score. Then the contract with consumers is: check the annotations before you invoke a model. A question that can be answered from the summary and the entity table should never cause the full document to be read again.

A note on extraction models. For high-volume, well-defined extraction tasks — classification, named entities in a known domain, date typing — a small specialized model, fine-tuned on your own labeled data, will usually match a frontier model at a fraction of the cost and latency, and it will be deterministic enough to audit. Reserve the large model for extraction tasks that are open-ended, rare, or require reasoning over the whole document. The pipeline should make this routing explicit and configurable per document type rather than defaulting everything to the largest model.