A 1998 lesson in strand convergence — and why checklists and technology stacks are not sufficient in the Agentic AI era
Procurement Insights
There is a genre of business writing that never goes out of style: the numbered list. Twenty rules for AI success. Ten steps to digital transformation. Seven habits of resilient supply chains. The format reassures because it promises that a hard thing can be made tractable by partition — break the problem into discrete checkpoints, satisfy each one, and the outcome takes care of itself.
I want to explain, using a case I have carried since 1998, why that promise fails — and not in the way you might expect. The problem with a checklist isn’t that it’s missing a few items. It’s that no checklist, however complete, can capture what actually determines the outcome. A longer list doesn’t help, because the list is the wrong tool for the job. And I want to show you why the way the lesson actually arrived — not as a finished diagram, but as a chain that revealed itself one link at a time, where each link I pulled exposed a link I couldn’t have seen until I got there.
That property — strands that surface in sequence, and that cannot be added without recomputing everything already in the model — is the whole point. It is also why the Agentic AI era is about to make this lesson urgent for people who have never heard of a 1998 defence contract.
The setting
In 1998 I was engaged on a Canadian Department of National Defence contract operated through SHL Systemhouse. The contract carried a hard service level: 90% of parts delivered, and calls closed, inside the agreed window. When I arrived, performance sat at 51%. Within three months it reached 97.3%, and it held there for seven years.
The instinct — then and now — is to ask what tool fixed it. That instinct is the trap. Nothing was fixed by a tool. What changed is that we stopped auditing each function in isolation and started following the strands — the threads of incentive and behaviour running between the functions, converging invisibly on the one number everyone was measured against.
Here is the chain, in the order it actually revealed itself. The order matters, because that is the part a list can never reproduce.
The first thread: a time of day that wasn’t the answer
The field technicians were measured on calls completed per day. That incentive — reasonable on its own — produced a behaviour: sandbagging. Work was paced and batched to maximise the count. The visible residue was a clustering of orders entering the system late in the day, around 4 p.m.
Had I asked “when do orders come in?”, accepted “around 4 p.m.” as a fact, and moved on, I would have learned nothing. The hour was not the finding. The hour was the symptom of an incentive — and the incentive was the first strand. Pulling it is what exposed the next one.
The second thread: a cleared screen that wasn’t progress
The buyers submitting the DND orders carried their own pressure. The contract mattered, and the visible measure of progress was a cleared screen at end of day — every day, whether or not a part had actually been sourced.
So they cleared the screen by issuing purchase orders to suppliers who had not confirmed they could deliver. The next morning they checked for confirmations; where a supplier could not provide the part, the PO was cancelled and the demand re-listed. The screen looked clear. Progress looked real. But the order list was churning — the same unmet demand recirculating nightly, dressed as activity.
Here is the first hard lesson. Each strand was defensible in isolation. Technicians were logging calls. Buyers were clearing queues. Both functions passing — and the system failing — because the failure lived in neither function. It lived in the convergence: sandbagged demand arriving late, meeting a buying process that manufactured phantom progress to relieve its own pressure. A siloed audit of either function would have certified it compliant and missed the trap entirely.
The strand that could not be added — only recomputed
With the supplier and customs strands constructed, I could see the shape of the operation. And only then — because I was now positioned to see it — did the next strand surface: a variance in shipping cost. This is the crucial point about how the method works, so I want to be exact about it.
I could not have put “uncaptured landed cost” on a checklist at the start. It was not identifiable until the earlier strands had been built. The construction of the prior strands is what created the vantage point from which this one became visible at all. You cannot pre-load a strand you have no way of seeing yet.
And when it did surface, I could not simply add it. This is not plug-and-play — not insert the memory stick and click. A new strand has to be recomputed back through the entire model, because every strand already in the convergence is a living, flowing stream, and a new one changes the equilibrium of all of them. Introducing landed cost altered what the supplier strand and the customs strand meant. That backward recomputation — the obligation to re-derive the whole convergence rather than append a fix — is what I call the loopback. The chain discovers itself forward, link by link; but each new link forces a recalculation that loops back through everything already established.
Here is what the shipping strand turned out to be.
Suppliers quoted the part and excluded shipping. The buyer issued a PO for the part only. The landed cost — the shipping — was never captured in the purchase order; it arrived later, on the invoice. That PO-to-invoice variance should have flagged and slowed payment. But slowing payment risked interrupting parts flow against the 90% requirement — so invoices were paid, and shipping was shunted to a separate ledger line to keep the variance from holding things up.
Now the trap closes. SHL’s only margin was a nominal markup on parts, meant to cover the sourcing group’s effort. That markup was smaller than the uncaptured shipping cost. Once landed cost was accounted for, the markup did not merely erase — it inverted. Every transaction moved into deficit.
Stated plainly: SHL was losing money on every single call — and still missing the 90% requirement. Both failures at once. Bleeding cash and under-delivering.
And it stayed hidden because the loss was concealed by the very incentive that caused it. The SLA pressure that made the team pay variant invoices without challenge was the same pressure that buried the shipping in a separate ledger, where it never met the markup it was destroying. The structure was, unintentionally, designed to keep the loss invisible — because surfacing it meant slowing payments, which threatened the SLA, which was the thing everyone was incentivised to protect.
No rule on any list would have caught this. Each function was honouring its mandate. The trap lived entirely in the interaction — and the strand that explained it could not be seen until the model that revealed it had been built.
Customs and the convergence point
Roughly 80% of the parts cleared customs into Canada. Customs was therefore not a footnote but a gate every order passed through, with its own timing and failure modes — none controlled by, or measured against, the buyers. A buyer could execute perfectly and still miss the window because a strand outside their authority stalled the part at the border.
Which raised the final question: if these strands all run separately, where can they be seen together? The answer was the courier. The carrier touches every other strand at once — downstream of the supplier’s shipping, the thing moving through customs, the physical event at which landed cost, clearance, and delivery timing all become real at the same moment. The delivery point is where the strands converge — and that makes it the one place where every otherwise-invisible strand can be observed and captured simultaneously, in real time. Capture at the convergence point and the emergent property stops being emergent-and-hidden. It becomes emergent-and-instrumented.
Why this defeats the numbered list
Step back and look at what the chain actually had:
- A behavioural strand (technician sandbagging) visible only as a misleading time-of-day signal
- A behavioural strand (buyer churn) visible only as false progress
- A structural-financial strand (inverted margin) unidentifiable until the prior strands were built, and impossible to add without recomputing them
- A regulatory strand (customs) imposing timing no one controlled
- A convergence point (the carrier) where all of it could finally be seen at once
Now imagine governing this with twenty rules. A rule for supplier confirmation. A rule for invoice matching. A rule for SLA monitoring. A rule for customs documentation. An organisation could satisfy every one independently and still lose money on every call while missing the target — because the determinant of the outcome was never inside any single rule. It was in the convergence between them, and one of the decisive strands could not even have appeared on the list, because it was unknowable until the others were constructed.
A list can represent a partition. It cannot represent a system that is sequentially revealed and mutually recomputing. Its silent promise is additivity — that satisfied checkpoints sum to success. The whole content of this case is that they do not sum. They interact, they surface in order, and adding one re-derives all the rest.
Rules govern nodes. Observation governs the strands that run between them. Outcomes live in the strands.
Why this is the Agentic AI lesson, not just a 1998 one
Everything above predates the technology people now reach for. And that is exactly why it matters in the Agentic AI era.
An agentic environment is a multi-strand convergence: autonomous agents, each with an objective and an incentive, interacting with humans, processes, data, and one another. The failures will not live inside any single agent — they will live in the convergence between them, exactly as DND’s failure lived between functions that were each individually compliant. New strands will surface only once earlier ones are understood. And you will not be able to govern such a system by adding a control and clicking; each new agent, each new interaction, recomputes the equilibrium of everything already deployed.
A technology stack and a governance checklist are necessary. The lesson of 1998 is that they are not sufficient — because neither can hold a system whose strands are sequentially revealed and mutually recomputing. That requires observation of the operating environment itself.
Readiness before the platform
One final point, and it is the one I guard most carefully.
The 51%→97.3% recovery was achieved through the observation and realignment of these converging strands — before any platform was credited with the result. The technology that later locked the gain in place came after the seeing. It did not cause the improvement; it preserved it. RAM 1998 is the cleanest proof I have of the sequence: align the operating environment first, instrument the convergence, and only then does a platform have something real to scale and hold.
That is the question the enterprise world is only now beginning to ask in earnest — not which tool do we buy, but what conditions determine whether any tool succeeds. In 1998 the answer was already sitting in the strands, waiting at the delivery point for someone to look. In the Agentic AI era, there will be far more strands, surfacing far faster — and the organisations that thrive will be the ones who learned to follow the converging strands instead of checking the boxes.
Truth Is Believing. Accuracy Is Knowing.
Jon Hansen is the creator of Implementation Physics™, a research-based framework developed over nearly three decades to explain why technology initiatives succeed or fail regardless of the technology being deployed. His work spans six technology generations — from ERP through Agentic AI — and includes the Metaprise™ model first articulated in the late 1990s. His research forms the foundation for the Hansen Method™, Hansen Fit Score™ (HFS™), Phase 0™ Readiness Assessment, and the ARA™ RAM 2025™ multimodel verification architecture. He currently serves as a Board Member of the CIPS Americas Chapter.
-30-
Related
Why a Checklist Could Never Have Saved This Contract
Posted on June 25, 2026
0
A 1998 lesson in strand convergence — and why checklists and technology stacks are not sufficient in the Agentic AI era
Procurement Insights
There is a genre of business writing that never goes out of style: the numbered list. Twenty rules for AI success. Ten steps to digital transformation. Seven habits of resilient supply chains. The format reassures because it promises that a hard thing can be made tractable by partition — break the problem into discrete checkpoints, satisfy each one, and the outcome takes care of itself.
I want to explain, using a case I have carried since 1998, why that promise fails — and not in the way you might expect. The problem with a checklist isn’t that it’s missing a few items. It’s that no checklist, however complete, can capture what actually determines the outcome. A longer list doesn’t help, because the list is the wrong tool for the job. And I want to show you why the way the lesson actually arrived — not as a finished diagram, but as a chain that revealed itself one link at a time, where each link I pulled exposed a link I couldn’t have seen until I got there.
That property — strands that surface in sequence, and that cannot be added without recomputing everything already in the model — is the whole point. It is also why the Agentic AI era is about to make this lesson urgent for people who have never heard of a 1998 defence contract.
The setting
In 1998 I was engaged on a Canadian Department of National Defence contract operated through SHL Systemhouse. The contract carried a hard service level: 90% of parts delivered, and calls closed, inside the agreed window. When I arrived, performance sat at 51%. Within three months it reached 97.3%, and it held there for seven years.
The instinct — then and now — is to ask what tool fixed it. That instinct is the trap. Nothing was fixed by a tool. What changed is that we stopped auditing each function in isolation and started following the strands — the threads of incentive and behaviour running between the functions, converging invisibly on the one number everyone was measured against.
Here is the chain, in the order it actually revealed itself. The order matters, because that is the part a list can never reproduce.
The first thread: a time of day that wasn’t the answer
The field technicians were measured on calls completed per day. That incentive — reasonable on its own — produced a behaviour: sandbagging. Work was paced and batched to maximise the count. The visible residue was a clustering of orders entering the system late in the day, around 4 p.m.
Had I asked “when do orders come in?”, accepted “around 4 p.m.” as a fact, and moved on, I would have learned nothing. The hour was not the finding. The hour was the symptom of an incentive — and the incentive was the first strand. Pulling it is what exposed the next one.
The second thread: a cleared screen that wasn’t progress
The buyers submitting the DND orders carried their own pressure. The contract mattered, and the visible measure of progress was a cleared screen at end of day — every day, whether or not a part had actually been sourced.
So they cleared the screen by issuing purchase orders to suppliers who had not confirmed they could deliver. The next morning they checked for confirmations; where a supplier could not provide the part, the PO was cancelled and the demand re-listed. The screen looked clear. Progress looked real. But the order list was churning — the same unmet demand recirculating nightly, dressed as activity.
Here is the first hard lesson. Each strand was defensible in isolation. Technicians were logging calls. Buyers were clearing queues. Both functions passing — and the system failing — because the failure lived in neither function. It lived in the convergence: sandbagged demand arriving late, meeting a buying process that manufactured phantom progress to relieve its own pressure. A siloed audit of either function would have certified it compliant and missed the trap entirely.
The strand that could not be added — only recomputed
With the supplier and customs strands constructed, I could see the shape of the operation. And only then — because I was now positioned to see it — did the next strand surface: a variance in shipping cost. This is the crucial point about how the method works, so I want to be exact about it.
I could not have put “uncaptured landed cost” on a checklist at the start. It was not identifiable until the earlier strands had been built. The construction of the prior strands is what created the vantage point from which this one became visible at all. You cannot pre-load a strand you have no way of seeing yet.
And when it did surface, I could not simply add it. This is not plug-and-play — not insert the memory stick and click. A new strand has to be recomputed back through the entire model, because every strand already in the convergence is a living, flowing stream, and a new one changes the equilibrium of all of them. Introducing landed cost altered what the supplier strand and the customs strand meant. That backward recomputation — the obligation to re-derive the whole convergence rather than append a fix — is what I call the loopback. The chain discovers itself forward, link by link; but each new link forces a recalculation that loops back through everything already established.
Here is what the shipping strand turned out to be.
Suppliers quoted the part and excluded shipping. The buyer issued a PO for the part only. The landed cost — the shipping — was never captured in the purchase order; it arrived later, on the invoice. That PO-to-invoice variance should have flagged and slowed payment. But slowing payment risked interrupting parts flow against the 90% requirement — so invoices were paid, and shipping was shunted to a separate ledger line to keep the variance from holding things up.
Now the trap closes. SHL’s only margin was a nominal markup on parts, meant to cover the sourcing group’s effort. That markup was smaller than the uncaptured shipping cost. Once landed cost was accounted for, the markup did not merely erase — it inverted. Every transaction moved into deficit.
Stated plainly: SHL was losing money on every single call — and still missing the 90% requirement. Both failures at once. Bleeding cash and under-delivering.
And it stayed hidden because the loss was concealed by the very incentive that caused it. The SLA pressure that made the team pay variant invoices without challenge was the same pressure that buried the shipping in a separate ledger, where it never met the markup it was destroying. The structure was, unintentionally, designed to keep the loss invisible — because surfacing it meant slowing payments, which threatened the SLA, which was the thing everyone was incentivised to protect.
No rule on any list would have caught this. Each function was honouring its mandate. The trap lived entirely in the interaction — and the strand that explained it could not be seen until the model that revealed it had been built.
Customs and the convergence point
Roughly 80% of the parts cleared customs into Canada. Customs was therefore not a footnote but a gate every order passed through, with its own timing and failure modes — none controlled by, or measured against, the buyers. A buyer could execute perfectly and still miss the window because a strand outside their authority stalled the part at the border.
Which raised the final question: if these strands all run separately, where can they be seen together? The answer was the courier. The carrier touches every other strand at once — downstream of the supplier’s shipping, the thing moving through customs, the physical event at which landed cost, clearance, and delivery timing all become real at the same moment. The delivery point is where the strands converge — and that makes it the one place where every otherwise-invisible strand can be observed and captured simultaneously, in real time. Capture at the convergence point and the emergent property stops being emergent-and-hidden. It becomes emergent-and-instrumented.
Why this defeats the numbered list
Step back and look at what the chain actually had:
Now imagine governing this with twenty rules. A rule for supplier confirmation. A rule for invoice matching. A rule for SLA monitoring. A rule for customs documentation. An organisation could satisfy every one independently and still lose money on every call while missing the target — because the determinant of the outcome was never inside any single rule. It was in the convergence between them, and one of the decisive strands could not even have appeared on the list, because it was unknowable until the others were constructed.
A list can represent a partition. It cannot represent a system that is sequentially revealed and mutually recomputing. Its silent promise is additivity — that satisfied checkpoints sum to success. The whole content of this case is that they do not sum. They interact, they surface in order, and adding one re-derives all the rest.
Rules govern nodes. Observation governs the strands that run between them. Outcomes live in the strands.
Why this is the Agentic AI lesson, not just a 1998 one
Everything above predates the technology people now reach for. And that is exactly why it matters in the Agentic AI era.
An agentic environment is a multi-strand convergence: autonomous agents, each with an objective and an incentive, interacting with humans, processes, data, and one another. The failures will not live inside any single agent — they will live in the convergence between them, exactly as DND’s failure lived between functions that were each individually compliant. New strands will surface only once earlier ones are understood. And you will not be able to govern such a system by adding a control and clicking; each new agent, each new interaction, recomputes the equilibrium of everything already deployed.
A technology stack and a governance checklist are necessary. The lesson of 1998 is that they are not sufficient — because neither can hold a system whose strands are sequentially revealed and mutually recomputing. That requires observation of the operating environment itself.
Readiness before the platform
One final point, and it is the one I guard most carefully.
The 51%→97.3% recovery was achieved through the observation and realignment of these converging strands — before any platform was credited with the result. The technology that later locked the gain in place came after the seeing. It did not cause the improvement; it preserved it. RAM 1998 is the cleanest proof I have of the sequence: align the operating environment first, instrument the convergence, and only then does a platform have something real to scale and hold.
That is the question the enterprise world is only now beginning to ask in earnest — not which tool do we buy, but what conditions determine whether any tool succeeds. In 1998 the answer was already sitting in the strands, waiting at the delivery point for someone to look. In the Agentic AI era, there will be far more strands, surfacing far faster — and the organisations that thrive will be the ones who learned to follow the converging strands instead of checking the boxes.
Truth Is Believing. Accuracy Is Knowing.
Jon Hansen is the creator of Implementation Physics™, a research-based framework developed over nearly three decades to explain why technology initiatives succeed or fail regardless of the technology being deployed. His work spans six technology generations — from ERP through Agentic AI — and includes the Metaprise™ model first articulated in the late 1990s. His research forms the foundation for the Hansen Method™, Hansen Fit Score™ (HFS™), Phase 0™ Readiness Assessment, and the ARA™ RAM 2025™ multimodel verification architecture. He currently serves as a Board Member of the CIPS Americas Chapter.
-30-
Share this:
Like this:
Related