Skip to content
MirrorFirm

How should a sample be packaged so it can be loaded and checked quickly?

A self-describing package layout with manifest, schema, tables, cases, trajectories, grader and environment, plus an acceptance run and a structured feedback channel.

A sample should load and run on your side without a call, so ask for a package that describes itself.

**Package layout** - `manifest.json`: release label, schema version, policy versions, file list and checksums - `schema/`: table definitions with types, keys and nullability - `tables/`: Parquet or JSONL, one file per table - `cases.jsonl`: case file with seeds and expected outcomes - `trajectories.jsonl`: reference steps with state hashes - `grader/`: scoring code and a description of each check - `env/`: tool definitions and a reset entry point

**Acceptance run.** Load the tables, call `reset` for three cases, replay the reference trajectories and confirm the state hashes match. If any hash differs, the environment is not deterministic and that should be raised before pilot work starts.

**Feedback channel.** Record review findings as JSONL with `case_id`, `step`, `finding_type` (policy, realism, grader or schema) and `note`, so corrections can be applied to the right cases and tracked across revisions.

**Interface options.** Direct file loading, a Python package, an HTTP service or an MCP tool surface. Pick the one your harness already uses.

**Limits.** The sample reflects the agreed scope only. Treat fields and tool names as a proposal until the scope sheet is signed.

A sample that loads, resets and replays on your side without a call shows quickly whether the environment is deterministic and the schema is usable.

Audience:
Model labs
Content type:
Integration
Buyer question:
Scope and getting started

Content release: r-a220eb6e099b243b

More on Loan booking