In short: A contract estate holds obligations with dates attached, and a repository of scanned documents with metadata records does not tell operations what the organisation has to do or by when. The usual value case is a missed option rather than a breach, since a price review window that opens and closes unobserved costs money that never appears in any variance report. Extraction is hard in this domain because a single obligation is assembled across a clause, an annexe and a defined term that points back to a date fixed by a separate certificate. Every extracted obligation needs provenance back to the clause it came from and a human review tier over the high value items, since a register nobody can trace will not be trusted when it matters.
A long term supply agreement contains a price review provision. Either party may request a review at defined points, and the request has to be served in writing not less than ninety days before the review date. The review dates sit in an annexe rather than in the clause, expressed as the last day of the fifth contract year and every third contract year thereafter, and contract year is a defined term pointing back to a commencement date that was fixed by a completion certificate issued eleven months after signature.
Working out whether the window is open this quarter takes four documents and about two hours. Nobody does it, because nobody knows the window exists. The window passes, the price stays where it is for another three years, and the difference between the contract price and where the market moved is a number that will never appear in any variance report because there is no line item for an option that was not exercised.
That is the shape of the problem in a large industrial contract estate. The documents all sit in a repository, each with a scan and a metadata record. What is missing is any structured statement of what they oblige the organisation to do and when, in a form that anything operational can act on.
What is in the estate that operations actually needs
Legal review at signature covers risk allocation. What survives into the operating years is a different and narrower set of terms, and it is worth being specific about which ones.
Delivery obligations and their tolerances. Annual and daily contract quantities, the tolerance band around a nomination, make-up and carry-forward rights, and the notice periods for changing a nomination. These are the terms that determine whether an operational decision made on Tuesday costs money on Friday, and they are frequently expressed as a percentage band in a schedule rather than as a number in the body.
Price review triggers and their notice periods. Both the scheduled windows described above and the event-driven ones, where a defined change in market conditions opens a right to reopen. The notice period is the part that matters operationally, because the right is worthless once it has expired, and these periods run from dates that are themselves defined elsewhere.
Take or pay and minimum volume commitments. The annual quantity you pay for whether or not you take it, the make-up gas rights that let you recover it later, and the deadline on those rights. This is a cash obligation that interacts directly with production and demand planning, and it is one of the few contract terms where a planning system can be told the constraint and honour it.
Change in law provisions. What happens when a tax, a tariff, a local content requirement or an emissions obligation changes after signature. Who bears it, whether there is a right to renegotiate, and whether there is a notification requirement with a clock on it. In a jurisdiction with an active regulatory agenda, this clause moves real money and it is almost never monitored, because monitoring it requires somebody watching legislation and somebody watching the contract estate to be the same person.
Liability caps, indemnities and insurance requirements. The aggregate cap, the carve-outs that sit outside it, and the insurance the counterparty is required to maintain. The operational hook is the requirement to hold current certificates, which expire.
Termination and step-in rights matter too, though they get read when they are needed. The five above are the ones that produce a cost from inattention rather than from a dispute.
Why extraction is genuinely hard in this domain
General purpose document extraction works better on invoices than on contracts, and industrial contracts are among the harder contract types. Four properties account for most of it.
Clauses cross-reference. The operative obligation is a composition of the clause you found, a defined term from the definitions schedule, an exception in a later clause, and a carve-out in a side letter. Extracting the clause text is easy and extracting the obligation requires resolving the whole chain. A model that returns clause 14 verbatim has returned an input to the answer.
Amendments supersede without replacing. The standard practice in most industrial estates is a stack of amendment agreements, each modifying specific clauses of the original by reference. The tenth amendment says that clause 8.3 is deleted and replaced with the following text, which itself references a clause that amendment four already changed. There is often no consolidated version, and where there is one, it may be a working copy with no legal status. Establishing the current operative text is a document assembly problem that has to happen before extraction, and getting it wrong produces confident answers from superseded terms.
The operative term is frequently in an annexe. Body clauses set the framework and schedules carry the numbers. Quantities, tolerances, price formulas, specifications and delivery points live in appendices that are formatted as tables, sometimes as scanned images, occasionally in a different language from the body. Extraction quality on a table in a scanned annexe is a different problem from extraction quality on body prose, and quoted accuracy figures rarely distinguish them.
Definitions do heavy lifting. A term like Delivery Point or Force Majeure Event carries a contract-specific meaning that can differ materially from the ordinary one, and the same defined term means different things in two contracts in the same estate. Any extraction that does not resolve definitions against the correct document has produced a plausible sentence with the wrong content.
Public benchmarks reflect this difficulty. The Contract Understanding Atticus Dataset, released by Hendrycks and colleagues in 2021, provides expert annotations across forty one clause categories on several hundred commercial contracts, and the results reported with it showed performance varying widely by category, with the harder clause types well below what unattended action would require. That benchmark uses relatively standard commercial agreements rather than amended long term supply contracts with annexes, which puts a ceiling on what to expect in this domain rather than a floor.
The workflow that makes it useful
Extraction on its own produces a pile of clause text, which is a modest improvement on a pile of documents. The value comes from two further steps.
The first is normalising into a structured obligation register. Each row is one obligation with typed fields: the counterparty, the obligation type, the trigger, the quantity or threshold, the applicable period, the notice requirement, the responsible internal function, and a pointer back to the source. The design decision that matters here is that the register holds obligations rather than clauses. One clause can generate several obligations, and one obligation can be assembled from several clauses, so a register keyed on clause number will not support monitoring.
The second is monitoring the register against operational data. This is the step that turns a legal artefact into an operating control, and it is straightforward once the register exists in typed form. Nominations and actual deliveries against tolerance bands. Cumulative annual offtake against the take or pay quantity, projected forward to year end so a shortfall is visible in month seven rather than in month twelve. Notice periods against a calendar with alerts far enough ahead that someone can actually act. Certificate expiry dates against today.
The projection is where most of the value sits. Knowing at the end of the year that you underlifted is an accounting fact. Knowing in July that current run rates land you eight percent short of the annual quantity is a decision, and it is still a decision with several months of options attached to it.
Provenance as a hard requirement
Every extracted value needs to carry a pointer back to its source: the document identifier, the version or amendment number, the page, and the clause reference, with the source text retrievable in one click.
The reason is asymmetric consequences. A missed extraction costs you an opportunity. A wrong extraction that someone acts on costs you a position. Serving a price review notice on the basis of a date read out of a superseded amendment is a real commercial event with a counterparty who will notice. Planning production against a tolerance band that was changed three amendments ago produces breaches you thought were compliance.
The design implication is that a system in this domain should be built to fail toward review rather than toward assertion. Where a value is extracted with low confidence, or where the chain of amendments could not be fully resolved, the register should hold an explicit uncertain state that routes to a human rather than a best guess presented like a fact. That state has to be visible in the interface and in any export, because an obligation register that looks uniformly authoritative will be treated as uniformly authoritative.
Provenance also determines whether the register survives its first challenge. When a commercial manager disputes an extracted quantity, the ability to show the clause in seconds ends the argument. Without it, the register loses to the manager's recollection, and once that happens twice, nobody uses it.
The human review tier
Reviewing everything defeats the purpose and reviewing nothing leaves the register unusable, so the design question is how to allocate a fixed amount of expert time.
Two dimensions do most of the sorting. Exposure is the first: the contract's value, the size of the obligation, and what a wrong reading would cost. A take or pay commitment on a major supply agreement earns full review regardless of extraction confidence. A notice address on a small service contract does not. Clause difficulty is the second: extraction confidence varies systematically by clause type, and the categories where it is weakest are known in advance from testing on your own documents rather than from a vendor's benchmark.
Combining them gives a workable policy. High exposure obligations get reviewed once at register creation and re-reviewed on amendment. Low exposure high confidence extractions go straight in. Everything in between gets sampled, with the sample rate set by measured error on that clause type, and the measured rate updated as reviewers correct things.
The review effort has a shape worth planning for. It is heavy at the start when the register is built and it decays, because contracts do not change often and most of the ongoing work is amendments and renewals. Staffing it as a project with a long tail is closer to right than staffing it as a permanent function, though the tail never reaches zero.
Where this stops
Extraction accuracy on the difficult clause types is not high enough to act on unattended, and it will not be soon, because the difficulty is in the document structure rather than in the language understanding. A model that reads perfectly still has to resolve a definition to the correct schedule, apply the right amendment version, and notice a carve-out three clauses later. Each of those is a retrieval and assembly problem where an error propagates silently into a confident answer.
So the honest description of what this capability is: triage and retrieval. It finds the clauses that probably matter, drafts a structured reading of them, points at exactly where each reading came from, and flags the ones it is unsure about. A person with domain knowledge then confirms the ones that carry money. That is a large improvement over the current state, where the obligations are known to a handful of people who negotiated the contracts and are gradually leaving, and it is a smaller claim than automation.
There is a second limit that no amount of model quality fixes. The register is only as current as the document repository behind it, and in most large operators the repository is incomplete. Side letters agreed by email, variations recorded in meeting minutes, and local agreements signed by an operating entity and never sent to the centre are all binding and all missing. An extraction programme run against an incomplete estate will produce a register that is internally consistent and materially wrong, and finding the missing documents is administrative work that no technology shortens.
Pick the ten highest value contracts in the estate, and for each one write down the next date on which somebody has to do something, along with the clause it comes from. If that exercise takes more than a day, or if two people produce different answers, the case for a register is already made.