How should a pilot preserve reproducibility as generated material changes?

Ask for a release manifest containing `release_id`, `schema_version`, `policy_bundle_id`, `environment_build` and content hashes for delivered artefacts. The buyer's run record can add the agent configuration, harness version and selected task identifiers. Together, these fields define what was actually evaluated.

For files, preserve the manifest beside the JSONL or Parquet export. For delivery through an MCP server, ask how a client requests a fixed release and verifies which revision a tool returned. A moving default should not silently replace the material used in a comparison run.

A revision record can distinguish editorial corrections from changes to task evidence, accepted outcomes or tool behaviour. Those categories have different implications: a wording correction may preserve comparability, while a changed routing policy can require a fresh evaluation baseline.

At pilot setup, define how changed tasks are identified and how results from withdrawn or corrected cases are treated. A useful first integration check is to load one pinned release, execute a task and confirm that the stored run record contains enough information to reproduce its inputs.