Org rules and project rules need different homes

I have three repos that all want the same TODO hygiene rules. The first one got them after a review where I caught a TODO: fix this with no owner. The second one picked them up by copying CLAUDE.md from the first. The third one is where I noticed I was opening the second project's CLAUDE.md to copy it a third time.

That is the exact failure Level 3 is supposed to prevent.

The taxonomy is easy enough to write down. Level 2 is the project harness; Level 3 is the organization harness. The hard part is the split inside the repo. If both kinds of rule end up in the same files, the boundary collapses every time someone edits anything. Keystone draws the line in the file tree itself.

The split Keystone draws

A Keystone harness has two halves.

The project half is harness/corpus/ and harness/guides/. The team owns it. They edit it freely. It is the reasoning and the rules that describe this codebase: which test runner, which lint config, which idioms, which domain constraints.

The org half is harness/policies/. Each policy is its own namespace, owned by whoever published it. Policies arrive through keystone init --policy <ref> and update through keystone policy update <name>. Local edits inside a policy namespace block the next update unless --force is passed.

harness/

├── corpus/              # project reasoning (Level 2)

├── guides/              # project rules (Level 2)

├── policies/            # Level 3

│   ├── universal/       # ships with the binary

│   └── tacoda/          # installed via --policy

├── sensors/

├── adapters/

├── learning/

└── archive/

Two things make the boundary stick. First, every policy writes only inside its own subtree; the installer enforces that. Second, the lockfile records per-file hashes, so the update flow can tell whether a policy file has been edited locally. The structure is what keeps a Level 3 rule from quietly becoming a Level 2 rule.

Sensors deliberately do not live inside a policy. Sensors describe project tooling (lint, type-check, test). A policy can declare what must be checked; the project decides how. That is the right cut: principles distribute, commands do not.

The example: tacoda-policy

The shape is easier to see in a real one. . The harness installer is keystone. The thing I keep returning to: the cost of a good split is one extra directory. The cost of no split is a file you stop trusting.