Build a Firm Wiki Your AI Can Query

There’s a special kind of letdown that comes from asking an AI assistant to do something actually useful for your practice.

You ask it to size up where a case stands on settlement. It hands you a competent, well-organized, completely generic discussion of settlement posture — the kind of thing a smart law student writes after reading one treatise and nothing else. It isn’t wrong. It’s just about nobody.

The instinct is to fix it 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 type the whole thing again.

Prompting isn’t the fix. Prompting is the symptom. What’s missing is context, and context belongs in a file, not in your typing.

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

Why a wiki, and why plain markdown

Start with the format, because everything downstream depends on it.

A firm knowledge base should be plain markdown files in ordinary folders on a disk you control. No database, no SaaS knowledge product, no proprietary format. The reasons stack up:

• Any model can read it. Claude, ChatGPT, whatever replaces both — they all read text. Put your knowledge base in somebody’s proprietary format and it works with whatever integrations that vendor feels like supporting.
• Ordinary tools work. grep finds things. git versions them, so you can see what changed and when, and roll back a bad edit. You get neither one inside a database blob.
• It lasts. Markdown written today will be readable in twenty years. Most legal software can’t say that, and a firm’s institutional knowledge ought to outlive its vendor contracts.
• You can check it. When the AI tells you something about a matter, you can open the file it read and look.

Obsidian is what I use to read it and get around in it, and I’ll single it out because of what it isn’t: a storage format. Obsidian is just a viewer sitting on a folder of markdown files. If Obsidian vanished tomorrow, every file would still be there and still be readable. That’s why it’s safe to build a firm’s memory on it.

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

Three layers, one rule

Here’s how our vault is laid out. The folder names matter less than keeping the layers apart.

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 we pulled it in — the practice management export, the email archive, the folder index. It’s the system of record. Everything else is interpretation, and interpretation should never be able to overwrite evidence. When the wiki and raw/ disagree, raw/ wins and the wiki’s wrong.

Sounds fussy, right up until the first time a model confidently “corrects” a date that was right. Then it’s the most important line in the whole setup.

Frontmatter is the actual product

Every page opens with YAML frontmatter. The markdown body holds the story; the frontmatter holds data. That’s what lets you query the thing instead of just searching it.

Every entity in our vault, whatever its 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 more than their share of the heavy lifting, and I’d argue they’re the difference between a knowledge base that helps you and one that eventually hurts you.

sources — where every fact came 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 gets its own value. Most of what a firm knows isn’t 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 deserves a name instead of getting quietly settled by whoever wrote the page last. A knowledge base that can’t express doubt 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 a page can be flagged as material that shouldn’t get casually surfaced or pulled into a general-purpose query.

Stack 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’ve cited it for.

Stable slugs, because the links are the point

Every entity needs an ID that never changes, because links are built on IDs and a renamed page is a broken graph. Here’s what we use:

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

Nobody has to maintain a list for any of that. It falls out of linking consistently.

The schema file is the whole trick

This took me the longest to figure out, and it’s the one thing I’d most want another lawyer to walk away with.

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’s the operating manual: the three layers, every entity type, the universal frontmatter fields, the slug conventions, the rules about what can and can’t be edited. It’s written to whatever model happens to open it.

Here’s why: an AI session has no memory of your previous sessions. Every session starts out knowing nothing. If the rules of your knowledge base live in your head, or in a document you wrote for people, then every session either has to be taught them again or gets them wrong. If the rules live in a file the model reads first, then any model — a new session, a different assistant, a colleague’s setup — gets it right from the first message.

That’s what turns a folder of notes into a system. The knowledge base explains itself. You quit prompting and start pointing.

And there’s a side benefit I didn’t see coming: writing the schema down forces you to actually decide things. What is a “matter” page, exactly? When does a communication get its own page instead of a line in a matter’s log? Half the value came from being made to answer questions I’d been putting off for years.

What it gets you

The real difference is that specialized work stops needing 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. You type one line.

Other things that turn into 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’s quietly the most useful thing in the vault — it digs up the things you’ve been meaning to nail down.
• “What have we not touched in sixty days?” A query on updated.

Those last two change how a practice feels, because they’re the questions nobody has time to ask and everybody wishes they had.

The rules I won’t bend

Never let the model edit raw/. I said it already. It’s worth saying twice, because it’s the only rule with no exceptions.

Every generated page cites its sources. If the assistant writes a matter page, the sources field has to say what it read. Anything it can’t source is tentative — not left out, and not stated as fact.

Label conflicts. Don’t resolve them. When two sources disagree, it’s confidence: conflicting and a note in the body explaining the disagreement. Don’t let the model pick a winner. It’ll pick confidently and it’ll sometimes be wrong, and once a fact’s written down flat, everything downstream inherits it.

The wiki isn’t 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 put. Don’t build a second copy of your file system that drifts out of sync.

The wiki doesn’t replace the practice management system for anything with legal consequences. Deadlines get calendared where deadlines get calendared. Time gets entered where time gets entered. The wiki is a knowledge layer, and you don’t hang a statute of limitations on a knowledge layer.

Check before you rely on it. A page a model wrote 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 doesn’t get you out of looking.

The part that isn’t optional

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

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 doesn’t change that duty. It just makes it concrete and answerable. Full-disk encryption. Backups that are encrypted too. Real thought about whether it syncs to a consumer cloud service and on what terms. A straight answer to 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 one 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 matter more, not less — the whole point is that the model gets better context, and better context means more client confidences per query.

None of that argues against building one. It argues for building it on purpose, on infrastructure you control, with the sensitivity tier on the page instead of in your head.

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

Start a lot smaller than this

Everything above is where a vault ends up after a year. It isn’t where it starts. If I were starting over:

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’s twenty lines. It’s what keeps the next hundred pages consistent, and retrofitting consistency is miserable.
3. Let the assistant write the pages, from what you’ve already got. Don’t write two hundred matter pages yourself; that’s exactly the work this is supposed to get rid of.
4. Add people when you catch yourself re-explaining who somebody is. Add authorities when you catch yourself hunting down the same case again. Let the pain pick the next entity type.
5. Only then add dashboards. A query’s only worth writing once there’s 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 one layer at a time, and every layer went in because something specific was bugging me. Try to design the whole ontology up front and you’ll spend a month modeling and build 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.