Teams that succeed with contract automation rarely think in terms of "the AI reads the contract." They think in stages, because the work has stages, and each stage has a different tolerance for machine error. The model described here, Triage, Extract, Verify, gives those stages names so a team can reason about where the software helps and where a human must stay in control.
The value of a named model is that it turns a vague capability into a workflow you can design, staff, and audit. Instead of asking "is the AI good enough," you ask the sharper question for each stage: what is the cost of a mistake here, and who catches it?
This piece lays out the three stages, the components inside each, and the conditions under which the whole model applies. It is deliberately opinionated about one thing: the machine sorts and surfaces, but a human verifies anything that carries real consequence.
Stage One: Triage
Triage decides what kind of document you are holding and what should happen to it next. It is the cheapest stage to automate and the highest leverage.
What triage does
The goal is classification, not understanding. Is this a standard NDA, a negotiated MSA, an order form, an amendment? Each class routes differently. Templated, repetitive documents flow into the assisted path; novel, negotiated documents route straight to a human.
Why it matters most
A surprising amount of wasted effort comes from treating every document the same. Triage prevents the classic failure described in Where Clause-Reading Software Earns Its Keep, and Where It Stalls: pointing extraction at a negotiated agreement that has no standard to check against. Good triage means the tool only does the jobs it is good at.
How triage can fail safely
Classification is not perfect, so the model assumes triage will occasionally misroute a document. The design principle is that errors should fail toward human attention, not away from it. If the tool is unsure whether a document is a standard NDA or a modified one, it should route to the human path, not the automated one. A false positive in triage costs a few minutes of unnecessary review; a false negative sends a negotiated agreement down the automated path where its unusual terms go unexamined. Tuning triage to err toward caution is what keeps the whole model trustworthy even when classification is imperfect.
Stage Two: Extract
Extraction pulls the specific clauses and terms you care about out of the document and presents them in a structured form.
The components
- Clause identification. Locate the governing law, term length, liability cap, renewal window, and any other terms on your watch list.
- Standard comparison. For documents with a written playbook, measure each extracted term against the acceptable range and flag deviations.
- Source linking. Every extraction points back to the exact clause text so a human can verify it in one glance.
Where extraction is strong and weak
Extraction is reliable on clearly worded, well-formatted clauses and shaky on obligations buried in exhibits, defined terms, or cross-references. Treat the output as a strong first pass, never a complete one. The single most common extraction failure is silence about what it did not see: a tool that confidently reports the liability terms while missing an indemnity carve-out in an attached schedule. Designing around this means treating extraction scope as bounded by default and assigning a human to chase incorporated documents, side letters, and amendments that the tool cannot reach.
Stage Three: Verify
Verification is where a human decides. The machine has sorted and surfaced; now a qualified person confirms or overrides.
Calibrating the human role
Not every extraction needs the same scrutiny. A flagged deviation on a high-stakes clause gets full attention; a clean match on boilerplate gets a glance. The art is matching reviewer effort to consequence, which is exactly what the model is designed to enable.
Why this stage cannot be skipped
The deployments that remove verification are the ones that fail loudly. Extraction confidence is not the same as correctness, and a confident wrong answer on a liability clause is far more dangerous than no answer. The verify stage is the safety valve.
Designing the verify queue
In practice, verification works best as an explicit queue rather than an ad hoc habit. Flagged items land in a list, each linked to its source clause, and a named owner works through them. Two design choices make the queue effective. First, sort by consequence so high-stakes flags surface first and never get buried under boilerplate. Second, capture the reviewer's decision, agree or override, because that record becomes the disagreement log that tells you whether the upstream stages are trustworthy. A verify stage without a record is a stage you cannot improve, since you never learn where the machine and the human part ways.
When to Apply the Model
The model is not universal. It pays off under specific conditions.
Good fit
- High document volume, where triage and extraction save real hours.
- Repetitive documents with a written decision rule, where standard comparison adds value.
- A clear human owner for the verify stage.
Poor fit
- Low volume of highly negotiated, one-off agreements, where the human reads everything anyway.
- No written standard to compare against, which strips the extraction stage of its judgment.
For sizing the payoff under good-fit conditions, pair this model with Cost, Payback, and the Business Case for Review Automation.
Applying it partially
The model is not all-or-nothing. A team with no written standard can still benefit from triage and clause location alone, using the tool to navigate documents faster while keeping all judgment human. A team with strong standards but low volume might skip the tool entirely and just adopt the discipline of a written verify queue. Reading the model as a menu rather than a mandate lets you take the stages that fit your situation and leave the ones that do not, which is usually how it earns its place in a real workflow.
Instrumenting the Model
A model you cannot measure will drift. Each stage produces a signal worth tracking.
What to watch per stage
Triage accuracy tells you whether documents are routed correctly. Extraction recall and false-alarm rate tell you whether the surfaced clauses are trustworthy. Verify-stage overrides tell you how often the human disagrees with the machine, which is the truest measure of whether the tool earns its place. The Instrumenting Clause Review: KPIs Worth Tracking and Reading guide maps each of these to a concrete metric.
A Walkthrough of the Model in Motion
It helps to trace a single document through all three stages to see how the pieces connect.
One contract, three stages
An inbound agreement arrives. Triage classifies it as a standard order form and routes it to the assisted path, because it matches a known template and a written playbook exists. Extraction then locates the governing law, payment terms, liability cap, and renewal window, comparing each against the acceptable ranges and linking every finding to its source clause. Two deviations surface: an unusually short payment term and a renewal window inside ninety days. Both land in the verify queue, sorted by consequence. The named reviewer opens the renewal flag first, confirms it against the linked clause in seconds, and records the decision. The whole document took a fraction of the time a full manual read would have, and nothing consequential reached a final state without a human confirming it. That is the model working as designed: the machine compressed the search, the human kept the judgment.
Where the same document could have gone wrong
Had triage misclassified this as a negotiated agreement, it would have routed to a human for full review, costing time but risking nothing. Had extraction missed a liability carve-out hidden in an attached schedule, the verify stage and the human habit of chasing references would have been the backstop. The model's resilience comes precisely from never relying on any single stage to be perfect.
Frequently Asked Questions
Why separate triage from extraction?
Because routing the wrong documents into extraction is the single most common failure. Triage ensures the tool only attempts the jobs it handles well, sending negotiated one-offs straight to a human instead of producing a useless summary.
Can the verify stage ever be automated away?
Not safely for anything consequential. Extraction confidence is not correctness, and a confident wrong answer on liability is more dangerous than no answer. Verification is the safety valve that makes the rest of the model usable.
What if my documents have no written standard?
Then the standard-comparison part of extraction adds little, and the model's value shrinks to triage and clause location. That is a sign your work is in the poor-fit category, where reviewers read everything regardless.
How is this different from just running an AI over contracts?
It separates sorting from judgment and assigns each to whoever does it best. The undifferentiated approach treats every document the same and removes the human, which is exactly where deployments break.
Does the model require a specific tool?
No. It is a workflow design, not a product. Most capable contract analysis tools can be configured to support triage, extraction with source linking, and a human verify queue.
Key Takeaways
- Reason in three stages, Triage, Extract, Verify, because each has a different tolerance for machine error.
- Triage is the highest-leverage stage; correct routing prevents the most common failure.
- Extraction is a strong first pass, not a complete one, especially around exhibits and cross-references.
- Verification by a qualified human is non-negotiable for anything consequential.
- Apply the model where volume, repetition, and a written standard exist; skip it where they do not.