How should a pilot manage versions across downloads and MCP access?

Ask for a delivery manifest that identifies `package_id`, `release_id`, `schema_version`, `task_id` and `rubric_version`. Where the same material is offered through downloadable exports and MCP resources, request a documented mapping between those identifiers and the corresponding resource references.

The runner should record the manifest with its results. Content digests can help detect an unexpected change between retrieval and execution. A task retrieved from a public endpoint should not silently replace the version used in an earlier comparison.

Scope a compatibility check before connecting the full evaluation runner. It can load a task, resolve its referenced records, validate required fields and confirm that agent-visible content excludes evaluator-only material. If the pilot includes an executable environment, check that its snapshot identifier matches the task's declared starting state.

Ask how corrections will be represented and how retired versions can be identified. These are requirements to discuss, not assumed service commitments. A useful first integration step is a small contract check against one agreed package, with clear failure messages for missing resources, incompatible schemas and mismatched rubric versions.