How could a set-up release be delivered and versioned for a lab pipeline?

A lab pipeline benefits from predictable packaging. A buyer can ask for the following, and the details are settled in the pilot.

**Files.** Record tables as JSONL or Parquet, one file per record type, plus `tasks`, `expected_state` and `policies` files. Trajectories, if requested, are a separate JSONL with one run per line.

**Manifest.** A `manifest.json` lists each file, its checksum, row count, schema version and release identifier. Loading code can refuse a release whose checksums do not match.

**Schema.** JSON Schema files define fields, types and closed status vocabularies. A changelog notes additions, renamed fields and removed tasks between releases.

**Validation.** A script checks that foreign keys resolve, status transitions are permitted and every expected state is reachable. Run it on receipt and in your continuous integration.

**Splits.** Each task carries `split` and `difficulty` fields. Held-out policy variants can be flagged so they stay out of training.

**Environment packaging.** If you want an interactive environment, ask for tool definitions, a reset entry point and the grader as a callable module that fits your harness.

**Provenance notes.** Request a short description of how the material was generated, so your team can assess grounding and disclosure risk from documentation as well as from the data.