Ask one question
“Can we extract these eight fields from these documents at above 85% accuracy?” is a question. “Can AI help our finance team?” is a topic.
The narrower the question, the more decisive the answer, and the cheaper it is to get.
What it must include
- Your real data, including the awkward cases
- An agreed definition of correct, written before the work starts
- A measured result, not an impression
- An honest account of what failed and why
A proof of concept that produces a percentage and a list of failure modes is worth the money. One that produces a demonstration on three chosen examples is worth nothing.
What it should skip
- Polished interfaces — the output can be a spreadsheet
- Integration — nothing needs to be written anywhere yet
- Scale — a hundred documents answers the question
- Production concerns — those belong to the build
Spending proof-of-concept budget on any of those means spending it on the wrong question.
The output document
| Section | Contents |
|---|---|
| The question | As agreed, verbatim |
| The result | A number, with the sample described |
| Failure modes | What went wrong, categorised, with counts |
| Ceiling | What accuracy looks achievable, and what it would take |
| Recommendation | Proceed, adjust or stop |
Stopping is a good outcome
If the proof shows the accuracy ceiling is too low to justify a build, you have spent a few thousand pounds instead of thirty.
We have written that recommendation more than once. It is the reason the recommendation to proceed means something.