What delivery metadata should survive a reseller's format conversion?

Ask for a sample delivery with a machine-readable manifest before building the reseller's ingestion pipeline. Useful fields include release_id, component_id, schema_version, file_format, content_hash, policy_configuration_id and evaluation_config_id. A licence_reference can identify the applicable agreement without embedding invented permission claims in the data.

Records can arrive as JSONL, while relational tables may suit Parquet. Conversion should preserve identifiers, null meanings, enumerated values and links between components. A reseller-specific identifier can be added alongside the source identifier, allowing support teams to trace a transformed record back to its generated release.

The manifest can also point to included scope notes and known limitations. These should travel with customer exports rather than remain only on the reseller's internal product page. If a component is omitted, the resulting package should declare that omission instead of retaining a manifest that implies completeness.

For simulated environments, include the fixture and runtime compatibility references needed to initialise a supported configuration. A useful first integration test is to import the sample, export it through the proposed sales channel and verify that identities, relationships and scope metadata survive the round trip. That tests packaging fidelity before commercial distribution.