Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
More than a decade ago, Aaron Levie described the ambition. What the years since have taught me is the discipline that ambition quietly depends on — and it hides inside a single word.
In August 2013, Aaron Levie — co-founder and CEO of Box — wrote a line that has stayed with me ever since:
“Uber is a $3.5 billion lesson in building for how the world should work instead of optimizing for how the world does work.”
I first carried that observation into procurement in 2014, writing about the future of the P2P cloud and the emerging Internet of Things and Humans. At the time the point was straightforward, and I still believe it: transformative technology wins when it rethinks the work, not when it automates the process that was already there.
Twelve years later, I think the observation needs one more step — not a correction, an extension.
Levie was right about the ambition. Build for how the world should work, not for how it currently does. But decades of watching implementations succeed and fail — through ERP, SaaS, cloud, digital transformation, and now AI — taught me the discipline that ambition depends on. And it is easy to miss, because it turns on one word.
Should only becomes real if you have first understood how the world really works.
And “really” is not the same as “intended.”
Two architectures
There is a long history in enterprise technology of designing systems around the way organizations are intended to operate rather than the way they actually operate once incentives, competing priorities, fragmented ownership, and changing conditions enter the picture. That gap explains more implementation failures than any technical limitation ever has.
So I have come to distinguish between two architectures.
The first is the designed architecture — how work is intended to happen. Process maps, governance frameworks, operating models. The diagrams are often excellent. Reality has never been obligated to follow them.
The second is the operating architecture — how work really happens once people, incentives, uncertainty, and real-world conditions start interacting with each other.
Implementation succeeds or fails inside the gap between the two. That is the gap Levie’s “should” has to cross to become anything other than a slide.
An excellent map of the intended world
Last week, Alex Miguel Meyer shared a genuinely good visual on how Human-in-the-Loop AI governance should work — five layers, each reinforcing the next: Ethics, Risk Management, Accountability, Transparency, Compliance. It is a clear, well-constructed model, and any organization would want the structure it describes.
Human-in-the-Loop AI Governance, as mapped by Alex Miguel Meyer (shared on LinkedIn). The graphic cites the EU AI Act (Article 14), the NIST AI Risk Management Framework, and Harvard Business School (2024). Reproduced with credit to Alex Miguel Meyer.
It is also, by design, a normative model. It describes how governance is intended to flow.
Which raises the question the diagram does not attempt to answer, and isn’t meant to: what happens when a real organization meets that model — and its incentives, workarounds, and competing objectives quietly route around it? A governance layer that everyone agrees with on the wall, and no one is actually measured against, is a designed architecture with no operating architecture underneath it. The map is right. The territory was never asked.
The lesson that taught me this, in 1998
That distinction was driven home for me during a 1998 engagement with Canada’s Department of National Defence.
On paper, the process was sound. Orders were received, work was performed, calls were closed, service levels were measured. Nothing in the documented process suggested a structural problem.
The parameter that reset the entire program was not found in any process diagram. It was found in a plain question about operating reality: what time of day was an order placed, and what did that do to cost and delivery? That single question exposed a behavioral driver hiding in plain sight — orders were being timed to how people were measured, not to when the goods were actually needed. No governance diagram revealed it. No workflow model predicted it. Only watching how the organization actually behaved exposed it, and the framework was rebuilt around that reality before any technology was selected.
That experience changed how I look at every transformation since. Through ERP, SaaS, cloud, digital transformation, and now AI, the same pattern repeats: the technology evolves, the diagrams evolve, and the operating reality remains the determining variable.
Why verification is not validation
This is also why Human-in-the-Loop, audit trails, and explainability — all necessary — cannot by themselves guarantee a trustworthy outcome.
They verify behavior. They confirm the system did what it was specified to do. They do not validate whether the specification reflected the operating reality the system was entering — or whether it still does as conditions change.
That distinction has quietly become a legal one. As I pointed out in April, courts have begun reclassifying AI errors from hallucinations to design outputs — the system performing exactly as designed against conditions no one structurally tested. Read against Levie, the warning writes itself: an ambitious “should-work” system that was never validated against how the world really works is not a breakthrough waiting to happen. It is a design output waiting for a court to name it.
Across the finish line
So this is the one step further.
Levie pointed at the destination: build for how the world should work. He was right. What the record adds is the discipline that gets you there — you reach “should” by building on how the world really works, not on the intended diagram of it. Confuse the aspirational should with the org-chart intended, and the vision collides with an operating reality it never validated against. Honor the difference, and the ambition survives contact with the real world.
Technology keeps advancing. Organizations keep behaving like organizations. The implementation challenge has never been getting the technology to work — it has been getting it to work inside the reality it inherits.
That distinction sits at the center of both Invariant Physics™ — why the same implementation pattern reappears across every technology generation — and Implementation Physics™, the discipline of designing for how organizations actually operate rather than how the diagram assumes they will.
Levie gave us the ambition. The work is making it true.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
With credit to Aaron Levie, whose 2013 observation still frames the question, and to Alex Miguel Meyer, whose governance visual prompted this one. This analysis draws on the Procurement Insights archive — an independent record I have published openly since 2007, consolidating documented client work, lectures, and writing reaching back to 1998, and carrying no vendor sponsorships across the past decade. Every claim is held to the Provenance Ledger™, a verify-before-publish discipline that traces each assertion to a primary source and reconciles the record forward rather than editing it in place. Getting it right, rather than being right.
-30-
Related
Building AI for the Way the World Really Works — Taking Aaron Levie’s Observation One Step Further
Posted on July 21, 2026
0
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
More than a decade ago, Aaron Levie described the ambition. What the years since have taught me is the discipline that ambition quietly depends on — and it hides inside a single word.
In August 2013, Aaron Levie — co-founder and CEO of Box — wrote a line that has stayed with me ever since:
I first carried that observation into procurement in 2014, writing about the future of the P2P cloud and the emerging Internet of Things and Humans. At the time the point was straightforward, and I still believe it: transformative technology wins when it rethinks the work, not when it automates the process that was already there.
Twelve years later, I think the observation needs one more step — not a correction, an extension.
Levie was right about the ambition. Build for how the world should work, not for how it currently does. But decades of watching implementations succeed and fail — through ERP, SaaS, cloud, digital transformation, and now AI — taught me the discipline that ambition depends on. And it is easy to miss, because it turns on one word.
Should only becomes real if you have first understood how the world really works.
And “really” is not the same as “intended.”
Two architectures
There is a long history in enterprise technology of designing systems around the way organizations are intended to operate rather than the way they actually operate once incentives, competing priorities, fragmented ownership, and changing conditions enter the picture. That gap explains more implementation failures than any technical limitation ever has.
So I have come to distinguish between two architectures.
The first is the designed architecture — how work is intended to happen. Process maps, governance frameworks, operating models. The diagrams are often excellent. Reality has never been obligated to follow them.
The second is the operating architecture — how work really happens once people, incentives, uncertainty, and real-world conditions start interacting with each other.
Implementation succeeds or fails inside the gap between the two. That is the gap Levie’s “should” has to cross to become anything other than a slide.
An excellent map of the intended world
Last week, Alex Miguel Meyer shared a genuinely good visual on how Human-in-the-Loop AI governance should work — five layers, each reinforcing the next: Ethics, Risk Management, Accountability, Transparency, Compliance. It is a clear, well-constructed model, and any organization would want the structure it describes.
Human-in-the-Loop AI Governance, as mapped by Alex Miguel Meyer (shared on LinkedIn). The graphic cites the EU AI Act (Article 14), the NIST AI Risk Management Framework, and Harvard Business School (2024). Reproduced with credit to Alex Miguel Meyer.
It is also, by design, a normative model. It describes how governance is intended to flow.
Which raises the question the diagram does not attempt to answer, and isn’t meant to: what happens when a real organization meets that model — and its incentives, workarounds, and competing objectives quietly route around it? A governance layer that everyone agrees with on the wall, and no one is actually measured against, is a designed architecture with no operating architecture underneath it. The map is right. The territory was never asked.
The lesson that taught me this, in 1998
That distinction was driven home for me during a 1998 engagement with Canada’s Department of National Defence.
On paper, the process was sound. Orders were received, work was performed, calls were closed, service levels were measured. Nothing in the documented process suggested a structural problem.
The parameter that reset the entire program was not found in any process diagram. It was found in a plain question about operating reality: what time of day was an order placed, and what did that do to cost and delivery? That single question exposed a behavioral driver hiding in plain sight — orders were being timed to how people were measured, not to when the goods were actually needed. No governance diagram revealed it. No workflow model predicted it. Only watching how the organization actually behaved exposed it, and the framework was rebuilt around that reality before any technology was selected.
That experience changed how I look at every transformation since. Through ERP, SaaS, cloud, digital transformation, and now AI, the same pattern repeats: the technology evolves, the diagrams evolve, and the operating reality remains the determining variable.
Why verification is not validation
This is also why Human-in-the-Loop, audit trails, and explainability — all necessary — cannot by themselves guarantee a trustworthy outcome.
They verify behavior. They confirm the system did what it was specified to do. They do not validate whether the specification reflected the operating reality the system was entering — or whether it still does as conditions change.
That distinction has quietly become a legal one. As I pointed out in April, courts have begun reclassifying AI errors from hallucinations to design outputs — the system performing exactly as designed against conditions no one structurally tested. Read against Levie, the warning writes itself: an ambitious “should-work” system that was never validated against how the world really works is not a breakthrough waiting to happen. It is a design output waiting for a court to name it.
Across the finish line
So this is the one step further.
Levie pointed at the destination: build for how the world should work. He was right. What the record adds is the discipline that gets you there — you reach “should” by building on how the world really works, not on the intended diagram of it. Confuse the aspirational should with the org-chart intended, and the vision collides with an operating reality it never validated against. Honor the difference, and the ambition survives contact with the real world.
Technology keeps advancing. Organizations keep behaving like organizations. The implementation challenge has never been getting the technology to work — it has been getting it to work inside the reality it inherits.
That distinction sits at the center of both Invariant Physics™ — why the same implementation pattern reappears across every technology generation — and Implementation Physics™, the discipline of designing for how organizations actually operate rather than how the diagram assumes they will.
Levie gave us the ambition. The work is making it true.
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
With credit to Aaron Levie, whose 2013 observation still frames the question, and to Alex Miguel Meyer, whose governance visual prompted this one. This analysis draws on the Procurement Insights archive — an independent record I have published openly since 2007, consolidating documented client work, lectures, and writing reaching back to 1998, and carrying no vendor sponsorships across the past decade. Every claim is held to the Provenance Ledger™, a verify-before-publish discipline that traces each assertion to a primary source and reconciles the record forward rather than editing it in place. Getting it right, rather than being right.
-30-
Share this:
Like this:
Related