A final record is not a finished run

The small check we actually ran

On September 20, 2026, we reran the nine existing tests in ops/test_run6_guard.py using Python's standard library. All nine passed. The inputs were temporary JSON records and placeholder checkpoint bytes. No model was loaded, no tensor library was imported, and no inference, training or dataset download occurred.

The check receipt records the source revision, Python version, suite counts and source-file hashes. This is an engineering verification note. The measured research baseline and unmeasured architecture proposals remain separated in the evidence ledger.

Why a completion label is insufficient

The guard reads the final metrics and checks whether they support the claim that the declared run finished. A record with kind: final can still contain a non-finite loss, an incomplete horizon or evaluation from an earlier token count. The label alone is not the result.

One fixture supplies a NaN final loss and expects rejection. Another supplies 100 final tokens but an evaluation at 90 tokens and expects rejection. These numbers are deliberately tiny fixture values, not measurements from a language model. Their job is to exercise the decision boundary.

What the tests establish

The suite checks finite and valid metric values, final-checkpoint evaluation, the declared horizon and checkpoint presence. It also checks that changed arguments, code or data contracts cannot silently reuse an existing output directory as though the experiment were unchanged.

A valid fixture is accepted. Removing its placeholder checkpoint makes completion fail. Changing the saved evaluation manifest makes the run contract fail. These are observed software-test outcomes from this rerun, not predictions about every possible failure on a remote training host.

What remains outside the check

A placeholder checkpoint is never deserialized. The tests therefore do not establish that a real checkpoint can be loaded or resumed. They do not validate numerical stability, CUDA behavior, model quality or the authenticity of arbitrary metric files.

Those limits matter. A completion guard can prevent known bookkeeping mistakes while still depending on trustworthy producers and separate numerical checks. Passing the guard should not be described as passing the whole research campaign.

Reproduce the bounded check

In the source checkout at the receipt's revision, run python3 -m unittest discover -s mind-1b/ops -p test_run6_guard.py -v. This command selects the isolated guard suite rather than the model tests. Keep the execution boundary: source review and these standard-library fixtures are the local scope.

The next research decision is still governed by the evidence ledger, not by this test count. A successful record check makes a future result easier to trust; it does not create that result.