A research archive should let another person identify what was tested, reconstruct the important transformations, and understand where reproduction stops. A source-code repository alone rarely contains that complete path. Build the bundle around a specific claim and its decisive evidence, then explain any restricted or unavailable component.
Start with a claim map
Create a small table connecting each published finding to an input identifier, operation, output, and interpretation note. Include contrary results. A reader should be able to move from a sentence in the report to a particular observation without guessing which screenshot or temporary file mattered. If a conclusion combines several observations, show that relationship explicitly.
Separate original inputs and derivatives
Keep an input manifest with size, digest algorithm, digest, source description, collection or construction date, and sharing status. Place transformations in a distinct area and record their parents. Preserve the transformation order, settings, and relevant logs. Renaming a generated report “original” does not make it a native source. A restricted-input placeholder should describe the missing role without pretending that a hash grants access to the underlying bytes.
Describe the executable environment
Record the operating system, architecture, tool and plugin versions, dependency resolution files, locale, and time-zone configuration where they affect the result. Keep exact parameter sets and expected output locations. Document network services or licensed components that another reader cannot recreate. A container can help preserve dependencies, but its presence does not establish that the experiment covered a representative population or that its conclusions are correct.
Preserve a minimal decisive example
Where sharing is authorized, include a small input that reproduces the key behavior and its independently established expected result. State which details differ from the larger dataset. A reduced synthetic example can demonstrate a parser issue without standing in for the statistical properties of operational evidence. Retain the fuller private record when it is needed to explain how the reduced example was derived.
Write a runbook that exposes failure
Describe prerequisites, ordered operations, expected observations, and known error conditions. Include how to check output against the claim map. Avoid a script that silently discards nonmatching records or overwrites failed runs. Preserve a run identifier and distinguish previous results from newly generated output. If an operation cannot be repeated because the service or source has changed, identify the archived observations that remain inspectable.
Release deliberately
Review the archive for personal data, reusable secrets, restricted binaries, and accidental case identifiers. Document licenses and permissions for included material. Provide a version, date, changelog, and package checksum. A later correction should link to the affected finding and state whether the conclusion changes. A public explanatory bundle and a protected evidence package may have different contents; describe that boundary plainly.
- Package a disagreement example
Retain both outputs and the reference used to decide between them.
- Check archive integrity
Define exactly which bytes each checksum identifies.
