What should we ask for in a sample or pilot request?
A checklist of specific items to include in a sufficiency sample or pilot request, from case type and defect mix to formats, held-out data and licence questions.
A tight sample request makes the first review quick and gives MirrorFirm enough detail to generate something you can actually test.
- Name one case type and one product, so the requirement table stays small enough to read in a sitting. - State the outcomes you need: sufficient, single gap, multiple gaps, resolvable from held records, and escalate. - List the defect types you want present, such as expired, unsigned, wrong party and conflicting values. - Specify the tool surface and status transitions your harness expects, or ask for a proposed set to review. - Ask for JSONL or Parquet, a schema version and a manifest with seeds, so loading needs no custom parsing. - Ask for a held-out slice kept apart from any cases used for tuning or training. - Ask what uses the licence permits, including publication of results, and have the answer recorded in writing. - Agree how review findings will be fed back as change requests for the next sample.
A tight, specific request makes the first review quick and produces a sample your team can test against its own checks.
- Audience:
- Environment builders
- Content type:
- Checklist
- Buyer question:
- Scope and getting started
Content release: r-a220eb6e099b243b
Related questions
- How do environment reset, seeds and versioning work for a sufficiency environment?
- What licence terms and limits should I expect for a sufficiency release?
- How should I scope a sufficiency dataset, task pack or environment?
- What does a useful first pilot look like for a team building a utility onboarding agent?
- What should I ask for in a sufficiency sample or pilot?
- What should a first handoff package contain and how do we integrate it?