AI Guardrails Are Centrally Established Objectives — 1998 Called

A paragraph published on 4 July 2007, in the seventh part of the Dangerous Supply Chain Myths series, describes work done in 1998: "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."

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.

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. 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.

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. A veto is not a weighting dial. Approving an answer is not asking a different question. 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.

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.