How should we scope delivery across downloads, APIs and MCP access?

Agree a delivery contract before building customer adapters. A release manifest can include `product_id`, `release_id`, `schema_version`, `task_contract_version`, `licence_reference` and checksums for downloadable assets. A customer should be able to record these identifiers with a training job or evaluation run.

For JSONL and Parquet exports, define field types, required columns and compatibility rules. For API or MCP access, define resource identifiers, pagination behaviour and whether a request resolves to a pinned release or a changing default. Silent movement between releases can make a customer unable to reproduce a result.

Ask how corrections will be represented. A revised narrative, repaired relationship and changed expected decision have different effects on downstream use. A machine-readable change record can identify affected tasks and whether customer caches or indexes need rebuilding.

Scope the first integration around one pinned release and one customer loading path. Verify that downloaded records and tool-returned records resolve to the same task definitions. For resellers, this establishes a practical distribution baseline without assuming any particular hosting arrangement, update schedule or service level has been agreed.