An immutable release identifies what ran and how affected data can be retired

Record ordered shard identifiers, integrity digests, source snapshot identifiers, document and token counts, tokenizer revision, extraction and normalization versions, deduplication rules, language and quality models, sensitive-data transformations, and overlap exclusions. Include mixture weights, sampling policy, seeds where meaningful, packing, and relevant loader behavior. Different orders or loader policies can create different training sequences from identical files. A seed alone does not guarantee bitwise reproducibility across nondeterministic kernels, changed libraries, or distributed scheduling. State the reproducibility level and retain the actual artifacts needed to support it.

A manifest digest can identify a canonical serialization of those records, while shard digests verify the referenced byte content. Specify the digest algorithm and serialization rather than assuming any JSON formatting produces the same bytes. Practical cryptographic content addressing relies on suitable collision assumptions; it does not certify that provenance is truthful or processing was correct. Do not publish raw sensitive text or guessable personal identifiers merely to make a manifest detailed. Access-controlled references and minimal audit metadata can preserve necessary traceability without exposing every underlying document to every manifest consumer.

Maintain relationships among raw captures, extracted documents, duplicate representatives, shards, mixtures, and training runs. W3C PROV provides a primary model family for describing entities, activities, and derivations; a useful local implementation still needs complete, truthful records. If a source is retired under the project's decision process, find the union of its affected descendants and identify each consumer. Shared shards or mixtures can be reached along several paths, so do not add path counts as though every path represented a distinct artifact. Distinguish an affected artifact from one that must necessarily be deleted unchanged.

Define the action: block new sampling, publish a replacement release, revoke access, delete specified storage copies, purge caches, or investigate trained models. Historical release identity can remain stable while an external status record marks it retired and prevents future use; immutability does not require indefinite storage of disallowed content. Keep only the audit metadata that the applicable process permits. Deleting a dataset file does not automatically remove learned influence from model weights, revoke every downloaded copy, or demonstrate successful unlearning. Those are separate dependencies and technical or policy questions with their own evidence.

A replacement manifest should name its predecessor, explain the changed scope, and give new shard digests and counts. Recompute mixtures if available domain mass changes, distinguishing natural proportions from intentionally maintained sampling targets. Verify that caches and loading jobs cannot silently resolve the retired alias to old bytes. Test reconstruction from the manifest and audit whether known affected records are excluded from the replacement. Dataset cards such as Dolma and FineWeb show why source and processing documentation belongs with usable releases; a card alone still cannot substitute for artifact-level identity and dependency records.

The modular lab illustrates why a tiny identifier space cannot uniquely label arbitrary artifacts. Reset, explicitly set BOTH modulus m=8 and stride a=4, predict an orbit of only two residues, then Play or Step. Reset and re-set BOTH m=8 and a=3; predict eight distinct residues before repetition. Edits retain t, and n=min(2000000,floor(2t)) selects the capped step. This additive orbit is not a cryptographic digest, manifest validator, or dependency engine. Its unavoidable repeats demonstrate only the limits of small finite identifiers, not an attack or collision-rate estimate for a real cryptographic hash.