How should a pilot be packaged and versioned for onward licensing?

A pilot delivery is easiest to resell when it arrives as a self-describing package that your platform can ingest and your customers can verify.

**Package layout:**

- `manifest.json`: release identifier, schema version, generation run identifier, file list with checksums, record families and a statement that content is generated - `tables/`: Parquet files for approvals, conditions, facilities, parties, security links, schedules and booking events - `tasks/`: JSONL task files, with train and eval splits in separate files - `policies/`: JSONL rule and delegation entries keyed by `rule_id` - `environment/`: scenario snapshots and the tool action specification, if included - `LICENCE` and `DISCLOSURE` text files as agreed in scoping - `CHANGELOG`: what changed between versions, including corrected defects

**Versioning:** use a version tag on the release and carry it in every file's metadata, so a customer can tell which version they hold. When a defect is corrected, the new version should list the affected `facility_id` or `task_id` values.

**Ingestion checks:** verify checksums, validate files against the schema, confirm keys resolve, and confirm that no case appears in both train and eval files.

Ask whether your platform's metadata fields map onto the manifest, and whether withdrawn versions can be flagged.