TL;DR: Traditional RAG breaks legal documents into meaningless chunks. Tabular document review uses a three-stage pipeline (knowledge graph enrichment, span-level semantic search, and extractive entity linking) to enable portfolio-scale structured analysis with zero hallucinations and full traceability.
The Problem With Legal AI Today
Vyzkoušejte HAQQ AI zdarma
Zažijte sepisování a rešerše s podporou AI
Most legal AI tools work like this: you upload a document, ask a question, get an answer. It's a glorified search engine with natural language on top. And for simple tasks (summarizing a clause, finding a definition) it works fine.
Key facts
- Tabular document review replaces chunk-and-retrieve RAG with a three-stage pipeline: knowledge-graph enrichment, span-level semantic search, and extractive entity linking (EXTERNAL-CITE: Isaacus tabular review cookbook, cited in article).
- HAQQ is building portfolio-scale structured legal analysis across 200+ jurisdictions and 17,000+ legal teams.
But real legal work isn't about answering one question at a time. It's about systematic review: reading 200 contracts, extracting the same 15 data points from each, spotting patterns across a portfolio, and doing it with zero hallucinations because your client's deal depends on it.
This is where traditional RAG (Retrieval-Augmented Generation) breaks down. Chunking a contract into 500-token blocks and embedding them into a vector store loses the very thing that makes legal documents meaningful: their structure.
A force majeure clause doesn't exist in isolation. It references defined terms from Section 1, interacts with termination provisions in Section 12, and its enforceability depends on the governing law clause buried in the miscellaneous section. Flatten that into chunks, and you've destroyed the relationships that a lawyer would use to actually analyze the document.
Tabular Review: A Different Architecture
The Isaacus team recently published a cookbook for tabular document review that demonstrates a fundamentally different approach. Instead of chunk-and-retrieve, it follows a three-stage pipeline.
Stage 1: Enrichment (Turn Documents Into Knowledge Graphs)
The first step isn't embedding. It's understanding. Using hierarchical document segmentation (Isaacus calls their schema ILGS: Isaacus Legal Graph Schema), the system segments documents by semantic structure, not arbitrary token counts. It extracts entities: persons, organizations, locations, dates. It maps relationships between entities and document sections. It preserves cross-references and hierarchical nesting.
The output isn't a bag of chunks. It's a structured graph where every entity is linked to the spans of text that define it, and every section knows its children.
# Not: split_into_chunks(document, size=500)
# Instead: understand the document's own structure
response = client.enrichments.create(
model="kanon-2-enricher",
texts=batch,
overflow_strategy="auto"
)
# Returns: entities, segments, relationships, cross-referencesStage 2: Span-Level Semantic Search
Once you have structured segments, you embed those, not arbitrary chunks. This means your retrieval operates on semantically meaningful units that the document itself defines.
The system uses Qdrant for vector search, but with a critical design choice: parent spans win over overlapping children. When a query matches both a full clause and a sub-clause within it, the system returns the larger context. This prevents the fragmented, context-poor results that plague naive RAG systems.
Stage 3: Extractive Entity Linking
This is where it gets powerful for tabular review. When you ask 'Who are the parties to this agreement?', the system doesn't generate an answer. It extracts answer spans from the source text, then cross-references them against the knowledge graph's entity database.
The result: every cell in your review table links back to the exact source text, with entity resolution across the entire document. No hallucinations. Full traceability. The lawyer can click any answer and see exactly where it came from.
Why This Matters for Legal AI Positioning
Here's the part that most legal tech companies get wrong: they position themselves as tools that do legal work. 'Upload your contract, get a summary.' 'Ask our AI a question, get a citation.' That's useful, but it's commoditized. Every LLM can summarize a contract. The differentiation isn't in the output. It's in the reasoning architecture underneath.
The Researcher vs. The Assistant
Think about how a junior associate reviews a data room. They don't read each document in isolation. They build a mental model of each document's structure, extract structured data into a review matrix, cross-reference findings across documents, trace every finding back to its source, and flag anomalies based on patterns across the corpus.
This is research methodology, not question-answering. And it's exactly what the tabular review architecture enables at machine scale.
At HAQQ, we've built our legal AI around this same principle. Our Justinian engine doesn't just answer questions. It constructs a 'digital fingerprint' of each firm's legal knowledge: their precedents, their clause preferences, their jurisdictional expertise. When a lawyer uses HAQQ to draft a contract or research a case theory, the system isn't searching a generic database. It's reasoning over a structured representation of that firm's accumulated legal intelligence.
From Practice Management to Legal Intelligence
This is also why we built HAQQ as a full legal operating system, not just a chat interface. When your AI has access to the firm's matter workspaces, contacts, document library, and double-entry accounting records through eFirm, it can build richer knowledge graphs. A contract review doesn't just extract parties and dates. It can cross-reference against the opposing counsel and court fields on past matters, flag clauses that differ from the firm's standard playbook, and surface relevant precedents from the hearing and matter-log history behind them.
The 16 free tools on our website, from NDA generation to contract clause checking, aren't just lead magnets. They're entry points into this structured legal reasoning pipeline. Every tool that processes a legal document is an opportunity to demonstrate what happens when AI actually understands legal structure rather than pattern-matching against it.
The Technical Moat
What makes this approach defensible isn't any single component. Vector databases, embedding models, and extractive QA are all available off the shelf. The moat is in three places:
- Legal-domain segmentation: Generic NLP tools don't understand that a 'Representations and Warranties' section has a specific hierarchical structure, or that 'Section 4(b)(iii)' is a cross-reference, not a parenthetical.
- Entity resolution across documents: When you're reviewing 200 contracts and 'Acme Corp', 'ACME Corporation', and 'the Company' all refer to the same entity, you need legal-aware entity linking, not just string matching.
- Firm-specific knowledge accumulation: Every document processed, every clause preferred, every correction made by a lawyer feeds back into the firm's knowledge graph. The system gets smarter in ways that are specific to that firm's practice.
What's Next
The tabular review pattern points toward where legal AI is headed: away from single-document Q&A, toward portfolio-scale structured analysis with full provenance.
- Due diligence that produces audit-ready review matrices, not chat transcripts
- Contract management that maintains a living knowledge graph of all active agreements
- Case research that builds structured argument maps, not lists of citations
- Compliance monitoring that systematically extracts and tracks obligations across regulatory filings
At HAQQ, we're building toward this future across 200+ jurisdictions and 17,000+ legal teams. The firms that will win the next decade aren't the ones with the best chatbot. They're the ones whose AI actually thinks like a legal researcher.
