Keep hold of what your software is for.

What changed

Code used to be expensive. A system lived for years because rewriting it was unthinkable, and the people who wrote it stayed long enough to remember why it worked the way it did. That memory was the real specification: which rule mattered, which customer depended on it, which shortcut would hurt someone.

Now code is cheap. An agent can refactor a module before lunch and port a service to another language by the end of the week. Frameworks change, models change, the harness driving the agent changes. None of that is the problem. The problem is that the memory did not come with it. The agent was never in the meeting where someone said "we must never do that", and it will not ask.

What quietly goes missing

You still have the usual defences, and they still matter, but none of them was built to hold intent.

• Specifications drift. By the time an agent reads one, it describes the system as it was hoped to be two releases ago.
• Documentation grows until nobody, human or model, can tell which sentence is a promise and which is a description of today.
• Tests pin behaviour, not purpose. A passing suite says the code does what it did yesterday. It cannot say whether that was the point, and an agent chasing a green build will happily change a test to match.

So the thing most likely to be lost in a rewrite is exactly the thing you would most regret losing: the reason the software exists, and the people it must not fail.

Write down less, but the right thing

IZ4 is a small plain-text file that sits beside your README and answers three questions: what is this software for, who is it for, and what must remain true for it to keep serving them. Each of those truths is an invariant, and each comes with a BECAUSE, so the reason travels with the rule.

The test for an invariant is simple. If the whole system were rewritten tomorrow, would you regret not telling the people, and the agents, rebuilding it? If yes, and it describes lasting intent rather than today's implementation, it belongs. Most things do not. A good IZ4 is short enough to read in a minute, which is exactly why it gets read.

Every IZ4 also carries the same foundation, word for word: humans-first.iz4.you, do-no-harm.iz4.you, human-agency.iz4.you, honesty.iz4.you and keystone.iz4.you. Your own are named under your project's domain, so a name still means the same thing years later. Nothing you write can weaken the foundation.

Put it where the agents read

A promise nobody reads is a wish. The iz4 CLI puts the file in front of the machines doing the work:

• iz4 agent prints the packet an agent reads before it plans: the effective invariants and the protocol for them. When a task conflicts with an invariant, the agent reports the conflict and pauses that action, rather than deciding for you.
• iz4 agent install adds that instruction to the repository's AGENTS.md, so tools that read it are told to run the packet before they start.
• iz4 review reads a change against the invariants, so a diff can be checked for intent as well as syntax.
• iz4 test drafts one test per invariant, and iz4 check shows which invariants have a test that names them and which have none.

None of this proves your software keeps its promises. A checker cannot verify a sentence written in English. What it does is make the promises visible, give every change a question to answer, and make it obvious where no test stands behind a promise yet.

What it gives you, as the person responsible

• One file per repository that says what matters, which you can read before you approve anything.
• Intent that outlives the model and the vendor. Swap the agent and the invariants stay put, in plain text, under version control.
• A clear line for your team and your agents between what may change freely and what may only change on purpose, by a person.
• If you choose, a public card on the register that shows what you declared and what was checked, dated, and never as a score.

Start with one repository

Pick the system you would least like to see rewritten badly. Run iz4 init, answer the two questions, and write the first three things that must stay true, each with its because. Then tell your agent to run iz4 agent before it touches anything. That is an afternoon's work, and from then on every change starts by reading what the software is for.

The rest of your stack will keep changing. Let it. Just keep hold of the part that should not.

Take the first steps Read the foundation

Nigel Hamilton, Nige Ltd