the deployed system ran the opposite of its specification

The frozen specification said one thing and the deployed code computed the other. The sign of the score was inverted in the branch that acted on it, so every decision taken went the opposite way to the one specified. In the same path the smoothing window was longer than the frozen text called for — two independent deviations from the same document, in the same few lines, in the one place where output still looks entirely plausible.

What made it findable was a parity re-run: reconstruct the value that had been logged, using the platform's own history and a transcription of the frozen rule, then compare. Before the fix the reconstruction disagreed with the log. After it, the reconstruction matched the frozen reference exactly, and a test now pins the mapping between score and direction so the sign cannot drift again.

Then came the harder question of what the inversion had actually done. A read-only replay measured it against the exact data the live system had processed, item by item, without touching anything live. On that stretch the inverted system happened to come out ahead. The finding was written down as it stood.

The frozen mapping stayed anyway. A system is not made correct by having been lucky, and an audit whose answer is allowed to depend on the outcome is not an audit. What it proves is that they can measure the distance between what a system does and what it was told to do, and that they publish the measurement even when the accident fell in their favour.