How should a pilot release be delivered and versioned for my pipeline?

Agree the delivery mechanics early, because they decide whether your results can be reproduced later. A pilot could be arranged along these lines, with details settled in scoping.

- **Manifest.** A file listing each data file, its schema version, a checksum and the relationships between files. - **Release identifier.** A version string for the release as a whole, so every run log can say which release it used. - **Schema version.** Changed whenever a field is added, renamed or retyped, with a short changelog. - **Seeds.** The generation seed or configuration reference for each snapshot, so a defect can be traced and a corrected snapshot regenerated. - **Field mapping.** A table linking release names such as `instalment.due_date` to your own columns and tool arguments, so loaders stay thin. - **Held-out split.** A flag on each task showing whether it belongs to training, development or sealed evaluation.

On your side, store the release identifier with every run record and grader result. When a new release arrives, rerun the same baseline agent on unchanged tasks to separate data changes from model changes.

Treat checksums and load-time validators as the first gate. The material is generated, so a validator that fails loudly on broken invariants is cheaper than finding them in training results.