I spent the better part of two decades in payments, where the interesting question was never what we could automate. It was what we deliberately would not. Plenty of that work was mechanical enough to hand to a machine, and some of it we kept in human hands on purpose, because the cost of being confidently wrong was somebody's money and a regulator's attention. That habit turns out to be the most useful thing I brought into AI work. The question is not where a model could go. It is where it belongs, and how little you can spend to put it there.
Two decisions sit in front of every AI feature, and most roadmaps skip the first. Does this problem belong to a model at all, and if it does, what is the cheapest adaptation that survives contact with your domain? Prompt, then ground, then teach: climb only as far as the evidence forces you, and keep the right to stop at the bottom.
- Four questions that disqualify most candidate use cases before anyone writes a prompt, and the one that quietly kills the majority.
- Where the real use cases actually cluster across the nine lifecycle phases, including the two phases where AI is most often described and least often specified.
- Why the ladder is climbed from the bottom, what each rung costs you in ways the invoice does not show, and the verdict worth writing into the roadmap: not here.
This dive sits at the front of Stage 02, before you learn to ration a context window or stand up retrieval, because both of those are answers. This is the question they answer. It assumes you have already picked a model family, which is its own procurement decision, and it does not re-teach the mechanics of grounding, which the RAG dive owns. It decides whether and how far.
Four Questions That Kill Most Candidates
Every backlog I have seen since 2024 has an AI section, and most of it is a list of places somebody noticed a model could plausibly go. That is not a use case list. It is a list of nouns. A use case survives four questions, and they are worth asking in this order, because each one is cheaper to answer than the next.
There is a fifth move for when the four are not decisive, and it is a habit I have leaned on long before any of this: invert the problem. Stop asking what would make this a good use case and ask what would have to be true for it to be a bad one. The answers arrive faster and they are more honest, because the failure conditions of a system are usually easier to name than its virtues.
The Phases Where They Actually Cluster
Run that screen across a delivery lifecycle and the survivors are not evenly spread. The full eight-forces-by-nine-phases grid is the practitioner map, and this is not a second copy of it. It is the shorter answer to a different question: given the screen above, which phases repay the attention first.
Analysis and Design, Read Properly
Design is where most AI writing, mine included, tells you what to hand the model rather than what the model can hand back. That asymmetry is worth correcting, because design work passes the screen more comfortably than almost anything else in the lifecycle. It is text. It is reviewed by people who can spot a bad answer in a minute. And nothing ships because a diagram was wrong.
Four things earn their place here. Decision records, where the model drafts the options and consequences from a design conversation and you supply the decision itself. Trade-off tables, where it is genuinely useful to be handed the axes you did not consider, including the ones you will reject. Diagram from code, where the source is ground truth and the output is checkable by anyone who knows the system. Context-map discovery, where a model reads a sprawl of services and proposes the seams, which is a proposal, not a finding.
Where it lies: a model will produce a confident architecture for a business it does not understand, complete with plausible trade-offs it has never paid for. It has read every reference architecture ever published and lived inside none of them. The judgment that survives contact with your constraints, your regulator, and your team's actual skills is the part that stays yours, and design is precisely where borrowed confidence is hardest to detect and most expensive later. The forces underneath this phase are Chapter 9; what follows here is only the adaptation question.
Three Rungs, Climbed From the Bottom
Once a use case survives, the second decision starts, and this is where money is usually lost. Teams begin at the top of the ladder because the top sounds the most serious. A fine-tuned model is a real project with a real budget and a slide. A better prompt is a Tuesday. The ladder is ordered by what each rung costs you in maintenance and lock-in rather than in licence fees, and the rule is to climb only when the rung below has demonstrably failed.
The discipline is to make the ladder visible in the decision. Write down which rung you are on and what evidence would move you up. Without that, teams drift upward for reasons that have nothing to do with quality, and end up maintaining a fine-tuned model to solve a problem a better payload had already solved twice as cheaply.
The No Is a Real Answer
The most useful outcome of this whole exercise is often a decision not to build. It is also the one nobody writes down, which means the same rejected idea returns in the next planning round with a new name and no memory of why it was dropped.
A deterministic solution already works and is cheaper to run. The output cannot be graded without the expert you were trying to free. The action is irreversible and no one will own the review. The knowledge that would make it valuable was never written down. Or the honest version: someone wants AI in the product and has worked backwards to a place to put it.
None of those are failures of the technology. They are the screen doing its job. Record the no with its reason and its expiry, because two of those conditions genuinely change over time and the other three rarely do.
The Same Judgment, Pointed Somewhere New
None of this is new engineering. Scoping work to what you can verify, sizing a solution to the problem instead of to the ambition, refusing the expensive option until the cheap one has actually failed, writing down why you said no: that is ordinary senior judgment. It is worth more in AI work than in most places, because this technology is unusually good at looking like it is working. The screen and the ladder are not a methodology. They are the questions a careful engineer already asks, made explicit so that a roomful of enthusiasm cannot skip them.
You have decided it belongs, and picked a rung. Now go build that rung properly. Rung 01 is the payload, and it is a larger subject than it looks: The Payload Contract is the next dive, then retrieval and the index behind it if question 03 sent you up a step. Or take the whole climb at a glance on the Route at Stage 02.