How is a pilot delivered and wired into an existing environment harness?

A pilot can be delivered as files, as a runnable service, or both. Choose based on how your harness loads state.

**File delivery**

- JSONL for entities that are read row by row, and Parquet for larger tables that you query. - A `manifest.json` listing each file, its schema version, a content hash and the generation seed. - A `tasks.jsonl` where each line holds `task_id`, `snapshot_id`, `prompt`, `accepted_end_states`, `trap_tags` and `split`. - A separate `labels` folder for validity labels and the answer key, so it can be withheld from agent-facing containers.

**Service delivery**

- Tool endpoints matching your action names, such as `get_request`, `get_authority`, `approve`, `escalate`. - `POST /reset` taking a `snapshot_id` and optional seed, returning a state version. - `GET /state/diff` returning added, changed and removed rows since reset. - `POST /grade` returning outcome, process and penalty scores for the episode trace.

**Wiring steps**

- Load the snapshot into your engine's store and confirm row counts and key joins against the manifest. - Map tool names and argument shapes with a thin adapter, rather than editing the generated files. - Run a scripted correct trajectory and a scripted invalid one for several tasks, and confirm the graders separate them. - Pin the release version in your configuration so later regenerations don't change results unnoticed.

Interface details are open to negotiation in scoping. The generated material is synthetic, so test the wiring on that, not on any production system.