Skip to content
MirrorFirm

What should a lab put in a sample or pilot request?

A checklist of items to include when requesting a sample, covering domain, intended use, record types, exception mix, formats, review plan and licence questions.

A clear request gets a sample that is easier to judge. Include the following:

- **Intended use:** supervised training, preference data, held-out evaluation or an interactive environment. - **Domain and variant:** for instance lending, utilities connection, healthcare administration or retail onboarding, plus any region-specific rules. - **Record types:** which of decisions, parties, accounts, conditions, policies, cases and handover notes you need. - **Exception mix:** the types of failure you most want to probe, and the proportion of hard cases. - **Format and schema:** JSONL or Parquet, field naming preferences and how identifiers should link. - **Harness details:** your tool-call format, how you run resets and what grader output you expect. - **Review plan:** who will inspect structure, policy fidelity, grounding and disclosure risk, and what findings would change scope. - **Licence questions:** use, derived models, redistribution and reporting.

State what you do not want too, such as free-text notes in a particular style. Volumes, timelines and terms are discussed directly, so leave them as open questions to resolve with MirrorFirm.

A complete request lets MirrorFirm scope a relevant sample on the first pass instead of asking you for the same details piecemeal.

Audience:
Model labs
Content type:
Checklist
Buyer question:
Scope and getting started

Content release: r-a220eb6e099b243b

More on Account setup