The thing that clicked today: a prompt that exists in a dozen places is not one prompt, it is a dozen prompts that happen to agree today, and nothing about the way they were put there guarantees they will agree tomorrow.
Every AI tool in the fleet reads persistent instructions before it works: a global contract shared by the strategy tools on my laptop, a per-project contract in each knowledge base, worker profiles on each Linux machine, and the instruction fields of several desktop-app projects. Those had accumulated by hand over two months. The conventions that govern fleet behaviour already had an index with owners and revisions; the instruction text that agents actually consume did not.
Built / shipped
One registry. A canonical index that identifies every instruction-bearing surface, preserves the last-known canonical content, carries revision and date evidence, and makes future propagation provably complete. It is modeled on the existing conventions index so it is found the same way.
Bodies in versioned templates, owned by path and hash. The exact text of each surface lives in a template file the registry references by path and SHA-256, rather than duplicated inline in one monolithic note. Templates stay readable and can be deployed directly; the registry still owns each body.
Surfaces classified by how they can be verified. Five classes: a canonical file; an exact copy; a symlink; an exact importer (a one-line file that pulls in the canonical one); and a manual UI field, a text box in a desktop application that can only be set by hand. Each class has an explicit verification method, because a text box in someone else's web UI cannot be verified the way a file on disk can. One fleet-wide parity marker plus a per-surface revision footer keeps drift detectable; importers and symlinks stay deliberately minimal.
A transport transform, declared. The desktop app removes exactly one trailing line feed from pasted project instructions. Rather than pretend otherwise, the registry records that as a declared transform and verifies the resulting payload hash, not the template hash.
Deployed and verified. Inventory of every surface across the laptop, the synced knowledge bases, three Linux machines' worker and strategy profiles, the remote-control profiles, and five desktop-app project fields; backups of every pre-change copy; templates deployed; each UI field replaced from its template, reopened and re-read; a standard-library parity checker run remotely from the laptop. Final: 103 of 103 checks current, 98 machine-verifiable and 5 manual fields current from verified receipts.
The ruling, two days later. The registry's design invites an obvious question: when the fleet-wide parity revision bumps, does every surface that embeds a parity token get re-stamped? Going looking for the fact that settles it rather than arguing from prose: the checker, the only mechanical enforcer of surface currency, verifies content hash, terminal marker, symlink target, importer text and payload hash, and never reads an embedded parity string. A string no checker enforces and no reader can act on is provenance: a record of the generation the surface was authored under, not a live field. Written into the index as a settled rule with its consequences and a row in the trigger matrix, so it is found at the moment someone bumps parity and is not re-litigated. No surface was re-stamped.
Problems & fixes
The manual fields were the honest difficulty. Five surfaces cannot be verified by a checker because they live in a desktop app's UI. The registry does not pretend they are automatable: they are a class with a receipt, a recorded date and the person who set them, and they are listed as "verification due" until someone reopens them and compares.
Startup surfaces consume the new revision only in a fresh conversation. Validating a change means opening a new terminal or session, not trusting the one that made the change.
The rule that makes this stick is procedural: a new project, agent profile or instruction-bearing UI gets added to the registry as part of its creation, not as later cleanup.
Decisions
One registry, one checker, templates owned by hash. The instruction text agents read is infrastructure and gets the same discipline as the conventions.
Classify by verification method, and say plainly which surfaces cannot be machine-verified.
Declare transport transforms instead of fighting them.
An embedded parity token is provenance. Re-stamping it would be churn that proves nothing, because nothing reads it.
Learned
Prompt and configuration text that lives in many places is a distributed system and fails like one. The fix is the same as for any other replicated state: one owner, a hash, a checker.
"Verified" has to name its method. A file's hash and a text box's receipt are both evidence; pretending they are the same kind is how UI drift hides.
Find the fact that settles a doctrine question before writing the doctrine. The checker's source ended the parity-token debate in ten minutes.
Still open / next
The five manual fields remain the weakest link by design; the next time the desktop app gains a way to read them back, they should move to the machine-verifiable class. And the registry now has to be part of every instruction change, which is a habit the parity audits over the following weeks were built to enforce.