How could a scheduling pack be delivered, versioned and connected to an evaluation harness?

A pack can be delivered in more than one form, and the choice should follow how your harness runs.

**Static files**

- JSONL per entity for readability and diffing, Parquet for large tables. - A `manifest.json` with schema version, generation parameters, seed, file hashes and a change log. - A `tasks` file linking each task to its starting snapshot, as-at date, policy references and expected end state.

**Interactive environment**

Where tasks need tool use, the environment can be offered as a container or as tools served over MCP. Typical tool set: `get_agreement`, `get_schedule`, `propose_adjustment`, `commit_adjustment`, `request_approval`, `add_note`, `list_postings`, plus `reset` and `snapshot` for the harness only. Keep harness-only tools hidden from the agent.

**Versioning**

- Use semantic versions for the schema and a separate release identifier for the data. - Never change a released task's expected state in place. Issue a new task version and mark the old one deprecated. - Record the release identifier in every result so scores can be compared like for like.

**Questions to settle in the pilot**

- Id formats and money representation (integer cents is a safe default). - Time zone and calendar handling. - Whether your tool names should be mirrored. - Where the environment runs, and how reset is triggered between runs.

These details are agreed during scoping, not fixed in advance.