Archiving and Independent Reproduction

An archive succeeds scientifically when an independent reader can recover the finite claim, reconstruct its environment, execute its transformations, and compare regenerated outputs with declared tolerances. Merely preserving bytes proves only that those bytes survived. Long-term reproduction therefore needs code, inputs, semantics, environment, workflow, checks, licensing, and version-specific citation, together with fallbacks for software and formats that will eventually become obsolete.

Required background. Calculus and Linear Algebra for Relativity supplies invariant comparisons and norms; Differential Equations for Relativity supplies the benchmark, discretization, and convergence evidence being preserved.

Helpful background. Formulations of General Relativity helps interpret archived field and gauge conventions; Probability and Inference for Gravity supports ensemble records and uncertainty comparisons.

The scientific preservation package

A durable package contains more than the files used in the last successful run. It should include:

• a human-readable statement of the question, claim, validity regime, observables, and failure criteria;
• source code at an immutable revision, including generated source and local changes;
• canonical physical and numerical inputs with checksums and licenses;
• environment lockfiles, compiler or interpreter details, library versions, precision, hardware assumptions, and a rebuild recipe;
• the executable workflow, its provenance graph, and the commands or targets that regenerate each result;
• raw and intermediate numerical products needed to inspect the derivation, not only figures;
• schema definitions for units, coordinates, conventions, array layout, missing values, and version compatibility;
• verification data, expected tolerances, convergence tables, and at least one negative test;
• metadata, authorship, software and data citations, license files, and a machine-readable manifest of every archived object.

The package should have one obvious entry point and a bounded success condition. “Run these notebooks in some order” is not a workflow. “Execute target reproduce, which verifies inputs, rebuilds four resolutions, emits the comparison record, and returns failure if any criterion is missed” is a finite interface—even if future readers must reimplement the target from the preserved specification.

RO-Crate provides a current packaging model that relates a root research object to data entities, contextual entities, provenance, and workflows; the required concepts and extensible profiles are set out in RO-Crate 1.3, §§ “Structure”, “Metadata”, “Provenance of entities”, and “Workflows and scripts”. A crate can describe the scientific bundle, but conformity alone does not demonstrate that its computation runs.

Identity, integrity, and location

Three questions are often conflated:

1. Identity: which exact version of an object is meant?
2. Integrity: are the retrieved bytes unchanged?
3. Location: where can a copy currently be obtained?

A version-specific DOI identifies a deposited release; a concept DOI may resolve to a changing latest version. Cite the former when a result depends on exact bytes, following Zenodo 2026, § “Which DOI should I use in citations?”. Record both when useful, with their roles explicit.

A cryptographic digest detects changed bytes. BagIt packages pair payload files with checksum manifests and tag metadata, as specified in Kunze et al. 2018, RFC 8493, §§ 2–5. Software Heritage persistent identifiers add content-derived identities for source-code objects and directory history; the identifier syntax, object types, qualifiers, and normalization rules are specified in Software Heritage 2025, SWHID v1.2, §§ 4–6, standardized as ISO/IEC 18670:2025. A content identifier still does not guarantee that a resolver, compiler, external dependency, or execution platform will exist in the future.

Preserve multiple routes where the cost is modest: a version deposit, a content identifier for source, checksum manifests inside the package, and lawful mirrors. Never make a clean rebuild depend silently on a moving branch, latest image tag, package index, or web API response.

Preserving meaning as software ages

An opaque virtual-machine or container image can be convenient for a near-term rerun but fragile as a sole record. Its runtime, instruction set, image registry, and security assumptions can disappear. Preserve both the image digest and the materials needed to rebuild it: base-image identity, package archives or resolvable exact versions, build files, source, patches, and verification commands.

Data need a similar two-layer strategy. Keep the native efficient representation and, when practical, a simple documented interchange form for small benchmark products. Preserve the format specification and schema, not just a library capable of opening it. For a tensor array, state units, coordinates, basis, signature, index variance and order, precision, endian convention, and complex encoding. A future reader who can parse all numbers but not distinguish $K_{ij}$ from $-K_{ij}$ has not recovered the result.

Licensing is part of executability. An archive may be technically complete yet impossible to redistribute or inspect because code, input tables, or calibration data have no compatible license. Record access restrictions and lawful acquisition instructions rather than copying material without permission. Secrets and credentials must never be embedded; a workflow that requires a private service should include a preserved local input or a clearly scoped unresolved dependency.

FAIR principles improve findability, accessibility, interoperability, and reuse, but they do not assert that a computation has been rerun. The distinction follows directly from Wilkinson et al. 2016, Box 2 and § “The principles precede implementation”. Preservation metadata is supporting evidence, not a substitute for reconstruction.

Independent scalar-wave reproduction

Package the periodic scalar-wave benchmark $u(t,x)=\sin(2(x-t))$ with the fourth-order centered derivative, fourth-order Runge–Kutta method, maximum Courant factor $\lambda_{\max}=1/4$, final time $T=1$, and $N=32,64,128,256$. Preserve the final-time rule $m=\lceil T/(\lambda_{\max}\Delta x)\rceil$, $\Delta t=T/m$, and each grid’s actual step size and Courant factor. Include the exact continuum solution and full analytic semidiscrete field, including its stationary discrete-constraint contribution, but keep their evaluation code independent of the evolution update. Preserve the canonical input digest, environment, source, workflow, raw fields, analysis records, and reference thresholds.

Give an uninvolved runner only the version DOI, source content identifiers, archive checksums, and package documentation. After retrieval, disable network access. The runner must:

1. verify every payload and metadata checksum;
2. construct the declared environment on a clean host and record any substitute needed for unavailable hardware;
3. execute the complete workflow without editing inputs or intermediates;
4. obtain $3.8\lt p_N\lt4.2$ on the two finest resolution pairs, $E_{256}\lt10^{-6}$, relative energy drift below $10^{-7}$, and agreement with the full analytic semidiscrete check after isolating temporal error;
5. repeat one case at higher precision and compare the conserved energy $4\pi$ in the declared Minkowski slicing;
6. trigger a deliberate checksum failure and a deliberately wrong sign or unit, both of which must stop the workflow;
7. emit actual discrepancies, environment differences, and pass or failure in a machine-readable reconstruction record.

The runner need not reproduce every byte on different hardware. The package must state whether each product requires bitwise identity, numerical-tolerance agreement, or statistical agreement. If a dependency cannot be reconstructed, the reproduction has failed at a named step; using a newer substitute is a new experiment whose effect must be tested with the same benchmark and refinement sequence.

Preservation failure modes

The archive opens but cannot execute. Outputs without source, workflow, environment, or inputs document a result but cannot regenerate it.

The image runs but cannot be inspected or rebuilt. Retain source, build recipes, dependency identities, and licenses alongside binary environments.

The workflow downloads mutable inputs. Archive the exact lawful inputs with checksums, or fail clearly when they are unavailable. A URL is not a version.

The headline number reproduces but its error evidence does not. Preserve all resolutions, tolerances, norms, residuals, and analysis transformations needed to reconstruct the uncertainty.

A preservation identifier is treated as a correctness badge. A DOI, content hash, or FAIR record identifies and describes material. Only scientific checks establish what that material supports.

Check your understanding

An archive contains a container image, the final waveform, and a checksum manifest. The image still launches, but the source, input-data license, units, and extraction convention are absent. Has the scientific result been independently reproduced when the waveform file is regenerated bit for bit?

Solution

Only a narrow execution has been repeated. The matching bytes show that the preserved binary environment can regenerate that file, but the missing source blocks inspection and rebuilding, the missing license leaves lawful reuse unresolved, and the missing units and extraction convention prevent physical interpretation. The archive does not support independent reconstruction of the scientific claim until those semantic and legal dependencies are supplied.

References

• Kunze, John, John Littman, Liz Madden, Emily Scancella, and Chris Adams. “The BagIt File Packaging Format (V1.0).” RFC 8493. Internet Engineering Task Force, October 2018. Specification.
• RO-Crate Community. RO-Crate Metadata Specification 1.3. 22 June 2026. Specification. DOI.
• Software Heritage. Software Hash Identifier (SWHID) Specification, Version 1.2. 2025. Public specification. ISO/IEC 18670:2025 record.
• Wilkinson, Mark D., et al. “The FAIR Guiding Principles for Scientific Data Management and Stewardship.” Scientific Data 3 (2016): 160018. DOI.
• Zenodo. “Versioning.” Zenodo Documentation, accessed 18 August 2026. Documentation. Records and files.