Every AI programme I am asked to look at arrives with a list. A wall of workshop stickies photographed badly, a spreadsheet with a scoring column, one slide carrying forty boxes. It is treated as the easy part, the thing you get past on the way to the real argument about platform and money.
It is usually the most revealing document in the pack, and what reveals it is not the scoring but the grammar.
There are three ways a use case gets named. As a question: why do we over-forecast in the northern channel. As a project: improve promotional planning. Or as a thing: a planner, a forecaster, a predictor. The first two are safe, because neither obliges anybody to still be there in six months. The third is a commitment, and almost nobody makes it.
I went back through a proposal I co-wrote for a European food and consumer goods manufacturer that was standing its first analytics capability up across marketing, sales and the supply chain. One slide in it carries the whole opportunity catalogue. Fourteen entries, sorted into four groupings covering marketing, sales, operations and a fourth bucket for the rest. Every single one of the fourteen is named as an agent-noun, a thing that does something. Six of them share one suffix. Not one is phrased as a question, and not one is phrased as a project.
A list of things, not a list of questions
Read the catalogue as prose and the pattern is unmissable. Marketing takes four entries, sales three, operations four, a residual grouping three more, and across all four the naming never slips. In every entry the topic sits in front and the agent-noun closes the line, so the last word already says what the thing does once it is running. The words ahead of it only say which corner of the business the verb is pointed at.
Compare that with the average AI backlog I read. Demand forecasting. Promotional effectiveness. Customer segmentation. Marketing mix. Each of those is a topic, and a topic can sit in a backlog for years without embarrassing anybody, because it makes no claim about ever finishing. You cannot leave a forecaster there that long. Somebody asks where it is, which is exactly the pressure a topic is built to avoid.
The convention also does something to prioritisation that scoring cannot. The proposal asks the client to pick one to three areas for a first case, and its own list of challenges sets the bar for what counts as one: five times return on the effort put in. That bar is only arguable because each entry is a thing. You can estimate the return on a forecaster somebody opens weekly, and not on promotional effectiveness, which is a direction rather than an object.
What the noun commits you to
A question ends when it is answered. A project ends when it ships. A thing that does something has to be opened by somebody on a Tuesday morning.
That difference forces three questions the question-form lets you skip. Who opens it. When in their week. What they do differently afterwards. None is a data question, and none is answerable by the team building the model, which is why lists that avoid the noun form get written inside the analytics function without ever leaving the room.
The three entries worked up into full pages show the discipline holding. Each states the situation, how value would be added, and what the benefits look like, and the benefits are written as behaviours rather than as accuracy. Faster decisions taken from a current picture. Market and sales information tied to the targets a person is held to. Those are statements about somebody's working week, and they are testable, which is more than most model specifications manage.
The figures those pages carry come from earlier engagements elsewhere, cited to argue the shape has worked before: an online marketing reallocation that lifted conversion by twenty percent, and a demand and supply programme reporting a thirty percent lead-time reduction. None of it had happened at this manufacturer. Nothing had started yet.
The row where the client's share is zero
Naming a use case as a product is a commitment. It is not, on its own, delivery of that commitment, and the same proposal shows where the seam is.
The effort plan lays the work out row by row, each split into a share for the supplier and a share for the client. The data rows are supplier-weighted, as you would expect: assessing the quality of what is there, eighty-twenty; crunching it into a usable state, ninety-ten; integrating and transforming it to test the hypotheses, ninety-ten again. The rows properly belonging to the client sit the other way: security safeguards before anything is gathered, ten-ninety; agreeing the analytics platform, ten-ninety.
Then there is one row about engaging stakeholders to define the insights and make the key issues visible. Twenty for the supplier. Zero for the client.
I do not read that as a typo, or not only as one. It is the row where the product needs its users in the room, and the row nobody was willing to sign for. The plan's own list of challenges says the same from the other side: absent senior sponsorship, data held tightly by its owners, no working combination of data-driven professionals and data scientists, and no habit of reporting benefits once the analysis is over.
Every one of those is a user problem wearing a data costume. The naming convention had already surfaced them. It could not fix them.
Naming a use case as a product is a commitment to it having users. Most use-case lists are written the way they are in order to avoid making that commitment out loud.
Why the grammar matters more now than it did
This proposal predates the current wave, which has made the test sharper rather than obsolete.
A retrieval-augmented assistant with no named user is a demo. It answers impressively for an hour and then has nothing to be judged against, because an evaluation set cannot be written until you know who is asking and what a good answer lets them do next. Naming the thing as a product forces that set into existence: a copilot for a demand planner has a testable notion of correct, while a copilot for the supply chain does not. The same holds a layer down, where a vector store only becomes a decidable choice once you know whose question has to come back grounded.
It holds hardest once the bill arrives. An assistant that answers anybody about anything has no denominator, so nobody can say what a query is worth, and the cost conversation flattens into an argument about whether to keep paying at all. A thing somebody opens on a schedule has a unit of work attached, which is what makes a guardrail and a budget arguable in the same meeting. The agent-noun test is the cheapest filter I know for whether that unit exists. Lineage and data readiness sit downstream of it, because you cannot decide which lineage matters until you know which thing has to be defensible to whom.
- 14
- Entries in the opportunity catalogue, every one an agent-noun
- 4
- Groupings across marketing, sales, operations and the rest
- 6
- Entries sharing a single agent-noun suffix
- 0
- Entries named as a question or as a project
What we do with a catalogue now
Rewrite every line as a thing that does something, before any scoring. Then put the three questions to it: who opens it, when in their week, what changes after they look. Lines that survive intact are candidates. Lines that cannot be rewritten without inventing a fictional user are not use cases. They are analyses somebody would like doing, and they belong in a different pile with a different budget.
That rewrite is the opening move in a RealAI Platform engagement and it costs an afternoon. It is also how we scope Hominis work, because an assistant inherits the ambiguity of its own name: the vaguer the noun, the wider its evaluation set has to be, and the less anyone can say whether it is working.
The manufacturer here got the naming right and had not yet built the ownership underneath it. That is the ordinary case, and a far better position than the reverse. A catalogue of fourteen products with no assigned users tells you exactly what is missing and who has to supply it. A backlog of fourteen topics tells you nothing, for as long as you are willing to fund it.
Drawn from a data analytics proposal written for a European food and consumer goods manufacturer, on which I was a named co-author and delivery-team member: its opportunity catalogue, its three worked-up examples, its effort plan and its stated challenges. It produced a recommended way in, not a delivered result, and the benefit figures inside it are references from earlier engagements elsewhere. The individual entry names are the authoring firm's and are not reproduced here. Reading the catalogue's grammar as the finding is ours.
“A question ends when it is answered. A project ends when it ships. A thing that does something has to be opened by somebody on a Tuesday morning, and that is the commitment most use-case lists are quietly built to avoid.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.