What should a reseller ask for in a sample or pilot?
This checklist sets out what to request in a sample or pilot so that you can test the data, the delivery and the onward licensing questions together.
Put these items in your pilot request so that nothing important is left to a later round.
- A sample covering one or two named case types, with the full set of linked records. - The schema file and a manifest stating the release version and generation settings. - A statement of how the content was generated and what filtering was applied to identifiers. - A defect mix you specify, such as more near-miss documents and fewer obvious gaps. - Reference scoring logic or hooks, so you can reproduce evaluation results. - If relevant, an environment with a reset call and a seeded snapshot. - Draft terms on sublicensing, restrictions passed on to customers and update handling. - A named contact for questions raised by your acceptance checks.
Agree your pass criteria before the sample arrives, and write them down.
Keep the pilot small. A sample that is easy to read in full will reveal more problems than a large one you can only skim.
The output is generated, so include a grounding and disclosure review as a step in the plan, and keep a record of what was checked and by whom.
Asking for data, documentation and terms together lets your technical and legal reviews run in parallel and finish sooner.
- Audience:
- Licensed resellers
- 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?