How should delivery, versioning and reset work for a resold pack?

When a pack passes through a reseller, three things decide whether customers can rely on it: versioning, identifiers and reset.

**Versioning.** Each delivery carries a `release_id` and a `schema_version` in `manifest.json`. Changes to field meaning increment the schema version. Corrections to records produce a new release with a change list by `case_id`. Customers should be able to pin a release when they report results.

**Identifiers.** Keep `case_id`, `doc_id`, `rule_id` and `gap_id` stable within a release lineage. If you combine releases from more than one source, add a namespace prefix so identifiers cannot collide.

**Formats.**

- JSONL for nested records, split by record family - Parquet for flat tables, with gaps and request items exploded to rows - a `schema.json` describing fields, enumerations and optional columns

**Environment.** If the pack includes tool actions, define `reset(seed)` so that the same seed restores the same case state. Log the seed, release and policy version with each run. Add an `export_state` call that returns the final case, request and audit records for scoring.

**Passing it on.** Include the manifest and schema in every customer delivery, along with any restrictions you are required to pass on.

All content is generated. Agree in scoping how corrections and withdrawals will be communicated to customers.