Professional work · Legal AI systems / 2026
Evidence-Gated Legal Drafting
Know when the evidence is not enough.
A legal drafting workflow that analyzes source material, detects evidence gaps and contradictions, and uses deterministic rules to decide whether drafting may proceed.
01Drafting goal
A typed session context carries the selected document type, case context, and uploaded file references through the workflow. The requested document determines which evidence elements are required.
02Source analysis
Documents are classified and summarized independently. The workflow builds an evidence inventory, attributes claims to their sources, and retains useful summaries even when the requested draft is unsupported.
03Evidence guardrails
Document-specific checks distinguish supported, missing, not-applicable, and unknown elements. Explicit mismatch rules handle cases where a general scoring threshold would be too weak.
04Feasibility resolver
Application rules—not free-form model output—select READY, PARTIAL_MISMATCH, INCOMPATIBLE, or AMBIGUOUS and return only the actions permitted for that evidence state.
05Controlled draft
Drafting starts only when the resolver permits it. Final validation checks source support, document structure, unresolved contradictions, and unsupported content before delivery.
↳ Ready → draft / partial → limited draft or request material / incompatible → explain mismatch / ambiguous → clarify.
Problem & context
Legal files can contain extensive case information without containing the evidence required for a requested document. Seven litigation filings may support a case summary while providing no expert qualifications, methodology, or opinions for an Expert Report. Treating document volume as evidence sufficiency produces confident but unsupported drafts.
System design
The workflow first identifies the drafting goal, then classifies and summarizes sources, builds an evidence inventory, and evaluates document-specific requirements. Specialized analysis components interpret the material; a deterministic feasibility resolver controls whether the product may proceed, request missing material, offer a limited draft, change the goal, or ask for clarification.
Decision model
READY permits a supported draft. PARTIAL_MISMATCH permits a limited draft only when meaningful relevant evidence exists. INCOMPATIBLE removes that option. AMBIGUOUS requests targeted clarification instead of treating uncertainty as incompatibility. Structured resolver output remains authoritative; the suggestion layer may explain actions but cannot invent new ones.
Failure behavior
A blocked draft still returns source summaries, available evidence, missing requirements, contradictions, and valid next steps. Allegations remain attributed rather than becoming established facts. Missing expert material cannot be replaced by background facts from pleadings, and changing the drafting goal reuses the source inventory while rerunning goal-specific analysis.
Validation & testing
Typed contracts keep analysis, feasibility, and presentation separate. Tests cover routing and resolver behavior, while TypeScript compilation checks service boundaries. Final validation is designed to stop unsupported claims, silent gap-filling, incorrect document structure, and evidence-free contradiction resolution.
Scope
This case study presents a sanitized architecture from professional work. It excludes employer-specific prompts, customer data, deployment details, and unconfirmed infrastructure. It describes evidence-control and workflow design—not legal advice or a claim that language models can independently determine legal sufficiency.
Engineering decision records
01 / Keep feasibility deterministic
Context. A model can interpret evidence but may also rationalize missing material or propose an unsafe action.
Decision. Represent evidence state and allowed actions as typed values resolved by explicit application rules.
Trade-off. Product behavior becomes testable and consistent, while document requirements must be maintained deliberately as supported drafting goals expand.
02 / Preserve analysis when drafting is blocked
Context. An incompatibility response previously risked hiding useful summaries of uploaded material.
Decision. Return source analysis and feasibility together instead of discarding analysis after a blocked decision.
Trade-off. Users retain useful work and understand the gap, at the cost of a richer response contract and more UI states.
03 / Separate missing from unknown
Context. Absent evidence, irrelevant evidence, and failed classification require different next steps.
Decision. Track supported, partial, missing, not-applicable, and unknown evidence states explicitly.
Trade-off. The system can ask focused questions instead of collapsing every uncertainty into a generic upload error.