All Three Breakouts Passed. None Could Restart.
Three AI systems built three Breakouts. I gave each one an explicit test contract. Then I ran the same mechanical driver against all three.
Flash: PASS.
Pro: PASS.
Haiku: PASS.
The driver could launch a deterministic simulation, move the paddle, observe paddle rebounds and brick collisions, watch the score change, clear the final brick, and exhaust the remaining lives. It checked the state API, replayed the same input twice, and reached both victory and defeat.
This was the result I had asked the harness to produce: three mechanically coherent Breakouts, verified by behavior rather than appearance.
Then I played them.
Flash began before I was ready. Pro did the same. Haiku at least waited for an input. But after game over, all three arrived at the same dead end.
None of them could restart.
Not one failed the driver.
Driver verdict vs. human floor
| Build | Driver verdict | Human floor |
|---|---|---|
| Gemini Flash | PASS | Auto-start; no restart after game over |
| Gemini Pro | PASS | Auto-start; no restart after game over |
| Claude Haiku | PASS | Waits for input; no restart after game over |
There is no contradiction in that ledger. The machine and the player were answering different questions.
The driver asked whether the game state behaved coherently under a named sequence of operations. It did. The human check asked whether a person could enter, understand, finish, and re-enter the play loop. They could not.
PASS meant the Breakout driver contract passed. It did not mean the product was complete.
That distinction sounds obvious when written down. It is much harder to feel when a green verdict arrives after a long run of deterministic checks. A detailed test suite creates a strong gravitational pull: whatever it measures starts to look like the whole system.
It was not the whole system.
What the driver could prove
Breakout was the next rung after Pong because one ball now had to stay coherent with a persistent field of bricks. A brick existed in several places at once: on screen, in collision logic, in the score, in the remaining-brick count, and in the victory condition. Reset and replay had to put all of those views back into agreement.
The engineered contract made that coupled state visible. Each build exposed an API for the ball, paddle, bricks, score, lives, and status. The driver could apply controlled input, advance time deterministically, and compare the resulting state.
At that scope, it covered a lot:
- the API shape and observable game state;
- deterministic reset and replay;
- paddle control;
- paddle bounce;
- brick collision and removal;
- score, lives, victory, and loss;
- page and console health during the run.
Those are not cosmetic checks. They are the mechanical spine of Breakout. All three builds passed them.
The driver had converted a playable-looking artifact into a falsifiable one. I could prove that the brick field was not merely painted onto the canvas. I could prove that a final brick led to victory and repeated misses led to defeat. I could replay the same steps and demand the same result.
The contract made Breakout legible to a machine.
What it never asked
The driver did not ask how a player entered the loop.
It did not ask whether the first ball waited for consent, whether a start prompt appeared at the right time, or whether that prompt disappeared when play began. It did not ask what happened after the terminal state. It did not click a restart control, because no restart control was part of the contract.
It also did not measure whether the game was balanced, readable, attractive, or fun.
Contract coverage
Driver contract
- Expose state
- Apply paddle input
- Step and replay deterministically
- Observe paddle bounce and brick collision
- Reach win and loss
Player lifecycle
- Explain how play begins
- Wait for the player when appropriate
- Keep prompts synchronized with play
- Recover after game over
- Invite another run
The right column was not secretly tested by the left one. A valid loss state only proved that the game could end. It said nothing about whether the player could begin again.
This is the coverage gap: the driver crossed the mechanical state graph, but it did not cross the player journey.
The missing checks are not vague in retrospect. A lifecycle probe could have asserted that the initial state waits for an explicit action, that prompts match the current state, and that game over exposes a working path back to a fresh run. These are testable properties.
They simply were not in this test.
That matters because the conclusion is narrower than “UX cannot be verified.” The evidence says something more useful: the same contract that lifted mechanical verifiability did not detect or prevent the lifecycle failure. It does not show that the contract caused the failure, and it does not show that lifecycle quality is inherently beyond a harness.
It shows where this harness stopped.
Verifier trace
Pro initially appeared to fail the paddle-bounce check. The build was not the problem. Inside the page context, the driver retained a live object returned by getState(). After the simulation stepped, that “before” object reflected the new values too. The comparison had lost its snapshot of the past. Tracing the transition exposed the mistake; copying the values before stepping hardened the check and restored the correct PASS.
That incident does not need another verifier autopsy. Its role here is smaller: even inside the covered surface, a verdict only earns trust when the observation behind it can be traced.
The corrected verdict still did not solve the lifecycle gap. It made the mechanical verdict honest.
Mechanical coherence is not lifecycle coherence
I had been treating “the game works” as one surface. Breakout split it into two.
Mechanical coherence asks whether the coupled system preserves its rules. Does input move the paddle? Does the ball rebound from the paddle? Does a brick disappear on contact? Do score, remaining bricks, victory, lives, and defeat agree? Can the state be reset and replayed?
Player-lifecycle coherence asks whether a person can travel through that system. Does the game wait when it should? Does the interface explain the current state? Does game over provide a route back into play? Do prompts appear and disappear with the state they describe?
A build can be coherent on the first surface and broken on the second.
All three engineered Breakouts were.
That does not diminish the PASS. The contract did real work. Without the explicit API, I would have had three games that looked functional and no cheap way to inspect their internal coupling. With it, I could verify the mechanical spine across three independent builds.
But a strong partial proof is still partial.
The management error would be to promote a local verdict into a global one: the driver passed, therefore the product passed. The better move is to name the boundary and add the next falsifier where the evidence says it belongs.
For Breakout, that next boundary is no longer hidden. Start flow, prompt lifecycle, and restart belong beside collision, replay, win, and loss in the acceptance surface. Balance and fun remain separate human judgments unless I design narrower probes for them.
The next Breakout autopsy will follow what happened when I changed the production route instead of expanding the mechanical contract.
For this round, the result is clean:
The contract made Breakout provable. It did not make the player journey complete.