What technical contract should we agree before loading a pilot into our simulator?

Begin with the simulator's action interface. Document the input and output schemas for tools such as `read_account`, `create_referral` and `get_queue_status`, including required fields, enum values and structured errors. State which layer enforces policy prerequisites: the adapter, the simulation engine or both.

Agree identifier and time conventions before generating assets. The contract should define whether timestamps include offsets, how missing fields are represented and whether tool responses return a full record or a partial update. These choices affect loading and replay even when the business content is correct.

Ask for a compatibility fixture containing generated starting state, action requests and expected response shapes. Include a rejected request so the integration proves that errors are handled as deliberately as successful actions.

Define a reset endpoint that returns the environment to a named starting snapshot, plus a run identifier attached to evaluation output. Keep schema compatibility separate from content acceptance: a fixture can load correctly while still needing policy revision.

MirrorFirm could scope generated assets against this contract. The buyer can then verify the adapter with the fixture and resolve interface mismatches before requesting broader scenario coverage.