Institutions rarely decide to do AI. They decide to do a category.
The decision, when reconstructed honestly, usually looks like this. A phrase enters circulation — from a product launch, an analyst report, a conference track, a peer institution’s press release. It gets used internally, first as shorthand and then as a name. A programme forms around the name. A budget follows the programme. And somewhere in that sequence, without anyone deciding it, the boundaries of the problem were set.
Nobody in this chain did anything wrong. The phrase was genuinely useful; that is why it spread. But a category is a compressed argument, and compression is where the authorship hides.
A category is a compressed argument, and compression is where the authorship hides.
Before an institution approves a budget, selects a vendor, or models ROI, it has already inherited the problem boundaries built into the category name.
Structural Analysis
What a category quietly decides
Take any of the terms currently in circulation and unpack what adopting it commits you to before any formal evaluation takes place:
Asserts loose capabilities belong together
Implies sequential stages of progress
Fixes evaluated candidates in advance
Supplies the metrics for progress
Upstream Impact
Why this precedes the decisions that feel more consequential
Attention concentrates on what comes later — the ROI case, the build-versus-buy call, the vendor selection — because that is where the money moves and the contracts get signed.
But each of those depends on how the problem was framed. An ROI model can only be built for the problem as framed. A build-versus-buy analysis can only compare options inside the category. A vendor evaluation can only assess candidates who presented themselves as belonging to it. Recovery upstream is worth more than remediation downstream, and framing is the furthest upstream a buyer can get.
The recent movement around “context layer” tooling is a live instance rather than a historical one. Several vendors converged on the term within months of each other, each defining the layer to include the capabilities they already sold and to exclude the ones they did not. An institution adopting the phrase inherits whichever vendor’s definition it happened to encounter first — and inherits it as vocabulary, which is far harder to notice than inheriting it as a recommendation.
Genealogical Method
The trace
The check is genealogical and it is not difficult, only rarely done.
Find the earliest written instance of the initiative’s name inside your institution. Not the approved business case — earlier. The memo, the slide, the email thread where the phrase first appears.
Identify who wrote it. Ask them where the phrasing came from. Follow that answer to its own source, and keep going until the trail either ends inside your institution or leaves it.
Internal Problem
The trail ends at an observed internal failure — someone noticed a operational breakdown and named it. Less common than expected.
Peer Institution
The trail ends at a peer. Note that you have inherited their framing and constraints along with the phrase.
Vendor or Analyst
The trail ends at a vendor or analyst. Not disqualifying, but means your problem statement was authored by a party with a position on the answer.
Diagnostic Closing Test
What to do with the finding:
Once you know the framing was inherited, restate the problem in your own institution’s terms — in the language of what is actually failing, for whom, at what cost — and then check whether the initiative as scoped still addresses it.
Sometimes the restated problem is materially narrower than the category, and the programme shrinks accordingly. All outcomes are useful. Only the default is comfortable.