How is a booking release keyed and described for catalogue listing?

A release for resale works best when every record can be traced through stable keys and each file states what it is.

A typical record chain links these identifiers:

- `application_id` (for example APP-2187) to `approval_id` - `approval_id` to `facility_id` (FAC-5531) and `condition_id` entries - `facility_id` to `security_id`, `party_id`, `schedule_id` and `settlement_id` - `facility_id` to `booking_event_id` rows that record each status change with a timestamp and actor role

Tabular files can be delivered as Parquet, and event streams or task definitions as JSONL, one object per line. A manifest should describe each file: the schema version, the generation run identifier, the row counts for that release and the record families included.

For catalogue metadata, ask for fields you can republish: a plain description of the workflow, the roles represented, the intended use (training, evaluation or both), and a statement that the content is generated. Keep the provenance fields in your listing so your customers see the same information you saw.

Foreign keys should resolve within a release. Ask for a referential integrity report so you can confirm that before listing.