Lawyers already carry an ontology in their heads. A partner who says "check the change of control definition against the mandatory prepayment provision" is reasoning over entity types (defined term, clause, agreement) and relationship types (defined in, used by, governs) without ever using those words. A legal ontology is that same vocabulary written down, precisely enough that software can use it too.
That is the entire idea. No philosophy seminar required. What follows is what an ontology actually contains, why it is not the same thing as a taxonomy or a folder tree, why generic versions fail law firms, and how a real one gets built.
A working definition
An ontology is a shared vocabulary of entity types and relationship types. Entity types are the categories of things a practice reasons about: matters, clients, documents, clauses, deadlines. Relationship types are the ways those things connect: this clause appears in that agreement, this deadline arises from that obligation, this party is adverse to that client.
A good ontology also carries light constraints. A deadline needs a date and a source. An obligation belongs to a party. A document version belongs to exactly one document. These small rules are what let software catch nonsense before it reaches an attorney.
Once the vocabulary is written down it becomes a schema, and software can populate that schema from real documents. The result is no longer "a document that mentions Meridian" but "the executed credit agreement, governed by New York law, under which Meridian Capital Holdings is the borrower, and in which the change of control definition controls three separate provisions." The populated schema is a knowledge graph: the ontology is the blueprint, the graph is the building. We cover the graph side of this in what a legal knowledge graph actually does for a law firm.
An ontology is not a taxonomy
Firms hear "ontology" and reach for things they already maintain: practice area lists, document type codes, the DMS filing tree. Those are taxonomies. A taxonomy sorts items into buckets, usually hierarchical ones. It answers one question: what kind of thing is this, and where should it live?
The limit shows up quickly. A side letter in a fund formation matter is simultaneously a document of a certain type, an amendment to economic terms, the source of a most favored nation obligation, and the reason a deadline exists eighteen months from now. A folder can hold it in exactly one place. A taxonomy can tag it. Only an ontology can say all four things at once, because an ontology is built from relationships rather than locations.
A practical test: if the questions you care about begin with "which" or "across" (which agreements contain this fallback, which obligations survive closing, across our sponsor deals what did we concede), a folder tree cannot answer them. A system built on an ontology can, because the connections are first-class data rather than something a senior associate reconstructs from memory at midnight.
The nouns and verbs of legal work
The core set is smaller than most people expect. For a broad transactional and disputes mix, the entity types that carry most of the weight:
- Matter. The unit of work, billing, and confidentiality. Nearly everything else hangs off it.
- Client and counterparty. Parties with roles, not name strings. The same company can be a client in one matter and adverse in the next, and the model has to keep those roles straight.
- Document. With versions and status. A third draft and an executed agreement are different objects, and conflating them is how confident wrong answers happen.
- Clause and defined term. The units lawyers actually negotiate. Clauses hold positions; defined terms hold meaning, often far from where they are used.
- Obligation and deadline. What a party must do and by when. Deadlines are usually derived: sixty days after closing, thirty days after notice.
- Precedent. Prior work product worth reusing, carrying the context that makes reuse safe: deal type, position taken, how it ended.
The relationship types are the verbs: governs, cites, defined in, adverse to, due by, amends, supersedes, arises from. A brief cites a decision. An amendment supersedes a section. A guarantee arises from a credit agreement. A deposition deadline is due by a date set in a scheduling order. None of this is exotic. It is the ordinary language of practice, made explicit enough for software to follow.
Why generic schemas fail law firms
Some vendors ship a universal legal schema: Document, Party, Date, Amount. It demos well and fails quietly, because different practices reason about different nouns.
A fund formation practice thinks in funds, closings, limited partners, side letters, most favored nation elections, and excuse rights. An IP litigation practice thinks in patents, claims, prior art references, inventors, and inter partes review proceedings. A restructuring group thinks in claims of an entirely different kind, plus committees, plans, and priority waterfalls. Flatten all of that into Document and Party and the nuance that made the knowledge valuable is gone. Retrieval still returns text; reasoning stops.
The answer is a tailored ontology: a shared core (matter, client, document, deadline) that every group uses, extended per practice where the firm's actual expertise lives. The edges of the vocabulary are the valuable part, because they encode what your lawyers know that a generic model does not.
How an ontology gets designed with a firm
Done empirically, this is a focused exercise, not a research program.
Start with interviews. Sit with the partners, senior associates, and knowledge lawyers of the first practice group and collect the questions they wish they could ask: real ones, phrased in their own words. Those questions name the entities and relationships that matter, and they become the acceptance tests for everything that follows.
Then sample matters. A few dozen representative matters, reviewed end to end, will show which entities and relationships actually occur in the documents. This is reliably different from what a whiteboard session predicts, which is why the sampling step cannot be skipped.
Draft a small core, wire it into extraction, and run it against the sample. Where the extraction finds something important with nowhere to land, extend the ontology. Where a type never gets populated, cut it. Iterate until the questions from the interviews come back with grounded answers.
In a Reframe deployment this happens at the very start, alongside ingestion, and the result becomes the schema of the firm's Context Graph. Our delivery process walks through the sequencing. The reason to work this way is discipline: the ontology is tested against real documents from day one, so every type earns its place.
Working this way also avoids the three failure modes that account for most dead ontology projects:
- Over-modeling upfront. Two hundred entity types before the first query. Every type you add is extraction you must maintain and quality you must audit. Start small and extend only under pressure from real questions.
- The committee artifact. A vocabulary negotiated for months, published as a beautiful document, wired into nothing. If extraction and retrieval do not enforce the ontology, it is documentation, not infrastructure.
- No provenance. If the system asserts that a survival period is eighteen months but cannot show the sentence in the executed agreement that says so, lawyers will not trust it. They will be right.
What it powers downstream
The ontology is load-bearing for everything above it.
Extraction gets a target. Models pulling parties, clauses, obligations, and dates out of contracts need somewhere structured to land, or their output is just more text to search.
Retrieval gets precision. When the system knows that Meridian resolves to one specific client, that drafts are not executed agreements, and that a defined term controls a clause forty pages away, questions return the right passages instead of similar-sounding ones. How this combines with passage-level retrieval is the subject of our companion piece, RAG or knowledge graph? For legal work, the answer is both.
Agents get guardrails. An agent asked to assemble a closing checklist is only trustworthy if it knows what an obligation is, what due by means, and which version of the document controls. The ontology makes agent behavior legible and reviewable instead of improvised.
An ontology earns its keep the first time an associate asks a question in the language of the practice and gets back an answer grounded in the firm's own documents.
Start with one practice group, a few dozen matters, and the questions partners already trade in the hallway. Write down the nouns and verbs those questions use. That is the ontology, and it is where Reframe begins every engagement. Everything after that is engineering.