One Build Failed. Then It Passed. Then It Failed Again.

FAIL.

PASS.

FAIL.

Those verdicts landed on one Claude Haiku route through the Space Invaders experiment. They do not contradict one another. Each verdict answered a different question, against a different artifact, at a different layer of evidence.

The useful lesson is not that a model went from bad to good and back again. It is that one verdict cannot stand in for prompt fit, contract coverage, and the player journey at the same time.

Rewind to the sparse prompt

The first artifact came from the primitive matrix: one sparse request, with no explicit mechanics/API contract for the evaluator to drive.

Play the primitive Haiku artifact and compare the visible result with the requested game shape.

That is a prompt-floor observation, recorded as SI06-C1. It describes this artifact under this sparse request. It does not establish a model-wide rank or an inherent limit.

The next run changed the question

The engineered run did not repeat the same experiment with one isolated improvement. It introduced a new artifact under an explicit mechanics/API contract and judged that artifact with a named driver.

That distinction matters. The primitive verdict asked whether the requested game shape appeared from sparse instructions. The engineered verdict asked whether exposed behavior met the checks in a specified mechanical contract.

This is SI06-C2: four mechanical passes at the named gate. It is not a quality score, a model leaderboard, or proof that the player journey works.

The primitive Haiku miss did not recur in the new Haiku artifact, but prompt, API contract, driver, and model-execution conditions changed together. This comparison does not isolate which change caused the different outcome.

The machine-green build still tripped the player

The engineered Haiku cell now had a mechanical PASS. Human-terminal review then asked a different question: what happens when someone follows the controls through an actual play session?

The engineered Haiku cell passed the mechanical driver, but one operator's human-terminal review found a practical FAIL: Space started the game and also toggled pause.

Play the engineered Haiku artifact and follow the Space-key path yourself.

That finding is SI06-C3. The driver PASS remained honest: the artifact met the mechanical checks that the driver named. The practical FAIL also remained honest: one operator found a control path that made the game awkward to operate. The second verdict did not erase the first; it exposed a surface the first verdict did not cover.

Keep three columns in the evidence ledger

When an AI-built interface changes verdicts, write down the layer before you write the conclusion:

1. Prompt floor: What appeared from the request, before a detailed behavioral contract?
2. Contract coverage: Which named, observable behaviors did the automated gate actually test?
3. Player journey: What happened when a person tried to start, play, pause, recover, and continue?

Do not collapse those columns into one word such as “works.” A sparse-prompt miss says little about a later artifact built under changed conditions. A mechanical PASS says only that the named gate passed. A human-terminal finding needs its reviewer and scope attached.

The full Space Invaders experiment keeps all three layers beside the playable evidence. Use the same rule on your next generated build: name the prompt floor, name the contract, then walk the player journey before you call the result done.