What delivery manifest, versioning and reset details should a pilot define?

A pilot is easier to run and to pass onward when delivery mechanics are agreed up front.

**Manifest.** A file such as `manifest.json` listing each table or document, its format (JSONL, Parquet, Markdown), row count, checksum, schema reference and `release_version`. Your ingestion job can verify the package before loading.

**Schemas.** One schema per table, plus a data dictionary giving each field's meaning, allowed values and key relationships, for example `condition_id` to `decision_id`.

**Versioning.** A release identifier plus a change note for each corrected version. Agree whether corrections replace earlier versions in full or as patches, and how you will tell customers.

**Snapshots and reset.** If the pilot includes a simulated environment, define named `snapshot_id` values, a reset call that restores one, and a seed parameter so repeat runs are comparable.

**Evaluation outputs.** The format of grader results, including `failure_labels`, so your customers can aggregate them.

**Traceability.** Keep a record of which customer received which `release_version`, so a later correction can be routed.

The specific fields and mechanics are agreed per pilot. The content is generated and synthetic, so include risk review in the plan.