How should a reseller package releases so customers can manage later changes?

Ask for a release manifest containing `package_id`, `release_version`, `schema_version`, `case_ids`, `file_checksums` and `licence_reference`. The licence reference should identify the applicable document; it should not be treated as a machine-readable grant of unspecified rights.

Reseller transformations can have their own manifest with `upstream_release_version`, `transformation_version` and a mapping from upstream case identifiers to customer-facing identifiers. This preserves traceability when a marketplace changes directory layouts or converts JSONL into Parquet.

Agree on how updates would be represented. A corrected evaluation label, a schema change and a removed case have different consequences for customers. An update record can state `change_type`, `affected_case_ids`, `replacement_refs` and `evaluation_impact`, allowing customers to decide whether prior runs need review.

During a pilot, test that a customer can identify an installed package and compare it with a proposed replacement. Keep versions immutable within this packaging design, rather than silently replacing files under an existing version. This is a requested integration approach, not an assumed commitment to any update schedule or support level.