The policy Claude read was four months out of date

For four months, the AI policy Claude worked from at our firm was not the one our people worked from. We issued version 1.0 on 1 April, reissued it in May, and shipped version 2.3 in August. The copy Claude itself read, and the wiki summary built from it, stayed on the April text the whole time.

That is the lesson in one line. Claude does your work the way your documents describe it. Not the way you explain it in a meeting, and not the way your best person does it. The documents.

Documentation is now the control surface

Liza Shakury of Microsoft’s engineering team makes this case in a post called Documentation Is the New Source Code. She is writing for developers, and the argument is simple: the model reads your documentation as its instructions, so the writing around the work now steers the work. Her sharpest line: “Whatever isn’t written down gets re-invented, badly, on every task.”

That holds well outside software. When Claude has nothing written to go on, it falls back on the most common way to do the job, which is the average of everything it has read. Your house format, your pricing rules, the thing you never say to a client: if it isn’t written down somewhere Claude reads, Claude doesn’t know it, and it will fill the gap with something plausible.

The business version of a well-documented repo

The Microsoft post sets out six layers of documentation in a well-run code repository. Four of them map straight onto a Claude rollout in any business:

• Repo-wide instructions are your AI policy and the one-page rules people actually read.
• Skills are written procedures for specific jobs, each with an owner.
• Decision records say why you chose this tool, this rule, this exception.
• Reference docs hold brand, tone, templates and what good looks like.

Our 25 skills are the second layer in practice. Brand and tone, the AI policy, solution design, user stories, testing standards, proposal review: each one is a written procedure with a named owner, peer reviewed before publish. None of them is clever. They are written down, and that is the point.

Written down is not the same as current

Our stale policy failed in the most ordinary way. The policy had an owner. The copy Claude read didn’t. Every reissue updated the version people signed and missed the file the model used.

The same pattern broke our training gate. The step lived in the rollout project, not the onboarding checklist, so two new starters walked straight past it. Different document, same failure: the thing that mattered had no owner where it was actually read.

Three questions worth asking of any document Claude reads:

1. Who owns it? A name, not a team.
2. When did it last change, and did the copy Claude reads change with it?
3. Does it say what not to do? Prohibitions are the part people leave out, and the part a model needs most.

Where to start

You don’t need six layers. Start with the one Claude reads most: your policy and your house rules. Put them in one place, give them one owner, and make updating Claude’s copy a step in every reissue. Then write your first skill for the job people ask Claude to do most often.

This site runs the same way. One approved positioning document and one instructions file, and every page is checked against both before it ships.

If your rollout has stalled, look at what Claude is reading before you blame the model.