The Company Rulebook

Problem: Every company already has a rulebook. It is a folder of documents nobody opens, a handbook written three reorgs ago, and about forty decisions that exist only in the head of the person who made them. New hires learn by asking. Everyone else guesses.

Quick Win: Software teams solved this exact problem with one file. CLAUDE.md is a plain text file of rules that Claude Code reads at the start of every work session, automatically, before anyone types a word (Anthropic). Nobody has to remember to open it. That single property, rules that arrive rather than rules you go and find, is the part worth copying at company scale. The rest of this post is the copy job, including the seven ways it rots.

What Software Teams Already Solved

A code repository, the shared folder where a company's software lives, is a small company. It has standards, history, hard-won lessons, and a dozen conventions that make no sense to an outsider. For twenty years the answer to "where do the rules live" was a project notes file that went stale in a month.

Then AI coding tools made the question urgent, because a machine reading the wrong rules ships the wrong thing at speed. The fix that stuck was almost boring: put the rules in one file, load it every session, keep it short.

Anthropic's guidance on what goes in that file is the interesting part. Add something when Claude makes the same mistake twice, when a code review catches something it should have known, when you type the same correction you typed last session, or when a new teammate would need the same context to be productive (Anthropic).

Read that last trigger again and swap "teammate" for "new hire." That is a company rulebook, described precisely, by a docs page about a text file.

Your company has the file already, scattered across Notion, Drive, and Slack. What it has never had is the loading mechanism: anything that puts the rule in front of a person at the moment they are about to act.

The Priority Order, Translated to a Company

Claude Code does not load one file. It loads four, ordered from broadest to most specific, and the most specific instruction is the last thing read (Anthropic). Each one maps cleanly onto something you already have.

Two more things load at the start of a session without sitting in that order. Auto memory is written by the tool itself, from your corrections, which is the company equivalent of what the team learned the hard way and never wrote down. Imports are linked files pulled in from elsewhere, the company equivalent of the appendix everyone skips.

Two things fall out of that table.

First, the only layer nobody can switch off is the one installed centrally (Anthropic). Everything else is negotiable by the person doing the work. Most companies have this backwards: their compliance rules are optional in practice and their formatting preferences are treated as sacred.

Second, the machine-only layer is where your real operating procedure lives. Every company runs on workarounds that were never written down because writing them down would have meant admitting they exist. That is the layer that walks out the door when someone resigns.

Seven Ways a Rulebook Rots

The failure modes of a bloated CLAUDE.md are documented in detail in AGENTS.md vs CLAUDE.md. Every one of them has an exact company analogue.

Trauma replay is the one nobody catches. Rules get added after incidents and almost never removed once the incident stops being possible. Anthropic's guidance is to review the file periodically and strip outdated or conflicting instructions, because if two rules contradict each other the model may simply pick one at random (Anthropic). People are no better: faced with two contradictory policies, staff pick whichever one the nearest manager will notice.

Your rulebook needs a deletion process at least as much as it needs an approval process.

A Rule With No System Behind It Is a Suggestion

This is the whole post compressed into one line, and Anthropic states it plainly for the file version: instructions shape behaviour but are not a hard enforcement layer. If something must happen at a specific point, write it as a hook, a command that fires automatically at that fixed moment regardless of what the AI decides (Anthropic).

Two categories. Guidance shapes behaviour. Enforcement removes the choice. Confusing them is the most expensive mistake in corporate policy, and there is now a price tag on it.

Microsoft and LinkedIn's 2024 Work Trend Index found that 75% of knowledge workers use AI at work, and 78% of those users bring their own AI tools rather than anything the company handed them, while 60% of leaders worry their own leadership has no plan or vision for putting it to work (Microsoft).

IBM put a number on the bill. In its 2025 breach report, one in five breached organisations said the breach involved AI tools nobody had approved, companies with heavy unapproved AI use paid $670,000 more per breach than those with little or none, and 63% of breached organisations either had no written rules for AI use or were still writing them (IBM).

The tools are already inside the company. The written rules mostly are not.

The test for any rule you are about to write: what breaks if someone ignores it? If the answer is "nothing, someone might mention it in a review," you have written a suggestion. That is fine, as long as you stop calling it a policy and stop being surprised when it fails.

What Actually Belongs in a Company Rulebook

Anthropic targets under 200 lines per file, because longer files crowd out everything else and get followed less reliably (Anthropic). The pruning principle that comes with it is the useful one: cut anything a reader could work out from the work itself, keep the pitfalls, the reasoning, and the conventions that differ from what an outsider would assume.

Apply that filter and most handbooks lose 80% of their pages.

The rightmost column is where most rulebooks die. A document that restates common sense trains everyone to skim, and a skimmed document cannot carry the four rules that actually matter.

Find the Rules That Matter Before You Write Any of Them

The instinct is to schedule a workshop and write the thing top to bottom. That produces a document weighted evenly across forty topics, of which four are load-bearing.

Do it in the other order. Find where work actually stalls, then write rules only for those places.

The evidence for going after the constraint first is strong. McKinsey's 2025 State of AI survey found that 88% of organisations now use AI in at least one part of the business, but only 39% can point to any effect on operating profit at all. Redesigning how the work itself gets done has the strongest link to that profit impact, and only 21% of adopters had fundamentally redesigned any workflow (McKinsey).

MIT's 2025 NANDA study, reported by Fortune, found roughly 95% of company AI pilots delivered no measurable impact on profit, and named the cause a learning gap: generic tools work brilliantly for one person and stall inside a company because they do not learn from or adapt to how that specific company works (Fortune). The same study found that buying from specialists succeeded roughly twice as often as building internally.

That is the same finding twice. A rulebook copied from a template is a generic tool. A rulebook built from your own constraints is not.

And the payoff for moving knowledge is measurable. A field experiment published in the Quarterly Journal of Economics put salespeople into structured sessions with a randomly assigned colleague and measured average sales gains above 15%, largest for those paired with high performers, with the effect still holding at least 20 weeks later (Sandvik et al., QJE). Nothing changed except who knew what.

This is the first half of what we do as a bottleneck diagnosis: a ranked, evidence-backed map of where a company loses time and money, built from its own data and its own people. You cannot write a good rulebook without one, because you do not yet know which rules are load-bearing. The same logic drives a revenue leak audit, where the leaks worth fixing are almost never the ones leadership names first.

Where This Breaks: The Rulebook Nobody Asked For

Honest failure modes, because this approach fails in predictable ways.

It was written by someone who does not do the work. Rules written by leadership about work leadership does not perform get quietly routed around. The people closest to the work write the first draft, or you get fiction.

Nobody owns it, so nobody prunes it. Additions are easy and deletions require courage. Assign both, with a review date.

It got written to impress rather than to instruct. If the document would work as a board slide, it will not work as a rulebook. Nobody has ever changed their behaviour because of a page about values.

Enforcement was skipped, again. The most common outcome by far. The document ships, the systems do not change, and six months later the same problems appear in the same review.

It got too big to read. The size limit is not bureaucracy, it is how attention works. The reason a 900-line file gets followed less reliably than a 150-line one applies to a person on a Tuesday afternoon too.

The Version That Runs Itself

Once the rules are written down and enforced, recurring work can be produced against them automatically: proposals that already meet the standard, quotes that already respect the discount rules, decks that already follow the format.

That is the payoff order. Diagnose where work stalls. Write the four rules that matter. Put a system behind each one. Then automate the work those rules govern, in that sequence, because automating a process nobody agrees on just produces wrong answers faster.

Related Reading

• AGENTS.md vs CLAUDE.md explained, the file-level version of everything above
• Onboarding a team onto Claude Code, what happens when the rules meet actual humans
• Where is my business losing money, finding the constraint before you write the rule

Frequently Asked Questions

Is this just a handbook with a new name?

No, and the difference is the loading mechanism. A handbook is a place you go when you remember it exists. The file version arrives at the start of every session, unprompted, whether or not anyone asks (Anthropic). At company scale that means rules attached to the moment of action, in the quoting tool and the approval step, not stored in a folder.

How long should a company rulebook be?

Shorter than you want. The software target is under 200 lines, because longer files get followed less reliably (Anthropic). The same holds for people. Four non-negotiable rules that everyone can recite beat forty that nobody can find.

What if the rules are already in a dozen systems?

That is the normal starting position, and merging everything into one document is the wrong first move. Pick the decisions that go wrong most often, find where the authoritative answer actually lives for each, and write down which system wins when two disagree. One page of "here is the real source of truth" is worth more than a hundred pages of restated policy.

---

Most companies do not have a rulebook problem. They have a problem knowing which four rules are worth enforcing, and no system standing behind any of them. We start with the diagnosis, write only the rules that carry weight, then build the machinery that makes them hold. See what we install inside companies, or reach out directly.