The question I get most about this section isn’t about any one article. It’s some version of: where does all of that actually live?
People expect a product. A platform I subscribe to, a system I bought, something with a login. The real answer is duller and a lot more interesting: it’s a folder. One directory on a laptop, backed up like any other directory, holding a few hundred files of plain text a person can read.
That’s the firm’s operating system. I mean that literally — the handbook, the org chart, the standing rules, the checklists, the institutional memory, all of it, written in English, in files, in one place. There’s no database. There’s no application. Open it and you’d find Markdown documents and nothing else.
This is the most important design decision I’ve made, and most firms setting up their AI work right now are giving away its payoff without noticing: the folder is portable across models. Every one of them. Including the ones you run yourself, on hardware you own, with no network connection at all.
What’s actually in there
Four kinds of file. Where one kind stops and the next starts matters more than what’s in any one of them.
The handbook. One document at the top. What the firm is, who it serves, the entity name that must never be typed wrong, the standing rules that apply to everything. Never publish an email address. Never compute a deadline from memory. Signature-required documents go to the practice management system, not the file share. This is the file that turns a generic assistant into one that acts like it works here. It’s short — a couple of pages — and it pays for itself every day.
The roles. A subfolder of briefs, one per specialist. Each is a job description written for a reader who’ll follow it to the letter: what this role handles, what it doesn’t, the standard it’s held to, and who it hands work to next. A researcher. A drafter. A citation verifier. A formatter who touches form and never substance. I’ve written separately about why you hire specialists rather than one general assistant. Short version: the limits do more work than the skills.
The memory. Small files, one fact each, built up by correction. Every time something comes back wrong and I explain why, the explanation gets written down instead of evaporating when the session ends. Preferences, conventions, decisions and the reasons for them, the mistake I don’t want to see again. This is the part that compounds. It’s also the part that feels like a waste of time the first month and like gold by the sixth.
The procedures. The things you do over and over, written as checklists. Opening a matter. Processing the day’s scanned mail from the scanner to the calendar. The four-pass citation gate that runs before anything with a case cite leaves the building. A procedure is the difference between getting it right once and getting it right every time.
Next to those sit the things the firm already had and just moved into the same directory: the templates, which were always a machine-readable specification of the firm’s knowledge; the wiki the model can query; and the evaluation set that tells you whether any of it still works.
None of that is code. All of it is prose. And that turns out to be the whole point.
Configuring a product versus writing it down
If you’re about to spend six months customizing an AI product for your practice, read this part first.
When you configure a vendor’s tool, your knowledge goes into their database. It turns into rows behind their screens, in whatever shapes their form fields allow, exportable only if somebody bothered to build an export. You’re renting a box for your own institutional memory, and the memory is only as portable as the box’s owner decided to make it.
When you describe your practice in a folder, the knowledge is a file. You can read it. You can print it. You can put it under version control and see exactly what changed and when. You can hand it to a colleague. And — here’s the part that matters — you can hand it to any model anybody’s ever built, because every one of them takes text.
I’ve made this argument before in the abstract: that the durable assets are yours rather than the vendor’s, and that the model is a part while the description of your practice is the machine. A folder is what that sentence looks like in real life. The description sits on your disk. The model is a temp who reads it on arrival and forgets everything on the way out.
What a model swap actually looks like
A word like “portable” tends to fall apart when it meets reality, so here are the specifics.
The part that really moves is the prose. The handbook reads the same to every model. So do the role briefs, the memory files, the checklists, the templates, and the wiki. Nothing in any of them is written to a particular vendor. They describe a law practice, not a product.
The conventions around the prose differ, and it’s trivial. Different tools look for their top-level instructions under different filenames — one wants a file with one name, another expects a different one, and a third takes a path on the command line. In this firm’s website repository the fix is a symbolic link: two filenames, one file, nothing duplicated. That’s the whole compatibility layer. It took a minute to write and hasn’t needed a minute of upkeep since.
So the swap is: point a different program at the same directory. The firm’s knowledge doesn’t move, doesn’t convert, doesn’t migrate. It sits still while the engine changes underneath it.
I don’t do this for show. When one provider goes down or rate-limits me mid-afternoon, the work keeps going on another vendor’s tool against the same folder. Different company, different model, same firm — because the firm was never inside the model to begin with.
The model under your desk
That portability runs in one more direction, and it’s the one with real professional consequences.
Open-weight models — the ones you download and run on your own hardware — are good now. Not frontier-good. Good. I’ve written about what local models actually cost and where they fall down, and about the specific stack for running one on firm hardware, so I won’t redo the hardware math here. What matters is that pointing a local model at the folder isn’t a migration project. It’s the same swap as any other. The instructions are text. The local model reads text.
And here’s the part I haven’t seen anybody else say, and I think it’s the most useful thing in this article:
A well-written folder narrows the gap between a frontier model and a local one.
It’s simple once you see it. Hand a frontier model a vague instruction and it has to fill in the missing structure on its own — figure out what you meant, what good output looks like, what order to do things in, what to check before it’s done. That guessing is exactly what raw horsepower buys you, and it’s exactly what a smaller model is worse at.
Now hand the same smaller model an explicit procedure. These are the seven steps. This is the format. Check these three things before you report done. If the answer is not in the file, say so rather than filling the gap. You’ve moved the hard structural work out of the model and into the folder, where a lawyer wrote it once and nobody has to rediscover it on every run. What’s left for the model is narrower, more mechanical, and a lot more forgiving of a weaker thinker.
Three features of the folder do most of the lifting. Explicit sequence, so nothing about order has to be guessed. Narrow roles, so the model is never picking among ten possible jobs. And hard checks around the model, not inside it — the deadline computed in code, the citation checked against a retrieved source, the conflict check run as a query. That’s the deterministic-versus-probabilistic line drawn in the right place.
What you get is a routing decision you can actually defend. The narrow band of work that truly needs frontier reasoning — hard argument, pulling together a difficult record — goes to the best model you can get. The big pile of ordinary work that touches client confidences — first-pass summaries, mail triage, records review, internal notes — runs on the machine in the office, where the data never leaves the building. Same folder. Same handbook. Same checklists. Two engines, picked by what’s at stake and how sensitive it is, not by habit.
What doesn’t survive the swap
Here’s what doesn’t move.
The tool wiring stays behind. The instructions are portable. The plumbing that lets a model read your calendar or write a time entry isn’t. Connectors are built for a particular runtime, and switching vendors means rebuilding or reconfiguring that part. The open standard for this is a real step forward, and it’s not universally implemented. Budget for it: the prose moves for free, the plumbing doesn’t.
Long-context work falls off first. The jobs that hold a whole record in view and reason across it are where a smaller model drops off hardest, and no amount of procedure fixes that. A checklist can stand in for structure. It can’t stand in for brains.
Your instructions drift toward whatever you tested on. Write against one model for a year and you’ll have tuned your phrasing to its habits without meaning to. It usually still works elsewhere. Usually isn’t a standard, which is the whole case for keeping an evaluation set. It’s the only thing that tells you a swap broke something before a client does.
A folder isn’t a system of record. It holds description, not data. Matters, deadlines, ledgers, and trust accounting belong in something with a schema and an audit trail. Don’t let a directory of Markdown quietly become the place a deadline lives.
The ethics rules
Three rules bear on this directly.
Rule 1.6(c) requires a lawyer to “make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client.” Comment [17] adds that unauthorized access or disclosure isn’t a violation “if the lawyer has made reasonable efforts to prevent” it. That’s a reasonableness standard. It isn’t a ban, which is why the sensible reading has never been never use outside services. But the math changes when a whole category of work can run without the data leaving your office at all. Model portability is what puts that option in front of a solo, and a folder is what makes taking it a five-minute decision instead of a project.
Rule 5.3 covers responsibilities regarding nonlawyer assistants, requiring reasonable efforts to make sure that help is “compatible with the professional obligations of the lawyer,” and Comment [3] carries the analysis to nonlawyers outside the firm. However squarely that framework ends up fitting AI tools, your duty to supervise doesn’t change when you change engines. What a folder gives you is the paper: written instructions, dated, versioned, reviewable, showing what the system was told and when. I’d rather hand that over than try to describe it from memory.
Rule 1.1, Comment [8], puts keeping abreast of “the benefits and risks associated with relevant technology” inside the definition of competence. Being stuck with one vendor is a risk associated with relevant technology. The rule already covers it.
None of that is ethics advice, and every lawyer answers these questions in their own jurisdiction. But the design choice and the ethics point the same way here, and that doesn’t happen often enough to pass up.
Start on a Tuesday
Don’t over-engineer this. It doesn’t work when you over-engineer it, and I’ve got the abandoned version to prove it.
Make the folder and write one page. What the practice does, who it serves, five rules you’d tell a new hire on their first morning. Point whatever AI tool you already use at it and give it one real task.
Spend the week correcting it in writing. When it gets something wrong, don’t just fix it in the chat — open a file and write down the rule. One fact per file. By Friday you’ll have a dozen, and the difference in output will be obvious enough that you won’t need me to convince you.
The next week, write down the thing you keep asking for. Write it as a numbered procedure, not a request. That’s your first repeatable process, and it’s the first piece of the folder that’ll still be paying off a year from now.
Then split. You’ll notice you’ve been asking for two unrelated kinds of work in the same breath — research and formatting, say. Give each its own brief with clear boundaries. That’s your first hire.
Then test the portability, before you need it. Point a second tool at the folder and run something real. Do it while it’s an experiment and not an emergency. You’ll find the seams — usually in the plumbing, rarely in the prose — and you’ll find them on a quiet afternoon instead of during a filing week.
Everything after that is accumulation. The folder gets better every time something goes wrong and you write down why.
Why I care about this one
There’s a version of the next few years where every small firm rents its brains from one vendor, on that vendor’s terms, with everything it’s learned about running itself sitting in a database it doesn’t control. Then it finds out what that costs at renewal, or at a deprecation notice, or at a terms-of-service change nobody asked it about.
There’s another version where the knowledge is a folder on a disk, the model is a commodity part, and switching takes an afternoon. What separates those two futures isn’t money and it isn’t technical skill. It’s whether you wrote your practice down somewhere you own.
The second version is also cheaper to run, and cost is the only lever big enough to matter for the people standing outside the courthouse right now. A lawyer who isn’t paying rent on their own institutional memory, and who can run the routine half of the work on hardware already sitting in the office, can produce competent work for a lot less. That margin is where a sliding scale comes from.
It’s a folder. Make it today.
Sources
- Minn. R. Prof. Conduct 1.1 and cmt. [8] (competence includes keeping abreast of “the benefits and risks associated with relevant technology”) — verified against the current rule text
- Minn. R. Prof. Conduct 1.6(c) and cmt. [17] (reasonable efforts to prevent inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation) — verified against the current rule text
- Minn. R. Prof. Conduct 5.3 and cmt. [3] (responsibilities regarding nonlawyer assistants; nonlawyers outside the firm) — verified against the current rule text
- Model Context Protocol — open standard for connecting AI applications to external tools and data
- Ollama, llama.cpp, and LM Studio — runtimes for models on your own hardware
- CommonMark — the Markdown specification these files are written in
General commentary on practice management. Not legal advice, not ethics advice, and not a recommendation of any particular product or vendor. No client information appears in this article; every example is generic or invented. Every lawyer is responsible for their own compliance in their own jurisdiction.