A rerun in a year, checkable against this one

The core does not move

One core runs every job. It is frozen and hash-asserted: the same weights, the same codebook, and a hash of both in every audit record. Adapting to a new pore or chemistry changes the decoder's front end and leaves the core alone — so the part your result depends on is the part that provably did not move.

What the record contains

Every job ships a signed JSON record. It is meant to be pasted into a methods section and kept in a validation file, which is why it names things rather than describing them.

• Identifiers and hashesThe core, the codebook, and your calibration ID if the job used one.
• ChecksumsOf what you sent and of what you received, so both files can still be identified later.
• Signal sample countsThe number the job was billed on, read from your file headers.
• ThresholdsFor a Specified Search Run, the thresholds you set and the hash of your target set.
• Country of originThe declaration you gave us, and the reference of any origin documentation.

What a rerun proves, and what it does not

The same input against the same core hash gives the same output. That is a statement about determinism, not about correctness: it shows the result is the one this software produces, not that the software is right about your sample. Those are different claims and we keep them apart, because a reviewer who conflates them will later feel misled.

What you keep

The outputs, the signed record, and the reconstruction as .sen-lite. The reconstruction is the layer you can go back to when a call is surprising — it is what makes a disagreement between your run and ours something you can look at rather than argue about.