Find the Use Case Before the Model

Article 10 of 10 The New Force · 8 min

There is a page on this site where I mapped the entire software lifecycle against AI: nine phases, the eight forces reshaping them, seventy-two cells, each one an honest note on where AI helps and where it hurts. I still stand behind that map. But laid out as a grid, it reads like a menu, and a menu makes every cell look ready to order. That is the moment the map stops helping, because the question that decides whether any cell becomes real value was never on it: not what AI can do in general, but what it is for, here, for us.

// the crux

Before anyone names a model, ask where the knowledge lives. When the honest answer is people’s heads, no model can retrieve it, and the first use case is the unglamorous one: writing it down.

// in one breath

Why a map of AI across the lifecycle, including my own, answers the easy half of the question.
Three questions that separate a use case from a demo, and what each answer decides.
The one-page record that turns a promising demo into a decision somebody signed, and the failure mode it exists to catch.

↳ the force itself · Make AI a First-Class Force – the mindset this essay applies: the fundamentals as the interface, the decision still yours to sign.

the backwards question

The Question That Arrives Backwards

When AI comes up in a delivery organisation, the first question is often a model name wearing a question mark. Which model should we standardise on. Which vendor, which platform, which licence. It arrives confident, budget attached, and it arrives backwards. Nobody has named the work yet. Nobody has said which phase of the lifecycle is bleeding hours, which knowledge the answers must come from, or who will be reading the output at the moment it is wrong.

This series opened with a discipline for exactly this failure: write the criteria before the shortlist, because whatever gets named first quietly becomes the anchor everything else is measured against. Choosing a model before naming the use case is that same bias. The tool is more impressive now. The mistake has not changed at all.

Capability is what the demo shows. A use case is a commitment: this work, this knowledge, this cost of being wrong, this person still accountable.

the map, read properly

Where the Lifecycle Actually Wants Help

Read as an architect rather than a tourist, the lifecycle is a map of candidate use cases, and each phase has a different honest answer. Two columns matter for every phase: where AI genuinely earns a place, and where it will lie to you while looking helpful.

Analysis

requirements → understanding

Interrogation. Feed it the draft requirements and instruct it to attack: name every ambiguity, every unstated assumption, every edge case the happy path is hiding. Asked to agree, a model flatters. Asked to attack, it is tireless, and it does not worry about offending the author. where it lies: it invents requirements as fluently as it finds them; every finding routes back to a human who can say that is not what the business meant.

Design

options → decisions

Sparring. Hand it the constraint set and demand three architectures with the trade-offs argued, then make it run your pre-mortem against the one you prefer. It widens the option space and attacks your favourite without politics. Let it draft the decision record after the decision is made, never instead of it. where it lies: it has no stake in the constraint you did not write down, and it designs beautifully for requirements nobody has.

Develop

intent → code

The documented territory. Generation, migration, boilerplate, the failing test handed over as the specification. This is the half everyone already knows, and the previous essay made the case that your fundamentals are the interface it runs through. where it lies: consistency impersonates correctness; a wrong pattern now arrives finished, tested, and applied everywhere it touches.

Test

claims → evidence

Adversarial coverage. Cases generated from the specification rather than from the code: boundary tables, property lists, the regression net for the bug class you just paid for. It reads a spec the way a bored tester on a Friday cannot. where it lies: a model grading its own homework passes it; a generated suite is only as honest as the spec it was generated from.

Monitor

signals → action

Retrieval before generation. On-call questions answered from your runbooks with a citation, incident timelines assembled from your logs, the postmortem draft that starts from what actually happened. The value is fetching your truth fast, and it is the phase where grounding stops being optional. where it lies: an answer synthesised from the open internet at three in the morning is a liability delivered in a helpful tone.

That table is deliberately small. The seventy-two-cell version lives in the practitioner’s map, phase by phase, force by force. What the small version adds is focus: one sentence per phase on how its help lies to you. A use case is a cell you can defend.

three questions

Three Questions Find the Use Case

Across every phase, the qualifying interview comes down to three questions, and each answer becomes a line on the record at the end of this essay. The full screen, with the deterministic-solution test and the verdict worth writing down when the answer is no, lives in Three Rungs and a No. What follows is the architect’s cut: what each answer decides, and who signs for it.

// question one

Where does the knowledge live?

decides: the adaptation pattern

Three places, three verdicts. In the model already (public patterns, standard code, the world’s documentation): prompt it as it stands. In your documents and systems (your runbooks, your domain rules, your tickets, your wiki): the model must be grounded in them, because it cannot cite what it never read. In people’s heads: stop. No adaptation pattern retrieves what was never written down. That use case has a different name, knowledge capture, and it comes first.

// question two

What does a wrong answer cost?

decides: the supervision

A wrong draft costs a shrug; a reviewer was reading it anyway. A wrong answer to a customer costs trust. A wrong action against production costs the weekend, and sometimes the quarter. Price the wrongness honestly and the right amount of human stays in the loop by construction. Price it on enthusiasm and the human leaves the loop exactly where the cost is highest.

// question three

Who catches it before it ships?

decides: whether it is a use case at all

A failing test, a check that runs on every output, a reviewer with time allocated for the volume: if a verifier stands between the model and the consequence, generation is safe to try. If nothing in that gap can say wrong, you have not found a use case. You have found a place to put an apology.

There is a quieter fourth question, and it is the commercial one: how often does the work repeat? A task that arrives twice a year earns a prompt saved in a text file. Toil that arrives every day, in volume, with a shape, is where the engineering pays for itself.

Question one also points at the rung. In the model: prompt it. In your documents: ground it. Only a gap in behaviour, a format or a tone the model keeps missing, justifies fine-tuning, and agents are a separate call that question two prices, because what they add is the power to act. The deep dive walks each rung and what it costs to keep; the architect’s rule is smaller than the ladder, and this series has already argued it: the smallest thing that can go to production and be measured, climbing only when the rung below has a measured failure written against it. And the model itself? Choose it last, the way you would choose a vendor: against the use case’s requirements, on paper, after the page below is filled in.

one page

The Page a Demo Never Fills

// the failure mode that fills backlogs

The demo that never meets a Tuesday

Use cases chosen by wow produce pilots, and pilots chosen by wow produce slide decks. The tell is a proof of concept that has never touched production data, never priced a wrong answer, and cannot name the person who reviews its output. A demo optimises for the applause in the room. A use case optimises for a Tuesday afternoon: unglamorous work, arriving constantly, wrong answers caught cheaply. If a pilot cannot say which phase it serves, which knowledge it draws on and who signs what it produces, calling it early is generous. It never started.

// write it down

The use-case record, one page

Phase. Task. Knowledge source. Cost of a wrong answer. Verifier. Rung. The metric that says it is working, and the date you will read that metric out loud. One page, argued over, signed. It is the habit this series opened with (criteria written before options), kept where the next person can challenge it. An AI use case that cannot fill one page is not ready to leave it.

into monday

// take this into your next build

Start from the work, not the model. Name the phase, the task and the toil before anyone names a vendor. A model name in the first sentence is the First Anchor, restated.
Ask where the knowledge lives. In the model: prompt. In your systems: ground. In people’s heads: write it down first, because nothing retrieves the unwritten.
Price the wrong answer out loud. Then size the supervision to the price. The loop should lose its human where mistakes are cheap, and never anywhere else.
Refuse use cases without a verifier. No test, check or reviewer between the model and the consequence means the use case is not ready, whatever the demo looked like.
Write the record before the pilot. Phase, task, knowledge source, cost of a wrong answer, verifier, rung, and the date its metric gets read out loud, on one page with a name at the bottom.

owned publicly

// I believe this

An architect does not adopt AI. An architect adopts use cases, one at a time, each with a written reason to exist and a test it must keep passing to stay.

The seventy-two cells are still on this site, and I stand behind every one of them. But a map of where AI helps and where it hurts was always the easy half, and I built the easy half first. The hard half fits in three questions and one page: where the knowledge lives, what a wrong answer costs, who catches it, signed. The fourteenth discipline said make AI a first-class force, and this is what first-class means in practice: a seat at the table with responsibilities attached. Forces get architected, and this one enters your lifecycle the way everything else in your architecture entered it, one justified decision at a time, earning its place the way the first essay in this series said every decision should: on merit, not momentum.

// carry forward

The selection discipline is this essay; the practice behind each rung has a whole book. The AI in Practice guide walks it end to end: how the machine thinks, what agents actually need, what the leverage costs, and how it all gets secured. A different track, the same rule. The use case first.