Start Here: What I Mean by Decision Engineering™
How institutional purpose becomes an actual decision — and where that journey quietly breaks.
A board decides that the institution should lend responsibly to self-employed customers.
The policy team translates that intention into criteria. A technology team encodes the criteria into rules. Data is transformed before entering the lending system. A model applies the rules, and thousands of applications are approved or rejected.
Every team may have done its job correctly.
Yet months later, the institution may discover that the system has been declining precisely the customers the board intended to serve.
The failure did not necessarily sit inside the policy, the model, the data or the technology. It may have occurred in the joins between them, where the original decision quietly changed shape.
That is the problem Decision Engineering™ examines.
How a decision travels
Every consequential institutional decision makes a journey. A board sets the purpose. Policies translate it. Teams interpret it. Data and technology encode it. People and, increasingly, AI systems execute it. Somewhere at the end, feedback returns — or does not.
At each step, the decision is handled by different people, different systems and different vocabularies. A policy writer works in principles. An engineer works in parameters. A model works in probabilities. Each translation is usually reasonable on its own terms. But a decision that passes through five reasonable translations can arrive somewhere its authors would not recognise.
The result may be operationally correct, technically compliant and completely different from what the institution intended.
The failures sit in the joins
Here is what makes this hard to see: every component usually has an owner.
The board owns purpose. Compliance owns policy. Technology owns systems. Risk owns models. Each is reviewed, audited and governed — separately.
What is rarely owned is the handoff. The join where policy becomes interpretation, interpretation becomes code, and code becomes execution. Authority, intent and accountability separate quietly at these joins, and no dashboard is watching them.
I call the slow result decision drift: the growing distance between what the institution decided and what its people and systems actually do. In the institutional failures I have analysed, most of the eventual damage did not come from the original error. It came from the time taken to see the problem, reconstruct what was happening and stop what followed.
What I mean by Decision Engineering™
Decision Engineering™ examines how institutional purpose and policy become actual human and automated decisions, where that chain breaks, and how control can be rebuilt.
It is not model governance, although models sit inside it. It is not risk management, although risk runs through it. It asks a different question: can the institution reconstruct what was decided, who or what had the authority to decide it, which rules and data shaped it, whether execution stayed aligned with the original intent and who remained accountable for the outcome?
If the answer is yes, control is real. If the answer is no, control is an assumption — and institutions tend to discover the difference at the worst possible moment.
Three ideas you will meet often
The Decision Integrity Chain™ maps the eight layers a decision passes through inside an institution, from purpose to feedback. I introduced it in The Foundation, and one layer at a time it is the backbone of this publication.
The Fiduciary Gap™ is the distance between who decides and who is accountable. When a human decided, the two were usually the same person. When an AI system decides, they are not — and the gap between them is where institutional control begins to weaken.
Close behind it sits a distinction readers return to often: responsibility, ownership and accountability are not the same thing. Responsibility may come with a title. Ownership may come with commitment. Accountability becomes real only when a person can produce the decision trail — you cannot genuinely answer for a decision that you cannot reconstruct.
Replayability is the standard this all points toward. When an automated system moves money or declines a customer, the institution should be able to reconstruct that decision later, the way a flight recorder reconstructs a flight. A log records what happened; a decision record captures why it was allowed to happen.
What you will find here
Longer essays apply these ideas to institutional cases — banks, hospitals, regulators — and to the shift now underway as AI moves from recommending decisions to making them. Shorter Notes look at markets, organisations and everyday decision-making through the same lens. Sunday Stillness is a separate, clearly labelled stream of reflective writing.
You do not need the frameworks to start reading. Each piece is written to stand on its own, with a plain-language bridge before any framework vocabulary appears.
Where to go next
Read the complete explanation of the discipline: What Is Decision Engineering™?
Three foundational pieces to begin with:
The Foundation — the Decision Integrity Chain™, layer by layer.
How I Work — how the discipline is applied inside institutions.
The archive — the framework applied to live cases and regulatory questions.
If this way of looking at institutions is useful to you, subscribe — it is free, and the foundational series arrives one layer at a time.