Why did Frank stop at the door in his CDO Magazine article?
Frank Gundlich, Global Head of SAP Data & AI at Capgemini, published an article in CDO Magazine this month with a title that stopped me: “AI Governance Has a Foundation Problem: Two Layers Down.”
His opening distinction is the important one. Most AI governance frameworks define what an agent is allowed to do. Almost none define what it is allowed to trust — or whether it understands what it is reading.
That is much closer to the real problem than another discussion of model controls, approved tools and prohibited actions. A technically compliant agent can still make an organizationally dangerous decision if the information underneath it is valid, coherent and wrong for the decision being made.
He identifies four layers:
- Data quality — did the record pass validation?
- Data confidence — should it be believed, given its provenance, recency and resolution history?
- Semantic context — does the system understand what it means for this particular decision-maker?
- Model confidence — how certain is the model about its own output?
Most organizations, he argues, have some version of Layers 1 and 4. Layers 2 and 3 — where the decision is actually formed — remain largely undesigned.
He is right. And I want to start where he ends, because his last argument is stronger than his first.
The part of his article that should have been the headline
Frank asks why the middle layers stay missing when the data teams understand the gap perfectly well. His answer is not technical.
The person who surfaces a data gap creates work. They delay a project. They generate questions from stakeholders who expected a decision. The person who quietly resolves the gap — even if the confidence score is never updated — gets a completed task and a grateful project manager.
Multiply that across a team and across months, and you have a governance framework that looks rigorous and is built on a foundation nobody has ever explicitly examined.
That is not a data problem. It is an operating condition, and it is the most useful paragraph published on AI governance this year.
It is also the 1998 problem in different clothing.
What a 51 percent delivery rate was actually measuring
In 1998, a Department of National Defence maintenance operation was achieving next-day parts delivery 51 percent of the time against a 90 percent contractual requirement.
The records were not obviously defective. The individual measures reconciled. Everyone involved was behaving coherently inside their own frame.
The failure became visible only after a question that was nowhere on the procurement map: what time of day do the orders come in?
The answer — around four o’clock — pulled the trace out of procurement entirely. Technicians were measured on responding to calls, so they cleared the calls first and submitted the parts orders afterward. A locally rational incentive was manufacturing a late-day batch of urgent demand.
That pressure shaped buyer behavior. Buyers cleared their queues by sending much of the work to small US suppliers with no cross-border experience, and by issuing purchase orders against delivery dates the suppliers had never confirmed.
The trace left procurement again. Each supplier used a separate courier, multiplying customs-clearance risk at the border.
Finally it reached finance. Purchase orders recorded the part cost. Courier charges arrived separately on the invoices. Each line was managed correctly and reconciled cleanly. The loss existed only in the relationship between the two lines, because the contractual markup applied to part cost alone — so the shipping the purchase order never captured was quietly consuming the margin.
Nobody had done anything wrong. Competent accounting had built the blindness.
And there is an irony in it that is worth sitting with. By holding orders to four o’clock in order to meet their call-response quota — which also drove the part cost up significantly — the service technicians made it impossible to meet their own call-closure incentives, which almost cost the service company the contract. The behavior that satisfied one measure defeated the other. Each number was accurate. Nothing in the system connected them.
Two different systems. The map on the left is the line to a destination. The map on the right is a search starting from failure.
Delivery moved from 51 percent to 97.3 percent within three months, once the operating relationships were exposed and realigned. The technology came afterward, onto a system that had first been made real.
Now run that operation through the four layers
The purchase-order record could pass every data-quality rule. Its origin could be known, recent and independently verified. Its meaning could be correctly defined for the buyer, the finance manager and the contract manager. The model could express a properly calibrated confidence in its own output.
And the system would still miss it.
The decisive relationship did not live in any single data element. It connected an incentive in the service department, a batching pattern that impacted procurement, supplier capability, courier fragmentation at the border, and an accounting separation in finance. Five domains, no common map.
No confidence score attached to a purchase order discovers that chain. No ontology confined to the declared procurement process necessarily contains it.
The failure did.
Known uncertainty is not the same as an unknown relationship
This is the distinction that matters, and it cuts cleanly.
Frank’s missing layers govern known uncertainty. We know the record exists. We know its provenance may be weak, its verification stale, its meaning contested between two decision-makers. Those are real governance problems and his architecture makes them explicit — which is more than most frameworks manage.
The backward trace begins with a different condition: an outcome proving that an unknown relationship exists outside the accepted explanation.
Known uncertainty can be scored. An unknown relationship has to be discovered.
The first can be represented inside an architecture. The second usually requires leaving the architecture behind.
I wrote about this in The Map You Design and the Map You Trace. A designed map begins with what people believe the system contains and builds forward toward the intended outcome. A traced map begins with evidence of failure and works backward, following the operating reality wherever it goes — including outside the declared process, department, technology and organizational boundary.
Lineage can tell you where a known element came from. It cannot reveal a variable nobody thought to record. A confidence score can tell you how much to trust a known record. It cannot tell you that the decisive relationship sits between two records the organization treats separately. An ontology can formalize known meanings. It cannot guarantee the system contains a relationship nobody knew existed.
Detail is not discovery. A more rigorous portrait of the declared system is still a portrait of the declared system.
The tension in his own argument
Frank calls the leverage point behavioral rather than architectural. I agree.
But his three remedies return to architecture: provenance and lineage tracking, a confidence-scoring layer, a semantic or ontology layer.
Those mechanisms can record uncertainty accurately, but only once someone is willing to log it. If logging it still delays the project and invites awkward questions, the field stays empty and the score stays clean. Architecture cannot fix that. It is a question of what happens to the person who says “I don’t know” in a governance meeting — which is Frank’s own third question, and the one he does not carry into his remedies.
The technicians servicing the DND contract were not corrupting the process because they misunderstood it. They were responding rationally to the measure governing their daily behavior. The resulting data was not merely contaminated by the incentive — it was accurate evidence of how the real system worked. A confidence score would have told you the numbers were sound. They were.
Human governance has to establish the decision rights, incentives, escalation paths, exception handling and accountability conditions under which an inconvenient truth can survive contact with a project plan. Only then can those requirements shape the AI architecture, and the technology that follows.
Otherwise the new stack will faithfully record behavior still being produced by the old operating physics.
If things had not changed at DND, the service company would have lost a multimillion-dollar contract and its industry reputation. How many companies suffer a similar fate wondering why?
Where he is closer than he may realize
Frank’s final recommendation is to start with the single highest-consequence AI-driven decision and assign one accountable owner for its Layer 2 and Layer 3 definitions before that decision is allowed to run unsupervised.
That is the condition I have been arguing for from the procurement side: accountability for an outcome and the authority to act on it, held by the same person. A narrow scope with real ownership behind it beats a governance policy written for every use case at once. He arrived at it from data architecture. I arrived at it from watching and recording implementations over several decades that failed without it.
Two traditions, no contact between them, same conclusion. That is worth more than either of us asserting it alone.
The layer beneath the layers
His four-layer stack does not need to be discarded. It needs a validated substrate.
Before asking whether the data is trustworthy: what operating behavior caused this data to exist?
Before encoding its semantic meaning: what evidence establishes that the organization’s definition reflects how the work actually happens?
Before assigning model confidence: what outcome would reveal that the entire explanation is incomplete?
And before allowing the decision to run unsupervised: what has the system never thought to record?
That last question cannot be answered from the architecture alone. If the answer were already represented there, it would not be the missing variable.
This is why Phase 0™ sits before technology selection and deployment. It tests the operating substrate: decision authority at the point of action, incentives, exceptions, escalation, variability, and the gap between the process people describe and the one they actually inhabit.
It is also why AI governance has to be shaped first by human governance. The organization has to determine how truth is surfaced, how uncertainty is treated, who may challenge an accepted definition, and what happens when outcome evidence contradicts the official model.
Which, by the way, can only be done through a continuous loop-back process. Not a review cycle that confirms the model still holds, but one in which new outcome evidence re-enters at the start and is allowed to overturn what was previously settled. A framework that can only be confirmed is not being governed. It is being maintained.
Only then can an agent be told what it is allowed to trust.
What Frank actually did
He moved the conversation below permissions and model controls, into confidence, context and behavior. That is a harder argument to make than it looks, and most of the field has not made it.
His unit of analysis is the data element. Mine is the operating outcome. Those are different starting points, and they lead to different questions — but we are describing the same gap from opposite sides of it.
Frank asks what the agent is allowed to trust.
The question underneath is: what happened in the real system that caused this information to exist — and what did the system never think to record?
That is not another data layer.
It is the foundation beneath all four.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Jon W. Hansen, FCIPS — Procurement Insights | Hansen Models™
Related
Two People Found the Same Gap From Opposite Directions. Here Is What Sits Beneath It.
Posted on September 13, 2026
0
Why did Frank stop at the door in his CDO Magazine article?
Frank Gundlich, Global Head of SAP Data & AI at Capgemini, published an article in CDO Magazine this month with a title that stopped me: “AI Governance Has a Foundation Problem: Two Layers Down.”
His opening distinction is the important one. Most AI governance frameworks define what an agent is allowed to do. Almost none define what it is allowed to trust — or whether it understands what it is reading.
That is much closer to the real problem than another discussion of model controls, approved tools and prohibited actions. A technically compliant agent can still make an organizationally dangerous decision if the information underneath it is valid, coherent and wrong for the decision being made.
He identifies four layers:
Most organizations, he argues, have some version of Layers 1 and 4. Layers 2 and 3 — where the decision is actually formed — remain largely undesigned.
He is right. And I want to start where he ends, because his last argument is stronger than his first.
The part of his article that should have been the headline
Frank asks why the middle layers stay missing when the data teams understand the gap perfectly well. His answer is not technical.
The person who surfaces a data gap creates work. They delay a project. They generate questions from stakeholders who expected a decision. The person who quietly resolves the gap — even if the confidence score is never updated — gets a completed task and a grateful project manager.
Multiply that across a team and across months, and you have a governance framework that looks rigorous and is built on a foundation nobody has ever explicitly examined.
That is not a data problem. It is an operating condition, and it is the most useful paragraph published on AI governance this year.
It is also the 1998 problem in different clothing.
What a 51 percent delivery rate was actually measuring
In 1998, a Department of National Defence maintenance operation was achieving next-day parts delivery 51 percent of the time against a 90 percent contractual requirement.
The records were not obviously defective. The individual measures reconciled. Everyone involved was behaving coherently inside their own frame.
The failure became visible only after a question that was nowhere on the procurement map: what time of day do the orders come in?
The answer — around four o’clock — pulled the trace out of procurement entirely. Technicians were measured on responding to calls, so they cleared the calls first and submitted the parts orders afterward. A locally rational incentive was manufacturing a late-day batch of urgent demand.
That pressure shaped buyer behavior. Buyers cleared their queues by sending much of the work to small US suppliers with no cross-border experience, and by issuing purchase orders against delivery dates the suppliers had never confirmed.
The trace left procurement again. Each supplier used a separate courier, multiplying customs-clearance risk at the border.
Finally it reached finance. Purchase orders recorded the part cost. Courier charges arrived separately on the invoices. Each line was managed correctly and reconciled cleanly. The loss existed only in the relationship between the two lines, because the contractual markup applied to part cost alone — so the shipping the purchase order never captured was quietly consuming the margin.
Nobody had done anything wrong. Competent accounting had built the blindness.
And there is an irony in it that is worth sitting with. By holding orders to four o’clock in order to meet their call-response quota — which also drove the part cost up significantly — the service technicians made it impossible to meet their own call-closure incentives, which almost cost the service company the contract. The behavior that satisfied one measure defeated the other. Each number was accurate. Nothing in the system connected them.
Two different systems. The map on the left is the line to a destination. The map on the right is a search starting from failure.
Delivery moved from 51 percent to 97.3 percent within three months, once the operating relationships were exposed and realigned. The technology came afterward, onto a system that had first been made real.
Now run that operation through the four layers
The purchase-order record could pass every data-quality rule. Its origin could be known, recent and independently verified. Its meaning could be correctly defined for the buyer, the finance manager and the contract manager. The model could express a properly calibrated confidence in its own output.
And the system would still miss it.
The decisive relationship did not live in any single data element. It connected an incentive in the service department, a batching pattern that impacted procurement, supplier capability, courier fragmentation at the border, and an accounting separation in finance. Five domains, no common map.
No confidence score attached to a purchase order discovers that chain. No ontology confined to the declared procurement process necessarily contains it.
The failure did.
Known uncertainty is not the same as an unknown relationship
This is the distinction that matters, and it cuts cleanly.
Frank’s missing layers govern known uncertainty. We know the record exists. We know its provenance may be weak, its verification stale, its meaning contested between two decision-makers. Those are real governance problems and his architecture makes them explicit — which is more than most frameworks manage.
The backward trace begins with a different condition: an outcome proving that an unknown relationship exists outside the accepted explanation.
Known uncertainty can be scored. An unknown relationship has to be discovered.
The first can be represented inside an architecture. The second usually requires leaving the architecture behind.
I wrote about this in The Map You Design and the Map You Trace. A designed map begins with what people believe the system contains and builds forward toward the intended outcome. A traced map begins with evidence of failure and works backward, following the operating reality wherever it goes — including outside the declared process, department, technology and organizational boundary.
Lineage can tell you where a known element came from. It cannot reveal a variable nobody thought to record. A confidence score can tell you how much to trust a known record. It cannot tell you that the decisive relationship sits between two records the organization treats separately. An ontology can formalize known meanings. It cannot guarantee the system contains a relationship nobody knew existed.
Detail is not discovery. A more rigorous portrait of the declared system is still a portrait of the declared system.
The tension in his own argument
Frank calls the leverage point behavioral rather than architectural. I agree.
But his three remedies return to architecture: provenance and lineage tracking, a confidence-scoring layer, a semantic or ontology layer.
Those mechanisms can record uncertainty accurately, but only once someone is willing to log it. If logging it still delays the project and invites awkward questions, the field stays empty and the score stays clean. Architecture cannot fix that. It is a question of what happens to the person who says “I don’t know” in a governance meeting — which is Frank’s own third question, and the one he does not carry into his remedies.
The technicians servicing the DND contract were not corrupting the process because they misunderstood it. They were responding rationally to the measure governing their daily behavior. The resulting data was not merely contaminated by the incentive — it was accurate evidence of how the real system worked. A confidence score would have told you the numbers were sound. They were.
Human governance has to establish the decision rights, incentives, escalation paths, exception handling and accountability conditions under which an inconvenient truth can survive contact with a project plan. Only then can those requirements shape the AI architecture, and the technology that follows.
Otherwise the new stack will faithfully record behavior still being produced by the old operating physics.
If things had not changed at DND, the service company would have lost a multimillion-dollar contract and its industry reputation. How many companies suffer a similar fate wondering why?
Where he is closer than he may realize
Frank’s final recommendation is to start with the single highest-consequence AI-driven decision and assign one accountable owner for its Layer 2 and Layer 3 definitions before that decision is allowed to run unsupervised.
That is the condition I have been arguing for from the procurement side: accountability for an outcome and the authority to act on it, held by the same person. A narrow scope with real ownership behind it beats a governance policy written for every use case at once. He arrived at it from data architecture. I arrived at it from watching and recording implementations over several decades that failed without it.
Two traditions, no contact between them, same conclusion. That is worth more than either of us asserting it alone.
The layer beneath the layers
His four-layer stack does not need to be discarded. It needs a validated substrate.
Before asking whether the data is trustworthy: what operating behavior caused this data to exist?
Before encoding its semantic meaning: what evidence establishes that the organization’s definition reflects how the work actually happens?
Before assigning model confidence: what outcome would reveal that the entire explanation is incomplete?
And before allowing the decision to run unsupervised: what has the system never thought to record?
That last question cannot be answered from the architecture alone. If the answer were already represented there, it would not be the missing variable.
This is why Phase 0™ sits before technology selection and deployment. It tests the operating substrate: decision authority at the point of action, incentives, exceptions, escalation, variability, and the gap between the process people describe and the one they actually inhabit.
It is also why AI governance has to be shaped first by human governance. The organization has to determine how truth is surfaced, how uncertainty is treated, who may challenge an accepted definition, and what happens when outcome evidence contradicts the official model.
Which, by the way, can only be done through a continuous loop-back process. Not a review cycle that confirms the model still holds, but one in which new outcome evidence re-enters at the start and is allowed to overturn what was previously settled. A framework that can only be confirmed is not being governed. It is being maintained.
Only then can an agent be told what it is allowed to trust.
What Frank actually did
He moved the conversation below permissions and model controls, into confidence, context and behavior. That is a harder argument to make than it looks, and most of the field has not made it.
His unit of analysis is the data element. Mine is the operating outcome. Those are different starting points, and they lead to different questions — but we are describing the same gap from opposite sides of it.
Frank asks what the agent is allowed to trust.
The question underneath is: what happened in the real system that caused this information to exist — and what did the system never think to record?
That is not another data layer.
It is the foundation beneath all four.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Jon W. Hansen, FCIPS — Procurement Insights | Hansen Models™
Share this:
Like this:
Related