The concept everyone is building committees around was the design brief for a defense procurement system twenty-eight years ago — running on technology that would be laughable today.
Here is a paragraph I published on 4 July 2007, in the seventh part of my Dangerous Supply Chain Myths series:
Motivated by the identification of the 2 commodity characteristics (in particular the Dynamic Flux findings), I began to investigate the potential to utilize advanced algorithms in 1998 as a means to both accelerate and increase purchasing autonomy on the front lines while still adhering to centrally established objectives. In short, although I did not know it at the time I was working to develop a meta-enterprise application.
Adhering to centrally established objectives.
That is a guardrail. Autonomy at the edge, bounded by objectives set centrally. It is the same concept the industry is now writing governance frameworks around — stated in 2007, about work done in 1998, in a defense MRO environment, on hardware that would be museum stock today.
So the guardrail is not the new idea. It is the old idea, renamed.
Which raises the only question that matters: if we had the boundary condition twenty-eight years ago and made it work, why has the failure rate for these initiatives held between 60 and 85% through every technology era since?
It is not the technology. The technology arrived a long time ago. What has not arrived alongside it is what used to operate inside the boundary.
What was inside the boundary in 1998
The system ranked suppliers on historical and real-time performance attributes. The buyer saw the ranking — not a recommendation, a visible ordering — and then decided whether delivery or price carried the weight for that particular purchase.
The default leaned heavily toward delivery, because the number that had to move was 51% next-day performance to above 97.3% against a 90% contract requirement. The default encoded the operational objective. But the buyer could apply price as an overlay and ask a specific question: is the lowest price still inside an acceptable delivery zone?
That question is answerable only because the ranking was visible and the weighting was adjustable at the point of use. No retrain. No configuration change. No ticket.
Every transaction was tracked in real time from purchase through delivery, so the historical attribute was never a historical baseline. Monday’s outcome was in Tuesday’s ranking. In an environment running on next-day delivery, there was no other option — a weekly review would have been useless, because twenty decisions would already have been made against stale rankings.
Then, after the system moved into production, it took on an attribute nobody had specified at design: capturing defective and wrong-part shipments.
That one matters more than it sounds. On-time delivery of the wrong item had been counting as success. Operating the system revealed that delivery had been the wrong measure, and the architecture absorbed a new attribute rather than being rebuilt around it.
A system that improves its score on a fixed set of measures is optimizing. A system that reveals a missing measure and takes it on is discovering. Those are not the same thing, and only one of them was ever the hard part.
What is inside the boundary in 2026
Mostly the boundary.
Objectives are set at design time and are not visible or adjustable to the person looking at the output. Permitted actions are enumerated. The human receives a result at the end and can approve or reject it.
That is a well-built constraint layer, and I am not against constraint layers. But a veto is not a weighting dial. Approving an answer is not asking a different question. And nothing in that arrangement can surface a measure that was never specified — which, in 1998, was the only reason the number moved.
The constraint layer has advanced considerably. The discovery layer has not moved nearly as far. We have built better fences around a smaller field.
A note on the vocabulary
In a June 2005 keynote in Calgary I described transactional algorithms that incorporate into the purchasing process so that with each transaction the system gets more intelligent — that it learns. I called them self-learning algorithms.
That phrase drew eye rolls at the time. So did Metaprise. So did agent-based modeling, which I put in print in the September 2005 Acres of Diamonds white paper: a true centralization of procurement objectives requires a decentralized architecture based on the real-world operating attributes of all transactional stakeholders, starting at the local or regional level — this is the cornerstone of agent-based modeling.
The vocabulary was early. The concepts were not wrong. They are standard now under different names.
Why this matters if you are deploying agents today
If your guardrail conversation is about what the agent is not allowed to do, you are having the 1998 conversation with better tools.
The three questions worth asking instead:
Can the person using this see what it is optimizing for? Not the documentation — the person at the desk, at the moment of the decision.
Can they change it without a ticket? A buyer who can reweight delivery against price for one purchase has authority. A buyer who can escalate a request to reweight has a process.
When the system reveals that you are measuring the wrong thing, can you take on the new measure? Or does that require rebuilding?
Three questions. None of them technical. All of them answerable this week, by anyone, without a pilot.
That is what I mean when I say governance isn’t that complicated. Not that the problem is easy — it has resisted seven technology eras. But the difficulty was never located where everyone keeps looking for it.
Jon Hansen — Procurement Insights | Hansen Models™ | Independent. Unsponsored. Archive-based.
Source: “Dangerous Supply Chain Myths (Part 7): Enabling Technology” — procureinsights.com, 4 July 2007
-30-
One final word, on demos
I stopped taking AI demos some time ago.
Not out of cynicism about the technology, but because of a pattern that became impossible to ignore: slides describing what a system would do, standing in for a system doing it. Architecture diagrams. Capability matrices. A workflow narrated over a static screen. Conceptual throughout, demonstrable almost nowhere.
The reason is structural rather than dishonest. A demo is built to produce agreement, and agreement is easiest to obtain in the abstract. Nobody nods along to a live transaction that goes sideways — but a live transaction that goes sideways is the only thing that tells you whether the system works.
Which is where the three questions above earn their keep. Used in the room, they convert a demo into a test:
Show me what it is optimizing for, on this screen, right now. Not in the documentation. In the interface, where the person making the decision would see it.
Let someone in this room change it. Not submit a request. Change it, now, and show me the output move.
Show me what happens when a measure you did not build for turns out to matter. Every deployment eventually meets one. The answer is either an architecture that absorbs it or a project that starts over.
If the answer to all three is a slide, you are not looking at a solution. You are looking at a proposal for one.
Related
AI Guardrails in 2026 Are What We Called Centrally Established Objectives in 1998. Governance Isn’t That Complicated.
Posted on August 13, 2026
0
The concept everyone is building committees around was the design brief for a defense procurement system twenty-eight years ago — running on technology that would be laughable today.
Here is a paragraph I published on 4 July 2007, in the seventh part of my Dangerous Supply Chain Myths series:
Adhering to centrally established objectives.
That is a guardrail. Autonomy at the edge, bounded by objectives set centrally. It is the same concept the industry is now writing governance frameworks around — stated in 2007, about work done in 1998, in a defense MRO environment, on hardware that would be museum stock today.
So the guardrail is not the new idea. It is the old idea, renamed.
Which raises the only question that matters: if we had the boundary condition twenty-eight years ago and made it work, why has the failure rate for these initiatives held between 60 and 85% through every technology era since?
It is not the technology. The technology arrived a long time ago. What has not arrived alongside it is what used to operate inside the boundary.
What was inside the boundary in 1998
The system ranked suppliers on historical and real-time performance attributes. The buyer saw the ranking — not a recommendation, a visible ordering — and then decided whether delivery or price carried the weight for that particular purchase.
The default leaned heavily toward delivery, because the number that had to move was 51% next-day performance to above 97.3% against a 90% contract requirement. The default encoded the operational objective. But the buyer could apply price as an overlay and ask a specific question: is the lowest price still inside an acceptable delivery zone?
That question is answerable only because the ranking was visible and the weighting was adjustable at the point of use. No retrain. No configuration change. No ticket.
Every transaction was tracked in real time from purchase through delivery, so the historical attribute was never a historical baseline. Monday’s outcome was in Tuesday’s ranking. In an environment running on next-day delivery, there was no other option — a weekly review would have been useless, because twenty decisions would already have been made against stale rankings.
Then, after the system moved into production, it took on an attribute nobody had specified at design: capturing defective and wrong-part shipments.
That one matters more than it sounds. On-time delivery of the wrong item had been counting as success. Operating the system revealed that delivery had been the wrong measure, and the architecture absorbed a new attribute rather than being rebuilt around it.
A system that improves its score on a fixed set of measures is optimizing. A system that reveals a missing measure and takes it on is discovering. Those are not the same thing, and only one of them was ever the hard part.
What is inside the boundary in 2026
Mostly the boundary.
Objectives are set at design time and are not visible or adjustable to the person looking at the output. Permitted actions are enumerated. The human receives a result at the end and can approve or reject it.
That is a well-built constraint layer, and I am not against constraint layers. But a veto is not a weighting dial. Approving an answer is not asking a different question. And nothing in that arrangement can surface a measure that was never specified — which, in 1998, was the only reason the number moved.
The constraint layer has advanced considerably. The discovery layer has not moved nearly as far. We have built better fences around a smaller field.
A note on the vocabulary
In a June 2005 keynote in Calgary I described transactional algorithms that incorporate into the purchasing process so that with each transaction the system gets more intelligent — that it learns. I called them self-learning algorithms.
That phrase drew eye rolls at the time. So did Metaprise. So did agent-based modeling, which I put in print in the September 2005 Acres of Diamonds white paper: a true centralization of procurement objectives requires a decentralized architecture based on the real-world operating attributes of all transactional stakeholders, starting at the local or regional level — this is the cornerstone of agent-based modeling.
The vocabulary was early. The concepts were not wrong. They are standard now under different names.
Why this matters if you are deploying agents today
If your guardrail conversation is about what the agent is not allowed to do, you are having the 1998 conversation with better tools.
The three questions worth asking instead:
Can the person using this see what it is optimizing for? Not the documentation — the person at the desk, at the moment of the decision.
Can they change it without a ticket? A buyer who can reweight delivery against price for one purchase has authority. A buyer who can escalate a request to reweight has a process.
When the system reveals that you are measuring the wrong thing, can you take on the new measure? Or does that require rebuilding?
Three questions. None of them technical. All of them answerable this week, by anyone, without a pilot.
That is what I mean when I say governance isn’t that complicated. Not that the problem is easy — it has resisted seven technology eras. But the difficulty was never located where everyone keeps looking for it.
Jon Hansen — Procurement Insights | Hansen Models™ | Independent. Unsponsored. Archive-based.
Source: “Dangerous Supply Chain Myths (Part 7): Enabling Technology” — procureinsights.com, 4 July 2007
-30-
One final word, on demos
I stopped taking AI demos some time ago.
Not out of cynicism about the technology, but because of a pattern that became impossible to ignore: slides describing what a system would do, standing in for a system doing it. Architecture diagrams. Capability matrices. A workflow narrated over a static screen. Conceptual throughout, demonstrable almost nowhere.
The reason is structural rather than dishonest. A demo is built to produce agreement, and agreement is easiest to obtain in the abstract. Nobody nods along to a live transaction that goes sideways — but a live transaction that goes sideways is the only thing that tells you whether the system works.
Which is where the three questions above earn their keep. Used in the room, they convert a demo into a test:
Show me what it is optimizing for, on this screen, right now. Not in the documentation. In the interface, where the person making the decision would see it.
Let someone in this room change it. Not submit a request. Change it, now, and show me the output move.
Show me what happens when a measure you did not build for turns out to matter. Every deployment eventually meets one. The answer is either an architecture that absorbs it or a project that starts over.
If the answer to all three is a slide, you are not looking at a solution. You are looking at a proposal for one.
Share this:
Like this:
Related