AI Adoption GuideLegalAssess
Missing clause detection
Compares document against a required-clause checklist and produces a gap report per contract type.
Legal processRequestAssessDraftNegotiateApproveSignStoreDispute
By Don, DoneThat’s AI coach · updated
Overview
Missing clause detection compares a contract document against a type-specific required-clause checklist and returns a gap report listing what is absent, incomplete, or present only in non-standard form. The output is a quality signal for intake and first-pass review: it tells counsel and contract operations which mandatory provisions still need attention before a document can move to negotiation, approval, or execution.
The use case sits in the assess stage of legal AI adoption. It does not draft language, rewrite terms, or approve contracts. It answers a narrower question: given this document and this contract type, which checklist items are not satisfied? That scope keeps the workflow auditable and keeps human judgment where it belongs.
What the gap report contains
Each finding in the gap report ties back to two anchors: a checklist item ID from the organization's required-clause library, and a contract section reference (heading, article number, or paragraph locator) where the model looked for a match or found a partial match.
A complete gap entry typically includes:
- Checklist item ID — stable identifier from the clause library (for example
MSA-INDEM-01orNDA-TERM-03) - Requirement label — short name of the expected clause (mutual indemnification, termination for convenience, data processing addendum)
- Status — missing, partial, non-standard placement, or ambiguous
- Contract section — where the model expected to find the clause, or the closest section if the clause appears elsewhere
- Evidence snippet — optional excerpt when partial or non-standard language was detected
Gaps are grouped per contract type. A master services agreement is checked against the MSA checklist; a mutual NDA against the NDA checklist. Mixing checklists across types produces false positives, so type resolution happens before comparison.
When the contract type cannot be determined with sufficient confidence, the use case returns an empty gap report rather than guessing. An empty result is intentional: it signals "type unknown, manual classification required" instead of flooding reviewers with irrelevant missing-clause alerts.
How checklist comparison works
The pipeline has four logical steps: classify contract type, load the matching checklist, scan the document section by section, and emit structured gaps.
1. Contract type resolution. The system reads title blocks, defined terms, party roles, and structural cues (recitals, scope of services, confidentiality framing) to assign a type such as MSA, SOW, NDA, DPA, or vendor order form. Low-confidence classification stops the pipeline and yields an empty report.
2. Checklist binding. Each contract type maps to an ordered list of required items maintained in the clause library. Items may be mandatory, conditional (required only when certain triggers appear), or tiered by deal size or jurisdiction.
3. Section-aware matching. The model does not treat the document as a flat bag of text. It aligns checklist items to expected locations: indemnification near liability caps, governing law near dispute resolution, IP assignment in work-product sections. A clause that exists but sits in an unexpected article may surface as non-standard placement rather than missing.
4. Gap assembly. Unmatched mandatory items become gaps. Partial matches note what was found and what checklist element is still absent (for example, indemnification present but one-way only when mutual is required).
This approach complements but differs from playbook deviation report, which measures distance from negotiated positions, and clause risk classifier, which flags risky language in clauses that are present. Missing clause detection focuses on absence and incompleteness against a baseline inventory, not on whether existing language deviates from fallback positions.
Contract types, conditional items, and empty results
Organizations rarely maintain one flat checklist for all agreements. Effective deployments model conditional requirements: a DPA checklist item applies only when personal data is processed; an export-control clause applies only for certain goods or destinations; insurance certificates apply above a spend threshold.
The gap report should distinguish:
- Unconditional gaps — required for every document of this type
- Conditional gaps — required because a trigger was detected in the document or metadata (jurisdiction, data categories, deal value)
- Not applicable — checklist items explicitly skipped when triggers are absent
When type is unknown, returning nothing is the correct behavior. Reviewers should re-run detection after manual type assignment or after full draft from metadata populates a skeleton where type is explicit in front matter. Feeding an misclassified type produces gaps that look authoritative but reference the wrong checklist; empty output preserves trust in the signal.
Where this fits in the review workflow
Missing clause detection is most valuable at intake and pre-negotiation:
- Intake triage — route incomplete third-party paper to the right playbook owner before counsel opens the file
- Counterparty paper review — produce a punch list of what the customer's paper still lacks relative to policy
- Renewal and amendment checks — confirm an amendment did not drop a previously required clause from the base agreement
- Handoff to drafting — gaps become instructions; counsel or a drafting workflow fills them using approved language from clause library retrieval
Counsel still drafts. The gap report does not insert boilerplate, select fallback tiers, or send redlines. It reduces time spent manually scanning for "do we have an indemnity?" and concentrates human effort on judgment calls: accept a gap, negotiate replacement language, or escalate.
Quality outcome here means fewer executables ship with silent omissions. A signed agreement without a required limitation-of-liability clause or without an acceptable confidentiality term is a downstream liability. Structured gap IDs make audit trails straightforward: reviewers can show which checklist version was applied and which items remained open at approval.
Vendor landscape
Major contract lifecycle and legal AI platforms expose checklist or obligation-style comparison, though product naming and depth vary.
Ironclad supports playbook and clause logic tied to workflow stages. Missing-element detection typically flows through Ironclad AI or playbook rules that compare uploaded documents against configured requirements, with results surfaced in review tasks before approval routing.
Icertis emphasizes obligation management and clause libraries at enterprise scale. Contract type and clause expectations often live in the Icertis Discover and authoring stack; gap-style outputs feed negotiation and compliance tracking when third-party paper is onboarded.
LegalOn focuses on pre-signature review against customer playbooks. Its review products highlight absent or non-compliant clauses relative to configured standards, aligned with the assess-stage gap report pattern described here.
Conga (Contracts and CLM) combines template-driven generation with incoming document review. Checklist comparison against approved clause sets supports sales and legal ops teams validating vendor or customer paper before sync to CRM or ERP records.
None of these vendors replaces counsel judgment out of the box. Configuration quality determines usefulness: stale checklists, wrong type mappings, and untested conditional rules produce noise. Treat vendor AI as an execution layer for the same checklist IDs and section logic the legal team already maintains.
Implementation notes
Checklist governance. Version checklist libraries and record the version ID on each gap report. When policy changes, re-run assess-stage jobs on open deals rather than assuming old reports remain valid.
Human-readable IDs. Stable checklist item IDs should survive rewording of requirement labels. Reports, dashboards, and integrations key off IDs; labels are display text only.
Confidence thresholds. Publish internal rules for when type classification is "unknown" versus when a best-guess type is shown with a warning. Defaulting to empty on low confidence avoids the worst failure mode: confident wrong-type gaps.
Integration with downstream use cases. Gaps feed drafting (full draft from metadata), library pulls (clause library retrieval), and risk review (clause risk classifier) without duplicating their outputs. Assess stays read-only and inventory-focused.
Metrics. Track gap count at intake versus gaps remaining at execution, time from intake to first counsel review, and recurrence of the same checklist IDs across counterparty templates. Repeated gaps on the same vendor paper indicate a negotiation or template problem, not a model problem.
Missing clause detection turns a manual "read the whole agreement against the policy memo" step into a structured, repeatable assess output. It improves quality by making omissions visible early, traceable by checklist ID, and actionable without crossing into automated drafting or approval.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first