The Invariant Harness: Letting Agents Change What They Can't See

We spent the weekend trying to build a game whose world you couldn't read by looking at the code. The game barely matters. What we walked out with is a method for letting an agent change a system it cannot fully see — and prove the change was sound.

An invariant harness is a verification layer that asserts properties which must hold regardless of what the code was intended to do — conservation, determinism, stability — rather than checking output against a known expected answer. That distinction sounds academic. This weekend it stopped being academic, because the author of the code was an agent and the behavior of the system was emergent. Under those two conditions, the invariant harness stops being optional and becomes the only thing standing between a plausible result and a correct one.

---

The experiment: a world you can't read

The origin project was a small game built on a reaction-diffusion field — the same class of Turing pattern-forming system that produces spots, stripes, and spirals from nothing but local chemistry. The design goal was deliberate: a world whose state is emergent, so you cannot glance at the source and predict what the running system will do. You have to run it.

That property makes the game interesting and makes it a nightmare to verify. There is no expected output to assert against. When an agent edits the solver, you cannot read the diff and know whether the world it produces is still valid. The correctness of the change is invisible to inspection — which is exactly the situation a growing share of real software is now in.

So the interesting artifact was never the game. It was the scaffolding we had to build to let an agent safely modify a system none of us could read: a verified deterministic solver, an invariant harness wrapped around it, and a tool interface an agent could use to inspect and perturb the live system. That triangle is the product. The physics was just the vehicle that forced us to build it honestly.

The harness earned its place under real pressure

The hardest question in the project was whether a viable regime even existed — a set of parameters producing a world that was structured, healthy, and stable at the same time. The search ran into three structural dead-ends. Each was caught as a genuine negative and recorded, rather than tuned around.

Two moments show the value directly.

In the first, a candidate configuration looked balanced at a snapshot, and we nearly promoted it. A longer run showed the balance was a transient the system was passing through on its way to a single winner. The stability check caught a result that looked correct and was quietly drifting.

In the second, a target written into the specification was proven physically impossible for the class of system — which corrected an assumption the designers themselves had made.

In both cases the harness caught an error produced by the people building it, before anything was built on top of it. Nothing broken was ever promoted. That is the whole test of a verification layer: not that it passes the good changes, but that it refuses the bad ones even when they look good and even when their author was confident.

Why this is different from the testing we already do

The technique is not new. Property-based testing, metamorphic testing, and formal methods have checked invariants for decades. The claim here is narrower and more useful: this layer becomes load-bearing, rather than optional, under two conditions that are now common.

1. Behavior is emergent, so there is no known expected output to assert against.
2. The author is an agent, so the generator can produce a matching wrong code and a wrong test — both plausible, both aligned, both incorrect.

Test-driven development anchors on human intent. A person who knows the expected answer writes a failing test and makes it pass. That anchor weakens as authorship moves to models, because the model can be confidently mistaken about the intent itself. It writes the test to match its own misunderstanding.

An invariant needs no such anchor. It holds regardless of intent, so it catches what an intent-based test written by the same author would miss. The two approaches are complementary. Example tests pin specific behavior. Invariants pin global properties. Agent-written and emergent code makes the second mandatory — a point we've argued before from the other direction in Provable Software.

What extracts, and what does not

Strip the biology from the origin project and three things remain: a verified deterministic solver, an invariant harness, and a tool interface into a running system.

• The solver is a commodity. Reaction-diffusion solvers exist. Having another one is not an advantage.
• The harness and the agent loop around it are the asset — together with the interface that lets an agent inspect and perturb a live system safely.

That asset is domain-general. It answers a question the broader move toward autonomous agents is now running into: how do you let an agent operate a system whose correctness is invisible to inspection? The physics was the vehicle. The verification method is the product. It's the same instinct behind pattern-based engineering — the durable value isn't the disposable system, it's the reusable method wrapped around it.

Where the pattern applies

The pattern fits any domain that has formal correctness properties an agent could violate while producing plausible output. The strongest fit is constraint-verified generation. Most generative systems today produce output that is plausible with no guarantee that it is valid. Placing the invariant check inside the generation loop converts plausible output into provably valid output.

Domain	Invariant checked	Value created
Generative design	Physical, code, or geometric constraints	Output valid by construction, not by later review
Building information modeling	Clash, egress, fire rating, consistency	Compliance checked inside the edit loop, not in a downstream pass
Scientific simulation	Conservation, stability, determinism	An agent can safely modify a model it cannot verify by reading
Financial systems	Balance, bounds, reconciliation	Agent changes that cannot silently break an accounting identity
Materials and chemistry	Valence, conservation, feasibility	Generated candidates that cannot be structurally impossible

In each case the solver or the model differs. The pattern is the same: wrap the system in invariants, expose a check, and close the loop so the agent cannot commit a change that violates a property.

The attestation multiplier

The harness answers one question: is this change correct? It does not answer a second question that regulated and high-stakes domains always ask: can I prove what happened, and prove it was not altered afterward?

Those are orthogonal halves of trust. One verifies correctness. The other verifies provenance and integrity.

Adjective's Zephyr provides the second half: Ed25519 signatures, a tamper-evident ledger, and signed artifacts. Combining the two turns every verification verdict into a signed, auditable record. A check that is not attested is a claim to be taken on faith — worthless in exactly the domains where the harness matters most. An attested check is proof that, at a given commit, a named invariant suite ran and returned a specific result, recorded so that no one can alter the history.

The combination produces attested autonomous agency: an unforgeable record of everything an agent did, and cryptographic proof that it was validated at each step. This repositions the work. It is no longer a verification convenience competing with test frameworks. It is the trust and audit layer for autonomous agents — the missing piece in every serious deployment story.

The market concern about agents is not only whether they will be correct. It is whether their actions can be proven and audited for regulators, insurers, and liability. The harness answers the first concern. Attestation answers the second. Together they answer both.

Where this goes

As more code is written by agents, testing shifts from asking whether output matches a specific expectation toward asking whether output satisfies properties that are true regardless of intent. The intent anchor that test-driven development relies on is exactly what weakens when a model is the author. The invariant harness is one expression of that shift — hardened by a real project this weekend rather than sketched in the abstract.

It began as a way to build a game that could not be read. Its value turned out to have nothing to do with games. It is a method for letting a machine change something it cannot fully see, and prove that the change was sound. That problem is arriving across every domain where agents are being handed real work. The pattern is ready before the demand has fully formed.

---

We build the verification and attestation layer that makes autonomous agents trustworthy in production. If you're handing real work to agents and need their changes to be provably correct and cryptographically auditable, explore Zephyr or start a conversation with us.