Build a Firm Wiki Your AI Can Query

There is a particular kind of disappointment that comes from asking an AI assistant to do something genuinely useful for your practice.

You ask it to assess a settlement posture. It gives you a competent, well-organized, utterly generic discussion of settlement posture — the kind of thing a smart law student writes after reading a treatise and nothing else. It is not wrong. It is just about nobody.

The instinct is to fix this with a better prompt. So you write a longer one: here’s the client, here’s the procedural posture, here’s what opposing counsel did in March, here’s the judge, here’s the insurance situation. And it works — the answer gets dramatically better. Then the session ends, and tomorrow you write the whole thing again.

Prompting is not the fix. Prompting is the symptom. What is missing is not instruction, it is context — and context should live in a file, not in your typing.

This is about building that file. Or rather, several hundred of them.

Why a wiki, and why plain markdown

Start with the format, because the format decision determines everything downstream.

A firm knowledge base should be plain markdown files in ordinary folders on a disk you control. Not a database, not a SaaS knowledge product, not a proprietary format. The reasons compound:

• Any model can read it. Claude, ChatGPT, whatever replaces both — they all read text. A knowledge base in someone’s proprietary format is a knowledge base that works with whatever integrations that vendor decides to support.
• Ordinary tools work. grep finds things. git versions them, which means you can see what changed and when, and roll back a bad edit. Neither of those is available inside a database blob.
• It survives. Markdown written today will be readable in twenty years. That is not true of most legal software, and a firm’s institutional knowledge should outlive its vendor contracts.
• It is inspectable. When the AI asserts something about a matter, you can open the file it read and check.

Obsidian is what I use to read and navigate it, and it deserves specific mention because of what it is not: it is not a storage format. Obsidian is a viewer over a folder of markdown files. If Obsidian vanished tomorrow, every file would still be there and still be readable. That property is why it is safe to build a firm’s memory on it.

What Obsidian adds on top is worth having: [[wikilinks]] between pages, a graph view that makes the relationships visible, and the Dataview plugin, which runs live queries against the structured fields in your files and renders them as tables. That last one turns a pile of notes into something closer to a database you can still read with cat.

The architecture: three layers, one rule

Here is the structure our vault uses. The specific folder names matter less than the separation.

raw/          ← immutable snapshots from source systems. Never edited.
active-matters/   ┐
people/           │
organizations/    ├─ the wiki proper: AI-written, AI-maintained
authorities/      │
doctrine/         ┘
_schema/      ← the data model, written as markdown
_dashboards/  ← live queries that present the data

The one rule: the AI never modifies raw/. That folder holds what the source systems actually said at the moment of ingest — the practice management export, the email archive, the folder index. It is the system of record. Everything else is interpretation, and interpretation must never be able to overwrite evidence. When the wiki and raw/ disagree, raw/ wins and the wiki is wrong.

This distinction sounds fussy until the first time a model confidently “corrects” a date that was right. Then it sounds like the most important line in the whole design.

Frontmatter is the actual product

Every page opens with YAML frontmatter. The markdown body holds narrative; the frontmatter holds data. This is the move that makes the whole thing queryable rather than just searchable.

Every entity in our vault, regardless of type, carries these fields:

---
id: 10024-Whitfield
type: matter
display_name: "Whitfield v. Kestrel Foods, LLC"
aliases: []
tags: [litigation, contract]
created: 2026-03-14
updated: 2026-07-26
sources:
  - clio:matter:1234567
  - dropbox:/Clio/Whitfield, Marcus/10024-Whitfield/
  - gmail:thread:abc123
confidence: confirmed
sensitivity: standard
---

Three of those fields do disproportionate work, and I would argue they are the difference between a knowledge base that helps and one that eventually hurts you.

sources — provenance on every fact. Where did this come from? A practice management record, a folder, an email thread, or somebody typing it? When an assistant tells you something surprising about a matter, the next question is always “how do we know that,” and this field answers it without a research project.

confidence: confirmed | tentative | conflicting — doubt as a first-class value. Most of what a firm knows is not equally certain. The opposing party’s registered agent is confirmed; what their expert is likely to say is tentative; two documents giving different dates for the same event is conflicting, and that state deserves a name rather than being silently resolved by whoever wrote the page last. A knowledge base that cannot express uncertainty will manufacture certainty, and a language model reading it will inherit that false confidence and build on it.

sensitivity: standard | high | sealed — an access tier, so that a page can carry a marker for material that should not be casually surfaced or included in a general-purpose query.

Add entity-specific fields on top. A matter page carries the court file number, the judge, the posture, the next deadline. A person page carries the role — judge, opposing counsel, expert, witness — and the organization. An authority page carries the citation, the holding, and what you have cited it for.

Stable slugs, because links are the point

Every entity needs an ID that does not change, because links are built on IDs and a renamed page is a broken graph. Our conventions:

The payoff is the graph. A judge’s page accumulates every matter they have touched. An opposing counsel’s page accumulates every case you have had against them and how each went. An authority page accumulates every brief in which you have relied on it — which is exactly what you want the moment a court questions your reading of it.

None of that requires anyone to maintain a list. It falls out of consistent linking.

The schema file is the whole trick

Here is the part that took me longest to understand, and it is the one I would most want another lawyer to take away.

The knowledge base has to document its own schema, in a file, in the knowledge base.

Our vault has a CLAUDE.md at its root. It is the operating manual: the three-layer architecture, every entity type, the universal frontmatter fields, the slug conventions, the rules about what may and may not be edited. It is addressed to whatever model happens to open it.

Why this matters: an AI session has no memory of your previous sessions. Every session begins knowing nothing. If the rules of your knowledge base live in your head, or in a document you wrote for humans, then every session either has to be taught them again or will get them wrong. If the rules live in a file that the model reads first, then any model — a new session, a different assistant, a colleague’s setup — behaves correctly from the first message.

This is what turns a folder of notes into a system. The knowledge base becomes self-describing. You stop prompting and start pointing.

There is a second-order benefit that took me by surprise: writing the schema down forces you to actually decide things. What is a “matter” page, precisely? When does a communication get its own page versus a line in a matter’s log? Half the value came from being made to answer questions I had been deferring for years.

What it buys you

The concrete difference is that specialized work stops requiring specialized prompting.

Before. “Draft a status letter for Whitfield.” Then four hundred words explaining who Whitfield is, what happened, and what the client already knows.

After. “Draft a status letter for 10024-Whitfield.” The assistant reads the matter page, follows the links to the events and the recent communications, sees the posture and the next deadline, and drafts from facts. What you type is one line.

Other things that become one-liners once the graph exists:

• “We’re in front of this judge next month — what have we filed with her before, and how did it go?” The judge’s page links every matter.
• “Have we ever cited this case, and for what?” The authority page lists them.
• “What’s tentative or conflicting on this file?” A query on the confidence field. This one is quietly the most useful thing in the vault — it surfaces the things you have been meaning to nail down.
• “What have we not touched in sixty days?” A query on updated.

The last two are the ones that change how a practice feels, because they are the questions nobody has time to ask manually and everybody wishes they had.

The rules I would not bend

Never let the model edit raw/. Already said, worth repeating, it is the only rule with no exceptions.

Every generated page cites its sources. If the assistant writes a matter page, the sources field must say what it read. Anything it cannot source is tentative, not omitted and not asserted.

Label conflicts rather than resolving them. When two sources disagree, confidence: conflicting and a note in the body explaining the disagreement. Do not let the model pick a winner. It will pick confidently and it will sometimes be wrong, and the moment a fact is written down flatly, everything downstream inherits it.

The wiki is not the file of record for documents. Document pages are index pages — what the document is, when it was filed, what it says, where it lives. The document itself stays where it is. Do not build a second, drifting copy of your file system.

The wiki does not replace the practice management system for anything with legal consequence. Deadlines get calendared where deadlines get calendared. Time gets entered where time gets entered. The wiki is a knowledge layer, and knowledge layers should not be load-bearing for a statute of limitations.

Verify before relying. A page written by a model six weeks ago is a summary, not a source. For anything with consequences — a deadline, a holding, a rule — go to the primary source. The wiki tells you where to look; it does not excuse you from looking.

The part that is not optional

This is a folder full of client confidences sitting on a disk. Treat it accordingly.

Minnesota Rule of Professional Conduct 1.6(c) requires “reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client.” A markdown vault does not change that duty; it just makes it concrete and answerable. Full-disk encryption. Backups that are themselves encrypted. Careful thought about whether it syncs to a consumer cloud service and under what terms. A clear-eyed answer to the question of which model reads it and what that provider does with what it reads.

The ABA’s Formal Opinion 512, issued July 29, 2024, is the framework to read here. Its confidentiality analysis is that a lawyer using generative AI must remain cognizant of the duty to protect information relating to the representation regardless of source, absent the client’s informed consent. A knowledge base that hands well-organized client information to a model makes that duty more salient, not less — the whole point is that the model gets better context, and better context is more client confidence per query.

That is not an argument against building one. It is an argument for building it deliberately, on infrastructure you control, with the sensitivity tier on the page rather than in your memory.

Descriptive of published guidance, not ethics advice. Formal Opinion 512 is advisory and not binding in any jurisdiction.

Start much smaller than this

Everything above is where a vault ends up after a year, not where it starts. If I were beginning again:

1. One entity type. Matters. Nothing else. A page per open file with a handful of frontmatter fields.
2. Write the schema file on day one, even if it is twenty lines. It is the thing that makes the next hundred pages consistent, and retrofitting consistency is miserable.
3. Let the assistant write the pages, from what you already have. Do not hand-author two hundred matter pages; that is exactly the work this is supposed to eliminate.
4. Add people when you notice yourself re-explaining who somebody is. Add authorities when you notice yourself re-finding the same case. Let the pain pick the next entity type.
5. Only then add dashboards. A query is only worth writing once there is enough behind it to be worth querying.

The vault I have now has eleven entity types and a schema page for each. It got there by accretion, and every layer was added because something specific was annoying. If you try to design the whole ontology up front you will spend a month modeling and produce nothing that answers a question.

Sources and tools

• Obsidian — markdown-based knowledge base; the files stay yours
• Dataview — live queries over frontmatter fields
• ABA Standing Committee on Ethics and Professional Responsibility, Formal Opinion 512 (July 29, 2024)
• Minn. R. Prof. Conduct 1.6

General commentary on practice management. Not legal advice, not ethics advice. All matters, clients, people, and file numbers in the examples above are invented; no client information appears in this article.