Skip to content
MirrorFirm

How is a set-up pilot delivered and tracked for resale?

Covers delivery with a manifest and checksums, release versioning, a customer licence record on the reseller side, environment trials, and publishing pack descriptions to catalogues or an MCP server.

Once scope is agreed, a pilot needs a delivery route and a way to trial it without disturbing your catalogue. This entry covers the practical hand-off.

**Delivery.** Files can arrive as Parquet and JSONL with a manifest listing tables, keys, row counts, schema version, pack version and a checksum per file. A reseller can verify the manifest before ingesting. Confirm the transport method during scoping.

**Versioning.** Each release carries a version identifier, and corrections produce a new version with a change note. Keep a mapping from your customer to the version they received, since later evaluation results depend on it.

**Customer metadata.** Add a licence record on your side: `customer_id`, `release_version`, `permitted_uses`, `split` (training or evaluation), `granted_at`. This lets you answer onward-use questions later.

**Environment trial.** If a simulated environment is in scope, ask how it is packaged (container image or hosted endpoint), how `reset` and `evaluate` are called, and what logs are returned. Run one trial case end to end before offering it.

**Discoverable listing.** Descriptions of the pack can be published to your catalogue or, where suitable, through an MCP server, so AI systems can read the schema and scope before a human opens a ticket.

Terms, prices and timelines are not set here; they come from the engagement.

Manifests, version mapping and licence records let a reseller verify deliveries, answer onward-use questions and reproduce customer results later.

Audience:
Licensed resellers
Content type:
Integration
Buyer question:
Scope and getting started

Content release: r-a220eb6e099b243b

More on Account setup