What this service solves
Assess one AI use case against the work it would support. The assessment traces the proposed input, output, and human decision that follows. It identifies where the team's data, access rules, or review process could make a pilot unreliable or unsuitable.
What you get
Feasibility brief
See which inputs and permissions are available, what remains uncertain, and where the workflow needs human review.
Pilot acceptance checklist
Agree on representative examples, expected behavior, and failure conditions that will determine whether the pilot is ready to continue.
What’s included
Assess data and quality
Inspect an approved sample for completeness, inconsistent formats, stale information, and coverage of difficult cases. Record which parts of the proposed workflow the sample can represent.
Identify model, access, and review constraints
Identify permitted data access, candidate model constraints, and the decisions a reviewer must own. Include the path for unsupported or ambiguous output.
Define go/no-go tests and a pilot
Specify go, revise, and stop criteria for a bounded pilot. Connect each criterion to a real task or failure mode that the sponsor can review.
How implementation works
Set the use case
Agree on the use case, intended audience, and the decision or task the output should support.
Review data and constraints
Review the dataset sample, the current process, and applicable security or review requirements with the relevant stakeholders.
Present the readiness decision
Present the readiness decision and explain which gaps need to be closed before proceeding to a pilot.
Technical considerations
- Evaluation material
- Separate examples that explain the task from examples a reviewer can use to judge a possible pilot. For each difficult case, describe the acceptable result or the condition that should send the case to a person. Check whether the approved sample contains enough evidence to write those rules.
- Permission boundaries
- Map which roles can access the sample and which fields a pilot would need. Record any unresolved approval about where that data can be processed. An access gap belongs in the readiness decision even when the sample looks technically suitable.
Systems, inputs & prerequisites
A sponsor, approved sanitized examples, security requirements, and the current process.
- A named sponsor, a description of the current workflow, and representative sanitized inputs with examples of acceptable and unacceptable output.
- Documented data access and handling requirements, along with the person responsible for judging pilot results.
Starting scope & pricing
Base scope
One candidate use case, one dataset sample, up to two stakeholder sessions, and a readout.
Illustrative workflow
Review ticket samples
Check categories, incomplete descriptions, and known ambiguous cases.
Define pilot checks
Ask reviewers to judge the routing choice and verify the handoff for uncertain cases.
Flag a data gap
Record cases with missing labels and decide which ones need review before a pilot.
Validation & handover
- Review the findings with the sponsor and name the data or permission gaps that would prevent a pilot.
- Walk through a clear case and an ambiguous case using the acceptance checklist to see whether reviewers can explain the expected behavior in each.
- Record what would justify proceeding, revising the proposal, or stopping, together with the evidence the sponsor would review.
Limitations & possible extras
Limitations
The assessment uses one sample and the agreed stakeholder sessions. Sensitive data, regulated workflows, specialist assurance, or significant data preparation can change the scope.
Regulated data, sensitive access, or specialist review may change scope.
Possible extras
Expanded security review, dataset preparation, or implementation.
Questions about this service
How do you decide whether our sample represents the task?
Check whether it covers the common requests, consequential exceptions, and ambiguous cases that a reviewer can score. For any missing category, record whether the pilot should exclude it or wait for better examples.
Do we need to choose a model before the assessment?
A model choice can help frame known limits. If it is open, start with the workflow, required output, and permitted data handling, then document which constraints any candidate would need to meet.
Can we replace sensitive fields with fictional values?
Yes, if the replacement preserves the characteristics relevant to the task. A sanitized example still needs to show the layout, ambiguity, or missing information that the proposed workflow must handle.
What happens if reviewers disagree about acceptable output?
Record the disagreement and the decision that needs an owner. Clarify the rubric or narrow the pilot before using those cases as evidence of readiness.