Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Something worth noticing happened this year. Report after report on enterprise AI — from the large consultancies and, tellingly, from the model makers themselves — converged on a single conclusion. The bottleneck is no longer the technology. In OpenAI’s own enterprise report, the company with every commercial incentive to tell you the models are ready instead concludes that the primary constraints are no longer model performance or tooling, but organizational readiness. Gartner said the same thing from the workforce side: the technology, in their analyst’s words, is “a whole lot more ready than humans are.”
When the firms selling the technology are the ones telling you the technology isn’t the problem, that is a signal worth taking seriously. They are independent sources — not disinterested ones, which is exactly what makes the agreement notable. The field has arrived, more or less all at once, at a conclusion I have been documenting since 1998: the constraint sits upstream of the tool, in the organization.
So the diagnosis is right. What I want to write about is the prescription — because nearly every one of these reports, having correctly named readiness as the problem, answers the next question the same way, and it is the one answer that cannot close the gap.
The tell is the checklist
Ask any of these reports what “readiness” actually is, and you get a list. Governance. Decision rights. Data readiness. System integration. Executive sponsorship. Change management. It is a good list. Every item on it is real, and every item matters.
And an organization can put every item in place — best-in-class governance, clean data, full integration, an engaged executive sponsor — and still fail. Two organizations can deploy the identical technology, satisfy the identical checklist, and arrive at opposite outcomes. If readiness were the sum of the components, that could not happen. It happens constantly.
The reason it happens is not that someone missed a checklist item. It is that readiness was never a property of the components in the first place.
The difference is ontological
There are two fundamentally different ways to describe an organization, and almost everyone is using the first one without noticing there is a second.
The first treats the organization as a system of processes and components. On this view, the organization is its parts — its functions, its process steps, its capabilities — and you improve outcomes by standardizing those parts and benchmarking them against a reference. Readiness, in this ontology, is naturally a checklist, because a system of components is made ready one component at a time.
The second treats the organization as a system of interacting relationships. On this view, the parts are real but they are not the point. The outcome emerges from how they interact — how incentives pull against decision rights, how a workflow depends on information that governance withholds, how one function’s measurement quietly reshapes another’s behaviour. Readiness, in this ontology, is not a component you install. It is a property that emerges from the relationships, and it cannot be found by inspecting any part in isolation.
A chain is made of links. A weave is made of relationships. That is not a metaphor about supply chains. It is a claim about what an organization fundamentally is — and the two answers lead to entirely different work.
I learned this the hard way and early. When I went into the Department of National Defence in 1998, deliveries were late and everyone knew where to look: procurement. No audit of procurement’s readiness would ever have found the cause. The late deliveries were an emergent property of technician incentives, dispatch measurement, time-of-day pricing, and customs paperwork intersecting at once — a cause that lived in none of the components and only in the interaction between them. You cannot find an intersection by inspecting a list.
Even the frameworks built to describe operations work this way
The clearest example of the reference-model ontology is the one I named when I first made this argument, in 2008: SCOR. And SCOR is instructive precisely because it has evolved, and evolving didn’t change the thing that matters.
To its credit, SCOR has not stood still. The current SCOR Digital Standard (Version 14, 2025) explicitly reframes the model away from a linear chain toward a synchronous network, and adds an “Orchestrate” layer to govern strategy, data, and coordination across the whole. That is real movement, and it lands close to where I was arguing from eighteen years ago.
But it moved its vocabulary, not its ontology. SCOR remains a reference model: a set of standardized process blocks that an organization maps itself onto and benchmarks against. Adding a governing layer on top of a decomposition is still a decomposition. Orchestration described as a set of activities to perform is not the same thing as an outcome understood as emergent from interaction. The updates are genuine, and they operate one full level above the level where the gap actually sits — which is why, three decades on, they don’t close it.
Laid side by side, the two ontologies are not competing answers to the same question. They are answers to different questions:
Reference-model ontology — SCOR, including SCOR DS
Interaction ontology
Primary object
The process is primary; the organization is a system of processes and components.
The relationship is primary; the organization is a system of interacting relationships.
Where outcomes come from
Executing standardized processes efficiently.
The interaction of people, incentives, decision rights, information, technology, and governance.
How coordination is handled
Modeled as a process to perform — in SCOR DS, the Orchestrate layer. Coordination is an activity you execute and benchmark.
The emergent product of the relationships. Processes exist because relationships need mechanisms — not the reverse.
What the organization is
Representable as a reference model of standardized activities.
Best understood as an emergent, adaptive system.
The method
Map to, and benchmark against, a reference architecture.
Diagnose the interaction patterns unique to each organization.
The improvement question
Improve the process — which processes aren’t mature?
Understand the relationships that generate the outcome — which interactions determine whether readiness emerges?
What “readiness” is
The presence of the right components — a checklist.
A property that emerges from the relationships — not installable one component at a time.
SCOR asks what processes the enterprise performs. The interaction ontology asks what interactions generate those processes’ outcomes. Complementary questions — not rival answers.
This is the shared structure underneath so much of what the industry reaches for. Wherever the answer to a problem is “enumerate the components and benchmark them against a reference,” you are inside reference-model ontology — and a relational property will always sit just beyond its reach. The readiness checklists in this year’s reports are the same move as SCOR’s process blocks, one abstraction up. That is why they will diagnose the readiness gap accurately and prescribe exactly the thing that cannot close it.
The question the other ontology asks
The interaction ontology does not ask which components are mature. It asks which interaction patterns determine whether readiness can emerge here, in this specific organization. That is the work of Strand Commonality™ — discovering how seemingly separate strands are expressions of the same underlying operating reality, and reading the relationships between them.
And because those relationships keep shifting, it cannot be a one-time diagnosis. It has to be a continuous learning loop, because a fixed description of a living system degenerates from the moment it is set — a line I wrote in 2008 and have had no reason to revise since.
Not a rivalry — a different question
I want to be careful here, because this is not SCOR versus anything, or me versus the frameworks. Reference models answer a real and valuable question: how do we describe, standardize, and benchmark what an organization does? The interaction ontology answers a different one: what generates the outcome those processes produce in the first place? The questions are complementary. The trouble only starts when we reach for a reference-model answer to a relational question — which is precisely what this year’s readiness prescriptions do.
The whole field has now converged on the right problem. It stays unsolved for one reason: readiness is a property of the relationships, and we keep trying to install it as a component.
So when your next AI deployment stalls — and the checklist is complete, and it stalls anyway — the useful question is not which box you missed. It is which interactions you never looked at.
-30-
This reflection draws on the Procurement Insights archive — an independent record I have published openly since 2007, consolidating documented client work, lectures, and writing reaching back to 1998, and carrying no vendor sponsorships across the past decade. Every claim is held to the Provenance Ledger™ — a verify-before-publish discipline that traces each assertion to a primary source and reconciles the record forward rather than editing it in place. Figures and quotations from the OpenAI and Gartner reports are drawn from those published sources. Strand Commonality™ and Invariant Physics™ are proprietary frameworks of Hansen Models™. Getting it right, rather than being right.
Every Firm Found the Same Problem. None of Them Found the Layer Beneath It.
Posted on July 27, 2026
0
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Something worth noticing happened this year. Report after report on enterprise AI — from the large consultancies and, tellingly, from the model makers themselves — converged on a single conclusion. The bottleneck is no longer the technology. In OpenAI’s own enterprise report, the company with every commercial incentive to tell you the models are ready instead concludes that the primary constraints are no longer model performance or tooling, but organizational readiness. Gartner said the same thing from the workforce side: the technology, in their analyst’s words, is “a whole lot more ready than humans are.”
When the firms selling the technology are the ones telling you the technology isn’t the problem, that is a signal worth taking seriously. They are independent sources — not disinterested ones, which is exactly what makes the agreement notable. The field has arrived, more or less all at once, at a conclusion I have been documenting since 1998: the constraint sits upstream of the tool, in the organization.
So the diagnosis is right. What I want to write about is the prescription — because nearly every one of these reports, having correctly named readiness as the problem, answers the next question the same way, and it is the one answer that cannot close the gap.
The tell is the checklist
Ask any of these reports what “readiness” actually is, and you get a list. Governance. Decision rights. Data readiness. System integration. Executive sponsorship. Change management. It is a good list. Every item on it is real, and every item matters.
And an organization can put every item in place — best-in-class governance, clean data, full integration, an engaged executive sponsor — and still fail. Two organizations can deploy the identical technology, satisfy the identical checklist, and arrive at opposite outcomes. If readiness were the sum of the components, that could not happen. It happens constantly.
The reason it happens is not that someone missed a checklist item. It is that readiness was never a property of the components in the first place.
The difference is ontological
There are two fundamentally different ways to describe an organization, and almost everyone is using the first one without noticing there is a second.
The first treats the organization as a system of processes and components. On this view, the organization is its parts — its functions, its process steps, its capabilities — and you improve outcomes by standardizing those parts and benchmarking them against a reference. Readiness, in this ontology, is naturally a checklist, because a system of components is made ready one component at a time.
The second treats the organization as a system of interacting relationships. On this view, the parts are real but they are not the point. The outcome emerges from how they interact — how incentives pull against decision rights, how a workflow depends on information that governance withholds, how one function’s measurement quietly reshapes another’s behaviour. Readiness, in this ontology, is not a component you install. It is a property that emerges from the relationships, and it cannot be found by inspecting any part in isolation.
A chain is made of links. A weave is made of relationships. That is not a metaphor about supply chains. It is a claim about what an organization fundamentally is — and the two answers lead to entirely different work.
I learned this the hard way and early. When I went into the Department of National Defence in 1998, deliveries were late and everyone knew where to look: procurement. No audit of procurement’s readiness would ever have found the cause. The late deliveries were an emergent property of technician incentives, dispatch measurement, time-of-day pricing, and customs paperwork intersecting at once — a cause that lived in none of the components and only in the interaction between them. You cannot find an intersection by inspecting a list.
Even the frameworks built to describe operations work this way
The clearest example of the reference-model ontology is the one I named when I first made this argument, in 2008: SCOR. And SCOR is instructive precisely because it has evolved, and evolving didn’t change the thing that matters.
To its credit, SCOR has not stood still. The current SCOR Digital Standard (Version 14, 2025) explicitly reframes the model away from a linear chain toward a synchronous network, and adds an “Orchestrate” layer to govern strategy, data, and coordination across the whole. That is real movement, and it lands close to where I was arguing from eighteen years ago.
But it moved its vocabulary, not its ontology. SCOR remains a reference model: a set of standardized process blocks that an organization maps itself onto and benchmarks against. Adding a governing layer on top of a decomposition is still a decomposition. Orchestration described as a set of activities to perform is not the same thing as an outcome understood as emergent from interaction. The updates are genuine, and they operate one full level above the level where the gap actually sits — which is why, three decades on, they don’t close it.
Laid side by side, the two ontologies are not competing answers to the same question. They are answers to different questions:
SCOR asks what processes the enterprise performs. The interaction ontology asks what interactions generate those processes’ outcomes. Complementary questions — not rival answers.
This is the shared structure underneath so much of what the industry reaches for. Wherever the answer to a problem is “enumerate the components and benchmark them against a reference,” you are inside reference-model ontology — and a relational property will always sit just beyond its reach. The readiness checklists in this year’s reports are the same move as SCOR’s process blocks, one abstraction up. That is why they will diagnose the readiness gap accurately and prescribe exactly the thing that cannot close it.
The question the other ontology asks
The interaction ontology does not ask which components are mature. It asks which interaction patterns determine whether readiness can emerge here, in this specific organization. That is the work of Strand Commonality™ — discovering how seemingly separate strands are expressions of the same underlying operating reality, and reading the relationships between them.
And because those relationships keep shifting, it cannot be a one-time diagnosis. It has to be a continuous learning loop, because a fixed description of a living system degenerates from the moment it is set — a line I wrote in 2008 and have had no reason to revise since.
Not a rivalry — a different question
I want to be careful here, because this is not SCOR versus anything, or me versus the frameworks. Reference models answer a real and valuable question: how do we describe, standardize, and benchmark what an organization does? The interaction ontology answers a different one: what generates the outcome those processes produce in the first place? The questions are complementary. The trouble only starts when we reach for a reference-model answer to a relational question — which is precisely what this year’s readiness prescriptions do.
The whole field has now converged on the right problem. It stays unsolved for one reason: readiness is a property of the relationships, and we keep trying to install it as a component.
So when your next AI deployment stalls — and the checklist is complete, and it stalls anyway — the useful question is not which box you missed. It is which interactions you never looked at.
-30-
This reflection draws on the Procurement Insights archive — an independent record I have published openly since 2007, consolidating documented client work, lectures, and writing reaching back to 1998, and carrying no vendor sponsorships across the past decade. Every claim is held to the Provenance Ledger™ — a verify-before-publish discipline that traces each assertion to a primary source and reconciles the record forward rather than editing it in place. Figures and quotations from the OpenAI and Gartner reports are drawn from those published sources. Strand Commonality™ and Invariant Physics™ are proprietary frameworks of Hansen Models™. Getting it right, rather than being right.
Share this:
Like this:
Related