Suit: The Ontological Layer for Law
Why legal AI needs structure, not just language. How Suit turns messy files into computable legal objects.
Headnote
An ontology teaches a system what the world looks like—not in language, but in structure. Suit reconstructs the internal structure of a legal matter from messy, real-world inputs: parties, filings, dates, events, and relationships. This turns legal work from text processing into computation.
What is an Ontology?
An ontology is a way of teaching a system what the world looks like. Not in language, but in structure. Instead of treating everything as text, an ontology defines the kinds of things that exist in a domain, the properties they have, and the relationships and constraints that govern how they connect.
Most lawyers already work with ontologies. They just don't call them that.
When a lawyer opens a case file, they are not reading prose. They are mapping information onto a mental model: parties, claims, elements, defenses, evidence, dates, and procedural posture. Evidence is not just an attachment. It supports specific assertions and is subject to admissibility rules. A deadline is not just a date. It constrains what actions are legally possible.
The same is true for other structured professions. A chartered accountant does not see spreadsheets. They see transactions, accounts, periods, and compliance thresholds. The work is not reading data. It is applying rules to a known structure.
Key Takeaway
Once this structure exists, reasoning becomes mechanical. Queries stop being vague searches through text. They become traversals over known objects and relationships. Actions stop being free-form. They become state changes that must satisfy explicit rules.
This is why ontologies matter. They turn professional judgment into something systems can operate on. They make it possible to ask precise questions, enforce consistency, and verify that outputs respect how the world is actually allowed to work.
Why does the law break without structure?
Law looks textual, but it does not behave like text. Courts do not evaluate filings by how well they read. They evaluate them by whether formal requirements are met. Elements must be pleaded. Limitation must be respected. Deadlines must be calculated correctly. Authority must actually support the proposition it is cited for. Miss any one of these and the work fails, regardless of how persuasive the writing sounds.
Lawyers compensate for this manually. They carry limitation periods, triggers, exclusions, and tolling rules in their heads and constantly verify against them. That does not scale. It is slow, error-prone, and expensive. The absence of an explicit ontology is why legal software stalls at assistance instead of becoming infrastructure.
An ontology is what makes legal work computable. It gives the system something to reason over besides raw text. Without it, every downstream capability remains fragile.
What Suit actually is in jhana
Suit is jhana's document-intelligence engine, but that description undersells what it does. Suit is not just reading documents. It is reconstructing the internal structure of a legal matter from messy, real-world inputs.
A typical matter file is chaotic. Multiple pleadings. Annexures spanning hundreds of pages. Scanned exhibits. Handwritten notes. Overlapping dates. Repeated facts stated differently across documents. Suit ingests all of this and imposes order. It extracts parties, filings, dates, events, and references. It builds indices so lawyers can navigate the bundle. It constructs timelines so procedural history is explicit.
It also generates comparative tables and compliance matrices. These are not summaries. They are mappings. They line up facts across documents. They align obligations against statutory requirements. They show what is present and what is missing.
Parties
Roles that remain consistentFilings
Procedural effects & linksDates
Limitation clocks & constraintsEvidence
Admissibility & supportClaims
Elements & defensesEvents
Timeline & causationThis is the critical point. Suit is already doing ontology-adjacent work. It is identifying entities, relationships, and constraints implicitly. The opportunity is to make that explicit and canonical, so the structure Suit infers becomes the shared source of truth for the matter.
Key Takeaway
Once that happens, Suit is no longer just a preprocessing step. It becomes the layer that defines what the matter is for the rest of the system.
From extracted structure to a formal ontology
Extracting structure is only the first step. The real shift happens when that structure becomes the authoritative model of the matter.
Suit reaches this by treating a bundle as a connected system, not a collection of files. It reads documents, reasons over individual pages, searches across text, and builds relationships between documents, events, and entities inferred from the material. Each document is understood in context, connected to the filings it belongs to, the events it references, and the procedural role it plays in the matter.
What matters is not how the information is accessed, but how it is represented. Parties are not just names appearing in multiple documents. They have roles that remain consistent across the bundle. Filings are not just standalone PDFs. They trigger procedural effects and link to annexures, evidence, and orders. Dates are not just timestamps scattered across pages. They start and stop limitation clocks and constrain what actions are legally permissible.
Because Suit connects every document into a shared representation, its outputs are not one-off artifacts. Timelines, limitation calculations, compliance tables, and summaries are all views over the same underlying model. When new material is added, that model updates and the entire bundle remains coherent.
This is what makes Suit an ontology for the law. It encodes legal objects, relationships, and constraints so systems can reason over the state of a matter, not just read its documents.
Formal proof verification for the law
Drafting is visible. Verification is decisive.
Most legal failures have nothing to do with style. They happen because formal requirements are not met. An element is missing. Limitation is miscalculated. Authority does not actually support the proposition it is cited for. These are structural failures, not matters of judgment.
Formal proof verification for law means checking whether a structured legal object satisfies the constraints imposed by the legal system. Not proof in the mathematical sense, but proof as courts apply it: have the required predicates been met, and can each step be justified.
Feature: Legal Verifiers
A legal verifier operates over Suit's structured representation. It checks, for a given jurisdiction and posture, whether required elements exist, whether evidence is linked and admissible, whether dates comply with limitation and procedure, and whether citations are controlling. The output is not prose. It is a pass, fail, or flagged risk with traceable reasons.
This does not require human preference. It requires structure and rules. Once legal work is represented ontologically, verification becomes mechanical, repeatable, and auditable. Suit provides the substrate. Verifiers provide the guarantees.
Test-time verification and legal reasoning
Legal reasoning is not one-shot. Lawyers explore multiple paths, test them against rules, and discard what fails. Modern AI systems that use test-time verification follow the same pattern.
Instead of producing a single answer, the system generates multiple candidate structures over Suit's structured representation of the matter. Different issue framings. Different element mappings. Different ways of connecting facts, evidence, and authority. Verifiers then score each candidate against explicit legal constraints and select the ones that survive.
1. Generate
Multiple candidate structures over Suit's representation
2. Verify
Score each candidate against explicit legal constraints
3. Select
Choose the structures that survive verification
This approach changes the economics of quality. Smaller models become effective because weak branches are filtered out. Accuracy improves through selection, not just generation. Law is particularly well-suited to this regime because latency is secondary and failure conditions are formal and well-defined.
Key Takeaway
The important shift is that quality is no longer tied to a single draft. It emerges from comparison and rejection, the same way lawyers reason under pressure.
What this makes jhana
This framing turns jhana into legal infrastructure, not just a drafting or legal research tool.
Suit becomes the structured representation of a matter. Search supplies authoritative legal constraints. Verifiers continuously check completeness, limitation, and support. Every output is grounded in an explicit model of legal state.
The Result
Work that can be inspected and trusted. Quality is no longer implicit. Risk is surfaced early. Structure, not text, becomes the source of truth.
This is how legal systems move from assistance to reliability, and why Suit sits at the center of that shift.
Discussion