Start with the guard that was already in place. It compared the number of sampled frames between the two files, and sampling is time-uniform, so two generations whose durations differ by 0.1s both yield exactly 60 samples [2]. The count is a function of the sampler, not of the pairing. Nothing else in the pipeline verified that the output had been burned from the preview it was being diffed against [3].
Calibration inherited the same hole. The single episode with both files on disk became the positive control [4], and the line went in at 55.0 with zero cluster overlap and a 33x gap [5]. A 33x gap is persuasive right up until you notice both clusters sit on the same side of the question. That episode's preview carried an mtime nine hours later than the output, and later than the gate run that had already approved it [6], so the control's reading of 19.51 describes a non-pair [7].
Genuine pairs, produced by writing a content-hash link at the moment the output was created, measured 2.94 and 3.37 [8]. Divide 19.51 by 3.37: the sample labelled known-good read about 5.8x above the worst real pair [19], and the threshold sat a further 2.8x above the control itself [21]. The recalibrated line is the log-midpoint of the worst verified pair and the best-known bad pair, sqrt(3.37 * 19.31) = 8.07, taken as 8.0 with 2.4x of headroom in each direction [14]. That is roughly 6.9x below where the measured threshold had been [20].
Two verified pairs is not a distribution, and the author writes that into the comment rather than burying it [15]. What picked the direction was cost. A false positive orders a re-render across a closed set of artifacts predating the new bookkeeping, while a false negative puts a fabricated violation into a publish decision and can mask a real one [16]. The 212px record is the second cost paid out: two unrelated regions of two different pictures, merged into a blob covering a quarter of the frame [12].
Treat 8.0 as local. It is pinned to this pipeline's background re-encode noise, the 3-to-4 range the repo's own comment file had documented long before the calibration [9]. To reuse the number you would need your preview and your output to come off the same codec path at the same settings, so that your band one also lands near 3 to 4 [9]. Otherwise you have borrowed the arithmetic without the measurement.
The framing is the part worth keeping: a threshold is a proxy for a fact you failed to record, and the repair is to record the fact [22]. One line at the end of each burn, preview_sha256 to output_sha256, read by the gate as proof [17]. It has to be the content hash and not the filename [18]. The re-rendered preview kept its path while its bytes changed [6], which is the case a name cannot express.
