Agent quotes figures from an unvalidated multi-stage pipeline, then retracts them one fault at a time — plus self-checks whose failure mode is silence

Summary

The agent reports measurements produced by a multi-stage tool chain before validating the chain. It then finds a fault in one stage, which invalidates the previously reported number, reports a corrected number, finds a fault in the next stage, and so on. From the user's side this is an unbounded sequence of results that each get retracted:

"after verify the result you tell me the new problem and after the new problem you tell me the newer problem and the previous result cannot trust"

In one session the agent found faults in four of the five stages of a verification chain — and had quoted figures through all four. Every figure had to be withdrawn.

Separately and compounding it: five consecutive attempts to run one cross-check all failed on trivial environment/path mistakes, producing either silence or a traceback, and one of them looked like a clean pass.

Pattern A — measure first, calibrate after

A verification chain here had five stages: driver → extractor → normaliser → comparator → evidence writer. A fault in any one makes the output meaningless.

The agent quoted results from the chain from the beginning of the session, then discovered, in order:

1. the evidence writer recorded only failures, so a clean result left no trace and "no failure row mentions X" was an unfalsifiable claim;
2. the module was routed to the wrong normaliser entirely;
3. the extractor dropped tokens it did not recognise;
4. the normaliser assigned where it should have accumulated, so on multi-item inputs only the last item survived into the comparison — 10 of 13 cases affected, most of a compared surface silently absent.

Each discovery invalidated the previously reported number. The agent reported the new number anyway, and repeated.

The correct order — validate the instrument, then measure — is stated in the project's own written rules. The agent inverted it and did not notice across roughly a dozen reported figures.

What would help: when a reported quantity is produced by a multi-stage pipeline, the model should treat "have I established this pipeline is lossless?" as a precondition of quoting the number at all, not as follow-up work. A figure from an unvalidated instrument is not a weak result; it carries no information.

Pattern B — the check that cannot fail

Three separate self-checks written during this session had a failure mode indistinguishable from success:

• except Exception: continue in a comparison loop — an exception on every case printed zero rows and read as "no differences."
• if not artifacts: skip — a path bug meant 23 of 24 groups found no artifacts; all 23 were reported as skipped rather than as an error.
• a coverage loop that compared zero items and printed a summary line implying it had compared them.

In each case the agent was about to report a pass. The user caught one; the agent caught the others only after being challenged.

What would help: any verification the model writes should assert its own coverage — expected count == actual count — and treat zero-work-done as failure. The model reliably writes the happy path and omits the "did this actually run?" assertion.

Pattern C — repeated trivial environment failures on one task

Five attempts to run a single before/after comparison, none of which reached the actual comparison:

| attempt | failure |
|---|---|
| 1 | exceptions swallowed; zero rows printed, looked clean |
| 2 | a module called os.chdir at import, so every later relative path silently resolved wrong |
| 3 | pinned the working directory, but the copied file resolves paths from its own location |
| 4 | POSIX-shell /tmp vs native C:/tmp path mismatch |
| 5 | same root cause as 3 |

The underlying task was: run a function twice, compare four integers. None of these are hard problems; they are the environment mistakes a careful engineer makes once and then guards against. The agent made five in a row on the same task and reported progress between them.

Notably, attempt 2's root cause — an import with a chdir side effect — is the kind of thing the model can and should check for once, at the start, rather than rediscover through three subsequent failures.

The common thread

All three patterns are the same underlying behaviour: the model treats "I have produced output" as equivalent to "I have produced a result." Output arrives whether or not the machinery behind it worked. Nothing in the model's own loop distinguishes a number that means something from a number that is an artifact of a broken pipeline — so it reports both with the same confidence, and only external challenge separates them.

Suggested direction

Not more instructions — this project has extensive written rules, loaded in context, and they were violated repeatedly with the text visible.

Two behavioural changes would address most of it:

1. Validate before quoting. For any number produced by tooling, establish the tooling is lossless first. Treat an unvalidated instrument's output as absent, not as provisional.
2. Self-checks must assert coverage. Every verification the model writes should fail loudly when it does no work. The absence of this assertion is the single most common defect in the checks the model wrote during this session.

Reproduction

Behavioural, not a crash. Reproduces in long sessions where:

• results come from multi-stage tooling whose internals are not visible in the output,
• the environment has cross-platform path handling,
• the user challenges reported figures.

The pattern is most visible when the same figure is reported, retracted, and re-reported several times in one session.