Identical report headers hid an eightfold gap between three runs of one model probe

The author wrote that the report could not tell him "whether I had one result and two outliers or two results and one accident" ^[15]. The blind spot is ordinary. His code never sent sampling parameters, so the effective values came from the model's own configuration file ^[6]. A re-pull of the same tag can replace that file ^[6]. The model column held the tag, so two runs on different weights read back identically ^[6].

The two readings differ by a factor of about eight ^[1]. The outlier run's scratch directory had already been cleaned up; housekeeping, for once, ran on schedule. He wrote: "Those four facts about it are permanently unrecoverable." ^[7]

His changes are to what a field means. When a provenance field cannot be read, the report records null, never an inferred value ^[8]. "An old report with no digest does not mean it ran the weights I have now, and filling that cell with today's digest would turn a gap into a false statement," he wrote ^[9]. A test enforces the rule. A report written before the change reads back as not recorded, so it cannot be mistaken for a clean run ^[8]. That test is the best engineering in the post, because a missing value becomes a state the reader can see. A second rule records what the system did. For context length that is the value the runtime granted, and a mismatch with the value sent is itself a finding ^[10].

Then he tested the header itself. Four runs under deliberately different machine conditions, one of them a cold start, showed zero drift across ten fields ^[11]. The context length matched because a server-side environment variable pinned it ^[12]. Three models with declared context lengths of 40960 and 262144 all read back the same effective number ^[12]. Those declared values differ by a factor of 6.4 ^[2]. Memory negotiation would not produce one number from that spread ^[12]. "So that field records a number and cannot record where the number came from," he wrote ^[16].

This case supports the claim that more columns will not close the gap. The field existed and its value was correct. I think a column for the value's origin would help only if something inside the record could read the variable that set it, and here the determining factor lived outside the record ^[13]. I'd expect the same failure in an approval ledger wherever a rule's outcome depends on configuration the ledger never reads. The author wrote that the ledger columns "are necessary and they are not sufficient" ^[2].

The claim holds less cleanly for the first incident. The digest and the server version were simply not recorded ^[6], and recording them means adding data to the row. The evidence is also narrow. It is one probe report, a measurement record, and the pinned-variable failure has appeared once, in one field ^[13]. The author calls the general form "a hypothesis worth testing rather than a law" ^[13]. The post does not include a case where an approval decision itself could not be reconstructed.