Skip to content
MirrorFirm

What formats and handover details should a pilot agree?

Agree file formats, a schema, a manifest, task definitions, tool lists, reset behaviour, log access and defect reporting up front so the pilot output loads into your harness.

Agree the delivery details in the pilot so your harness can load the output without rework.

**Files and formats.** Ask for JSONL for record files, and Parquet if you prefer columnar loading. Request a schema file listing each field, its type, allowed enumerations and which fields are foreign keys.

**Manifest.** A manifest should list every file, its record count, the release version and the schema version. Request a changelog, so a corrected sample can be compared with the first.

**Task definitions.** If you want a task pack, ask for a tasks file with task_id, decision_id, start_state_ref, allowed_actions, expected_end_state and accepted_reason_codes. Keep it separate from the records, so tasks can be regenerated without changing the underlying cases.

**Environment.** For a simulated environment, agree the tool list, such as get_decision, list_conditions, read_evidence, request_evidence, mark_condition_reviewed, escalate_to_approver and release_step. Agree how reset works: snapshot restore, fixed seeds for evidence arrival, and whether runs can execute in parallel.

**Evaluation hooks.** Ask how action logs are exposed and in what format, so your grader can read them without parsing free text.

**Feedback.** Agree how defects are reported, by case identifier and file, and how corrected versions are issued.

The content is generated, so build a validation step that checks referential integrity on every delivery.

Agreeing delivery details before the sample arrives avoids rework and gives you a clear way to report and correct defects.

Audience:
Evaluation teams
Content type:
Integration
Buyer question:
Scope and getting started

Content release: r-a220eb6e099b243b

More on Approval conditions