The document you extracted is not the contract.

Ask a contract extraction pipeline for the payment terms of a vendor relationship and it will usually return a clean answer. It opens the master services agreement, finds the section headed “Payment,” reads “net 30,” and attaches a citation to the page. The field is correct. The document is real. The citation points to the right sentence.

And the answer can still be wrong, because the master agreement is rarely the whole contract. Commercial relationships are assembled from several instruments: the master agreement, one or more order forms, statements of work, a data processing addendum, exhibits, and amendments signed months or years apart. The value that actually governs a given order depends on which of those documents says what, and on a clause, usually buried in the master agreement, that ranks them when they disagree.

This article is about extracting the set rather than the file. It walks through what a contract set contains, how an order-of-precedence clause works using two published examples, a worked conflict over a single field, the three ways single-document extraction fails, and what the output has to carry so that a reviewer can see which value governs and why.

A contract is a set of documents

A typical software or services relationship starts with a master agreement that sets the durable terms: definitions, confidentiality, warranties, indemnities, limitation of liability, governing law, termination. It deliberately says little about what is being bought. That goes into order forms or statements of work, each of which references the master agreement and adds the commercial specifics: products or services, quantities, fees, a term for that order, and sometimes a line or two that changes a master term for that order only.

Around that core sit further documents. A data processing addendum governs personal data. Exhibits hold service levels, security requirements or a price list. Amendments change the master agreement itself, and they are often short: “Section 5.2 is deleted and replaced with the following.” Many of these documents incorporate others by reference, and the master agreement usually defines “Agreement” to mean the master plus every order form and exhibit executed under it.

Each of those documents can be extracted perfectly on its own terms. None of them, read alone, tells you what the parties are bound to. The contract is the set, and the set has rules for how its parts combine.

The clause that ranks the documents

When documents in a set disagree, most commercial contracts settle the question in advance with an order-of-precedence clause. It lists the component documents and says which one controls in the event of a conflict. The clause is a piece of data like any other, and it is the most important one in the set, because it decides how every other conflict is resolved.

Two published examples show how much the ranking varies even within one body of rules. The United States Federal Acquisition Regulation prescribes standard precedence clauses for government contracts, and the text is public on acquisition.gov. FAR 52.215-8, Order of Precedence—Uniform Contract Format, resolves any inconsistency by giving precedence in this order: the Schedule (excluding the specifications), then representations and other instructions, then contract clauses, then other documents, exhibits and attachments, and finally the specifications.

FAR 52.212-4, the standard terms for commercial products and services, carries its own ranking in paragraph (s), and it is longer and different. It puts the schedule of supplies or services first, then a named set of paragraphs of the clause itself, then the clause at 52.212-5, then addenda including any software license agreements, then solicitation provisions, then the other paragraphs of the clause, then the Standard Form 1449, then other documents, exhibits and attachments, and the specification last.

The point is not the government contracting detail. It is that two standard clauses written by the same regulator rank similar components differently, and that a private master agreement is free to write its own list. Some rank the master agreement above every order form. Some rank the order form first because it was negotiated last. Many add an exception: an order form prevails only where it expressly identifies the section of the master agreement it modifies. There is no default ranking an extraction can safely assume. The clause has to be read from the set in front of you.

Precedence is not chronology

The tempting shortcut is “latest document wins.” It is how people often reason about a folder of files, and it is how many pipelines resolve duplicates. It is also a different rule from the one most contracts state.

A precedence clause ranks documents by type, not by date. An order form signed last week does not override the master agreement just because it is newer, if the master agreement says it controls. An amendment is different in kind: it does not compete with the master agreement, it changes the text of the master agreement from its effective date. So an amendment is applied first, producing the current master text, and the precedence clause is then applied across the current versions of each document type. Two different operations, performed in that order, and each needs its own extracted inputs.

This is where contract sets differ from the lease packet described in the lease abstraction article. A lease file is mostly a timeline for one agreement, in which later instruments confirm, supplement or supersede earlier ones. A commercial contract set adds a second axis: parallel documents of different types, each with a scope, ranked by a clause rather than by time.

One field, four documents

Take a single field, payment terms, across a small set. The master agreement, signed in January, says in Section 5.2 that invoices are payable net 30. Its precedence clause reads, in substance: in the event of a conflict, this Agreement prevails over any Order Form, unless the Order Form expressly identifies the Section of this Agreement it modifies, in which case the Order Form prevails for that order only.

In March the parties sign Order Form 1. Its commercial terms include the line “Payment terms: net 60.” It does not mention Section 5.2. In June they sign Amendment 1 to the master agreement, which deletes Section 5.2 and replaces it with net 45. In September they sign Order Form 2, which states: “Notwithstanding Section 5.2 of the Agreement, invoices under this Order Form are payable net 60.”

Apply the rules as written. For invoices under Order Form 1 issued after June, the governing term is net 45: the order form’s net 60 loses to the master under the precedence clause, and the master now says net 45. For invoices under Order Form 2, the governing term is net 60, because that order form names the section it modifies. The relationship as a whole has no single payment term. It has one per order, and each one is derived from three documents and a rule.

Now look at what a single-document extraction reports. Pointed at the master agreement, it says net 30, which has been superseded. Pointed at the most recent document, it says net 60, which is right for one order and wrong for the other. Pointed at the whole folder and asked for “payment terms,” it returns three values with three citations and no way to choose. Every one of those outputs is a correct reading of a real sentence.

Whether a particular clause in a particular contract works the way this example describes is a legal question, and nothing here answers it for any real agreement. The extraction task is narrower and still valuable: surface every candidate value, surface the rule the contract states, apply that rule mechanically where it is unambiguous, and show the work.

Three ways single-document extraction fails

The example generalizes into three failure patterns, and each one has a characteristic output that a reviewer can learn to recognize.

• Reading the anchor document only — the pipeline extracts the master agreement and stops, so every term later changed by an amendment or overridden by an order form is reported at its original value, with a valid citation that makes it look settled.
• Latest document wins — the pipeline treats the newest file as authoritative, which applies chronology where the contract applies a ranking, and turns an order-scoped override into a relationship-wide term.
• Flattening the set — the pipeline extracts every document and merges fields by name, so the output carries several values for one field with no scope, no rank and no indication of which one a system downstream should use.

The third pattern is the most honest of the three, since at least it does not hide the conflict. It is also the one that most often gets “fixed” by a rule that picks the first value, which quietly turns it back into the first or second pattern.

What the extraction has to deliver

The output that makes the set usable is not a longer list of fields. It is a small graph of documents, with the precedence clause captured as data and every field value carrying enough context to be ranked.

• A role for every document — master agreement, order form, statement of work, addendum, exhibit or amendment, classified before any field is read, because the role decides where the document sits in the ranking.
• The links between documents — which master each order form is issued under, which document each amendment changes, and which exhibits are incorporated by reference, captured from the text rather than inferred from file names.
• Effective date and scope per document — when each instrument takes effect and whether it applies to the whole relationship or to one order, since scope decides how far an override reaches.
• The precedence clause as structured data — the ranked list of document types and any conditions, such as an express-reference requirement, extracted and cited like any other field.
• Every candidate value, kept — each document’s value for a field, with its section and its page region, so a resolved value never erases the ones it beat.
• A resolved value with its trace, or a flag — where the rule is unambiguous, the governing value plus the steps that produced it; where the clause is missing, circular or conditional in a way the text does not settle, a conflict routed to a reviewer instead of a guess.

The contract extraction page describes the parts this depends on: a classifier that identifies contract types including MSA, SOW, DPA and amendment, a schema per type, source-clause citations for each field, and cross-clause checks such as whether the term length agrees between the term and renewal clauses. Precedence resolution is the same kind of check, run across documents instead of within one.

Where conflicts actually show up

Payment terms make a clean example, but they are not where set-level conflicts cost the most. In practice the fields worth checking across the whole set are the ones negotiated in more than one place.

Each row is a place where a reviewer reading one document would report a confident value, and where the set may say something else. The table is a checklist of fields to resolve across the set, not a statement of how any given contract resolves them.

Extraction, not interpretation

There is a line here worth drawing clearly. Deciding what a contract means, whether an order form’s language is an express override, whether an ambiguity should be read against the drafter, is legal work. Extraction does not do it and should not pretend to.

What extraction can do is make that work smaller and more reliable. It can find every document in the set, identify its role, read the precedence clause, place every candidate value next to its rank and scope, apply the stated rule where the text leaves no room for doubt, and put the remaining conflicts in front of counsel with the relevant sentences side by side. A reviewer who receives “net 45 for Order Form 1, net 60 for Order Form 2, derived as follows” is doing a different and faster job from one who receives a folder.

Two neighbouring topics touch the same documents from other directions. The lease abstraction article covers one lease read deeply as a timeline of amendments. The agent liability article covers how master agreements are starting to allocate losses caused by AI agents, which is a question about what the clauses should say rather than how to read the ones that exist.

Extract the set, then the field

A citation proves that a value appears in a document. It does not prove that the document governs. In a contract assembled from a master agreement, order forms, addenda and amendments, the governing value is the output of a rule the contract itself states, applied to documents of different types, scopes and dates.

So change the order of operations. Classify the documents and link them. Extract the precedence clause first and treat it as data. Then extract each field from every document that addresses it, keep all the candidates, and resolve them by the contract’s own rule, with a flag wherever that rule runs out. The result is a value that can point not only to the sentence it came from, but to the reason that sentence won.