6.4 Reproducibility Evidence
Reproducibility material should let a reviewer verify inputs, BioLine objects, downstream implementation, and runtime environment. The workspace layout may vary; the items below describe evidence types rather than mandatory filenames.
| Evidence | What to retain |
|---|---|
| Flow and plan | BioLine-returned Flow/Version ID, inspect/sourceGraph read-back, input bindings, parameters, defaults, and user confirmation. |
| Job lifecycle | Real Job ID, submission response, polling states, download, and finalization result. |
| Downstream Tool | Exact NAME:VERSION, summary/config snapshot or hash, and registered-object read-back. |
| Script and command | The script generated for this task, actual runtime command, dependencies, and exit status. |
| Pull identity | Exact derived local Tool tag, whether it existed before pull, image IDs before/after, and timestamp. |
| Outputs and logs | Result files, stdout, stderr, failure details, and relevant input summary. |
| Isolation boundary | Read-only stage, disabled execution networking, task resource settings, and cleanup decision. |
Check reproducibility at three levels:
- Object: the BioLine Flow/Job and exact Tool version used.
- Implementation: summary/config snapshot or hash and the task-generated script.
- Runtime: pulled image identity, actual command, logs, outputs, and input summary.
Historical Skill snapshots or Dockerfiles may remain as migration material, but they do not select current downstream capabilities and cannot replace exact Tool-version and task evidence.