Skip to content
MirrorFirm

What should a first handoff package contain and how do we integrate it?

Lists the manifest, schemas, policy tables, answer key and environment files a handoff package can hold, with ordered first integration steps and decisions to agree early.

Plan the handoff as a package your harness can load without custom parsing.

**Package contents** - `manifest.json`: schema version, seed list, entity file names and the record counts for this package - Entity files in JSONL, with Parquet if you need columnar loading - `schema/` with field types, enumerations for status and defect tags, and nullability - The requirement policy as both a readable document and the machine table used to build the key - `expected.jsonl`, the answer key, kept separate from the agent-visible files - `env/` with tool definitions, a reset entry point and an event schedule

**First integration steps** 1. Load the entity files and validate them against the schema. 2. Rebuild the answer key from the requirement table and compare it with `expected.jsonl`. 3. Register the tools with your harness and run one case by hand. 4. Call reset twice with the same seed and diff the state. 5. Run a small batch and write one JSONL result line per episode.

**Agree early** - Whether tools are exposed as function-calling schemas, a Python interface or an MCP-style server - How versions are named so results can be tied to a release - Where held-out cases are stored and who can see them

Start with one case type and one tool surface. Extend only when the first run is reproducible.

A package your harness can load without custom parsing, plus a reproducibility check at the start, makes the first run trustworthy.

Audience:
Environment builders
Content type:
Integration
Buyer question:
Scope and getting started

Content release: r-a220eb6e099b243b

More on Document sufficiency