What should I ask for in a pilot sample for a booking environment?
A checklist of items to request in a first sample so you can test loading, solvability, grading and variety without committing to a larger release.
Use this list when you request a first sample, and adjust it to your harness.
- State tables in the formats you can load, with a data dictionary covering types and nullability. - A task file with instructions, seed snapshots, scheduled events and allowed outcomes. - Expected end states or diff specifications for every task, including tasks that should end in an exception. - Policy documents referenced by tasks, with identifiers that match. - A few reference passing and failing trajectories, so you can test your grader. - A manifest listing files, schema versions and the generation seed. - A clear statement of how the sample was produced, what was reviewed, and what limits apply to its use. - The licence terms you will be asked to accept, in writing, before you load anything into production tooling.
Also decide your own acceptance checks before the sample arrives, and name who will run them. That keeps the pilot short and the result easy to explain to colleagues who were not involved.
Asking for the right artefacts up front lets a small sample answer whether the material fits your harness.
- Audience:
- Environment builders
- Content type:
- Checklist
- Buyer question:
- Scope and getting started
Content release: r-a220eb6e099b243b
Related questions
- What does a first pilot look like for an agent team in vendor finance?
- What limits apply, and will we receive any real customer records?
- How could a pilot be delivered, versioned and wired into our CI?
- How should a team scope and license a generated booking pack?
- What should we ask for in a sample or pilot of generated booking material?
- How should a sample be delivered, versioned and load-checked in my pipeline?