Contract families: the parent, the child, and the amendment on both
In short
A contract family is the set of documents that together decide what two parties owe each other, and it is a graph rather than a tree. One agreement can be governed by a second, amended by a third and partly incorporated from a fourth, so a repository needs typed, dated, scoped relationships instead of a parent field.
Key takeaways
- A parent field holds 1 relationship of 1 type; a real family needs 6 edge types and dates on each.
- An amendment routinely touches a master agreement and one schedule, so edges must carry a scope.
- Amending, restating, superseding and novating are different acts with different downstream effects.
- Incorporation by reference points at a document that can change without anyone signing anything.
- Model relationships as a separate table with source clause and effective date on every row.
A contract family is the set of documents that together decide what two parties owe each other: an MSA or other framework agreement, the orders placed under it, the amendments that changed either, the schedules attached, and the policies pulled in by reference. Most repositories model that as one parent field on the child record, and that field expresses exactly 1 relationship, of 1 unstated type, with no date on it.
The shape is a graph. Working out which document wins when two of them conflict is a separate question, resolved in which document wins when the MSA and the SOW disagree; this page is about being able to draw the edges at all.
A framework agreement is not the root of a tree
Take an ordinary arrangement: an MSA signed by a group holding company, with work orders raised under it by 3 business units, each carrying its own term, fees and sometimes its own schedule. A tree says each order has 1 parent. It does not say that the ordering entity on 2 of them is a subsidiary rather than the signatory — the ambiguity in one counterparty appearing under nine names.
The same shape appears wherever framework contracting meets high-volume operations, such as a master transportation agreement governing thousands of movements, which is why record structure matters as much as documents in AI in logistics operations.
Six edges a repository has to be able to draw
| Edge | What it asserts | What breaks without it |
|---|---|---|
| Governs | This order or schedule is placed under that framework agreement | Orders float free and the framework's terms never reach them |
| Amends | Named provisions of the target change from a stated date | The current text cannot be assembled, only guessed at |
| Amends and restates | The whole text is replaced while the agreement continues | The restatement is filed as a new contract and the history is severed |
| Supersedes | A later agreement replaces an earlier one going forward | Both look live, and reporting counts the relationship twice |
| Incorporates by reference | Terms held elsewhere form part of this document | Obligations sitting in a policy or standard terms are never registered |
| Novates or assigns | A party's position moves to a different legal entity | The counterparty on record stops being the party actually bound |
Termination is worth naming as a 7th, but it ends a document rather than relating two, and it interacts with survival. Incorporation by reference is the edge most often skipped and the most dangerous — it points at a DPA, a security policy or standard terms that can change without either party signing anything.
The amendment that hangs off two documents at once
A single amendment routinely changes a payment term in the MSA and a deliverable in one SOW schedule. Under a parent field it must be filed against one of them, and the other keeps showing superseded text. This is the case that forces the model, and it forces 4 attributes onto the edge itself.
- Scope. What the amendment reaches: the whole document, or a named clause, schedule or exhibit. Without scope you cannot tell a wholesale replacement from a change to 1 payment term.
- Effective date. Amendments are often signed after the date they take effect, and some take effect on a condition. The edge needs the date the change bites, held apart from the date the paper was signed.
- Source. Which clause of which document asserts the relationship. An edge a reviewer cannot trace back to a sentence is an assertion, and it will not survive a dispute.
- Confirmation state. Extracted, human-confirmed or disputed. Relationship extraction is more error-prone than field extraction, so an unconfirmed edge must look different from a confirmed one.
The minimum relational shape that survives contact
- Keep documents in 1 table: identifier, type, parties as counterparty entity references rather than typed names, and its own dates. No relationship columns.
- Keep relationships in a second table: from document, to document, edge type, scope, effective date, source clause and confirmation state. Edges are directed, and amends and is amended by carry different consequences.
- Derive the family at read time by walking edges rather than storing a family identifier, which has to be recomputed whenever a novation or supersession changes the shape.
- Report on edges as data: documents with no governing agreement, amendments with no target, incorporations pointing at a document not held. Each is a queue of work.
A repository that can only say which contract this one sits under cannot answer the question people ask: what is in force between us today, and where does each part of it come from.
The dates on these edges are what make downstream alerting possible: a child order can outlive the framework that governs it, and terminating a parent does not automatically end everything beneath it. That interaction produces the failure in the renewal alert that fired after the window closed. Extracting relationships and holding them for confirmation is AI agents and automation work. This page sits in the contract lifecycle: request to renewal, part of our legal technology practice.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a contract hierarchy?
It is the set of relationships between an agreement and the documents that govern, change or replace it — an MSA and the orders under it, the amendments to each, the schedules attached and the terms incorporated by reference. Calling it a hierarchy misleads: a document can sit under more than 1 other document, so the structure is a graph.
Can one contract have more than one parent?
Yes, routinely. A work order can be governed by an MSA, incorporate a separate DPA, and be modified by a change order that also touches a schedule. Each is a distinct relationship with its own type and date, which is why a single parent field cannot represent the arrangement and a relationship table can.
How should an amendment that changes a master agreement and a schedule be linked?
As 2 edges, not 1. Draw an amends edge to the MSA scoped to the clauses it changes, and a second amends edge to the schedule scoped to its own affected section, each carrying the same effective date and a reference to the operative clause. Filing the amendment against whichever document seems primary leaves the other showing superseded text indefinitely.
- contract repository
- data model
- contract lifecycle
- amendments
The work behind this page
Builds from our portfolio that this page draws on.
AskVault
An AI internal knowledge-search platform that answers employee questions from your own docs — grounded in citations, with knowledge gaps surfaced and deflection tracked.
Productivity AINotewell
An AI meeting assistant that records and transcribes every meeting, extracts the decisions and action items, assigns owners and due dates, and tracks follow-through until it's done.
Productivity AIBrief Forge
Contract review AI for solo lawyers and small firms — extract, score, and redline contracts in minutes.
Legal TechRead next
- Order of precedence: the clause that decides which document winsA precedence clause ranks a stack of documents. It is also why a single file is an incomplete unit of review: the same words bind or not, depending on which instrument controls.definition
- Three dates a contract record keeps confusing, and what each one governsA repository with one date field has already chosen which of three questions it can answer, usually without noticing that it chose.definition
- One counterparty, nine records, and never the whole relationshipAsk what you have with a supplier group and the repository answers with half of it. Some near-duplicate records are typing errors; some are different legal persons.diagnostic
- The renewal alert fired on time and the notice window had already closedThe alert was accurate, timely and useless. It counted back from the wrong date, and it treated a decision that takes six weeks as something a person does on the morning they are told.diagnostic
- The obligation register: 5 attributes an entry cannot work withoutMost registers are lists of clause summaries. A summary tells you what the contract says, not what to do, by when, or how you would prove it was done.definition
- Auto-renewal: alert on the notice deadline, not the renewal dateThe date printed in the contract is the last date anything can be done about it. The date worth diarising sits 3 subtractions earlier.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation