Accept a pretraining artifact with reproducible evidence

Record the model architecture and parameter mapping, source revision, dependency and device environment, tokenizer artifact, corpus release and split references, serialization and packing policy, objective masks, precision settings, optimizer, applied schedule convention, and mixture history. Include successful update count and the token ledgers defined earlier. Digests help identify exact files and detect changes relative to recorded bytes; they do not prove that source permissions, labels, or scientific conclusions are correct. Those claims need their own provenance and review evidence.

Attach small objective fixtures showing target shifts, document isolation, token-count normalization, and schedule boundaries. Save evaluation document and context policies with domain numerators, valid counts, and the aggregation method. State intended use and known limits rather than converting a next-token metric into a guarantee about every downstream behavior. Model Cards provides an original framework for reporting model context and evaluation, while the experiment manifest supplies the concrete identities needed to reproduce this particular training and acceptance record.

An inference artifact may need only weights, tokenizer, and serving configuration. Faithful training continuation also needs the relevant optimizer moments, scheduler progress, scaler state when used, random-generator states, data and sampler cursors, mixture phase, and any in-flight accumulation state at the chosen checkpoint boundary. Decide whether checkpoints occur only after completed updates or explicitly preserve partial work. Restoring weights at one update with a data cursor from another can silently skip or repeat examples and break the claimed trajectory.

PyTorch 2.9 distributed-checkpoint documentation describes saving selected distributed state and distinguishes asynchronous staging from save completion. It does not automatically invent missing application state or guarantee cross-version compatibility. A successful load verifies only part of recovery. Run a controlled restore drill: compare the next batch identities, applied rates, valid counts, and subsequent updates with a reference under the documented environment. Exact bitwise continuation may be an appropriate narrow oracle, while a changed backend may require a declared numerical and behavioral comparison instead.

Require complete artifact availability, integrity checks against the manifest, objective and normalization fixtures, fixed-domain evaluation, and the restore drill defined for the release. Record failures and accepted limitations with ownership rather than erasing them from the report. A demonstration on one topology does not establish restore behavior on every topology, and seeds alone do not guarantee identical results across releases or devices. PyTorch's reproducibility guidance explicitly scopes those guarantees; the acceptance record should be equally precise.

The cache lab is a deterministic fixture for reproducing one trace from a complete initial state. Reset, set both C=4,s=4, predict twelve hits after the initial sixteen requests, then take one Step for seventeen requests and thirteen hits. Reset and set both C=4,s=4 again to reproduce the same trace. The model caps at 4,096 requests and has no checkpoint serializer, optimizer, RNG, data cursor, or asynchronous storage. It illustrates a repeatable oracle, not evidence that a real training checkpoint has captured all necessary state.