Jon W. Hansen, FCIPS · Procurement Insights | Hansen Models™ · 14 October 2026
The defining AI problem in 2026 is no longer whether the technology works. It is whether organizations understand the operations they are dispatching it into. Agents are being sent into operations nobody has traced. They do what they were built to do, and the technical checks confirm they are functioning as designed. The outcome still fails, because the design rests on an understanding of the operation that was never tested against reality. Guardrails and harnesses are added in flight. Everyone knows the destination; no one has confirmed that the flight path, the operation as it actually runs, will get them there.
That is not the only way AI fails. Models still hallucinate, drift and operate on bad data, and tracing an operation does not by itself fix any of that. But it is the failure that no improvement in the models will fix, because it sits in the organization, not in the model.
The pattern underneath is not new. It first became visible in 1983, in a few lines of dBASE II code. A change to one working line caused another working line to fail. Neither line was wrong on its own; the connection between them had simply never been made visible. Programmers call that coupling. What mattered was what came after: the same condition kept appearing in organizations, incentives and workflows, where it was far harder to see. A software error announces itself; coupling in an organization fails silently, until the outcome drops. That was the first observed expression of what would later become Strand Commonality™.
It has been tested against reality since, and the receipts exist. In 1998, at DND, it was applied to a supply operation running at 51% next-day delivery. The trace started with a single question, what time of day do the orders come in?, and found a cause no system was measuring. The operating cause was found first, the intervention followed, and the technology came last. Delivery reached 97.3% in three months. The architecture was published in 2001 as international patent application WO 01/65428.
DND is not the only case. Closely related technology has produced opposite outcomes again and again: Hewlett-Packard lost roughly $400 million on an SAP implementation while Arapahoe County brought the same class of system in on time and on budget; Virginia developed Ariba into one of the most durable public e-procurement programs on record while Ontario’s OECM lost $20 million with the same platform. When comparable technology produces materially different outcomes under different operating conditions, the technology cannot be the deciding variable. Technology still matters: it can limit what is possible. But it is not what separates success from failure. Since 2007, a dated public archive has recorded the same pattern repeating through ERP, e-procurement, cloud and now AI, in posts written before the outcomes were known.
The claim is testable. If comparable implementations begin producing consistently successful outcomes regardless of differences in operating conditions, incentives, decision rights and exception handling, then the method’s central premise is wrong. The archive shows the opposite: operating conditions continue to separate success from failure.
The way to fix it follows from the record. First, trace the operation before you build on it, and find out what is actually happening, including accurately identifying every shadow operation within the enterprise: the workarounds, spreadsheets and side processes that never appear on the official map.
Second, set the firm fence: a way for real outcomes to stop an action and change the explanation behind it.
Third, for each crossing the trace reveals, decide whether the system or a person leads, and who can stop it. Keep people where the system cannot reach: holding the purpose, weighing the trade-offs, bringing in what the data does not yet show, and with the authority to stop the action when experience says the data is wrong.
Only then build the harness and the guardrails, against that foundation, and keep feeding outcomes back so the understanding changes as the operation does.
ARA™ RAM 2025™ running on SLAP OS™ is that method, carried into the AI era. Its labs are dated, locked and corrected in the open, including when they get something wrong. In the October 2026 hurricane lab, its own record caught a price figure that every reviewer had passed. The correction was appended to the record rather than smoothed over.
The method does not depend on individual genius. It is a way of seeing that can be taught. It does not ask whether your next agent can perform its assigned task. It asks: which connections does your operation depend on, and what happens where they cross?
Any organization can ask that question. The choice that matters is whether it asks before or after it dispatches the next agent.
The receipts referred to above:
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
Related
It’s Too Late to Put the AI Genie Back in the Bottle. Forty-Three Years of Receipts Show We Don’t Have To.
Posted on October 14, 2026
0
Jon W. Hansen, FCIPS · Procurement Insights | Hansen Models™ · 14 October 2026
The defining AI problem in 2026 is no longer whether the technology works. It is whether organizations understand the operations they are dispatching it into. Agents are being sent into operations nobody has traced. They do what they were built to do, and the technical checks confirm they are functioning as designed. The outcome still fails, because the design rests on an understanding of the operation that was never tested against reality. Guardrails and harnesses are added in flight. Everyone knows the destination; no one has confirmed that the flight path, the operation as it actually runs, will get them there.
That is not the only way AI fails. Models still hallucinate, drift and operate on bad data, and tracing an operation does not by itself fix any of that. But it is the failure that no improvement in the models will fix, because it sits in the organization, not in the model.
The pattern underneath is not new. It first became visible in 1983, in a few lines of dBASE II code. A change to one working line caused another working line to fail. Neither line was wrong on its own; the connection between them had simply never been made visible. Programmers call that coupling. What mattered was what came after: the same condition kept appearing in organizations, incentives and workflows, where it was far harder to see. A software error announces itself; coupling in an organization fails silently, until the outcome drops. That was the first observed expression of what would later become Strand Commonality™.
It has been tested against reality since, and the receipts exist. In 1998, at DND, it was applied to a supply operation running at 51% next-day delivery. The trace started with a single question, what time of day do the orders come in?, and found a cause no system was measuring. The operating cause was found first, the intervention followed, and the technology came last. Delivery reached 97.3% in three months. The architecture was published in 2001 as international patent application WO 01/65428.
DND is not the only case. Closely related technology has produced opposite outcomes again and again: Hewlett-Packard lost roughly $400 million on an SAP implementation while Arapahoe County brought the same class of system in on time and on budget; Virginia developed Ariba into one of the most durable public e-procurement programs on record while Ontario’s OECM lost $20 million with the same platform. When comparable technology produces materially different outcomes under different operating conditions, the technology cannot be the deciding variable. Technology still matters: it can limit what is possible. But it is not what separates success from failure. Since 2007, a dated public archive has recorded the same pattern repeating through ERP, e-procurement, cloud and now AI, in posts written before the outcomes were known.
The claim is testable. If comparable implementations begin producing consistently successful outcomes regardless of differences in operating conditions, incentives, decision rights and exception handling, then the method’s central premise is wrong. The archive shows the opposite: operating conditions continue to separate success from failure.
The way to fix it follows from the record. First, trace the operation before you build on it, and find out what is actually happening, including accurately identifying every shadow operation within the enterprise: the workarounds, spreadsheets and side processes that never appear on the official map.
Second, set the firm fence: a way for real outcomes to stop an action and change the explanation behind it.
Third, for each crossing the trace reveals, decide whether the system or a person leads, and who can stop it. Keep people where the system cannot reach: holding the purpose, weighing the trade-offs, bringing in what the data does not yet show, and with the authority to stop the action when experience says the data is wrong.
Only then build the harness and the guardrails, against that foundation, and keep feeding outcomes back so the understanding changes as the operation does.
ARA™ RAM 2025™ running on SLAP OS™ is that method, carried into the AI era. Its labs are dated, locked and corrected in the open, including when they get something wrong. In the October 2026 hurricane lab, its own record caught a price figure that every reviewer had passed. The correction was appended to the record rather than smoothed over.
The method does not depend on individual genius. It is a way of seeing that can be taught. It does not ask whether your next agent can perform its assigned task. It asks: which connections does your operation depend on, and what happens where they cross?
Any organization can ask that question. The choice that matters is whether it asks before or after it dispatches the next agent.
The receipts referred to above:
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
-30-
Share this:
Like this:
Related