What technical delivery details should be agreed before a pilot starts?

A pilot can begin with a delivery contract that defines the package structure independently of individual tasks. A release manifest can contain release_id, schema_version, content_hash, file_inventory, encoding and licence_reference. Each file entry can state its format and the schema it follows, allowing the lab to validate a download before ingestion.

For JSONL, agree how multiline text, missing values and malformed records are handled. For Parquet, agree field types and timestamp conventions. Stable task identifiers can let reviewers reconcile a website preview with an exported record without relying on display order.

If material is accessed through a public MCP server, ask for the relevant tool or resource schemas, pagination behaviour and version-selection rules. The lab should establish whether requests retrieve a fixed release or changing content, and how interrupted retrieval can resume without silently duplicating records.

MirrorFirm could scope these details alongside the generated sample. A useful first integration step is a loader that checks the manifest, validates a task and records the release reference used in a run. Schema migration and compatibility expectations should be agreed explicitly rather than inferred from an initial successful import.