How should a reseller prepare for schema changes and corrected releases?

Before ingestion, agree how a proposed release would identify versions and changes. A manifest could contain `release_id`, `schema_version`, `task_spec_version`, `file_checksums` and `supersedes_release_id`. These fields distinguish altered content from a packaging change and help detect accidental file mixing.

A reseller should maintain its own transformation record linking the source release to the customer-facing package. Useful fields include `package_id`, `source_release_id`, `transform_version` and `derived_asset_ids`. If a task answer changes, this mapping can identify which translated, filtered or reformatted products require review.

Customer-facing APIs, including MCP delivery, should return release identifiers with content. Downloadable exports should retain equivalent metadata. Avoid silently replacing an evaluation case under an unchanged identifier, because customers may otherwise compare results from different task definitions.

A pilot could exercise an import followed by a proposed correction, checking whether the reseller can locate affected assets and preserve reproducible evaluations. Ask how incompatible schema changes and superseded artefacts would be communicated; do not assume a particular support commitment.

MirrorFirm could scope versioned delivery artefacts alongside the generated content so onward distribution remains traceable.