The Second Brain Under My Practice

In the flagship piece I said the whole practice runs on a folder that Claude reads and writes. A few posts back I showed you one corner of that folder: the structured notes that can tell a signed term from a draft. This post is about a different corner, the one that answers a different question. Not “what did we agree on this deal,” but “what does the law actually say.”

That corner is a wiki. This is what it is, what mine was quietly getting wrong, what I rebuilt, and how I expect it to change the way I work.

What a wiki is

Strip away the software and a wiki is a set of linked pages, each covering one thing, that point to each other. The value is in the links, not in any single page. You land on “limitation of liability” and the page carries you to “indemnification,” to the vendor it came up with, to the source articles it was built from. Knowledge stops being buried in folders and becomes something you can walk through.

For a law practice I run it as three layers, and the separation is the whole trick.

The first layer is inputs: the outside material I collect (articles, alerts, primary sources, CLE decks). I read from it and never change it. Someone else wrote it; it stays as filed.

The second layer is the wiki itself: my conclusions. These are pages I write (the doctrine, the frameworks, the market-standard positions, the case notes), synthesized from those inputs in my own words. The pages cite the inputs but never copy them.

The third layer is the day-to-day: client notes and matter files, the working memory of who’s doing what this week.

The test for where something goes is simple. If someone else wrote it, it’s an input. If it’s my synthesis, it’s a wiki page. If it’s this week’s activity, it’s a note. Inputs remember what others said, the wiki remembers what I concluded, notes remember what I did.

What I had, and where it was quietly failing

I already had a wiki. It was doing real work: research done once for one client was there for the next one, and a rule in the system made the AI check it before running to the open web. That alone saved me from re-deriving the same analysis every few weeks.

But it had three weaknesses, and all three are the kind that don’t announce themselves.

The first is decay. A wiki page has a date it was written. It does not have a date its law expired. I had pages leaning on pending litigation, on bills that hadn’t passed, on a penalty figure that adjusts every January. The page looked as authoritative the day the law changed under it as it did the day I wrote it. Nothing in the system was watching for the world to move.

The second is unverified citations. Case cites had accumulated in the pages the way they accumulate in anyone’s notes: carried over from a CLE deck or a secondary source, correct-looking, never actually pulled and read. A correct-looking cite you haven’t verified is a latent problem, and in a wiki it quietly becomes the source the next memo copies from.

The third is scatter. The substance of the law (the actual doctrine and figures) had leaked out of the wiki and into the automated tools I use to do the work. The same indemnity framework lived in four places. A compliance penalty lived inside a tool. When one copy went stale, nothing pulled the others along. That is the exact failure the wiki was supposed to prevent, happening one level down.

None of this was breaking anything I could see. That’s what made it worth fixing. The failure mode of a knowledge base is confidently handing you something that used to be true.

What I rebuilt, and why

The rebuild wasn’t new pages. It was the machinery that keeps the pages honest, aimed at those three weaknesses.

For decay, a watchlist. Every place the wiki leans on something that can change (a case still being litigated, a bill not yet passed, a proposed rule) now has an entry that names the thing, the pages that depend on it, and a date to go check for movement. A scheduled job works that list and flags anything overdue. The page’s “written on” date tells me when I wrote it; the watchlist tells me which of its claims are still provisional. Those are different questions, and I’d been answering only the first.

For citations, a verified-cite register and a hard rule: no case goes into a page until it’s been resolved to the real opinion, read to confirm it says what I claim, and checked for negative treatment. The register records what was verified, when, and what would undo it. It also records the failures. The failures are the point. In the rebuild, one decision’s online text was corrupted, so I couldn’t confirm the holding; another source’s reporter citations wouldn’t resolve. The old instinct is to let a correct-looking cite ride. The register makes me write down “couldn’t verify” instead, so the unconfirmed cite is visibly unconfirmed rather than silently trusted.

For scatter, a boundary rule: the wiki holds the substance of the law, and the tools hold the process. A tool can point to a wiki page, but it doesn’t get to keep its own private copy of the doctrine. Enforcing that turned up exactly what I feared: a compliance penalty sitting inside a tool that was two years out of date, surfaced only because moving the substance to one maintained page forced the comparison. One page of record now, everything else a pointer to it.

Why do this at all, rather than just be more careful? Because “be more careful” is not a system. A rule in your head doesn’t enforce itself, and a solo practice doesn’t have a second lawyer to catch the stale cite. The rebuild turns three habits I was trying to hold in my head into three files that hold them for me.

How I expect this to change the work

The day-to-day change is that the wiki is now the thing I trust to check first, not the thing I check and then re-verify against the web anyway.

Before, a wiki page was a decent starting point I didn’t fully trust, so I’d read it and then go confirm the law was still current, which is most of the work the page was supposed to save. Now the currency question has its own answer. If a page’s claims were provisional, the watchlist is already tracking them. If it cites a case, the register already shows the verification. The page is where I wrote down what I concluded, and now also where I can see how much of that conclusion is still standing.

The second change is quieter and probably bigger. The tools I use to review a contract or assess a termination now read the matching wiki page before they start, and write a one-line note back to that page when they’re done. So the page accumulates a record of where its framework has actually been applied. Over time that gives a doctrine page precedent value: the law on indemnity caps, plus a record of where I took that position before and when. A one-lawyer shop doesn’t usually get that kind of institutional memory. This builds it as a byproduct of doing the work.

None of this verifies the law for me at the moment I rely on it. The machinery lowers the odds a page is stale; it doesn’t drive them to zero. Every synthesis still gets my review before it lands; the machinery drafts and flags, it doesn’t publish on its own. And the register reduces bad cites, it doesn’t abolish the duty to check a citation before it goes in front of a court. The rebuild makes the system trustworthy enough to lean on. It doesn’t make it a lawyer.

How the wiki keeps improving

The part I’m most pleased with is that the wiki now gets better without me sitting down to improve it.

New reading flows in on its own. When I file a source, a detection pass flags which existing pages it might affect and queues them; a synthesis step then drafts each change against the source and puts it in front of me to approve. Detection is cheap and runs unattended; synthesis is judgment, so it never lands without review. The reading I do anyway becomes wiki maintenance without a separate chore.

The watchlist keeps the existing pages from drifting, on a cadence rather than by luck. And a periodic coverage check compares where I actually spend billable time against where the wiki is deep, so it grows toward the work I’m really doing, not just toward whatever I happened to read that week. When I found the wiki was thick on the topics I read about and thin on the ones I bill the most, that check is what surfaced it.

Put together, the three edges each have an engine now: new knowledge comes in through the reading pipeline, existing knowledge is kept current by the watchlist and the register, and growth is steered by the coverage check. My job shifts from feeding the thing to reviewing what it proposes. That’s the version of this I can actually sustain in a practice.

If the blackboard post was about a note that knows what’s signed, this is about a library that knows what’s still good law. Same instinct in both: don’t ask yourself to remember the discipline, build the discipline into the memory. The rule was always right. This is what it looks like when the system holds you to it.