Blackletter: Legal Document Intelligence

A retrieval-augmented system for interpreting statutes, contracts, and procedural material, built so every output stays traceable to a source.

Problem

Legal text is the worst case for a language model. It is long, hierarchical, full of internal cross-references, and the cost of a confident wrong answer is high enough that a plausible-sounding summary is worse than no answer at all. General-purpose retrieval flattens exactly the structure that makes the text mean what it means.

Approach

Hierarchical parsing preserves the document structure that cross-references depend on, so a retrieved passage arrives with the section context it needs. Retrieval-augmented generation grounds every claim in specific source text, validation layers check that generated statements are supported by what was retrieved, and the workflow routes claims, objections, and procedural arguments to human review rather than presenting them as settled.

Result

Statutes, contracts, and procedural material are made queryable with the source of each answer visible, so a reviewer can check the reasoning rather than accept it. The system is built to decline rather than guess when retrieval does not support an answer.

Traceability as the design constraint

The controlling requirement is not answer quality in the average case. It is that a reader can always see which source text produced a given statement. Ungrounded output is not a degraded answer in this domain; it is a liability. That constraint drives everything else in the architecture.

Why hierarchical parsing

A statute section means what it means partly because of where it sits. Flat chunking splits a subsection from its parent and loses the definitions and qualifications that govern it. Parsing the hierarchy first means a retrieved passage carries its context, so the model reasons over a complete unit rather than a fragment that reads coherently while omitting the clause that changes it.

Declining to answer

Validation checks whether retrieved material actually supports a generated claim. When it does not, the correct output is to say so. A system that always produces an answer is indistinguishable from one that produces a wrong answer, which is why the review workflow treats every claim as provisional until a person confirms it.

Stack

Python
NLP
RAG
Document AI