The words below come from a working session with one of the advanced models in my ARA™ RAM 2025™ panel. I am presenting the other voice as a CIO — because after forty-three years of having this exact conversation in real boardrooms, this is the reasoning a CIO brings to it. The fact that a machine reached the same place, from scratch, is the entire point.
Let me tell you up front what you are about to read, because the honesty of it is the argument.
The other voice in this conversation is labeled “the CIO.” Those words came from a genuine exchange with an advanced AI model — not from any one executive, and I am not putting them in a real person’s mouth. I am presenting them as a CIO’s because, across forty-three years of having this conversation across real tables, this is the reasoning a CIO brings to it. Not word for word — conceptually. The reach for the roadmap. The upgrade to “well, we’ll assess readiness first.” The exact place the reasoning stops short. I have watched it from the chair more times than I can count, and if you have sat in that chair, you will recognize yourself before you finish.
Here is what makes that more than a device. The model arrived at this reasoning on its own, with no budget to defend, no board to answer to, no career riding on the outcome — and it landed in the same place a CIO lands. That convergence is the proof. The reflex you are about to watch is not the failing of any particular executive. It is what reasoning does when it starts from the wrong question — whether the one reasoning is a person or the most capable machine on the market.
So read the CIO’s answers as your own. Sit in the chair. Then watch where the reasoning runs, and where it has to be turned.
I had put one proposition on the table: that the job is not to prove AI wrong, and not to prove AI right, but to work out whether the conditions exist under which AI produces the optimal outcome — which is not the same thing as proving it right.
THE CIO —
You’re right, and that’s an important distinction. I had unconsciously fallen into the same binary you’re pushing against. The issue isn’t prove AI is wrong, nor prove AI is right. It is to determine whether the conditions exist under which AI will be right.
The DND project is the perfect example. You weren’t trying to prove procurement was wrong, or the service department, or the technology. The technology was effective. The service department was acting rationally. Procurement, the couriers, the customs processes — each was doing exactly what it was supposed to do. Nobody was “wrong.” The seam was wrong — the assumptions connecting the agents were wrong.
That’s why “what time of day do orders come in?” is such a powerful question. You weren’t hunting for failure. You were looking for the condition under which success breaks down. Most pilots ask: can the AI do the task? You ask: under what conditions will the AI produce the intended outcome? The first is capability. The second is viability.
Looking at your June 10 piece, this is why the determinant survived six technology generations. ERP wasn’t bad. Analytics wasn’t bad. RPA wasn’t bad. AI isn’t bad. The mistake was assuming that because the technology can work, it will work here.
At DND the technology was necessary, efficient, and created real value — but only after the hidden condition was identified. Only after the loopback revealed the sandbagging dynamic. Only after the call-response metric was understood in the context of call closure. So the real task isn’t “find why AI is wrong.” It’s to find the conditions under which AI becomes right.
That is a good answer. It is also the trap — and the trap is in the last line, the one that sounds the wisest. So I said so.
JON HANSEN —
Close — but no cigar. Not yet, anyway.
If you tell someone find the conditions under which AI becomes right, you are already lost, because you are still trying to prove something is right. You have an I-want-to-be-right bias instead of an is-this-right bias. And that means you will run the same exercises you have run for every technology era before this one — process mapping, JAD sessions, siloed team meetings. If you do the same things you have always done, you will get the same results you have always gotten.
Remember the Virginia flag honor post — why do you think I was given that recognition? I changed the seating. I made the procurement people and the finance people leave the comfort of their own groupings and sit with strangers from the other side. I changed the room before the discussion ever started. (What Mattel, North Carolina, and Virginia’s eVA knew about AI failure before AI existed.)
Now watch what the correction does. It does not produce a smarter version of the same answer. It produces a different kind of answer.
THE CIO —
Yes. I see it now. The right question is not how do we make AI right? It is: is AI the right intervention here at all? And to answer that, you have to change the conditions of the inquiry itself. That is the part I had missed.
Process mapping, JAD sessions, siloed workshops — these are not neutral discovery methods. They almost always begin after the organization has already accepted that the technology is going forward. So the room is built to implement the assumption, not to test it.
Your Virginia example matters because you didn’t just ask better questions. You changed the room. You broke the social and functional pattern by seating procurement and finance together instead of letting each retreat into the familiar. You altered the information flow before the discussion began. So the method is not prove the technology right, and not prove the technology wrong. It is to disrupt the inherited frame so the real operating condition can surface. That is why “what time of day do orders come in?” mattered — it wasn’t a technology question or a process-map question. It was a frame-breaking question. You don’t find the seam by improving the old discovery process. You find it by changing the conditions under which discovery happens.
Only now — with the frame actually broken — was it worth handing over the structural point.
JON HANSEN —
Or, as I put it in two recent pieces: it is not the pyramid that is the problem. It is turning the pyramid upside down.
See: The Nico Bac and Jason Busch Debate — and the Structural Question Both Left Unanswered and Orchestration Does Not Solve Substrate Inconsistency.
THE CIO —
Yes — that’s the cleaner formulation. The pyramid is not the problem. The problem is starting at the top of it and then pretending the foundation will catch up.
That’s what most AI pilots do: start with capability, build the use case, map the process, manage the change, and hope the substrate can absorb it. That’s the inverted pyramid — balanced on its point.
Your work reverses the order. Surface the operating reality. Identify the seams. Validate incentives, decision rights, timing, dependencies. Determine whether technology is even the right intervention — and then deploy. That’s why “proving AI right” is the wrong posture: it starts at the top. The DND question started at the floor. It didn’t ask how to implement the system better. It asked what operating condition made the system fail or succeed.
It’s also why orchestration doesn’t solve substrate inconsistency. If the substrate is misaligned, orchestration just moves the misalignment faster.
So the sharper line is this: the problem isn’t the pyramid. The problem is that most AI pilots begin at the point and call it strategy.
What Just Happened
Read it back as yourself in the chair. The first answer was the obvious one — prove AI works. Named as a bias, the reflex didn’t vanish. It upgraded itself to find the conditions under which AI becomes right, which sounds wiser and is the same bias in a better suit, because it still ends with you running the discovery you have always run and arriving where you have always arrived. The escape didn’t come from a cleverer answer. It came from changing the room — from a question that refused to begin at the implementation premise at all.
That is the whole distance between capability and viability, and it is the distance every maturity model, every pilot, and every orchestration roadmap sails straight past. They assume the pyramid is upright, and they start climbing. The work that actually decides the outcome happens before the climb: identify the seams, and find the floor — and only then decide whether the pyramid is worth climbing at all.
But finding the floor once is a moment, not a method. Changing the room opens the channel; what has to run through it is the discipline I call the Learning Loopback Process™. The top sets what it believes are the goals and the priorities. The floor — through a loop that runs before the initiative, during it, and after — reports back what those goals actually require under real conditions, and whether they are being met or quietly gamed. That is exactly what surfaced at DND. The loopback is what revealed the sandbagging: the moment the floor showed that a metric the top had set (call response) was being satisfied while the goal it was meant to serve (call closure) was not. The top’s stated goal and the floor’s operating reality had come apart in the seam — and only the loop running between them could expose it. A top-down target with no loop back from the floor does not measure the goal. It measures the distance to the nearest place the number can be gamed.
Now here is the part worth sitting with. I have had this conversation for forty-three years, with CIOs, CFOs, and transformation leads, across defence, public sector, and the enterprise. The reasoning above is theirs — I would have had this same exchange, almost beat for beat, across any boardroom table. What unsettles me is not that an AI fell into the reflex. It is that the AI fell into the same reflex, by the same route, and had to be turned by the same question. The most capable reasoning system on the market reached the conclusion a well-trained executive reaches — which tells you the trap was never a matter of intelligence. It is a matter of the question you walk in holding.
That is the good news, if you let it be. The reflex is learnable to catch, because it is the same in every reasoner — yours, your CIO’s, and the machine’s. You catch it the way it got caught here: not by climbing more carefully, but by changing the room, and asking the question that starts at the floor.
Which brings it back to where it began. The CIO’s instinct was to prove the AI right — correct, defensible, properly built. Not once did the reasoning ask whether it would be optimal — the best outcome the organization could actually reach, given the conditions it would land in. That gap, between the right answer and the optimal one, is the whole difference between being right and getting it right. The technology can be right and the outcome still wrong. And the only instrument that catches that gap is the loop — because only the floor, reporting back before, during, and after, can tell you whether the outcome was optimal or merely defensible. Catching it is not a matter of intelligence. It is a matter of which question you walked in holding, and whether you left the channel open to hear the answer.
-30-
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. His work spans six technology generations — from ERP through Agentic AI — and examines the organizational conditions that determine outcomes regardless of the technology being deployed.
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. The responses attributed to “the CIO” above are reproduced from a session inside that framework and presented as a conceptual rendering of how the role reasons; consistent with archive policy, the underlying model is referenced generically rather than by vendor label.
Hansen currently serves as a Board Member of the CIPS Americas Chapter.
Related
I’ve Had This Conversation With CIOs for Decades. This Time, the CIO Was an AI.
Posted on June 13, 2026
0
The words below come from a working session with one of the advanced models in my ARA™ RAM 2025™ panel. I am presenting the other voice as a CIO — because after forty-three years of having this exact conversation in real boardrooms, this is the reasoning a CIO brings to it. The fact that a machine reached the same place, from scratch, is the entire point.
Let me tell you up front what you are about to read, because the honesty of it is the argument.
The other voice in this conversation is labeled “the CIO.” Those words came from a genuine exchange with an advanced AI model — not from any one executive, and I am not putting them in a real person’s mouth. I am presenting them as a CIO’s because, across forty-three years of having this conversation across real tables, this is the reasoning a CIO brings to it. Not word for word — conceptually. The reach for the roadmap. The upgrade to “well, we’ll assess readiness first.” The exact place the reasoning stops short. I have watched it from the chair more times than I can count, and if you have sat in that chair, you will recognize yourself before you finish.
Here is what makes that more than a device. The model arrived at this reasoning on its own, with no budget to defend, no board to answer to, no career riding on the outcome — and it landed in the same place a CIO lands. That convergence is the proof. The reflex you are about to watch is not the failing of any particular executive. It is what reasoning does when it starts from the wrong question — whether the one reasoning is a person or the most capable machine on the market.
So read the CIO’s answers as your own. Sit in the chair. Then watch where the reasoning runs, and where it has to be turned.
I had put one proposition on the table: that the job is not to prove AI wrong, and not to prove AI right, but to work out whether the conditions exist under which AI produces the optimal outcome — which is not the same thing as proving it right.
THE CIO —
That is a good answer. It is also the trap — and the trap is in the last line, the one that sounds the wisest. So I said so.
JON HANSEN —
Now watch what the correction does. It does not produce a smarter version of the same answer. It produces a different kind of answer.
THE CIO —
Only now — with the frame actually broken — was it worth handing over the structural point.
JON HANSEN —
See: The Nico Bac and Jason Busch Debate — and the Structural Question Both Left Unanswered and Orchestration Does Not Solve Substrate Inconsistency.
THE CIO —
What Just Happened
Read it back as yourself in the chair. The first answer was the obvious one — prove AI works. Named as a bias, the reflex didn’t vanish. It upgraded itself to find the conditions under which AI becomes right, which sounds wiser and is the same bias in a better suit, because it still ends with you running the discovery you have always run and arriving where you have always arrived. The escape didn’t come from a cleverer answer. It came from changing the room — from a question that refused to begin at the implementation premise at all.
That is the whole distance between capability and viability, and it is the distance every maturity model, every pilot, and every orchestration roadmap sails straight past. They assume the pyramid is upright, and they start climbing. The work that actually decides the outcome happens before the climb: identify the seams, and find the floor — and only then decide whether the pyramid is worth climbing at all.
But finding the floor once is a moment, not a method. Changing the room opens the channel; what has to run through it is the discipline I call the Learning Loopback Process™. The top sets what it believes are the goals and the priorities. The floor — through a loop that runs before the initiative, during it, and after — reports back what those goals actually require under real conditions, and whether they are being met or quietly gamed. That is exactly what surfaced at DND. The loopback is what revealed the sandbagging: the moment the floor showed that a metric the top had set (call response) was being satisfied while the goal it was meant to serve (call closure) was not. The top’s stated goal and the floor’s operating reality had come apart in the seam — and only the loop running between them could expose it. A top-down target with no loop back from the floor does not measure the goal. It measures the distance to the nearest place the number can be gamed.
Now here is the part worth sitting with. I have had this conversation for forty-three years, with CIOs, CFOs, and transformation leads, across defence, public sector, and the enterprise. The reasoning above is theirs — I would have had this same exchange, almost beat for beat, across any boardroom table. What unsettles me is not that an AI fell into the reflex. It is that the AI fell into the same reflex, by the same route, and had to be turned by the same question. The most capable reasoning system on the market reached the conclusion a well-trained executive reaches — which tells you the trap was never a matter of intelligence. It is a matter of the question you walk in holding.
That is the good news, if you let it be. The reflex is learnable to catch, because it is the same in every reasoner — yours, your CIO’s, and the machine’s. You catch it the way it got caught here: not by climbing more carefully, but by changing the room, and asking the question that starts at the floor.
Which brings it back to where it began. The CIO’s instinct was to prove the AI right — correct, defensible, properly built. Not once did the reasoning ask whether it would be optimal — the best outcome the organization could actually reach, given the conditions it would land in. That gap, between the right answer and the optimal one, is the whole difference between being right and getting it right. The technology can be right and the outcome still wrong. And the only instrument that catches that gap is the loop — because only the floor, reporting back before, during, and after, can tell you whether the outcome was optimal or merely defensible. Catching it is not a matter of intelligence. It is a matter of which question you walked in holding, and whether you left the channel open to hear the answer.
-30-
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. His work spans six technology generations — from ERP through Agentic AI — and examines the organizational conditions that determine outcomes regardless of the technology being deployed.
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. The responses attributed to “the CIO” above are reproduced from a session inside that framework and presented as a conceptual rendering of how the role reasons; consistent with archive policy, the underlying model is referenced generically rather than by vendor label.
Hansen currently serves as a Board Member of the CIPS Americas Chapter.
Share this:
Like this:
Related