What manifest and licence metadata should come with a release for our platform?

Resellers usually need machine-readable metadata alongside the data. Ask for a `manifest.json` per release with fields such as:

- `release_id`, `version`, `generated_at`, `schema_version` - `workflow`, `domain`, `layers_included` - `files`: name, format (JSONL or Parquet), row count and checksum - `generation_note`: a statement that the content is generated and not real business records - `licence_ref`: a pointer to the agreed licence text, with `onward_licence_allowed`, `permitted_uses` and `redistribution_allowed` set to what is actually agreed - `split`: which files are train, validation or held-out evaluation - `known_limitations`: free text

Checksums let your platform verify delivery and detect silent changes between versions. Semantic versioning on the schema helps customers tell a new column from a breaking change. Keep `release_id` stable and bump `version` when files change, so customers on an earlier version can be identified and notified.

For a pilot sample, ask for the same manifest structure the full release would use, so your ingestion and listing pipeline is tested properly. Validate the manifest against a JSON Schema before publishing, and fail the listing if a licence field is empty. Delivery mechanics, such as object storage or an API, are a pilot decision.