Image 2 (Very Good) — John Wernfeldt’s AI governance rings.Published openly on LinkedIn, and reproduced here with attribution.
Image 3 (Explaining The Difference) — The map you design and the map you trace.From The Map You Design and the Map You Trace, Procurement Insights, 29 July 2026.
Last December I wrote about the first of those three.
I said I did not get Gartner’s wheel, that at 66 I am not afraid to say so, and that if the graphic confused you, the graphic was the problem. Three encoding systems layered on top of each other — color, shape, and the direction the triangles happened to point — to communicate something a ranked list would have handled. Twelve priorities arranged in a circle with no connections between any of them.
I called it authority theater, and I stand by that.
This post is not about that.
The second graphic is a different thing entirely, and it is the more interesting one, because it is good.
The good one
John Wernfeldt published it on LinkedIn. Concentric rings, working outward.
At the center, the data foundation — sources, definitions, ownership, quality. Around it, the governance layer — policies, validation, lineage, catalog. Then trusted outputs, meaning answers you can actually defend. And on the outside, responsible AI.
His point in drawing it as rings is that you cannot buy the outer one without building every ring inside it first. Plenty of organizations are shopping for model cards and impact assessments while nobody owns the definitions three rings in.
That is correct, it is well made, and unlike the wheel it has connections. Each ring depends on the one inside it. You can use it as a gap analysis, walk around it, and come out with a roadmap.
Then I looked at it again and thought: I get it, but I don’t.
Not that I failed to follow it. Every ring made sense.
Something was missing.
Where does my question go?
One of the clearest engagements of my career came down to one question.
A defense maintenance operation was delivering parts on time 51 percent of the time against a 90 percent requirement. Everyone understood the problem. Procurement was underperforming. Suppliers were inconsistent. The process documentation was current and accurate, and everyone had read it.
The question that changed the outcome was:
What time of day do orders come in?
Late afternoon. Almost all of them, around four o’clock — because service technicians were holding order releases and batching them at the end of the day. Releasing orders as they came up interrupted service calls, and technicians were measured on call volume.
A rational response to how they were being measured. One department away from the people being blamed.
Delivery performance went from 51 percent to 97.3 percent in three months. No new system.
So I went back to the rings and asked where that question goes.
It is not data quality. Not metadata. Not ownership, stewardship, lineage or a definition. Not a policy, not a control, not an output you can defend.
It is nowhere on the diagram. And it was the only question that mattered.
The diagram starts one layer late
That is what was bothering me.
The framework assumes a data foundation exists and asks how to govern it. It never asks whether the foundation corresponds to how the organization actually operates.
Those are different questions. One governs a representation. The other tests whether the representation is true.
At that defense operation, every ring could have been built to a high standard. Clear ownership. Standardized definitions. Documented lineage. Excellent metadata. Governance committees meeting on schedule. Trustworthy outputs.
All of it would have worked exactly as designed.
And the technicians would still have been batching orders at four o’clock. Nothing in the framework asks about technician incentives, because technician incentives are not a data governance problem.
The concept and detail of Wernfeldt’s AI governance rings were not wrong. The assumptions about behavior were.
What the rings are for
Wernfeldt’s framework answers a real question: now that we have decided what we are building, how do we govern it? Who owns the data. Who approves definitions. How outputs get validated. What controls exist.
Those questions have to be answered, and organizations that skip them pay for it. It is an implementation architecture, and it is a good one.
The question is what has to be true before you use it.
If an organization has already established how it actually operates, a framework like this is genuinely valuable. It governs, documents and scales something real.
If it has not, the framework will govern beautifully — an operating model whose assumptions nobody ever checked.
The order of the work
Here is what that defense engagement actually looked like, in sequence, based on my theory of Strand Commonality™ — that seemingly unrelated strands of data have attributes that individually and collectively impact outcomes across the enterprise and beyond. Service technician incentives and parts delivery performance are connected on no org chart, in no process map, and in no dataset. The theory is what made that a place to look.
Observe. What is actually happening, as opposed to what the process says happens.
Explain. Why is it happening. Not that orders arrived at four — why they arrived at four.
Validate. Prove the relationship in the real world. Change what needs changing.
Govern. Now you know what you are governing, and you can define ownership, controls and policies around something demonstrated rather than assumed.
Automate. Last. The technology was selected after the result was substantially in hand, which is why no platform can be credited with it.
Most organizations run that in a different order — process, then data, then AI, then governance, with the first real check arriving after everything is built.
Automate before establishing the causal relationships and you do not remove the problem. You encode it, and then you execute it faster.
That was true in 1998. It matters more now, because an incorrect assumption then affected human decisions one at a time. The same assumption today sits inside an autonomous system making thousands of decisions at machine speed.
AI does not reduce the need for that first step. It raises the cost of skipping it.
How much air is in the tires?
There is an old story about a truck wedged under a low bridge. Engineers arrive. They discuss cutting the bridge, dismantling the trailer, calling in a crane.
A boy watching asks why they do not let some air out of the tires.
I understood the application the moment I first heard that story, because it describes something I was already doing.
The boy did not know more than the engineers. He knew less. What he had was no investment in the frame everyone else was working inside. The engineers had accepted that the bridge height and the truck height were the fixed variables. The boy had not, so he could see one that was not fixed.
Air pressure is not on anyone’s diagram. Neither is time of day.
Neither relationship becomes visible by making the existing framework more elaborate — because the framework is what is hiding it.
Why the third graphic looks the way it does
Two boxes, some arrows, one question. Next to concentric rings it looks like it is missing something.
It is missing something. It is missing everything that has not been established yet.
An elaborate framework does something subtle: it gives an unvalidated understanding greater authority. The more rings you draw around an assumption, the less anyone questions the assumption. The diagram becomes the reason to believe.
So the plain version is not a simplification of the complicated version. It is a refusal to add complexity before establishing what actually needs solving.
Get it right
The job at Hansen is not to be smart. And it is not to be right. It is to GET IT RIGHT — and the three are not the same.
Being smart rewards sophistication. Being right rewards defending the model you already have. Getting it right requires being willing to find out that your model, your data, your assumptions, or your own conclusion were wrong.
What time of day do orders come in? was not an impressive question. It was the question that exposed a relationship everybody else had missed.
So when I look at a well-built governance diagram and ask what exactly we are governing, I am not dismissing governance. I am asking the question that determines whether governance is being applied to the right thing.
Before building an elaborate system for governing something, establish that the thing you are governing corresponds to how the organization actually operates.
If it does, build every ring. They will hold.
If it does not, you will have governed a description of an operation that no longer exists — carefully, thoroughly, and with excellent documentation.
Sometimes the most important question is the one the existing model gives you no reason to ask.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
I Get It, But I Don’t
Posted on August 8, 2026
0
Two framework graphics, one of them very good, and the question that isn’t on either, and the third graphic that explains the difference
Image 1 — Gartner’s CIO Board Presentation Prep wheel. As published in Gartner’s Wheel: Decoder Ring or Clarifying Tool? (You Tell Me), Procurement Insights, 15 December 2025.
Image 2 (Very Good) — John Wernfeldt’s AI governance rings. Published openly on LinkedIn, and reproduced here with attribution.
Image 3 (Explaining The Difference) — The map you design and the map you trace. From The Map You Design and the Map You Trace, Procurement Insights, 29 July 2026.
Last December I wrote about the first of those three.
I said I did not get Gartner’s wheel, that at 66 I am not afraid to say so, and that if the graphic confused you, the graphic was the problem. Three encoding systems layered on top of each other — color, shape, and the direction the triangles happened to point — to communicate something a ranked list would have handled. Twelve priorities arranged in a circle with no connections between any of them.
I called it authority theater, and I stand by that.
This post is not about that.
The second graphic is a different thing entirely, and it is the more interesting one, because it is good.
The good one
John Wernfeldt published it on LinkedIn. Concentric rings, working outward.
At the center, the data foundation — sources, definitions, ownership, quality. Around it, the governance layer — policies, validation, lineage, catalog. Then trusted outputs, meaning answers you can actually defend. And on the outside, responsible AI.
His point in drawing it as rings is that you cannot buy the outer one without building every ring inside it first. Plenty of organizations are shopping for model cards and impact assessments while nobody owns the definitions three rings in.
That is correct, it is well made, and unlike the wheel it has connections. Each ring depends on the one inside it. You can use it as a gap analysis, walk around it, and come out with a roadmap.
Then I looked at it again and thought: I get it, but I don’t.
Not that I failed to follow it. Every ring made sense.
Something was missing.
Where does my question go?
One of the clearest engagements of my career came down to one question.
A defense maintenance operation was delivering parts on time 51 percent of the time against a 90 percent requirement. Everyone understood the problem. Procurement was underperforming. Suppliers were inconsistent. The process documentation was current and accurate, and everyone had read it.
The question that changed the outcome was:
Late afternoon. Almost all of them, around four o’clock — because service technicians were holding order releases and batching them at the end of the day. Releasing orders as they came up interrupted service calls, and technicians were measured on call volume.
A rational response to how they were being measured. One department away from the people being blamed.
Delivery performance went from 51 percent to 97.3 percent in three months. No new system.
So I went back to the rings and asked where that question goes.
It is not data quality. Not metadata. Not ownership, stewardship, lineage or a definition. Not a policy, not a control, not an output you can defend.
It is nowhere on the diagram. And it was the only question that mattered.
The diagram starts one layer late
That is what was bothering me.
The framework assumes a data foundation exists and asks how to govern it. It never asks whether the foundation corresponds to how the organization actually operates.
Those are different questions. One governs a representation. The other tests whether the representation is true.
At that defense operation, every ring could have been built to a high standard. Clear ownership. Standardized definitions. Documented lineage. Excellent metadata. Governance committees meeting on schedule. Trustworthy outputs.
All of it would have worked exactly as designed.
And the technicians would still have been batching orders at four o’clock. Nothing in the framework asks about technician incentives, because technician incentives are not a data governance problem.
The concept and detail of Wernfeldt’s AI governance rings were not wrong. The assumptions about behavior were.
What the rings are for
Wernfeldt’s framework answers a real question: now that we have decided what we are building, how do we govern it? Who owns the data. Who approves definitions. How outputs get validated. What controls exist.
Those questions have to be answered, and organizations that skip them pay for it. It is an implementation architecture, and it is a good one.
The question is what has to be true before you use it.
If an organization has already established how it actually operates, a framework like this is genuinely valuable. It governs, documents and scales something real.
If it has not, the framework will govern beautifully — an operating model whose assumptions nobody ever checked.
The order of the work
Here is what that defense engagement actually looked like, in sequence, based on my theory of Strand Commonality™ — that seemingly unrelated strands of data have attributes that individually and collectively impact outcomes across the enterprise and beyond. Service technician incentives and parts delivery performance are connected on no org chart, in no process map, and in no dataset. The theory is what made that a place to look.
Observe. What is actually happening, as opposed to what the process says happens.
Explain. Why is it happening. Not that orders arrived at four — why they arrived at four.
Validate. Prove the relationship in the real world. Change what needs changing.
Govern. Now you know what you are governing, and you can define ownership, controls and policies around something demonstrated rather than assumed.
Automate. Last. The technology was selected after the result was substantially in hand, which is why no platform can be credited with it.
Most organizations run that in a different order — process, then data, then AI, then governance, with the first real check arriving after everything is built.
Automate before establishing the causal relationships and you do not remove the problem. You encode it, and then you execute it faster.
That was true in 1998. It matters more now, because an incorrect assumption then affected human decisions one at a time. The same assumption today sits inside an autonomous system making thousands of decisions at machine speed.
AI does not reduce the need for that first step. It raises the cost of skipping it.
How much air is in the tires?
There is an old story about a truck wedged under a low bridge. Engineers arrive. They discuss cutting the bridge, dismantling the trailer, calling in a crane.
A boy watching asks why they do not let some air out of the tires.
I understood the application the moment I first heard that story, because it describes something I was already doing.
The boy did not know more than the engineers. He knew less. What he had was no investment in the frame everyone else was working inside. The engineers had accepted that the bridge height and the truck height were the fixed variables. The boy had not, so he could see one that was not fixed.
Air pressure is not on anyone’s diagram. Neither is time of day.
Neither relationship becomes visible by making the existing framework more elaborate — because the framework is what is hiding it.
Why the third graphic looks the way it does
Two boxes, some arrows, one question. Next to concentric rings it looks like it is missing something.
It is missing something. It is missing everything that has not been established yet.
An elaborate framework does something subtle: it gives an unvalidated understanding greater authority. The more rings you draw around an assumption, the less anyone questions the assumption. The diagram becomes the reason to believe.
So the plain version is not a simplification of the complicated version. It is a refusal to add complexity before establishing what actually needs solving.
Get it right
The job at Hansen is not to be smart. And it is not to be right. It is to GET IT RIGHT — and the three are not the same.
Being smart rewards sophistication. Being right rewards defending the model you already have. Getting it right requires being willing to find out that your model, your data, your assumptions, or your own conclusion were wrong.
What time of day do orders come in? was not an impressive question. It was the question that exposed a relationship everybody else had missed.
So when I look at a well-built governance diagram and ask what exactly we are governing, I am not dismissing governance. I am asking the question that determines whether governance is being applied to the right thing.
Before building an elaborate system for governing something, establish that the thing you are governing corresponds to how the organization actually operates.
If it does, build every ring. They will hold.
If it does not, you will have governed a description of an operation that no longer exists — carefully, thoroughly, and with excellent documentation.
Sometimes the most important question is the one the existing model gives you no reason to ask.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Share this:
Like this:
Related