What integration contract should be agreed before a generated environment pilot starts?

Agree whether the pilot supplies generated state and task definitions, executable transition logic, or a runnable environment. Those are different integration boundaries. A set of JSONL records does not by itself define tool behaviour, scheduling or reset semantics.

A release manifest can identify `release_id`, `schema_version`, `scenario_version`, `supported_actions`, `entry_state` and `artefact_checksums`. Ask for field types, null semantics, identifier rules and the treatment of unknown enum values. These details help an adapter fail clearly when it receives an incompatible package.

Specify who implements the observation adapter, action dispatcher and evaluator connection. Where the buyer supplies runtime components, request conformance examples showing valid input, expected output and error behaviour. Also identify whether a new release requires state migration or a fresh environment reset.

The pilot can use a small compatibility check that loads the package, resolves its references, executes a permitted action and restores the entry state. This checks the delivery contract without claiming broader workflow validity.

Before starting, document the supported export formats and runtime assumptions. Keep any proposed delivery or support arrangements subject to agreement rather than assuming they accompany the generated material.