A repository is not yet a reproducibility record
Source code and model weights are necessary, but they do not answer the decision a practitioner actually faces: will this specific artifact run on my specific setup, and what result should I expect?
The missing information generally falls into six contracts. Each should be explicit, versioned, and separable from prose.
The six contracts
A useful transfer record describes the artifact, embodiment, sensing, action, runtime, and evaluation contracts.
- Artifact: immutable source, weights, dataset, container, license, and dependency revisions.
- Embodiment: robot model, actuators, firmware, end effector, physical modifications, and calibration fingerprint.
- Sensing: camera and sensor models, placement, intrinsics, resolution, rate, transforms, and preprocessing.
- Action: joint order, units, coordinate frames, normalization, clipping, and safety limits.
- Runtime: compute hardware, drivers, inference latency, control frequency, and communication path.
- Evaluation: task definition, reset procedure, success rule, trials, interventions, seeds, and raw evidence.
What should remain private
Reproducibility does not require publishing credentials, facility layouts, proprietary datasets, serial numbers, human-subject data, or exploitable safety details. The record should support hashes, redacted fields, and controlled evidence while keeping the public claim precise about what was not disclosed.
A decision-oriented test
A repository is sufficiently described when an independent practitioner can estimate required hardware, integration work, safety constraints, and evaluation cost before downloading large artifacts. Our interviews will test which fields actually change that decision.