Every legal AI demo I've seen does the same magic trick: it answers a question about case law, drops in a citation that looks correct, and the partner in the room nods. Then someone asks me to click the citation. Half the time the case doesn't exist. The other half it exists but doesn't say what the model claims. This is the Mata v. Avianca problem in miniature, and it's why most general-purpose LLMs are unsafe for legal work without a hard architectural constraint: every citation must be reachable, retrievable, and verifiable before it leaves the system.
The fix isn't a better model. It's a pattern. Below is how I build citation-checking into the Intelligence Brain when it's deployed for a legal team — the engineering, the failure modes, and the bits that genuinely matter when the output goes in front of a judge.
Why generative models fabricate citations in the first place
An LLM doesn't store case law. It stores a statistical map of how legal language fits together. When you ask it about O'Keeffe v. Hickey, it knows the case name pattern, the kind of court that decided it, the sort of paragraphs a judgment contains, and roughly the shape of citations from that era. It will happily generate a paragraph that reads exactly like the real judgment. It will also happily invent a paragraph number, a neutral citation, or an entirely new case that sounds like real Irish case law because the surface form is what the model optimises for.
This isn't a bug you can prompt your way out of. "Don't hallucinate citations" is a polite request to a system that has no concept of truth — only plausibility. The architectural fix is to stop asking the model to remember anything. Instead, the model becomes a reader and summariser of documents you've already retrieved, and the system enforces that every citation in the output traces back to a real document the system fetched and parsed.
The pattern: retrieval-grounded generation with citation locks
The pattern has four components, and you need all four:
- A controlled corpus. A vector index plus a structured catalogue of judgments, statutes, statutory instruments, and (where relevant) regulator decisions. For Irish work, this means Courts Service judgments, the Irish Legal Information Initiative, the eISB for legislation, and whatever firm-specific knowledge base the team maintains. Every document has a stable internal ID, the original URL or file path, a hash of the source text, and metadata: court, date, neutral citation, parties, jurisdiction.
- A retrieval step that returns spans, not summaries. When a user asks a question, the system retrieves specific paragraphs — with their paragraph numbers and document IDs — not "the gist of three relevant cases".
- A generation step that can only cite what was retrieved. The model is given the retrieved spans and instructed to produce an answer where every factual claim is tagged with the document ID and paragraph it came from. The output schema enforces this — it's not a request, it's a structured output the model must conform to.
- A post-generation verifier. A separate process that takes every citation in the output, looks it up in the catalogue, fetches the underlying paragraph, and checks two things: (1) does the citation resolve to a real document; (2) does the cited paragraph actually support the claim. If either check fails, the claim is stripped or flagged before the user sees it.
The verifier is the bit most teams skip. It's also the bit that makes the difference between a system you can put in front of a partner and a system that occasionally embarrasses you.
Building the verifier: what "reachable" actually means
"Reachable" has three layers, and each catches a different class of failure.
Layer 1: existence. The citation string parses to a known document in the catalogue. Director of Public Prosecutions v. Gormley [2014] IESC 17 resolves to a specific judgment ID. If it doesn't resolve — if the neutral citation is malformed, or refers to a case the system has never indexed — the citation fails. This catches pure hallucinations: invented case names, wrong years, transposed citation numbers.
Layer 2: retrievability. The system can fetch the actual text of the cited paragraph right now, from the original source or a cached copy with matching hash. If the document exists in the catalogue but the paragraph number is out of range, that fails too. This catches a subtler failure where the model picks a real case but invents a paragraph reference.
Layer 3: support. The cited paragraph genuinely supports the claim attached to it. This is where you need a second model call — a small, focused entailment check. You give it the claim and the paragraph and ask: does this paragraph support, contradict, or is it neutral on this claim? Anything that isn't "support" gets flagged. This catches the most dangerous failure: a real case, a real paragraph, but the paragraph says something different (or even the opposite) from what the answer claims.
Layer 3 is computationally expensive and you have to be careful about which model you use for it — ideally one trained or fine-tuned for natural language inference, not the same generative model that produced the answer. Otherwise you're asking the student to mark their own homework.
Handling Irish case law specifically
Irish case law has quirks that break naive systems. Neutral citations only became standard from 2001 onwards, so older cases rely on report series — the Irish Reports (IR), Irish Law Reports Monthly (ILRM), and others — which need parsing rules of their own. The Supreme Court, Court of Appeal (post-2014), and High Court each have their own neutral citation patterns. Unreported judgments still circulate and they need their own handling: a delivery date, the judge, and a document hash become the de facto identifier.
Then there's the EU layer. Irish courts cite CJEU and ECtHR judgments routinely, and a serious legal AI for Irish work has to resolve those citations against EUR-Lex and HUDOC respectively. If a system answers a GDPR question for an Irish controller and cites Schrems II without a working link to the actual CJEU judgment, it isn't doing its job.
I've written more about how the Intelligence Brain for legal teams handles the Irish-specific corpus — the indexing strategy, the paragraph-level retrieval, the way unreported judgments are folded in alongside reported ones. The short version: you build the parser around the actual citation conventions Irish lawyers use, not the conventions a US-trained model expects.
Failure modes I've watched happen
A few things go wrong in production that don't show up in test sets.
Stale corpora. A judgment gets reversed on appeal, or a statutory instrument is revoked, and the system happily cites the old position because nobody told it. The fix is a freshness signal on every document and a re-check at retrieval time: is this still good law? For statutes, this means watching the eISB for amendments. For case law, it means tracking subsequent treatment.
Paragraph drift. The same judgment exists in three formats — the official Courts Service PDF, a transcribed HTML version, and a commercial database version — and the paragraph numbering doesn't always match. If your retrieval pulls from one and your verifier checks against another, citations will fail for no real reason. Pick a canonical source per document and stick to it.
Over-confident summarisation. The model retrieves a paragraph that says "the court was not required to decide this point" and summarises it as "the court held X". The entailment check catches this if it's tuned correctly, but it's the most common subtle failure and worth specifically testing for.
Quote fabrication. The model puts something in quotation marks that isn't a verbatim quote. The fix is a string-level check: any text inside quotes in the output must appear character-for-character in a retrieved span, with normalised whitespace. If it doesn't match, strip the quotes or flag the claim.
What this costs and what it buys you
The honest trade-off: a citation-checked system is slower and more expensive to run than a vanilla LLM call. You're doing retrieval, generation, then a second pass of verification. Latency goes up. Compute goes up. For a regulated firm, that's the right trade. The cost of one fabricated citation reaching a court filing is orders of magnitude greater than the cost of a few extra seconds and a verifier model.
What it buys you, beyond not getting struck off, is a system whose outputs are auditable. Every claim in every answer has a document ID, a paragraph reference, and a verification log. When a partner asks "where did this come from?", the answer is a click, not a shrug. That's the actual product. The generation is the easy part. The audit trail is what makes it usable in a regulated environment — which is the whole point of running an on-premise intelligence layer rather than piping client data to a public API.
Where to start this week
If you're a firm thinking about legal AI and wondering whether your current tool is safe, run one experiment this week. Pick ten questions your associates have asked an AI tool in the last month. For each answer, click every citation. Note three things: did it resolve, did the paragraph exist, and did the paragraph actually say what the answer claimed. If any of those three fails on more than one in ten, the tool isn't ready for client work. That's the bar. Everything in this article is a way of building toward that bar — and it's also a fair test for any vendor pitching at you.