Last year, a lawyer at a large international law firm spent five to eight hours reading a 53-page GDPR lawsuit, manually extracting parties, mapping claims to evidence, and building a mental model of how 73 statutory citations related to each other. adorsys built a system that does the same job in 39 minutes, with every finding linked back to its exact source passage. The same AI tools that promised to transform legal work are also producing invented case citations in court filings at a rate that has triggered over 700 sanctions cases worldwide.

The gap between those two outcomes is not a matter of which AI model you use. It is a matter of architecture. General-purpose AI treats legal text like any other text: it summarises, it infers, it generates plausible-sounding answers. What it cannot do is prove where those answers came from. And in law, an answer without a source is not an answer at all.

The problem isn't the model

The dominant response to legal AI failures is to wait for better models. Hallucinations will decrease, reasoning will improve, and the next release will get it right. This misses the structural issue.

LLMs are probability engines. They generate text that is statistically plausible given everything they have been trained on. For most tasks, that is fine. For legal work, it is dangerous: plausible-sounding legal text that is factually wrong is worse than no answer at all. Research published in the Journal of Legal Analysis found that leading LLMs produce hallucinated, factually wrong answers to specific legal questions in 69% to 88% of cases, depending on the model. Stanford's HAI identified three reasons why this happens: training corpora compress legal doctrine into statistical averages, model knowledge lags current case law by years, and LLMs accept and elaborate false premises rather than correcting them.

The legal profession's response has been institutional. ABA Formal Opinion 512, issued in July 2024, established that existing professional conduct rules apply fully to AI-assisted legal work. Supervising attorneys must review AI-generated work product before it leaves the firm, and that review must be logged. Courts are enforcing this: a 6th Circuit panel imposed $30,000 in sanctions against two attorneys for 24 fabricated citations; a Colorado attorney received a 90-day suspension. The requirement is not only accuracy. It is also traceability. Legal practice needs both: answers that are factually correct and a clear chain of evidence behind each one. An AI answer that is accurate but cannot be traced to its source is still professionally unusable. An AI answer that can be traced but is wrong is dangerous. Courts, clients, and disciplinary committees require both at once.

Standard retrieval-augmented generation (RAG) reduces hallucinations but does not resolve this. A RAG system can retrieve the right statute and still misrepresent its provisions, and the output arrives as text with no inherent provenance. What legal practice requires is a system where every answer is structurally linked to a verifiable source from the start.

Certain legal instruments are already graphs

To be precise about what can and cannot be encoded as a graph: not all of law is amenable to this approach. Law's substantive content, including rights, duties, values, the political choices embedded in a statute, cannot be reduced to data. "Human dignity is inviolable" is a normative position, not a database entry. That substance is the domain of jurists, legislators, and courts. And not every legal document follows the same internal structure: a commercial arbitration record, a constitutional court ruling, and an administrative regulation are built on different logics and require very different treatment.

What does have inherent graph structure is a specific and important category: codified statutes and regulatory frameworks. The German Civil Code (BGB), the GDPR, the German Protection Against Dismissal Act (KSchG). These instruments are built from numbered provisions that reference each other explicitly and connect through conditional logic. §242 BGB, Art. 22 GDPR, §14 Abs. 2 Nr. 3 KSchG are structured identifiers that function like node IDs in a database. The conditional logic that links them, "this obligation applies unless...", "except where the conditions in paragraph 3 are met...", is a graph of dependencies written in plain sight.

This means the approach must always be domain-specific. Construction law, employment law, data protection regulation: each has its own conceptual vocabulary, its own relationship types, its own patterns of cross-reference. There is no universal legal ontology. Each legal domain requires its own schema, its own extraction logic, and its own validation against real documents from that domain. A Knowledge Graph doesn't impose a single structure on all of law. It reveals the specific structure that a given body of law already has, once you look for it.

Within that scope, the representation is powerful. Nodes capture legal entities: provisions, obligations, parties, evidence items, case law references. Edges capture the relationships between them: "references", "amends", "provides exception for", "is violated by", "establishes liability under". Stored in a property graph database, those relationships become directly traversable. Ask "which GDPR articles govern this automated decision-making system, and what are the exceptions?" and the graph follows the edges to a complete, auditable answer.

Two recent papers demonstrate this concretely. A 2024 study modelling Italian legislation in a property graph found that queries previously impractical on raw text, including measuring legislative coherence, tracking amendment chains, and mapping cross-referential complexity, became straightforward once the law was encoded as a graph. A 2025 paper confirmed that flat-text retrieval is "blind to the hierarchical, diachronic, and causal structure of law," producing outdated answers when legislation has changed, and proposed ontology-driven graph retrieval as the structural fix.

The THEMIS case: what it looks like in practice

In 2025, adorsys built THEMIS (Tool for Handling, Extracting, Mapping & Intelligent Structure-analysis) for a leading international law firm with a presence in more than 30 countries. The challenge was familiar: lawsuit documents running to 40-80 pages, containing layered claims, factual assertions, evidentiary references, and statutory citations all interwoven in free-form prose. Initial analysis of a single document required five to eight hours of associate time at billing rates of €181-276 per hour.

The system we built processes a PDF, extracts entities and relationships using LLMs, and stores them in a Neo4j property graph with a 13-type legal ontology covering lawsuits, claims, evidence, persons, legal statutes, events, and more. Applied to an anonymised 53-page GDPR lawsuit, THEMIS extracted 448 entity nodes and 1,630 semantic relationships in approximately 39 minutes.

The decisive design choice was provenance. Every answer the system produces links back through the graph to the specific passage in the original PDF. Lawyers can read the cited text, verify the inference, and document the review. This is the audit chain ABA Formal Opinion 512 effectively requires. The result: 85-94% reduction in analysis time, cost per document reduced from €905-2,208 to approximately €90-140, and estimated annual savings of €75,000-205,000 per firm handling 100 documents per year. The client described it as having "enormous potential to disrupt the legal market.".

The accuracy numbers reflect this directly. A 2025 study at ACM ICAIL measured how often legal AI systems answered questions correctly: hybrid Knowledge Graph plus RAG systems reached 70%, against 37.5% for RAG-only. On tasks that require following chains of statutory cross-references, the gap is wider still: graph-enhanced systems exceed 85% accuracy where conventional RAG reaches 32-75%.

Answer Accuracy by Architecture - Legal Document Task

That 85% raises two questions the industry is still working through. First: what does it already enable? For document triage, first-pass claim extraction, and structured querying across a large filing, 85% accuracy on multi-hop reasoning tasks is likely sufficient. Lawyers review and verify every provenance-linked result before it informs an argument or a filing. The system reduces the search space and structures the evidence. The lawyer closes the remaining gap with judgment.

The second question is harder. What does the missing 15% cost? In adversarial proceedings, an unidentified statutory exception or a missed cross-reference can change the outcome of a case. That gap tends to concentrate in the places where legal reasoning is most contested: novel fact patterns, genuinely ambiguous provisions, multi-party liability structures where the graph itself is disputed. These are not edge cases to optimize away. They are the core of what experienced lawyers are paid to argue.

The architecture works not because it is more sophisticated, but because it matches the structure of the problem. And the 15% tells you where that structure alone is not enough.

Three places where this changes the calculus

Public sector change management.

Consider Germany's unemployment benefit system. Every calculation it runs is grounded in the Social Security Code. When the legislature changes benefit rates or eligibility criteria, every IT system that touches that calculation has to change too: the benefit calculator, the application portal, the case management system, the internal eligibility rules. The same is true for permit approvals, tax assessments, visa eligibility checks: any digital service that operationalises legal rules inherits a dependency on the law it implements. Currently, discovering the full scope of that dependency when legislation changes is largely manual: program managers ask system owners, who check documentation that is months or years out of date. New South Wales in Australia demonstrated a cleaner model: a Rules as Code engine encodes legislation as machine-readable rules, and a single update propagates instantly to all linked services. Germany's federal innovation agency SPRIND has made Law as Code a national strategic project, with a target that machine-readable publication becomes the binding standard for new German legislation by 2028. The implication is direct: if the code implementing a public service is linked to the specific statutory paragraph it implements, a legal change becomes a traceable engineering task rather than an undiscovered liability.

Compliance in a multi-regulation environment.

The convergence of GDPR, NIS2, DORA, and the EU AI Act has created compliance obligations that overlap and cross-reference in ways that are structurally identical to the graph traversal problem. A supply chain incident can simultaneously trigger reporting requirements under all four frameworks, each with different timelines and regulators. Currently, 77% of compliance teams still rely on manual processes for regulatory change management, with discovery lags measured in weeks and evidence scattered across spreadsheets and shared drives. Knowledge graphs let compliance teams model regulatory provisions as named nodes and map explicit relationships between legal obligations and the internal systems, contracts, and processes they govern. GRC platforms built on knowledge graph architectures have reported significant reductions in compliance analysis time and audit preparation effort, with cascading impact analysis replacing the manual process of interviewing system owners one by one.

Contract analysis.

Commercial contracts are private legal structures with the same graph properties as statutory law: obligations, conditions, exceptions, and defined terms that chain through clauses to consequential effects. The same extraction and ontology approach that works for statutes works here. Knowledge Graph architectures applied to contract portfolios enable the same capabilities: structured querying across hundreds of documents, provenance-linked answers, and cross-document reasoning that flat-text search cannot support.

What this actually takes

To understand what THEMIS solves, it helps to understand what large-scale litigation actually looks like from the inside. An enterprise court case is not one document. It is hundreds, sometimes thousands of pages: the original claim (Klage), the counter-party's response (Erwiderung der Klage), supporting evidence, witness statements, referenced prior rulings, statutory foundations. When the counter-party files their response, the law firm representing the client has to deploy a team of lawyers for weeks or months to work through it: identifying every argument made, matching each argument to the evidence cited, tracing references back to the original claim, and assessing where the counter-arguments are strong or weak. Every step is manual. Every cross-reference has to be found and evaluated by a human reading pages of dense legal prose.

THEMIS was built to change that workflow, not replace it. The system processes the documents, extracts the structured content (parties, claims, evidence items, legal statutes, case law references) and builds the graph of relationships between them. Lawyers then work with that structured representation instead of raw text: they can query across the full document set, jump directly to the evidence behind any argument, and see at a glance how the counter-party's claims map against the original filing. The work that previously took a team of full-time lawyers several months can be done faster, with fewer people, and without losing the quality of analysis that complex litigation demands.

The scope was defined precisely from the start. THEMIS covers a single, well-defined document type: civil and labour lawsuit documents filed at German courts. Its 13-type ontology covers the entities that appear in those proceedings: parties, claims, evidence, legal statutes, case law references, financial amounts, court filings, across employment, construction, tenancy, traffic, and family law cases. That specificity is what made a four-month delivery timeline realistic with a team of two engineers and one client domain expert. The system does not try to represent all of law; it accurately represents one high-value slice of it.

The tooling is open-source and production-ready: Neo4j for graph storage, Graphiti Core for LLM-powered extraction, Docling for PDF parsing. No custom LLM training is required. The real constraint is skills: graph database expertise remains relatively rare, and legal ontology design requires genuine legal domain knowledge alongside the technical work. But those constraints are bounded. The lawyers remain essential throughout, interpreting findings, making arguments, and exercising the judgment that no system replaces.

The Window is open now

The technology for this is not a future roadmap item. The tooling is open-source and production-ready. The methodology has been validated in practice. Tools like Catala and LegalRuleML are already implementing the next step beyond retrieval: systems that execute legal rules directly, computing whether a statutory obligation is triggered, what the penalty is, and which exceptions apply. France's OpenFisca already does this for tax and social benefit calculations, used by governments in France, New Zealand, and Tunisia. Germany's 2028 target for machine-readable legislation is a marker of when this will be a baseline expectation, not a differentiator. The question is not whether to build these capabilities. It is whether to build them now or catch up later.

One thing worth stating clearly: AI alone is not enough for this problem. Most of the legal AI tools entering the market use language models natively: they summarise, they draft, they retrieve. That is useful, and the market is growing fast. But language models are probabilistic. For legal work that requires deterministic, auditable answers, you need the neurosymbolic layer: ontologies and Knowledge Graphs that bring structure, control, and verifiability into the AI reasoning process. That combination of structured knowledge representation and language model capabilities is what produces a system lawyers can actually rely on.

The firms that build this way now will have a structural cost advantage. A law firm that can process a counter-party's filing in days instead of weeks, with two analysts instead of ten, and produce a structured analysis that is immediately queryable. That firm works at a different economics than one that still processes everything manually. The new generation of legal practices will be built around exactly these systems. Established firms that wait for a ready-made SaaS product to solve this will find that the product, when it arrives, is already embedded in their competitors.

There are two paths to get started. You can wait for the tool vendors to reach the required capability level and buy when they get there. Or you can build now, with a defined scope, around the specific legal domain where you face the highest volume and the clearest structure, and have a working system, real data, and genuine expertise before the market catches up. THEMIS was built in four months, with a team of three, on open-source tooling. adorsys is available to work through the scoping, the ontology design, and the implementation with organisations ready to move.

References

[S001] adorsys. "THEMIS: AI-Assisted Legal Knowledge Graph for International Law Firms." Internal Case Study, 2025.

[S004] Neo4j. "What Is a Knowledge Graph?" neo4j.com.

[S007] Blair-Stanek, A., Holzenberger, N., Van Durme, B. "Large Legal Fictions: Profiling Legal Hallucinations in Large Language Models." *Journal of Legal Analysis*, Oxford Academic, 2024.

[S008] Stanford HAI. "Hallucinating Law: Legal Mistakes with Large Language Models are Pervasive." hai.stanford.edu.

[S012] arXiv preprint. "Large Legal Fictions: Profiling Legal Hallucinations in Large Language Models." arXiv:2401.01301.

[S013] Merigoux, D., Chataing, N., Protzenko, J. "Catala: A Programming Language for the Law." ACM ICFP 2021. arXiv:2103.03198.

[S014] Merigoux, D., Monat, R., Protzenko, J. "Catala: Moving towards the future of legal expert systems." *Artificial Intelligence and Law*, Springer, 2022.

[S015] Rapson, et al. "Rules as Code for a More Transparent and Efficient Global Economy." CIGI/G7 Task Force, April 2025.

[S016] SPRIND. "Law as Code." German Federal Agency for Breakthrough Innovation.

[S102] legalaigovernance.com. "ABA Formal Opinion 512: A Compliance Guide."

[S103] ABA Journal. "Sanctions ramping up in cases involving AI hallucinations."

[S107] 47Billion. "Graph RAG for Legal Reasoning: Multi-Hop Insights with Knowledge Graphs, Vector Search, and LLMs."

[S108] ACM ICAIL 2025. "Bridging Legal Knowledge and AI: RAG with Vector Stores, Knowledge Graphs, and NMF."

[S114] GraphAware. "Knowledge graphs for regulatory compliance."

[S202] v-comply.com. "Top 5 Compliance Challenges for Teams in 2025."

[S212] Enactia. "The Compliance Triple Threat: Mastering the Overlap Between DORA, NIS2, and the EU AI Act."

[S214] MetricStream. "Knowledge Graphs in Governance, Risk, and Compliance."

[S305] Digital.NSW. "Rules as Code — NSW Joins the Worldwide Movement."

[S306] Code for Australia. "Digital.NSW Rules as Code case study."