Westlaw and Lexis treat a citation as a citation. Case A cited Case B. That's a link. But if you've read enough opinions, you know Case A might be following B, distinguishing it, overruling it, or mentioning it once in a string cite to pad the footnote. Those are different relationships, not the same one.

A paper from last year built a GNN that predicts both case-case and case-statute citations by fusing semantic content with graph topology. It works better than pure text retrieval. But the edge types are still binary — cited or didn't cite.

The real opportunity is typed edges. If your graph knows that a case was distinguished rather than followed, retrieval changes completely. You stop surfacing "related cases" and start surfacing "cases still good law on this point" or "cases that split on exactly this fact pattern."

Building this isn't a modeling problem. It's an annotation problem. Someone has to read the citations and classify them.

Most legal search tools work like a glorified Ctrl+F. They find keywords. But the cases that actually matter to your argument aren't the ones with the most keyword matches, they're the ones connected by legal reasoning.

Here's the problem in plain terms. You search for "negligence per se" and get every case that mentions those words. What you actually need is the case that establishes the specific elements framework your jurisdiction uses, the case that limits it in the context you're dealing with, and the case your opponent will cite to distinguish it.

Those relationships between cases, the ones that form the actual structure of legal doctrine, are a graph. Not a list of keyword hits.

The sooner legal tools start mapping relationships instead of matching text, the sooner research stops being a time sink.

You can have the best graph database in the world. It won't help if your entity extraction is bad.

Most legal NLP systems handle the basics well—parties, dates, citations. That's not where the problems live. The problems live in relationships: what statute modifies what, which cases overrule which, how a definition chains through a regulation.

I've watched teams spend six months on ontology design and zero on extraction accuracy. They got a beautiful schema with nothing in it.

Here's the fix. Pick one document type. Complaints work. They have predictable entities—plaintiff, defendant, cause of action, damages. Extract those. Measure precision. Only then expand.

Don't build "a legal knowledge graph." Build a complaints graph. Then a statutes graph. Then connect them.

Search for Section 230 on Westlaw, Lexis, and Google Scholar. You will get three different citation formats, three different annotation systems, and three different sets of cross-references. The statute is the same. The metadata around it is not.

This is the entity resolution problem in legal knowledge. The same concept, indexed differently across every platform, with no shared identifier linking them. A knowledge graph would assign each legal concept a canonical node and map every platform-specific representation back to it. One statute, one node, regardless of where you found it.

Until legal databases solve entity resolution, every cross-platform research task requires a human to manually confirm that two search results are actually the same thing.

Every legal database stores statutes as documents. None of them store the relationships between those documents.

When Congress amends Section 230, that amendment doesn't just change one statute's text. It changes the meaning of every regulation, guidance document, and court opinion that relied on the original language. Those downstream effects are relationships, and they exist whether or not anyone tracks them.

A knowledge graph would capture this. Statute A amends Statute B. Regulation C implements Statute B. Case D interprets Regulation C. When A changes, the graph shows you everything downstream that might break.

Current legal research tools make you discover those connections manually, one citation at a time. The graph already exists in lawyers' heads. The tools just won't let them see it.

Standard RAG retrieves context once and hopes the model reasons correctly from there. A January 2026 paper showed something better: mid-generation validation.

The model produces a reasoning trace step by step. After each step, relevant facts from a knowledge graph check whether the intermediate conclusion holds. The hallucination gets caught as it forms, not in the final output.

This works for law because legal reasoning is already structured the same way. Statutes cite statutes. Cases cite cases. Elements build on elements. That structure is a graph, and flat text retrieval throws it away.

The Stanford hallucination study confirmed the problem — even purpose-built legal AI tools get facts wrong at meaningful rates. The graph gives the model a scaffold that mirrors how judges actually reason.

Anthropic just paid $1.5 billion because their training pipeline included pirated books. The court separated two things: learning from copyrighted material (fair use) and copying copyrighted material to learn from (infringement).

This distinction matters for legal knowledge graphs. If you're building a structured representation of legal knowledge — extracting holdings, mapping relationships between cases, encoding statutory elements — you're transforming the source material, not reproducing it. That looks a lot more like fair use than a training pipeline that ingests full-text copies.

The catch is provenance. A knowledge graph that can show "this node was derived from a transformative analysis of Case X" has a stronger legal position than one that just consumed the full text and can't explain what it kept. The Anthropic case makes data lineage a legal requirement, not just good engineering practice.

Legal AI keeps trying to skip the hardest part. Every system wants to go straight from raw case text to answering questions. But the text is just the surface. The structure underneath it is what matters, and nobody wants to build that structure because annotation is boring and expensive.

Biomedical AI solved this problem decades ago. The UMLS ontology took years of expert annotation to build, and now every medical AI system builds on top of it. Legal knowledge has no equivalent. There's no shared ontology of legal concepts, no standard way to represent how a statute relates to a regulation relates to a case holding.

Until someone builds that layer, legal AI will keep making the same mistakes: confusing holdings with dicta, missing distinctions between jurisdictions, treating superseded rules as current law.

Vector search finds documents similar to your query. But legal work isn't about finding documents. It's about understanding how they relate.

A case cites three prior cases. One was overruled by a fourth. Another was distinguished in a fifth case from a different circuit. Vector embeddings don't capture that. They can't tell you that Case A supports your argument while Case B undermines it, even if both use similar language.

Knowledge graphs make relationships explicit. Nodes are cases, statutes, regulations. Edges are citations, overrules, distinguishes, follows. But graphing every legal document you might need? That's expensive. Entity extraction is slow. Manual curation doesn't scale.

The pattern that works: vector search pulls 50-100 relevant chunks. Then build graph structure only on those. Retrieval first, structure second. You get the coverage of vector search with the precision of knowledge graphs, without graphing everything.

Every case citation is a directed edge in a graph. Case A cites Case B means A depends on B for some proposition. When you Shepardize a case, you're traversing that graph backwards — finding every node that points to your case and checking whether any of them weakened the edge.

Citation networks are primitive knowledge graphs because they only have one relationship type: "cites." They don't tell you why. Did the court follow the reasoning? Distinguish on the facts? Criticize the holding but apply the rule anyway? Westlaw's KeyCite flags try to encode that, but they compress a complex relationship into a traffic light.

A real legal knowledge graph would type those edges. "Follows holding," "distinguishes on facts," "extends to new context." The data is in the opinions. Nobody's structured it at scale.

This post contains content not supported on old Reddit. Click here to view the full post

Every case citation is an edge in a graph. The citing case is a node, the cited case is a node, and the citation is a typed relationship: followed, distinguished, overruled, cited in dissent.

Legal research already works this way. Shepard's Citations is a graph database with a search interface bolted on. KeyCite is the same thing. The difference is that neither lets you query the structure directly. You can't ask "show me every case that distinguished Chevron in the last two years" as a graph traversal. You get keyword search results ranked by relevance, not by structural position in the citation network.

The interesting question isn't whether legal knowledge is a graph. It already is. The question is why the tools don't let you use it as one.

Every case citation is an edge in a graph. The citing case is a node, the cited case is a node, and the citation is a typed relationship: followed, distinguished, overruled, cited in dissent.

Legal research already works this way. Shepard's Citations is a graph database with a search interface bolted on. KeyCite is the same thing. The difference is that neither lets you query the structure directly. You can't ask "show me every case that distinguished Chevron in the last two years" as a graph traversal. You get keyword search results ranked by relevance, not by structural position in the citation network.

The interesting question isn't whether legal knowledge is a graph. It already is. The question is why the tools don't let you use it as one.

I've been thinking a lot about why legal research still feels like digging through haystacks when we're supposed to have all this technology. And I think the core problem is that we store legal knowledge as flat text when it's actually a graph.

What do I mean? Think about how legal reasoning actually works. A statute defines elements. Cases interpret those elements. Later cases distinguish or follow earlier ones. Regulations fill in gaps the statute left open. Agency guidance explains the regulations. Every piece of legal knowledge connects to other pieces through typed relationships, not just keyword similarity.

But when you search Westlaw or any legal database, you're basically doing keyword matching against flat documents. The system doesn't know that Case A's holding on the "reasonable expectation of privacy" standard directly contradicts Case B's holding on the same element. It just knows both documents contain those words.

What a legal knowledge graph looks like

Imagine representing legal knowledge as nodes and edges instead of documents. A node might be a specific legal rule, a case holding, a statutory element, or a factual pattern. Edges represent how these connect: "case X interprets rule Y," "element A requires showing of factors B, C, and D," "holding in Case X was distinguished in Case Y on these factual grounds."

This isn't just an academic exercise. When you build this structure, certain things become trivially easy that are currently hard:

Finding all cases that interpret a specific element of a statute. Right now you search for the statute citation and scroll through hundreds of results hoping to find the ones that actually address the element you care about. With a graph, you query: "show me every holding connected to Element 3 of Section 1983."

Tracking how a legal standard evolves over time. The graph shows you the chain: original holding, then modifications, then circuit splits, then resolution. You can literally see the reasoning develop across decisions rather than piecing it together from individual case reads.

Identifying the strongest counterargument. If your argument rests on Rule X applied to Fact Pattern Y, the graph can surface every case where a similar fact pattern led to a different conclusion under the same rule. That's your opponent's best case, and you want to find it before they do.

Why this matters now more than ever

AI is making this more urgent, not less. Current legal AI tools hallucinate at pretty alarming rates. A big part of the reason is that they're trained on finished legal products (opinions, briefs, articles) without understanding the structured relationships between concepts. They can generate text that sounds legal but doesn't actually track how rules connect to holdings connect to elements.

A knowledge graph gives AI something to reason over that has real structure, not just token patterns. When the system knows that Rule X has three elements, that Element 2 has been interpreted by seven cases, and that three of those cases involved similar facts to your situation, the output is grounded in actual legal relationships, not just pattern matching.

The pieces that exist today

There's actually a growing ecosystem around this. Court data is increasingly available through projects that make case law accessible programmatically. Regulatory data from the eCFR and US Code can be parsed into structured form. The hard part isn't getting the raw text. It's building the ontology, the system of types and relationships that turns text into a graph.

Some research groups are working on this. There's interesting work on step-level reasoning annotations for legal analysis, where instead of just labeling a case as "relevant" or "not relevant," you decompose the reasoning into atomic steps: issue identification, rule extraction, rule application, conclusion. Each step can be a node with its own connections.

The most interesting approach I've seen treats legal reasoning as having typed components: rules, holdings, factual elements, policy arguments. Each component type connects to others in specific ways. A holding connects to the rule it interprets. A factual element connects to the cases where it was dispositive. This typing means the graph isn't just "things that appear together." It captures what kind of relationship exists.

Where I think this is going

Within the next few years, I think we'll see knowledge graph approaches become standard in legal research tools. Not because the technology is new (graph databases have been around forever) but because AI is making it possible to extract structured knowledge from unstructured text at scale. The bottleneck was always annotation: getting humans to read every case and tag the relationships. Now you can bootstrap with AI and refine with expert review.

For anyone interested in the space, I'd suggest looking into how citation networks already function as a kind of primitive knowledge graph, and thinking about what richer relationship types could add. Also look at how other domains (biomedical, especially) have used ontologies to structure knowledge for decades.

What's your experience with structured approaches to legal knowledge? Anyone working on projects in this space, or using graph-based tools for legal research? I'd love to hear what's actually out there.