Here is what happens when I try to change one line of my agent's prompt.
Before the edit, a guidance doc auto-loads into the coding agent's context. It makes me walk an intervention ladder: is there a deterministic layer — a validator, a schema check, a tool contract — that would fix this before I touch prose? It makes me run Step 0: go read the live data my diagnosis depends on, because the bug I'm chasing might not exist. It makes me meet an evidence threshold: a prompt change requires the failure reproduced in at least two independent eval runs; a deterministic fix requires one smoking-gun trace plus a unit test pinning the shape of the fix. And it makes me pay a tax: every rule I add to the prompt, I have to delete one, because prompts only grow and grown prompts rot.
When the change ships, a second doc fires. It requires an append-only changelog entry with a fixed anatomy: the triggering signal, the hypotheses I considered and why the losers lost, the one scoped change I made, the verification results, and a regression test pinned to the failure. Ninety-seven of these entries exist as I write this. These are the two paired skills I introduced in The System Prompt Is the Last Resort — the pre-change guidance skill and the changelog skill. The coding agent loads both automatically at the relevant moments; I steer and review. I don't have to remember the process, because the process is in the loop.
That's the setup. The thesis of this post is the part that took me longer to notice: the agent isn't the interesting artifact here. The process is. And the process only became trustworthy when I started treating it exactly like software — versioned, evidence-gated, linted, and honest about its own rot.
The documents carry version numbers
Both documents have a semver line at the top and their own changelog. The scheme is boring on purpose. MAJOR means an enforced rule changed — something that gates whether a change can ship. MINOR means a principle or checklist step was added. PATCH means wording. The guidance doc is on 1.x; it has gone MAJOR once, and I'll get to why.
The versioning would be decoration except for one detail. The master changelog — the 97-entry record of every harness change — carries watermarks: dated lines that record which version of each process document was in force for the entries below them. So when I read entry 23, I can see not just what the harness believed at that point, but what the process believed. Entry 23 shipped a prompt change with a single eval reproduction. Under today's rules that's a violation. Under the rules in force that week, it wasn't — the two-reproduction threshold didn't exist yet. The watermark is what makes that entry interpretable instead of embarrassing.
The process failed its own review
In early May, about four weeks in, I ran an external review over the whole package — the harness, the changelog, and the process documents themselves. The reviewer found two flaws. Not in the agent. In the process. And both were cited against specific changelog entries, which is the only reason I believed them.
The first flaw: the evidence rule was uniform and wrong in both directions. The rule said "reproduce the failure in at least two independent eval runs before patching," full stop. The reviewer pointed at one entry where a prompt change had shipped with no reproduction at all — the rule was simply ignored — and that change rotted on contact with reality, generating follow-up fixes within days. Then the reviewer pointed at another entry: a deterministic security fix, shipped correctly from a single smoking-gun trace plus unit tests. Under a strict reading of the rule, that fix should have been delayed while I manufactured a second eval reproduction of a failure I could already prove from one trace. A uniform rule was being ignored where it was needed and would have obstructed where it wasn't.
The second flaw was worse. The process had no step for verifying ground truth before diagnosing. The reviewer traced a chain of four consecutive entries — four rounds of patching — all built on an assumption about a value in the live data store. Everyone involved, me and the coding agent both, assumed the value was 30. Nobody had read it. It was 0.3. The bug we spent four entries fixing was a phantom; the system had been behaving correctly the whole time, given the data it actually had.
The response was a process change, and this is the part I want to be precise about: the process change went through the process. The evidence rule was split in two — prose changes keep the two-reproduction threshold, deterministic fixes need one conclusive trace plus a shape-pinning test. A Step 0 was added: before diagnosing anything, read the live values your diagnosis depends on. Both changes shipped as guidance doc version 1.2.0, with a changelog entry of their own. The evidence section of that entry cites the exact entries that proved each flaw — the un-reproduced prompt change and its follow-up fixes for the split, the four-entry phantom chain for Step 0. A change to the rules met the same evidence bar as a change to the agent. If it hadn't, the rules would be exactly as trustworthy as an untested hotfix.
This is the property I've started calling process provenance. Code provenance tells you what the system was at time T. Process provenance tells you what the standards were at time T — which rules an entry was authored under, and whether today's rules would have allowed it. Once a machine is executing your process at scale — 97 entries in ten weeks is a rate no human team sustains by hand — you need both, because "we didn't know better yet" and "we broke our own rule" are different failures with different fixes.
A rule without enforcement is a suggestion
After the May review I had a second uncomfortable realization: every rule in the changelog doc was enforced by nothing but my own discipline, and the review had just demonstrated what my discipline was worth under deadline pressure.
So the process got a linter. It's a small script, nothing clever. It validates every changelog entry's structure: status and kind fields must come from fixed enums, each entry must carry exactly one component tag, trace references must resolve to archived trace files that actually exist on disk, and no entry marked shipped may contain "unverified" placeholder text in its verification section.
On its first run it flagged 8 violations out of the entries that existed at the time. Here is the detail that convinced me the exercise was worth it: those 8 were the same cohort the external reviewer had flagged by hand. A reviewer had spent real attention finding structural defects that forty lines of validation found for free. Manufacturing engineers call this poka-yoke — mistake-proofing, building the check into the fixture so the error becomes impossible rather than discouraged. The insight transfers cleanly: a process rule that lives only in a document is a suggestion. A process rule that lives in a script is a rule.
The process rots exactly like prompts do
Now the honest part. Ten weeks in, I ran the linter over all 97 entries. It fails 17 of them.
The root causes are legible. The field the linter expects to contain trace-file references drifted. In real usage it became a free-form "signal citation" field — entries cite ticket links, cross-reference other entries, or just say "design-review-driven," none of which resolve to a file on disk. The schema said one thing; sustained practice said another; nothing pushed back. And the reason nothing pushed back is the second root cause: the follow-up task that would have wired the linter into CI never landed. It sat in the backlog while feature work won every prioritization, week after week.
I built a vocabulary for exactly this failure mode. An unenforced contract decays roughly linearly with use — that is the sentence I wrote about the agent's prompt in week two, and it describes the meta-layer without changing a word. The fix is also the same fix the process prescribes for the agent: don't lecture the offenders, widen the schema to match real usage — the signal-citation field is legitimately more useful than a trace-only field, so make it a typed union and validate each variant — and then make the gate deterministic by putting the linter in CI, where it should have been from the start.
I want to resist the framing that 17 failures means the process is hypocritical. Rot in the meta-layer isn't hypocrisy. It's the same physics one level up. Any layer that is written once and enforced never will drift, whether it's a prompt, a schema, or the document that governs both. The only question is whether you have instrumentation at that layer too. I did — that's the only reason I can tell you the number is 17 and not "some."
Is the overhead worth it?
Fair question. Meta-work — entries whose subject is the process rather than the agent — is roughly 6% of the changelog. That's the cost side, and it's not nothing.
The rent it pays is traceable, which is the point of keeping the ledger. The clearest case: in mid-June, eval scores for one segment of the test suite collapsed overnight. Pre-May me would have started a multi-day archaeology of recent harness changes, because a score collapse right after a change window looks exactly like a regression. Post-1.2.0, Step 0 fired first: read the live data before diagnosing. The test organization's data had been purged from the environment. The agent was answering correctly about a world that had vanished. Total time to diagnosis: one session. A second, smaller repeat burn was prevented the same way in July. Both incidents are changelog entries, and both cite the Step-0 rule — and through it, the May review entry — as load-bearing.
That citation chain is my actual test for meta-work, and I'd offer it as the test for yours: later entries must cite the process rule as load-bearing. Not "we followed the checklist" — cite it as the thing that changed the outcome. If nothing downstream ever leans on a rule, the rule is ceremony, and the same add-one-delete-one discipline that applies to the prompt applies to the process. Delete it.
One level up
None of the individual pieces here are novel. Changelogs are old. Semver is old. Linters are old. Evidence thresholds are just science hygiene. The pattern is what happens when you point all of them at the process layer at once, and the reason the pattern is suddenly worth adopting is that a machine is now the primary executor of that layer. A human team can carry an unwritten process in its culture and mostly get away with it. A coding agent executes exactly what the documents say, at whatever rate you can review, and it will happily execute a bad rule 97 times.
Everyone versions their code. Almost no one versions the process that changes it. The moment that process is executed by a machine, versioning it stops being bureaucracy and becomes engineering.