How should a pilot delivery be structured, versioned and validated?

A pilot delivery is easier to assess and to catalogue when it is structured like a small release.

A typical sample folder:

- `manifest.json` listing each file, its format, schema version and row count - `schema/` holding field definitions, types, keys and enumerations - `data/` with `schedules`, `instalments`, `amendments`, `policies` and `events` as Parquet or JSONL - `tasks/` with task definitions and expected outcomes - `snapshots/` with named environment states and a reset instruction - `NOTICE` stating that the content is generated, and how grounding was described

**Versioning.** Ask for a release identifier and a change note on every drop, plus a seed value where variation is generated. A reseller can then tell customers exactly which version they hold, and reproduce a result.

**Keys.** Confirm that `schedule_id` and `amendment_id` are stable across versions unless the change note says otherwise. Broken keys make it hard to compare releases.

**Metadata for your catalogue.** Carry the domain, lifecycle stages, record counts per file, formats and the generated-data statement into your own listing fields. Avoid adding claims the supplier has not made.

**Validation.** Load the sample, check manifest row counts, run key joins and run the recomputation checks. Report failures by identifier.