The filing rules, in enough detail to hand to someone

The last article ended with a five-step order: name the system of record, pick a naming convention and folder shape, write the retention rule, then automate, then point AI at it. The reasonable objection to a list like that is that it's still a list. Nobody can act on "pick a naming convention" on a Tuesday morning.

So here is each step at the level of detail you'd need to hand it to the person who actually files things.

Step 1 — One system wins per fact, and it's written down

Not per system. Per fact. The AMS can own the policy effective date while the accounting package owns the invoice amount, and both of those can live in the same client record without conflict — as long as somebody has decided which is which.

The written version is one line per fact, and it's shorter than people expect:

Fact	System of record	Everyone else
Client legal name	AMS	Displays it, doesn't edit it
Renewal date	Carrier portal	Displays it, doesn't edit it
Invoice amount	Accounting	Displays it, doesn't edit it

"Displays it, doesn't edit it" is the whole governance rule. When the CRM and the AMS disagree about a spelling, nobody has to hold a meeting — the AMS wins, the CRM gets corrected. The value isn't in choosing the right system. It's in having chosen at all, so disagreements resolve in seconds instead of becoming a conversation about whose department is sloppier.

Step 2 — A delimiter you reserve, and a field order you don't change

This is the step people skip, and it's the one that quietly does the most work.

Pick one delimiter and reserve it. It separates fields, and it never appears inside a field. Underscore is my default, with hyphens or spaces inside a field where words need separating. The pattern is then a fixed sequence:

Entity_DocumentType_Date_OptionalDetail

Which in practice looks like:

Acme Inc_Invoice_2026-07-28_July Delivery.pdf
Acme Inc_Invoice_2026-06-30.pdf
Acme Inc_COI_2026-01-15_Renewal.pdf

Reserving the delimiter is what makes this more than tidiness. A filename with a reserved separator is a row of data. Split Acme Inc_Invoice_2026-07-28_July Delivery.pdf on the underscore and you get four columns: who, what, when, notes. That's structured data, sitting in the name of an unstructured file, created for free by the person who saved it. It is the cheapest metadata a business will ever get, and it's the reason a convention pays off long before anyone automates anything.

Five rules make it hold up:

• One delimiter, reserved. If underscores also show up inside client names, the split breaks and you're back to guessing.
• Fixed field order, always. Same fields, same sequence, every time. A field that's sometimes second and sometimes third is not a field.
• The entity name matches the system of record, exactly. This is step 1 doing its job. "Acme Inc," "Acme, Inc.," and "ACME" are three clients to a machine.
• One date format. Pick it once and never mix.
• Free text goes last, or nowhere. The optional detail field is where human judgment lives, so it goes at the end where it can't disturb the fields in front of it.

On the date format specifically, there's a real trade-off worth stating. 07282026 is what a lot of people type by habit, and inside a folder already scoped to one client and one document type it's perfectly readable. But it sorts wrong — every July of every year clumps together — and anything that ever reads these names as data will have to be told how to parse it. 2026-07-28 sorts correctly by default, everywhere, in every tool, forever. If you're choosing today, choose the one that sorts.

One more thing that looks like redundancy and isn't: keep the client name in the filename even when the file already sits in a client folder. Files get detached. They get emailed, downloaded to a laptop, dropped into a chat thread, attached to a claim. The folder context evaporates the moment the file leaves the folder; the name is the only part that travels.

And no _final, no _v2, no _FINAL_revised. Version words in filenames are a symptom of the version-discipline problem, not a solution to it. One live copy, the rest archived.

Folder shape follows the work, not the org chart

The folder tree should answer "where does this live" without anyone having to think about who reports to whom. Work moves through stages — client, then engagement, then document type — so the tree nests in that order. Departments reorganize; the shape of the work rarely does. A tree built around the org chart needs a migration every time someone gets promoted.

Depth is the other half. Three or four levels is usually the ceiling. Past that, filing becomes a decision, and any filing step that requires a decision will be made differently by different people, which is how you end up with the same document in two places.

Step 3 — The retention rule names a person and a trigger

"We keep everything" is not a retention policy; it's the absence of one, and it's what makes search return 2019. A real rule has four parts, and the two people skip are the last two:

Document type	Keep for	Trigger	Who
Signed policy docs	7 years	Policy termination	Ops manager
Quotes not bound	1 year	Quote date	Ops manager
Internal drafts	Until superseded	Final version saved	Author

Without a named person, deletion is everyone's job, which means it's nobody's. Without a trigger, "seven years" is ambiguous — seven years from what? Your industry's regulator or your carrier likely dictates the durations; what they won't do is tell you who clicks delete. Write that part yourself.

Steps 4 and 5 — Why they're last

Automation is last-but-one because a workflow keyed to a field that three people fill in three ways doesn't fail cleanly — it produces an exception queue somebody works by hand, which is the thing you were automating away.

AI is genuinely last, and steps 1 through 3 are what it's been waiting on. Consistent names make documents retrievable. One system of record gives every answer something to be checked against. A retention rule stops the model from citing a superseded 2019 draft with total confidence. Skip the three and you don't get a broken assistant — you get a plausible one, which is worse, because nobody can tell when it's wrong.

"Do we have to rename everything?"

No, and the answer matters because the fear of a 40,000-file backlog is what kills these projects before they start.

The convention applies going forward, starting the day it's written. Then backfill only what's active — the current clients, the open engagements, the documents someone actually opens. Everything else gets archived where it is, findable by full-text search if it's ever needed. Renaming a decade of dormant files is a large project with almost no payoff, and treating it as a prerequisite is the most common way businesses talk themselves out of doing the useful 5%.

Where this comes from

None of the above is a technology purchase. It's four or five decisions, written on one page, that everyone follows — and writing them down is most of the work, because the arguments only surface once someone tries to be specific.

That page is a byproduct of the $999 assessment: documenting how a business actually runs means writing down where each fact lives, what it's called, who owns it, and which system wins when two disagree. Useful whether or not you automate anything afterward. Necessary if you do.