What should we put in a pilot sample request for mismatch cases?
A short list of items to include when requesting a pilot sample so the first delivery can be inspected, run and scored without rework.
Include these in the request so the first sample is usable on arrival.
- The decision the pilot supports, and what result would change it. - One domain, the two systems in conflict, and the cause types to cover. - Whether you need static cases, a stateful environment, or both. - The labels required: root cause, correct action, alternatives, required evidence and expected final state. - The policies and approval limits to include, with some variation across cases. - A share of cases where the correct action is escalation or no change. - Your file formats, identifier conventions and any harness constraints. - The inspection checks you will run, and who on your side will review the cases.
Ask MirrorFirm to confirm in writing what is in scope, what the licence permits and how disclosure risk will be handled before delivery starts.
A complete request gets you a sample you can inspect and run in your harness, rather than one that needs another round to be usable.
- Audience:
- Evaluation teams
- Content type:
- Checklist
- Buyer question:
- Scope and getting started
Content release: r-a220eb6e099b243b
Related questions
- What does a first sample review look like for a bank feed and ledger pilot?
- How is generated mismatch material licensed, and what limits apply?
- What technical steps make up a useful first end-to-end trial?
- How should I scope a pilot for this workflow?
- What should a pilot brief for a mismatch environment include?
- How should a pilot delivery be packaged so it loads into our environment?