Narrowing an AI Idea Into Something Buildable

Broad ideas cannot be built or measured

“An AI assistant for our operations” is a mood rather than a specification. Every project that starts there converges, after a month of expensive discovery, on something much narrower.

Doing the narrowing first saves that month.

Four cuts

1. By input. Which single document type, message format or data source first?
2. By user. Which one team, and what do they do with the output?
3. By decision. What specific decision or output does it produce?
4. By consequence. What happens if it is wrong, and who catches it?

If you cannot answer the fourth, stop. A system whose errors nobody catches is not ready to be built, however good the idea.

A worked narrowing

Start: “We want AI to help with our supplier paperwork.”

• By input: supplier invoices arriving as PDF by email — not delivery notes, not statements, yet
• By user: the two people in accounts payable
• By decision: extract nine fields and match against the purchase order
• By consequence: wrong match delays a payment; a person reviews anything below threshold or above £2,000

That is buildable, measurable and quotable. The original sentence was none of those.

Check it against the four traits

Volume in the hundreds a month at least. Errors recoverable rather than catastrophic. A clear definition of correct that two of your own people would agree on. And existing material to work from.

Missing any one of those is usually enough to sink a project, and the one most often missing is a clear definition of correct.

Then prove it on fifty cases

Before commissioning the build, run the narrowed version against fifty real historical examples with known answers. Days of work, and it settles whether the project is a delivery project or a research project.

Knowing which you are funding is worth a great deal on its own.

Frequently asked questions