Intelai
If You Cannot Name the Decision, You Have a Topic
Most AI use case frameworks start with a problem and a KPI. Start one step earlier, with the decision, the person who makes it, and the record it leaves.
"Reduce readmissions." "Improve maintenance throughput." "Automate compliance review."
Those are topics. They are not use cases, and the frameworks that start with them produce a stack of documents that nobody funds.
A use case has a decision at the center of it: a specific person, at a specific moment, choosing between specific options, with something at stake. If you cannot point at that person and that moment, the project will spend its first quarter trying to find them, and its second quarter building for whoever showed up.
Four questions before anything else
Ask these in order, and do not move on until each has an answer you could write down.
Who decides today? Not the department. A role and, if possible, a name. The maintenance planner at the depot. The contracting officer reviewing a modification. The analyst who writes the threat assessment. If the answer is "leadership," you have not found the decision.
What do they look at now? The actual inputs, including the ugly ones: a spreadsheet, a PDF, a phone call, a legacy screen with a green field. Whatever the system will replace has to beat that, and the spreadsheet is usually faster than people admit.
What would they accept instead? This is the question that determines whether the model can be simple. A ranking they review or a decision you make for them. A draft they edit or a document they sign. Acceptance criteria live here, not in a KPI list.
What record does the decision leave? In a regulated environment, this is the question that decides the architecture. If the decision produces a signature, a justification, or an entry in a system of record, the AI has to produce evidence along with the answer.
Where the usual framework goes wrong
The standard six-step template asks for problem framing, data evaluation, modeling feasibility, value estimation, deployment path, and change management. That is a reasonable table of contents for a project plan. It is the wrong order for deciding whether to start.
Framing as a KPI exercise. "What metric are we optimizing" invites a metric that is easy to measure rather than one that is worth moving. Readmission rate is measurable and partly outside anyone's control. The decision to flag a patient for follow-up is controllable, and it is the thing you can actually improve. Frame on the decision, then pick the metric that tells you whether the decision got better.
Data as a feasibility question. The framework asks whether the data exists and is clean. The harder question is whether you are allowed to use it, in that place, for that purpose. In federal work the answer is often no, or not without a handling caveat, an authorization boundary, or a data rights negotiation. A use case that requires a data flow nobody will approve is dead regardless of model quality.
Value as ROI. Dollars saved is the easiest number to write and the hardest to defend in a mission agency. The defensible versions are hours returned to a person, cycle time reduced on a process with a queue, or a risk reduced with a named consequence. Pick one and attach it to the decision. "Saves $1M a year" invites a question about the baseline that nobody can answer.
Change management as a section. Adoption is not a phase. If the person who makes the decision is not in the room when you design the output, you are building a demo for an audience of one procurement file.
The federal additions
Four questions that the generic template omits entirely, and every one of them has killed a project I have seen proposed.
Who has the authority? If the AI recommends and a human signs, say so and design the signature. If the AI acts, name the delegation and the ceiling. Blurry authority is where pilots go to die, because nobody will put their name on the first wrong output.
What is the failure mode and who catches it? A wrong recommendation that a human reviews is a nuisance. A wrong action that flows into a record is an incident. Write the failure down and name the catcher before you build.
Can this be sustained? A model is a component with a retraining schedule. If there is no team to own it in eighteen months, the honest plan is a rules engine with a human in the loop, which is often the right answer anyway.
What does the evidence package look like? Input, output, model version, threshold, and the human decision. If you cannot produce that on demand, the system cannot support the decision it was built for, no matter how good the accuracy is.
One page is enough
| Field | What goes in it |
|---|---|
| Decision | The choice, in one sentence |
| Decider | Role and name |
| Today | Inputs, time taken, current error rate |
| Output | What the system produces, and what the human does with it |
| Threshold | The number that decides good enough, set before evaluation |
| Failure | What goes wrong, who catches it, what it costs |
| Record | What the decision leaves behind, and where it lives |
| Owner | Who maintains this in eighteen months |
If a row is blank, the use case is not ready for a budget. That is not a failure. It is a cheap way to find out.
The model is the last decision you make, not the first. Everything above can be settled in a week of conversations, and settling it is what stops a technically successful project from being an expensive answer to a question nobody asked.
Write the page, take it to the person named in the second row, and ask whether the decision described is the one they actually make. If they say no, you just saved a quarter.