AI use cases: is it real?
Before you scope an AI use case, argue it down to three nouns: its grounding, its number, and its owner. Name all three and you have something worth building. Miss one and you have a hope, and hopes fail quietly in delivery, months after the demo impressed the room. The three gates below force those names out early, while changing your mind is still cheap.
The foundations overview introduces these gates in summary. This page is the working version: what each gate actually asks, what a failing answer looks like, and what to do with “we don’t know yet.”
Gate 1: Grounding. Where does the truth live?
Section titled “Gate 1: Grounding. Where does the truth live?”Name the system or the documents that hold the ground truth this use case needs. Not “our data” or “the intranet.” The actual system: the ERP module, the ticket queue, the contract folder, the product database. If you can’t point at it, the model has nothing to answer from, and a model with nothing to answer from doesn’t stay silent. It guesses. A guessing system is not an early version of the right system; it’s a different and dangerous thing, and you don’t ship guessing.
Two follow-ups separate a real answer from a comfortable one:
- Is the source actually good? A system can exist and still be useless as grounding: stale records, half the cases living in someone’s inbox, three fields that mean different things per team. If the humans doing this job today don’t trust the source, the AI won’t fix that. It will amplify it.
- Who controls access? “IT will grant access” and access are different things, sometimes by months. The gate isn’t “does a source exist somewhere,” it’s “can this project read it.” Name the person or team who says yes, and ask them early. Access is part of the use case, not an admin detail to sort out later.
Gate 2: Measurement. Which number moves?
Section titled “Gate 2: Measurement. Which number moves?”If this works, something changes. Name it as a number: hours per case, days until first response, tickets closed per week, error rate, backlog size. Then ask the harder half of the question: can you read that number from a system today, before anything is built?
This matters because value is proven by comparison. A baseline measured before the build, the same counter read after. No baseline before means the value can only ever be asserted afterwards, and an assertion is testimony, not evidence. “The team feels faster” convinces nobody who signs budgets, including, eventually, you.
Prefer a process counter over a person metric: measure the queue, the case, the document, not the individual. It’s cleaner to read, and it keeps the measurement about the work instead of the worker.
Gate 3: Ownership. Who decides?
Section titled “Gate 3: Ownership. Who decides?”Every process this could improve belongs to someone whose week actually changes if it works. That person is the owner: the one who can say what “correct” means, accept or reject the output, and decide go or no-go. A sponsor who finds the idea exciting is not an owner. Enthusiasm doesn’t answer edge-case questions in week six.
Orphaned AI projects don’t fail loudly. They pass the demo, get praised in a meeting, and then never reach production, because nobody’s job depended on getting them there. If you can’t name the owner, the project has no immune system: no one to defend its budget, resolve its conflicts, or notice when it quietly stops being used. Find the owner before the build, or accept that you’re building a demo.
No, Park, or Go
Section titled “No, Park, or Go”Run all three questions and give each answer one of three dispositions:
| Disposition | When | What happens |
|---|---|---|
| No | A gate fails in principle: no source exists anywhere, the value genuinely can’t be measured, nobody could ever own it | Kill it now, however good the demo feels. This is the cheapest decision you will make all year. |
| Park | You don’t know yet: the source system is unconfirmed, the number hasn’t been pulled, the owner hasn’t been asked | Homework, not a verdict. Name the system, read the counter once, get the owner’s yes. Then ask again. |
| Go | All three have names: a reachable source, a readable number, a person who decides | Proceed to the next question: what are you actually building? |
The Park column is the one teams get wrong. “We don’t know” feels like failure, so ideas get talked past the gates instead of sent back for answers. Resist that. An unanswered gate costs a week of homework. An unasked one costs the whole budget.
A use case with three names attached is real. The next question is what kind of thing it is: an assistant that answers, or an agent that acts. The distinction changes the cost, the risk, and the build.