The question I get most often about this section is not about any particular article. It is some version of: where does all of that actually live?
People expect the answer to be a product. A platform I subscribe to, a system I bought, something with a login. The real answer is duller and much more interesting: it is a folder. One directory on a laptop, backed up like any other directory, containing a few hundred files of plain text that a person can read.
That is the firm’s operating system. Not a metaphor — 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 is no database. There is no application. If you opened it you would find Markdown documents and nothing else.
I want to make the case that this is not an implementation detail. It is the single most consequential architectural decision I have made, and the payoff is one that most firms organizing their AI work right now are giving away 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 is actually in there
Four kinds of file, and the boundaries between them matter more than the contents of any one.
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 converts a generic assistant into one that behaves like it works here. It is short — a couple of pages — and it earns its length back every day.
The roles. A subdirectory of briefs, one per specialist. Each is a job description written for a reader who will follow it literally: what this role handles, what it explicitly does not, the standard it is 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 have written separately about why you hire specialists rather than one general assistant, and the short version is that the limits do more work than the capabilities.
The memory. Small files, one fact each, accumulated by correction. Every time something comes back wrong and I explain why, the explanation gets written down instead of evaporating at the end of the session. Preferences, conventions, decisions and the reasoning behind them, the mistake I do not want repeated. This is the layer that compounds. It is also the layer that feels least productive to maintain for the first month and most valuable by the sixth.
The procedures. The repeatable sequences, 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 an outcome you got once and an outcome you get every time.
Alongside those sit the things the firm already had and simply 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. Which turns out to be the whole point.
Configuration versus description
Here is the distinction I would put in front of anyone about to spend six months customizing an AI product for their practice.
When you configure a vendor’s tool, your knowledge goes into their database. It becomes rows behind their interface, expressible only in the shapes their form fields allow, exportable only insofar as someone built an export. You are renting a container for your own institutional memory, and the memory is only as portable as the container’s owner has 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 — the part that matters here — you can hand it to any model that has ever been built, because the interface every one of them exposes is text.
This is the concrete form of an argument I have made abstractly: that the durable assets are yours rather than the vendor’s, and that the model is a component while the description of your practice is the machine. A folder is what that sentence looks like when you make it real. The description sits on your disk. The model is a temporary worker who reads it on arrival and forgets everything on leaving.
What a model swap actually looks like
I should be specific, because “portable” is the kind of word that survives contact with reality poorly.
The genuinely portable layer 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 addressed to a particular vendor. They describe a law practice, not a product.
The conventions around the prose differ, and trivially. 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 is the entire compatibility layer. It took a minute to write and has needed no maintenance since.
So the swap is: point a different program at the same directory. The firm’s knowledge does not move, does not convert, does not migrate. It sits still while the engine changes underneath it.
I do this in earnest, not as a demonstration. When one provider is unavailable or rate-limited mid-afternoon, the work continues on another vendor’s tool against the same folder. Different company, different model, same firm — because the firm was never inside the model in the first place.
The model under your desk
That portability extends in a direction worth dwelling on, because it is 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 have 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 will not repeat the hardware arithmetic here. The relevant fact is that pointing a local model at the folder is not a migration project. It is the same swap as any other. The instructions are text; the local model reads text.
And here is the claim I actually want to make, which I have not seen made anywhere and which I think is the most useful thing in this article:
A well-written folder narrows the gap between a frontier model and a local one.
The reason is straightforward once you see it. A frontier model handed a vague instruction has to supply the missing structure itself — it has to infer what you meant, what good output looks like, what order to do things in, what to check before finishing. That inference is exactly what raw capability buys you, and it is 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 have moved the structural work out of the model and into the folder, where it was written once by a lawyer and does not have to be rediscovered on every run. What remains for the model is narrower, more mechanical, and far more forgiving of a weaker reasoner.
Three properties of the folder do most of that load-bearing. Explicit sequence, so nothing has to be inferred about order. Narrow role scope, so the model is never choosing among ten possible jobs. And deterministic checks around the model rather than inside it — the deadline computed in code, the citation verified against a retrieved source, the conflict check run as a query — which is the deterministic-versus-probabilistic line drawn in the right place.
The practical consequence is a routing decision you can actually defend. The narrow band of work that genuinely needs frontier reasoning — hard argument, synthesis across a difficult record — goes to the best model available. The large volume 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, chosen by consequence and sensitivity rather than by habit.
What does not survive the swap
I would rather state the limits than have you discover them.
Tool wiring does not move. The instructions are portable; the plumbing that lets a model read your calendar or write a time entry is not. Connectors are built against a particular runtime, and moving vendors means rebuilding or reconfiguring that layer. The open standard for this is a real improvement and it is not universally implemented. Budget for it honestly: the prose moves for free, the plumbing does not.
Long-context work degrades first. The tasks that hold a whole record in view and reason across it are the ones where a smaller model falls off most sharply, and no amount of procedural scaffolding fixes it. Scaffolding substitutes for structure, not for reasoning.
Instructions drift toward whatever you tested on. Write against one model for a year and you will have unconsciously tuned phrasings to its habits. They usually still work elsewhere. Usually is not a standard, which is the entire argument for keeping an evaluation set — it is the only instrument that tells you a swap degraded something rather than leaving you to find out from a client.
A folder is not 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. Do not let a directory of Markdown quietly become the place a deadline lives.
The professional layer
Three rules bear on this directly, and I verified each against the current text rather than quoting from memory.
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 is not a violation “if the lawyer has made reasonable efforts to prevent” it. That is a reasonableness standard, not a prohibition — which is why the sensible reading has never been never use outside services. But the calculus changes when a category of work can run without the data leaving your office at all. Model portability is what puts that option on the table for a solo, and a folder is what makes exercising it a five-minute decision instead of a project.
Rule 5.3 governs responsibilities regarding nonlawyer assistants, requiring reasonable efforts to ensure that assistance is “compatible with the professional obligations of the lawyer,” and Comment [3] extends the analysis to nonlawyers outside the firm. Whatever the eventual consensus on how squarely that framework fits AI tools, the supervisory obligation does not change when you change engines. What a folder gives you is the artifact: written instructions, dated, versioned, reviewable, showing what the system was told and when it was told it. I would rather be able to produce that than 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. Vendor dependency is a risk associated with relevant technology. It is worth noticing that the rule already covers this.
None of that is ethics advice, and every lawyer answers these questions in their own jurisdiction. But the design decision and the professional decision point the same direction here, which does not happen often enough to pass up.
Start on a Tuesday
Do not architect this. It does not work when you architect it, and I have the abandoned version to prove it.
Make the folder and write one page. What the practice does, who it serves, five rules you would 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, do not just fix it in the conversation — open a file and write down the rule. One fact per file. By Friday you will have a dozen and the difference in output will be obvious enough that you will not need convincing.
The following week, write down the thing you keep asking for. Not as a request; as a numbered procedure. That is your first repeatable process, and it is the first piece of the folder that will still be earning in a year.
Then split. You will notice you have been asking for two unrelated kinds of work in the same breath — research and formatting, say. Give each its own brief with explicit boundaries. That is 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 is an experiment rather than an emergency. You will find the seams — usually in the plumbing, rarely in the prose — and you will 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 this is the article I wanted to write
There is a version of the next few years where every small firm rents its intelligence from one vendor, on that vendor’s terms, with its accumulated operational knowledge sitting in a database it does not control — and discovers the price of that arrangement at renewal, or at a deprecation notice, or at a terms-of-service change it had no part in negotiating.
There is another version where the knowledge is a folder on a disk, the model is a commodity component, and switching is an afternoon. The difference between those two futures is not budget and it is not technical skill. It is whether you wrote your practice down somewhere you own.
The second version is also the cheaper one to operate, and cost is the only lever with enough leverage to matter for the people currently standing outside the courthouse. A lawyer who is not paying rent on their own institutional memory, and who can run the routine half of the work on hardware already sitting in the office, has a materially lower cost of producing competent work. That margin is where a sliding scale comes from.
It is 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.