The Execution Gap

Preface | The Problem Comes Before the Answer

I did not begin with the intention of writing a book about the Execution Gap, much less a trilogy.

What I had at first were a set of concrete engineering problems.

In a system, Intent could already be clear. Approval could already have been granted. Authorization could already exist. Policy could already match. Everything we knew how to inspect might appear correct.

And yet what ultimately happened in the real world could still be different from what was originally meant to happen.

That kind of problem is surprisingly difficult to describe.

In software engineering, we look for bugs.

In security engineering, we examine identity, permissions, attack surfaces, and unauthorized access.

In governance systems, we ask whether approval was complete and whether the rules were adequate.

And with the rise of AI Agents, it has become natural to attribute failures to hallucination, reasoning errors, or excessive autonomy.

Any of those explanations may be correct in a particular case.

But none of them fully answered the question I was trying to ask:

Why should the fact that all of these things are individually valid be enough to establish that this particular real-world Action should occur?

The engineering work behind HAVENLON kept bringing me back to that question.

As systems began to interact not only with information, but with money, devices, accounts, and production environments, several observations that had previously appeared separate began to converge:

Intent is not Execution.

Authorization is not Execution.

A Policy being satisfied does not mean that a real-world Action should therefore occur.

And whether a subject is qualified to do something is not the same question as whether that subject is correct in this particular judgment.

Together, these observations pointed toward a problem I came to call the Execution Gap.

The Execution Gap did not begin with a finished theory in search of cases that could prove it.

The process ran in the opposite direction.

We began with engineering failures that did not fit neatly into existing categories, and repeatedly asked what they actually were.

Was this simply a bug?

Was it an access-control failure?

Was the approval process defective?

Was it something specific to AI?

Did it require an attacker?

The real-world cases did not prove the theory.

What they did was force the theory to narrow its own boundaries.

Because if the Execution Gap can explain every bad outcome, then it explains nothing in particular.

That is why this book is concerned not only with what an Execution Gap is, but equally with another question:

What does not count as an Execution Gap?

The work eventually expanded into three books.

The Execution Gap asks what the problem is.

Execution Control Engineering asks how real-world execution can be controlled.

Adversarial Completeness goes one step further: when the people, AI systems, services, administrators, runtimes, and devices participating in control may themselves fail or be compromised, what must still remain true?

But this first book does not rush toward a complete solution.

There is a reason for that.

If a problem is defined at the same time as a preferred solution is being constructed, the resulting theory can easily become a theory designed to justify that solution.

I would rather the Execution Gap first stand on its own.

This matters increasingly in the age of AI.

Traditional software dealt primarily with information.

More and more AI systems now deal with action.

They invoke tools.

They modify State.

They move money.

They operate devices.

And eventually, they turn a judgment into something that actually happens in the world.

Security can therefore no longer stop at asking what a system knows or what it has permission to access.

It must continue to ask:

What made this particular Action actually happen?

AI amplifies this problem.

It did not create it.

This book does not answer every question.

Some questions are deliberately left open, because the work follows a simple rule:

What is not yet known should remain unknown.

Before asking how execution should be controlled, we should at least establish something more basic:

What problem are we actually trying to solve?

The Execution Gap begins there.

Lin Wang
September 2026 · Chengdu

---

Acknowledgments

This work is not mine alone.

First, I want to thank Mengting Wu, Yong Zhang, and Jiang Deng. As co-authors of this book, they have been part of the process by which these ideas moved from engineering problems and research materials into a more coherent body of thought. Many of the conclusions that remain in these pages were not ideas that appeared fully formed in a single moment. They emerged gradually through engineering practice, research discussions, repeated challenges, and continual revision.

I am also grateful to everyone who has contributed to the engineering and research work behind HAVENLON.

Many of the ideas in this book were not developed in the quiet of a study. They were forced into view through architecture debates, protocol design, hardware implementation, failure analysis, and difficult engineering trade-offs. The product kept confronting the theory with questions it had not yet answered, while the theory kept turning back to the product and asking why something had to be designed one way rather than another.

My thanks also go to the colleagues and collaborators who contributed to the papers, source collection, case verification, and broader research effort. Turning an intuition into a claim that can withstand public scrutiny requires a great deal of work that is rarely visible: locating primary sources, reconstructing timelines, separating fact from interpretation, testing the boundaries of a case, and repeatedly deleting sentences that sound plausible but are not actually supported by the evidence.

I am equally grateful to the people and institutions that left behind public records.

Accident investigations, court documents, regulatory reports, engineering postmortems, research papers, and technical documentation gave these questions a basis in reality that thought experiments alone could never provide. Without those materials, The Execution Gap would have been far less capable of defining its own boundaries.

I also want to thank everyone who has read, questioned, discussed, challenged, or cited these ideas.

A theory begins to acquire a life of its own not when the author writes it down, but when other people begin using it to ask new questions. Disagreement, criticism, and counterexamples are often more valuable than agreement, because they force a theory to explain how far it can go—and where it must stop.

Finally, I want to thank my family, especially my child.

Writing books, doing research, and building systems means spending a great deal of time in front of a computer. It also means that many evenings, weekends, and holidays that might otherwise have been spent together were instead given to code, papers, cases, diagrams, and yet another round of revisions.

A child, of course, has no reason to care what an Execution Gap is, or to understand why I keep asking what made a particular Action actually happen.

But it is precisely those ordinary moments that have nothing to do with this work—a sudden question, an interruption, a meal together, a little time spent side by side—that keep reminding me that every discussion about systems, execution, and reality should ultimately return to real people and real life.

Thank you for continuing to grow beside me while I spent so much time working on things that must often have seemed strange, distant, and very slow.

And I hope that many years from now, if you happen to open this book, you will know that while it was being completed, you were part of that time too.

Lin Wang
September 2026 · Chengdu

---

Chapter 1 | When Every Check Passes, Yet the Result Is Wrong

This chapter begins with a counterintuitive fact: approvals, authorizations, policies, qualifications, and other local judgments may each hold within their own scope without thereby establishing end-to-end execution correctness. The Execution Gap does not begin with a bad result. It begins when what ultimately happens in the world no longer corresponds to an established upstream object. Severe consequences, malicious intent, and AI are therefore not necessary conditions for the gap to exist. Nor can a subject’s legitimacy, authorization, good faith, or capability guarantee that a particular judgment is correct. Robodebt serves as a boundary case: when a flawed upstream decision is faithfully executed, the severity of the consequences alone does not establish a deviation on the execution side. This pushes the inquiry back one step further. Unless we first distinguish what we mean when we say that something “was executed,” we cannot locate the deviation with precision.

Actions rarely arise out of nowhere in modern systems. Before money moves, goods are released, a machine is shut down, an account is revoked, or a production configuration is changed, a sequence of software objects will usually already have been involved: a recorded intent, an approval, an authorization check, a policy match, a qualification check. Each has an interface, a state, an audit trail, and its own criteria for determining what passes, what fails, and under what conditions that determination holds.

Engineers are accustomed to examining these objects one by one. Did the approval workflow complete? Did the authorization check pass? Did the policy engine match the rule it was supposed to match? Was the relevant qualification still valid when the action took place? Each question can produce a yes-or-no answer. Each answer can be reproduced. Each can be placed on the timeline of an incident report.

These checks answer concrete questions: who was qualified to initiate the action, who approved it, whether the system was permitted to modify the data at that moment, whether the change remained within the scope that had been declared. The difficulty begins with the next step in the reasoning. Once every local determination holds, it is natural to conclude that if every part is right, then what ultimately happens in the world should be right as well.

That inference does not hold.

What makes this failure subtle is that it need not mean the checks were too shallow, or that one link in the chain was actually broken but escaped detection. Every local determination may withstand scrutiny under its own criteria, while what ultimately happens in the world no longer corresponds to the established upstream objects. No identifiable local error is required. Neither is malice.

This is one reason such failures are so difficult to handle in post-incident review. Every person and every system in the chain may be able to produce evidence that its own part held. Yet those pieces of evidence, even taken together, may still fail to explain what actually happened. The discussion then tends to retreat to a familiar prescription—tighten the process—because the existing vocabulary offers no better way to describe the problem.

This chapter has one task: to turn that vague unease into a question precise enough to pursue.

Local Correctness Cannot Support That Inference

Start by asking what each local determination actually establishes.

An approval holds when, under the approval system’s own rules, a request has been approved by someone authorized to approve it. An authorization holds when, under the authorization system’s own rules, the subject currently possesses the permission required to perform that class of action. A policy match holds when, given the input available to the policy engine, the request matches a particular rule and receives the conclusion prescribed by that rule. A qualification check holds when, at the moment of evaluation, the object being checked satisfies the conditions that have been specified.

Each of these statements comes with a scope. Under the approval system’s own rules. Under the authorization system’s own rules. Given the input available to the policy engine. At the moment of evaluation. These qualifications are not incidental wording. They are what make the determinations mechanically decidable in the first place. A judgment can be delegated to a machine precisely because its criteria have been narrowed to something the machine can evaluate. That narrowing makes the judgment usable. It also defines its boundary.

The question, then, is what happens next. Once all of these local determinations hold, what establishes the step from them to the final outcome?

Consider the implicit argument:

The approval holds. The authorization holds. The policy matches. The qualification is valid. Therefore, the action is correct end to end.

The part that requires scrutiny is therefore.

That word belongs to none of the local determinations. It is not contained in the approval criteria, the authorization criteria, the policy rule, or the qualification check.

That is the problem. Each local determination may be verifiable. Each may leave behind clear evidence that it held. But the fact that they all hold does not, by itself, establish the inference that connects them to what ultimately happens in the world.

This is the central claim of the chapter:

Local Correctness ≠ End-to-End Execution Correctness

It is important to be precise about what this inequality denies, because it is easy to read more into it than it says.

It denies the therefore.

It says that the fact that an upstream intent, decision, approval, authorization, policy, or qualification holds within its own scope is not, by itself, sufficient to establish the correctness of the eventual execution and real-world result.

It does not say that there must be an identifiable break somewhere in the chain. It does not say that if the conclusion fails to follow, then one of the local determinations must secretly have been wrong. Nor does it say that something else must necessarily be missing.

Those are tempting inversions, but they do not follow. From “A is insufficient to establish B,” we cannot infer that “therefore some C must exist.” The inequality closes one inferential path. It does not promise a new object at the other end.

That negative form is the conclusion. It is not a cautious way of avoiding a stronger positive claim.

If we were to rewrite it as, “For the result to be correct, the system must additionally contain X,” we would be supplying an answer that the argument has not established. Worse, we would be claiming more than the evidence can support.

This chapter will not do that.

At this point, the natural response is to inspect the entire chain and ask: Which link failed?

But that already goes one step too far.

The inequality identifies no hidden point of failure. It establishes only this: local correctness, by itself, is insufficient to establish end-to-end execution correctness.

Correctness Cannot Serve as the Reference Point

A more basic problem now has to be resolved.

When we say that the result was wrong, what exactly was wrong about it? Wrong relative to what?

The easiest answer is: relative to what would have been correct. But that answer is empty. Correctness is not yet a defined property here, and this book has not established a positive theory of what the correct result must be.

That is not an omission.

If we were to introduce such a standard at this point, the rest of the argument would be forced to rest on a premise that has never been established. We would merely have moved the problem from an unsupported therefore to an unsupported notion of correctness.

Worse, using correctness itself as the reference point would collapse the inequality introduced in the previous section. Local correctness is not the same as overall correctness would sound little more than tautological. It would invite an easy interpretation: software has bugs; complex systems sometimes fail. If that were all this book meant, there would be little reason to continue.

The reference point therefore has to change.

It must be an Established Upstream Object: the recorded intent, the particular decision that was made, the specific approval that was granted, the authorization that held, the policy that matched, or the qualification that passed.

The reference is no longer an abstract property. It is now an identifiable object, with specific content, a point in time, and a defined scope of applicability. We can place it beside what ultimately happened and ask a concrete question:

Does what happened in the world still correspond to that established upstream object?

In an incident investigation, this distinction becomes practical.

If the reference point is merely “correctness,” the question What exactly was wrong? can quickly dissolve into an argument without a fixed baseline. Once the reference becomes a particular established intent, decision, approval, authorization, policy, or qualification, the investigation has something concrete to compare against. Put the upstream object beside what actually happened and ask whether the required correspondence still holds.

That comparison may still be difficult. But at least the objects being compared are now clear.

The meaning of deviation therefore becomes narrower, but also more precise. It does not mean that the outcome was undesirable. It means that what ultimately took effect in the world no longer corresponded to an established upstream object.

This distinction is not precision for its own sake. It determines what belongs inside the problem space of this book and what does not.

On one side are cases in which the upstream object still holds, yet the real-world action or result no longer corresponds to it: the recorded intent is still there, the approval remains valid, the matched policy is still the policy that applied, but what actually happened no longer lines up with those objects.

The other side of the boundary will become clearer through a concrete case shortly.

The problem space described here has a name: the Execution Gap.

This chapter will not define it yet.

Before a definition is possible, we first have to be clear about what we mean by execution.

A Bad Outcome Is Not the Entry Point

Robodebt pushes this boundary into a form that is difficult to ignore.

In that case, the upstream rules were themselves unlawful and rested on an inadequate evidentiary basis. Those rules were then executed faithfully, automatically, and at scale. The consequences were severe, and automation undeniably played a central role in producing them.

If a bad outcome were enough to enter the problem space, Robodebt would plainly qualify. The harm was serious, the scale was substantial, and automation was deeply involved.

But a bad outcome is not the entry point.

Under the distinction established in the previous section, the question is whether what ultimately happened in the world still corresponded to the Established Upstream Object. In Robodebt, that correspondence was largely intact. The system did what it had been instructed to do, and did so with little deviation from the governing rule.

The problem lay upstream: in the rule itself, its legal basis, and the evidentiary basis on which it rested. That is first a problem of upstream decision and authority, not a deviation on the execution side.

This does not excuse the execution. Faithfully carrying out a rule that should not have been carried out does nothing to lessen the harm.

The point is different.

We cannot determine where a failure belongs merely by working backward from the severity of its consequences. Consequences can tell us that something went wrong. They do not tell us at what layer it went wrong. And that distinction—where the failure sits—is precisely what matters here.

If Robodebt were classified as an execution deviation simply because its consequences were severe, the problem space would begin to lose its shape. Any automated system that produced a harmful result could be brought under the same label. The question Did execution deviate? would collapse into another version of Was the outcome bad?

At that point, the inequality developed earlier in this chapter would become almost impossible to dispute—and for the same reason, almost impossible to use.

Robodebt therefore serves here not as proof, but as a boundary case.

It forces a harder question: if the real-world consequences are clearly wrong, but the execution process faithfully carries out an upstream decision that was itself flawed, has there been an execution deviation in the sense used in this book?

A bad outcome alone is not enough to answer yes.

Nor does that mean that every case in which a flawed upstream decision is faithfully executed must remain permanently outside the Execution Gap. Some may re-enter the problem space under additional conditions. Those conditions require separate analysis.

For now, only one boundary needs to hold:

The severity of a real-world outcome is not, by itself, sufficient to establish a deviation on the execution side.

Robodebt is therefore not a positive example of the Execution Gap, nor does it add evidentiary weight to the chapter’s central claim. Its role is narrower: it makes the boundary harder to blur.

There is no need to retell the full history of Robodebt here. Its factual record, responsibility findings, and governance consequences matter, but they belong to a different line of inquiry.

For this chapter, one conclusion is enough:

A severe bad outcome does not, by itself, mean that execution deviated.

Malice Is Not Required

If every local check holds and the result is still wrong, another explanation comes naturally: someone must have interfered.

The appeal of that explanation is easy to see. It preserves the original inference. Remove malice, and the reasoning appears to work again: if every local check holds, the result should follow. The investigation also gains an obvious target—find the malicious actor, or find the control that was breached.

But the inference still does not hold.

The problem examined here does not require malice.

Fallibility and malice are not the same thing.

Fallibility means that a subject’s identity, qualification, good faith, or capability cannot by itself establish that a particular judgment is correct. Malice is a different question. Conflating the two turns a problem about judgment into a problem about adversaries.

The distinction becomes clearer if we separate a few things that are often compressed together.

A valid identity, a valid credential, and valid authorization can all be established without establishing that this particular action is correct. These are all things engineering systems know how to verify reasonably well. They answer a question such as: Is this subject permitted to perform this class of action?

They do not answer a different question: Is this the right thing to do in this particular instance?

Moving from the first answer to the second is another inferential step—one that is easy to overlook because the first question has explicit criteria while the second does not.

Good faith raises a different issue: can it serve as a security boundary?

Again, the answer is no.

A security boundary has to rest on conditions that can be verified. Motivation itself is not verifiable in the same way. We can verify a signature. We can verify an authorization. We can verify whether a policy matched. We cannot verify, by the same means, that a person or a system acted “with good intentions.”

Good faith may be real. It may matter. But it cannot substitute for a verifiable boundary.

Capability does not solve the problem either. Greater capability does not eliminate fallibility.

Fallibility means precisely that we cannot establish, in advance, that a subject will be correct in every particular judgment it makes. In that sense, fallibility is first an engineering property: it reflects the structural condition of a subject acting on an incomplete view of reality. It is not merely a temporary consequence of insufficient intelligence, and it therefore does not disappear simply because capability improves.

Taken together, these observations give us a deliberately limited negative core. It is all this book needs to assume about subjects at this stage—no more, but also no less.

A Negative Core

A subject’s legitimacy, authorization, qualification, or good faith is insufficient to establish the correctness of its judgment.

Two points must be read together.

Authentication, authorization, good faith, high capability, and a long record of reliable behavior cannot establish that a subject is correct in a particular judgment.

Whether a judgment is correct and whether that judgment has been given the power to change the world are two different questions.

This claim is easy to overread, so its boundary matters just as much as the claim itself.

It does not say that every subject will make mistakes. It does not say that subjects are likely to make mistakes. Nor does it imply that a subject is untrustworthy.

It denies only this: authentication, authorization, good faith, high capability, or a history of reliable behavior cannot guarantee the correctness of a particular judgment.

Nor do we define correctness here, close the set of possible subjects, or define authority. What we are accepting is a limited premise, not constructing a complete formal theory.

The second point carries most of the weight.

Whether an error occurs and whether that error can acquire the power to change reality are independent questions.

Engineering systems often place those two questions along the same operational path, but they are determined by different things. Whether a judgment is correct depends on the information available to the decision-maker, the reasoning applied to it, and the portion of reality the decision-maker can observe. Whether that judgment can change reality depends on how the system has been wired: which service can invoke which interface, which policy decision can take effect directly, and which approval leaves no further check before action.

Those arrangements are often made much earlier, for reasons entirely separate from whether this particular judgment happens to be correct.

Collapsing the two questions leads to a conclusion this book does not accept: because subjects are fallible, they should be allowed to do less.

That is not the argument here.

Fallibility is not the same as untrustworthiness. Treating fallibility as a reason to withdraw autonomy is a misuse of the premise.

Who Counts as a Subject?

Once the negative core is accepted, another question follows almost immediately: who, exactly, counts as a subject?

If the premise applied only to ordinary users, the problem would be relatively simple. But the same question quickly reaches administrators, owners, and root users. From there it extends to hardware, to the components that actually carry out actions, and even to the layer that records evidence.

At each step, the same question returns: does the negative claim established above still apply to this subject?

This is where we have to stop.

At present, no established criterion tells us where the set should end. Does it stop at the administrator? At the owner? Does an execution component count? Does hardware? What about an evidence system?

This book will not supply an answer merely to make the structure look complete.

Closing the category of subject into a rigorously defined set would require further formal work. Chapter 1 does not need that closure in order to make its argument.

It needs only a smaller claim: for any particular subject under discussion, identity, qualification, authorization, good faith, or capability is not, by itself, sufficient to establish the correctness of that subject’s particular judgment.

That negative claim does not require us to enumerate every possible subject before it can hold.

The evidence layer should also remain unresolved here. Mentioning it establishes only that the question can be pursued that far. It does not establish the final place of evidence within the larger structure.

Some questions are better left explicitly open than prematurely resolved.

Knowing where an argument must stop is itself part of defining its theoretical boundary.

Where AI Fits

Once the subject in an execution chain changes from a human to an AI agent, an obvious question follows: do the conclusions established so far change with it?

The core conclusion does not.

In the problem space examined here, AI agents primarily amplify existing problems rather than create them.

Both halves of that statement matter. Amplification means that AI can materially change the scale, speed, and reach of a judgment. A single decision can travel farther, take effect faster, and influence more actions than it could in a slower or more manually mediated system. But rather than create points in the other direction: the underlying problems being amplified were already present before AI entered the chain.

The fact that an upstream object holds does not, by itself, establish that the real-world result will correspond to it. That inequality does not depend on a model. Malice is not a necessary condition either, and that conclusion does not depend on a model. The preceding sections have had little need to discuss models at all because the argument does not require one.

Reducing the problem to “the model made a mistake” or “the model hallucinated” therefore makes the underlying issue disappear for the wrong reason.

Hallucination concerns a mismatch between a model’s output and the facts. The problem examined in this chapter concerns a different relationship: whether established upstream objects continue to correspond to what ultimately happens in the world. The two can occur together, but they are not the same phenomenon, and neither can stand in for the other.

The distinction becomes clearer when AI is removed from the picture entirely. The problem described in this chapter can arise in systems with no model involved at all.

If the entire class of risk is attributed to model error, the problem quickly shrinks into a question of model reliability: better training, a more capable model, or the next release may appear to be the answer.

But the issue examined here does not come into existence with a particular model version, nor does it disappear merely because the model improves. The inequality established earlier concerns the relationship between upstream objects and real-world execution. It is not a statement about model accuracy.

None of this makes automation unimportant. Amplification has consequences, and those consequences can be substantial. But the magnitude of a consequence and the origin of the underlying problem are different questions. Conflating them encourages another mistaken inference: make the automated part reliable enough, and the earlier inequality will disappear.

It will not.

The exact place of automation within this problem space requires a finer analysis than this chapter provides. That analysis comes later.

First, Clarify What “Executed” Means

At this point, what we have established is still mostly negative.

Local validity is insufficient to establish end-to-end execution correctness. A bad outcome alone is insufficient to locate the deviation on the execution side. Malice is not a necessary condition. AI can amplify the problem without being required for the problem to exist.

This chapter has not yet told us where the deviation occurs. Nor has it supplied a structure to fill the space that has now been exposed.

It has done something more limited: it has removed an inference that was previously being taken for granted.

Once that inference is removed, however, an earlier question can no longer be avoided.

Throughout this chapter, we have spoken about what ultimately happens in the world as though execution were self-explanatory.

It is not.

In engineering language, saying that something “was executed” can refer to different moments and to different objects. If we have not yet distinguished what that word refers to, then the question Where did the deviation occur? cannot be asked with precision.

So before we go any further, we need to ask:

When we say that an action “was executed,” what exactly do we mean? And at what layer can the deviation occur?

---

Chapter Terms

• Local Correctness
• End-to-End Execution Correctness
• Established Upstream Object
• Execution Gap
• Fallibility
• Boundary Case
• Execution

Case and Sources

Robodebt

This chapter uses Australia’s Robodebt scheme as a Boundary Case.

Robodebt involved automated welfare-debt identification and recovery and produced severe real-world consequences. Its inclusion here does not mean that the case is being classified as an instance of the Execution Gap, nor is it being used as proof of the chapter’s central claim.

Its role is narrower: to clarify the boundary of the problem space.

Severe real-world consequences are not, by themselves, sufficient to establish that the deviation occurred on the execution side.

When the primary problem lies in an upstream rule, its legal basis, or the evidentiary basis on which it rests, faithful downstream execution does not become an execution deviation merely because the eventual consequences are severe.

The necessary distinction is therefore this: an Execution Gap must be evaluated against an Established Upstream Object, not against an outcome that is judged, after the fact, to have been “correct” or “incorrect.”

This chapter does not attempt to determine the conditions under which a normatively flawed upstream decision might later re-enter the Execution Gap problem space.

For the full factual background, verification record, principal official sources, and the evidentiary limits of Robodebt as a boundary case, see the appendix “Real-World Failures and Boundary Cases.”

Sources

The full factual chain and bibliographic record for Robodebt are not repeated in this chapter. The supporting material is consolidated in the appendix “Real-World Failures and Boundary Cases” and in the book-wide “References and Sources.”

---

---

Chapter 2 | What Do We Mean When We Say an Action Was “Executed”?

This chapter takes apart the deceptively simple claim that something “was executed.” Execution is not a single moment. The Execution Process spans the period from entry into an identifiable execution path through the formation of a real-world result; the Execution Act is the action that actually changes real-world state. Result is a separate object again: the fact that an Execution Act occurred does not, by itself, establish that a Result has been established. Commit, Invocation, Execution State, Receipt, Result, and Evidence likewise must not be treated as interchangeable, nor arranged by default into six stages that necessarily occur in sequence. Any relationships among them must be established separately. The chapter opens with a hypothetical shutdown command that appears to have been executed while the equipment continues to run, showing how the same word—“executed”—can refer to different objects. The chapter also leaves unresolved the formal relationship among Technical Result, External State, and Business Result rather than imposing a hierarchy prematurely. Once these objects have been separated, the question becomes sharper: if each object can hold within its own scope, where does the deviation actually occur?

In engineering conversation, whether an action happened often seems to require little explanation. Someone asks, “Did that command execute?” Another person glances at a dashboard and answers, “Yes.” The conversation usually ends there.

The problem is that the question and the answer may not always be referring to the same thing.

Consider an ordinary post-incident review. A command was issued to shut down a piece of equipment, and afterward the command is reported as having been “executed.” The engineer responsible for the change says the command was committed; the timestamp and record are there. The interface engineer says the invocation was sent and returned successfully. Operations says the system state now shows the equipment as stopped. The person coordinating with the external vendor says a receipt has arrived stating that the request was “accepted and processed.”

Then someone goes to the site.

The equipment is still running.

That does not make every earlier statement false. The commit may indeed have completed. The invocation may indeed have returned successfully. The system state may indeed say stopped. The external receipt may indeed exist.

What the scene exposes is something else: everyone has been using the same word—executed—to answer questions about different objects.

As long as those objects remain aligned, this compression usually causes little trouble. Once they separate, the original yes-or-no question stops working. “Was it executed?” can no longer be answered meaningfully with a simple yes or nountil we know which object the question is asking about.

The previous chapter ended with a negative conclusion: the fact that upstream objects each hold within their own scope is insufficient to establish correct end-to-end execution and real-world result. To pursue that problem further, we first have to separate the different objects that have been compressed into the word execution.

That is the task of this chapter.

Execution Is Not a Single Act

Execution is not a term that belongs to a single instant. It refers more broadly to the process by which expressions, judgments, and commitments enter into real-world change. Within that broader concept, at least two objects have to be kept distinct.

The first is the Execution Process. It begins when something enters an identifiable execution path and extends through the period in which a real-world result is formed. A change that crosses seven systems, takes forty minutes, and is retried twice along the way can still be understood as one Execution Process.

The second is the Execution Act. This is the action that actually changes real-world state: the moment power to the equipment is cut, the moment funds leave an account, the moment a valve closes.

The two are easily conflated because ordinary language lets us use execute in both senses. We can speak of executing a change as a process, and we can also say that the act of execution has occurred.

But those statements answer different questions.

An Execution Process can be in progress, complete, or stalled. An Execution Act asks something else: has reality actually changed?

Once the two are compressed into the same term, even a seemingly simple question such as “How far has execution progressed?” becomes ambiguous. It may be asking how far the process has advanced, or whether the real-world change has already occurred.

The distinction is easiest to see in time.

An Execution Process has duration. A change can remain within it for quite some time—queued, waiting for a maintenance window, awaiting confirmation, or retrying after failure. During that period, it may be entirely accurate to say that the change is “being executed” even though no real-world state has yet changed.

An Execution Act is different. The question is whether the relevant real-world change has occurred. Once the act has taken place, whatever happens later in the process cannot make the fact of that change cease to have occurred.

That is why a question such as “Is there still time to stop it?” cannot be answered merely by looking at how far the Execution Process has progressed. What matters is whether the Execution Act has already occurred.

So far, we have separated only two objects within the broader concept of Execution. The next object cannot simply be placed inside that concept in the same way:

Result.

Result must also be distinguished, but its relationship to the first two objects is different. Execution Process and Execution Act are two objects that must be separated within the broader concept of Execution. Result is not a third layer of Execution. It is a separate object.

If Result is drawn after the Execution Act as though it were the act’s output, a misleading inference appears almost automatically: the act completed, therefore the result exists.

That inference is wrong, and it fails quietly. Nothing has to throw an error. Everyone may agree that the Execution Act occurred, and the words “therefore the Result is established” can still slip into the reasoning without ever having been justified.

Result Does Not Sit Downstream of the Act

Result is independent of the Execution Act.

Here, independent does not mean that a result may occasionally differ from what was expected, nor is this a claim about system reliability.

It means something more basic:

The occurrence of an Execution Act is not, by itself, sufficient to establish a Result.

The fact that an action occurred does not by itself tell us whether the result has formed, whether what formed is the result currently being asked about, or whether that result counts as established in the relevant context. None of those questions can be answered merely by pointing to the fact that the action occurred.

Engineering intuition tends to connect the two. When a system behaves normally, the act and the result often appear together, and the reasoning gradually becomes automatic: the act completed, therefore the result holds.

But a familiar inference is not an established relation.

Once Result is separated from the Execution Act, several states that initially sound awkward become perfectly expressible.

The act may have occurred while the result remains unknown.

A result may be present while there is not yet enough information to establish its correspondence to that act.

A result may even exist when the act in question did not occur at all. If the same part of reality can be affected by multiple subjects or systems, there is nothing contradictory about that possibility.

These statements sound unusual only because ordinary engineering language has long compressed action and result into a single idea.

Result also cannot be replaced by the objects that happen to sit closest to it in an operational system.

Systems readily produce things that look almost result-like: a commit record, a successful return, an external receipt. These are often available earlier than the result itself, and they may be formally complete—with timestamps, signatures, database records, and fields suitable for reporting.

If the question is merely, “Do we have something showing that execution occurred?”, these objects are easy to use as answers. But what each one can establish depends on what that object actually represents. Its existence does not, by itself, substitute for Result.

Figure 2-1. The Distinction Within Execution and the Independent Position of Result

The figure presents three separate object domains: Execution Process, Execution Act, and Result. Result is placed alongside the Execution Act without an arrow connecting the two; it is not drawn as an output or endpoint of the act. The other half of the figure contains six objects—Commit, Invocation, Execution State, Receipt, Result, and Evidence—connected only by the symbol “≠”. There are no directional arrows, no implied sequence, and no swimlanes.

Six Objects That Must Not Be Treated as Equivalent

At this point, the most important negative distinction can be stated directly:

Commit
≠ Invocation
≠ Execution State
≠ Receipt
≠ Result
≠ Evidence

The purpose here is not to give each term a complete formal definition. It is simply to make clear what these words ordinarily refer to in engineering practice. Otherwise, the inequality signs would amount to little more than notation.

The point that matters is this: because these objects appear along the same execution path, they must not be assumed to be the same object.

A Commit ordinarily means that something has been accepted, recorded, or made definite within a system. In some systems, later processing begins automatically once a commit occurs, which makes it easy to treat the commit as evidence that the real-world action has already begun. But what a commit establishes first is that the system has accepted and recorded something. It does not, by itself, establish that reality has changed.

An Invocation ordinarily means that a request has been sent to the party or component expected to carry it out. The request being sent, the recipient receiving it, and the recipient actually performing the action are separate facts that may each hold independently. What a successful return code establishes depends on the semantics of the interface. The word success alone cannot guarantee that the corresponding real-world action occurred.

An Execution State is ordinarily the system’s representation of the current status of an execution. A state marked completed does not inherently mean that the corresponding real-world change has been completed. The state may reflect an actual action, but it may also result from a timeout, a default rule, or some other state-transition logic.

There is another state that is especially easy to erase:

unknown.

Unknown cannot be interpreted as success merely because it is inconvenient to handle.

A Receipt is a statement from an external source about what that source claims to have received, processed, or returned. The difficulty is that the meaning of processed still depends on the external system’s own semantics. It may mean only that a request was queued. It may mean that some internal step completed. Even a receipt that is well formed, signed, and successfully verified therefore cannot, by itself, substitute for Result.

Result answers a different question from any of these objects. A Commit tells us what a system accepted or recorded. An Invocation tells us what request was sent. A Receipt tells us what an external party claims occurred. Each may contribute information toward determining a Result, but none becomes the Result merely by existing.

Evidence is a verifiable record that supports facts about intent, decision, execution, denial, recovery, result, or related events. The record and the fact it records remain different objects. No amount of documentation can cause an event that never occurred to have occurred; conversely, an event that did occur does not become nonexistent merely because a record of it is missing.

This chapter does not yet address where Evidence sits within the causal chain or how it participates in subsequent judgments. Only one distinction is required here:

Evidence must not be treated as identical to the object or fact it records.

Return now to the shutdown scenario from the beginning of the chapter. Each person’s use of the word executed can now be attached to a different object. One was referring to the Commit. Another to the Invocation. Another to the Execution State. Another to the Receipt. Only the person who went to the site was directly observing the Result.

This is not a matter of one person being more rigorous than the others. Each role had access to a different object, and each person was using the object available to them to answer a question that was ultimately about Result.

Such substitutions do not necessarily arise from carelessness. Commit, Invocation, Execution State, Receipt, and Evidence usually have explicit system representations. They have status fields, return values, records, timestamps, and places in logs and reports.

Result is different. Whether it can be established directly from those objects depends on the system and on what result is actually being asked about. Additional observation or judgment may be required. When discussion remains confined to the objects that are already available, the object nearest to Result is easily mistaken for Result itself.

One shorter distinction is therefore worth retaining:

Execution Act ≠ Execution State ≠ Receipt ≠ Evidence

The Execution Act refers to an action in the world. Execution State is the system’s representation of what is happening. Receipt is an external source’s statement about what happened. Evidence is a record supporting claims about relevant facts.

They may all concern the same event, but they occupy different positions and cannot substitute for one another.

They Are Not Six Stages

At this point, a natural interpretation presents itself: arrange the six objects into a pipeline—Commit, then Invocation, then an Execution State update, then Receipt, then Result, and finally Evidence. The sequence reads smoothly, and it produces a tidy diagram.

But the inequality establishes no such order.

It says only that the six objects must not be treated as equivalent by default.

Reading them as stages adds another relationship that has not yet been established: once one stage is present, the next should follow; if one object is missing, the process must have broken at that point.

The inequality says none of this.

A Receipt may arrive before an Execution State is updated, or no Receipt may appear at all. Evidence may be produced from the beginning of the process, or it may cover only part of what occurred. A Result may already exist even though no corresponding Commit record exists on the originating side.

Placing the six objects into a fixed sequence in advance would rule out states that are otherwise entirely possible.

A stage model introduces another, subtler inference as well. It encourages us to assume that if an object later in the sequence is established, the objects earlier in the sequence must also have been established.

This resembles the inference removed in the previous chapter. There, the reasoning was horizontal: each local determination holds, therefore the whole is correct. Here, the reasoning becomes sequential: a later object is present, therefore the earlier objects must also hold.

Both arguments contain an extra inferential step.

Neither step has been established.

There is a simple test.

Reverse the order:

Evidence
≠ Result
≠ Receipt
≠ Execution State
≠ Invocation
≠ Commit

The meaning of the statement does not change.

If the objects can be reordered while the claim remains intact, then the claim is not describing a sequence of stages.

None of this means that relationships among these objects cannot exist. Engineering systems routinely establish such relationships. An Invocation may be associated with a particular Commit. A Receipt may correspond to a particular request. Evidence may record a particular action or Result.

But those relationships have to be established.

They cannot be inferred merely from the fact that the objects coexist within the same system or execution context.

At this point, the inequality requires us to accept only one thing:

they are different objects.

The Distinction Is an Adjudication, Not a Discovery

The distinctions introduced above require one further clarification: how did this structure acquire its status?

In the earlier development of this theory, the word execution was used at different times to refer to process, decision, action, and result. Those earlier uses do not need to be rewritten to conform to the distinctions adopted here. They arose in different contexts and were answering different questions.

Separating these objects now does not mean that the earlier language was wrong. What has changed is the question being asked. Once the inquiry becomes Where does the deviation occur?, the broader and previously sufficient use of execution is no longer precise enough.

The structure introduced here is therefore not a pre-existing consensus discovered in earlier usage.

It is a theoretical adjudication made by this book.

That adjudication is constrained by the objects and boundaries established so far, but it does not claim that people had always understood execution in exactly this way and simply failed to state the distinction explicitly.

The distinction now has to pass a practical test. Does it allow us to ask Where does the deviation occur? more precisely? Does it allow people in different engineering roles to say what object they mean when they report that something “executed”? Does it turn previously ambiguous states into states that can be discussed separately?

If it cannot do those things, then the distinction has not fulfilled the purpose for which it was introduced.

Treating an adjudication as a discovery would create an unnecessary conclusion: that every use of execution that does not adopt this structure must therefore be wrong.

That is not the claim.

Broader uses of execution can remain entirely appropriate in other contexts. For the problem examined in this book, however, the term needs to be separated into more precise objects.

The distinction itself does not establish that any particular execution was correct, nor does it explain why a deviation occurred.

Its role is more limited:

to give us a set of objects that can be identified and discussed separately.

Result Still Contains an Unresolved Question

There is still an unresolved question on the Result side.

When we ask, “What was the result?”, we may in fact be asking about different things. A technical result returned by an executor or external system is one kind of object. The state that has actually come to exist outside the system—or that can be observed there—is another. In a business context, the question changes again. Whether the money should count as paid, or whether the shutdown should count as complete, may not be answerable from either the technical return or the external state alone.

For convenience, these can be referred to as Technical Result, External State, and Business Result.

What relationship holds among them, however, has not been formally settled.

There is not yet sufficient basis to say that one contains another, that one establishes another, or that the three belong to a single ordered hierarchy. This book therefore does not impose a tidy structure on them here.

That restraint is not merely a matter of presentation. The moment several objects are placed side by side in the same row, table, or level of a diagram, readers naturally begin to infer a relationship: that the objects are directly comparable, occupy equivalent positions, or belong to the same layer.

None of those relationships has yet been established.

That does not make the question unimportant.

In a concrete system, asking “What was the result of this execution?” may require several different answers. What did the system return? What actually happened in the world? And, in the relevant business context, does what happened count as the outcome that matters?

Those questions may produce different answers. They may also depend on different forms of observation and different time scales.

Recognizing those differences is one thing. Defining a formal hierarchy among them is another.

This book does not take that second step here. A reliable hierarchy would require additional formal work. Imposing a complete-looking structure before the evidence supports it would only cause later arguments to rest on a premise that has not itself been established.

This unresolved point does not prevent the argument of this chapter from holding.

Result can remain independent of the Execution Act even while the internal structure of Result remains unresolved.

So Where Does the Deviation Occur?

What we have at this point is not an answer to the question of where the deviation occurs. What we have is a set of objects that can now be identified separately.

Execution is the broader concept. Execution Process and Execution Act must be distinguished within it. Result is a separate object: it is not automatically established by the occurrence of an Execution Act, nor can it be replaced by Commit, Invocation, or Receipt.

Commit, Invocation, Execution State, Receipt, Result, and Evidence are distinct objects. Nor do they constitute six stages that must occur in sequence.

With those distinctions in place, the question left by the previous chapter can finally be asked more precisely.

Chapter 1 began with a simple puzzle: every local determination may hold, yet the result can still be wrong. We can now see that the “local determinations” on the execution side are themselves more numerous than they first appeared. A Commit may hold. An Invocation may have succeeded. An Execution State may be valid within the system that reports it. A Receipt may exist. The associated records may all withstand inspection.

And the Result being asked about may still fail to correspond to those established objects.

At that point, the problem can no longer be reduced to the claim that one particular object must be wrong. Each object may hold within its own scope, while the deviation remains.

The question is therefore sharper than it was before:

If each object holds within its own scope, where does the deviation occur?

---

Chapter Terms

• Execution
• Execution Process
• Execution Act
• Commit
• Invocation
• Execution State
• Receipt
• Result
• Evidence
• Technical Result
• External State
• Business Result

Scenario and Sources

This chapter does not use a real-world case.

The equipment-shutdown scenario at the beginning of the chapter is a hypothetical engineering scenario used to distinguish Commit, Invocation, Execution State, Receipt, and Result.

It does not refer to any particular company, product, incident, or publicly documented event. No external case source is therefore required for that scenario.

---

---

Chapter 3 | The Deviation Is Not at a Single Point

This chapter changes the diagnostic question from “Which component failed?” to “Which relationship between objects failed to remain intact?” Transformation, temporal gap, seam, and relation are not four new mechanism categories. They point toward the same analytical location: two objects may each hold within their own scope without thereby guaranteeing that the meaning, conditions, or correspondence that should connect them still holds. More logs, finer-grained components, and denser observation can reveal more about what happened inside individual objects, but they do not automatically expose a break between objects. Seventeen verified real-world failures provide empirical context: multiple analytical dimensions can be rated Strong within the same incident, and the failures do not consistently collapse into a single point of failure. These cases are not proof of the theory. Components still fail; the relational view is meant to address what component-level inspection can leave unexplained. That leads to the next question: which relationships can fail?

The previous chapter separated the word executed into a set of objects that can be identified independently: Commit, Invocation, Execution State, Receipt, Result, and Evidence. They must not be treated as interchangeable.

That creates a more difficult problem.

A Commit may hold. An Invocation may have succeeded. An Execution State may hold within the system that reports it. A Receipt may exist. The associated records may all withstand inspection. Yet when each object is examined separately, there may be no clearly defective object to point to.

And the deviation may already have occurred.

Consider a post-incident review. Different parts of the system produce their own records: what input was received upstream, which rule was applied, what was handed downstream, and what state the system recorded. Each body of evidence may be internally consistent. Taken together, the records may even appear to cover the entire process.

And yet the final Result still does not correspond.

At that point, decomposing the existing objects into ever smaller units does not automatically solve the problem. More logs, smaller components, and denser observation points may tell us more about what happened inside each object. They do not necessarily answer a different question:

If these objects each hold within their own scope, where does the deviation occur?

“Which Component Failed?” Already Narrows the Search Space

Engineering diagnosis naturally begins with components. We list services, modules, instances, or nodes and then check them one by one to determine whether each is operating as expected.

That approach contains an implicit assumption: the deviation should be locatable inside one of those components. The checklist is therefore a checklist of components, the search space is the set of components, and the investigation ultimately aims to identify a particular object that failed.

There are, of course, many cases in which that assumption is exactly right. A service can go down. A piece of code can take the wrong branch. A configuration can be incorrect. Failures of this kind can often be found by following component boundaries.

The difficulty is that the system itself reinforces the same way of searching. Code, services, monitoring, and logs are usually organized around components that have already been defined. Those components have names and boundaries, and they can be inspected individually. When we ask, “Where did something go wrong?”, the first things that come into view are therefore the objects the system has already made visible.

The kind of post-incident review described at the beginning of this chapter is partly a consequence of that structure.

Each body of evidence may accurately describe what happened inside its own component: what input arrived, what processing occurred, and what output was produced. When all of those records are assembled, they can appear to cover the system end to end.

But what they actually cover is still a collection of separately defined objects.

What happened between those objects does not become visible merely because the internal record of each object is complete.

The difficulty becomes apparent when every item on the component checklist has been examined and no component failure is sufficient to explain the result.

The most natural response is then to increase resolution: split components into smaller units, add more logging, add tracing, and increase observation density. These steps may produce more information. But they still preserve the same underlying assumption—that the problem must exist inside some object and that we simply have not examined that object closely enough.

If what is missing lies in a relationship between objects, adding more detail inside the objects will not automatically make that relationship visible.

Once the component checklist has been exhausted without finding a failure sufficient to explain the result, what needs to be reconsidered is not only the resolution of the investigation.

The original question may need to change as well.

Four Terms Point to the Same Place

The idea can be stated compactly:

The Gap lies in transformations, temporal gaps, seams, and relationships—not only in single-point failures.

The first thing to make clear is that these are not four categories.

Transformation, temporal gap, seam, and relation are not four kinds of defect, nor are they four mechanisms to be checked off one by one. Turning them into a classification table would merely replace the component checklist with a different checklist. The investigation would still be searching for a single box to circle.

These terms are being used to point to a location.

They direct attention away from what happens inside individual objects and toward what must remain true betweenthem.

Transformation makes this location especially easy to see. When one object is expressed as another, the two ends do not necessarily share the same representation, completeness criteria, or concerns. What the upstream side considers fully expressed may have no place to be represented downstream. What the downstream side considers fully received may be only the portion it is capable of representing.

A transformation can therefore lose something even when both endpoints remain valid within their own scope.

The loss need not appear as an obvious error. A judgment may originally carry conditions under which it holds, while the next system accepts only a binary yes or no. The conditions remain upstream while the conclusion continues downstream. Each side may still pass its own checks, even though what was required to preserve the same meaning across the transformation did not cross intact.

A seam makes the same location visible in a different way.

Two internally complete parts do not make their point of connection automatically belong to either side. Each side can be checked all the way to its own boundary without thereby establishing that the connection beyond that boundary still holds.

In systems organized around component boundaries, seams are particularly easy to lose from view. An architecture diagram can draw two boxes and a line between them. But the conditions represented by that line do not become valid merely because both boxes are valid independently.

A temporal gap removes the problem from a purely spatial picture.

A judgment may hold at one point in time while the real-world action occurs at another. The elapsed time belongs neither to the earlier judgment nor to the later action as an internal property. The judgment may have been valid when it was made, and the action may be formally valid when it occurs, while the facts and conditions that once made the two correspond may have changed in between.

The issue is not simply that events happened in the wrong order. It is that a judgment that held at one moment continued to be treated as though the facts supporting it were timeless.

Transformation, seam, and temporal gap therefore do not form three mechanism categories. They simply make the same analytical location easier to see: between two objects that each hold within their own scope, something required to preserve meaning, conditions, or correspondence may still fall outside the internal checks of either object.

Relation, in this chapter, points to that same location. It does not introduce a new taxonomic layer, nor is it a formal object waiting to be registered, numbered, or given its own internal structure.

Internally Valid, Broken Between

“The deviation is not at a single point” is a negative claim. It is easy to complete it too quickly: then it must be at some other point.

That interpretation changes nothing. We would merely move from one box to another, still searching for the object that is really broken.

That is not what this chapter is proposing.

Consider the structure visually.

Figure 3-1. Each Object Holds Internally; the Break Occurs Between Objects

Each box represents an object that holds under its own rules and within its own scope. Every break marker is placed between objects rather than inside them. The locations and number of breaks shown are illustrative only: they do not imply that breaks can occur only at those positions, nor that a deviation must contain only one break. The relationship line spanning non-adjacent endpoints indicates that a relationship that must remain intact may also exist across intermediate objects—and that such a relationship can fail as well.

If every box can stand on its own terms, further inspection inside the boxes does not automatically explain why the connections between them failed to remain intact. At that point, the objects themselves are no longer the only things that require examination. So do the connections that were required to hold between them.

That is why every break marker in the figure sits outside the boxes.

The internal validity shown inside each box is not a concession. It is the premise of the chapter.

The situation examined here is not simply one in which some component has already failed and the failure has not yet been discovered. Such failures certainly exist. This chapter is concerned with a different case: the individual objects hold within their own scope and withstand separate verification, while the final Result still deviates.

The two problems require different targets of investigation. In the first, diagnosis can continue inward, into the component. In the second, attention has to move between objects.

The relationships that must hold are not limited to adjacent objects. A commitment and a final Result may be separated by several intermediate objects. Every intermediate object may hold independently without thereby establishing that the two endpoints still preserve the same meaning.

Time can alter that relationship further. Facts and conditions may change between the two endpoints, and those changes do not belong to the internal validity of either endpoint.

The multiple break markers in the figure serve only to prevent another misreading: a single deviation does not necessarily reduce to one unique break.

If we assume in advance that there must always be one decisive fault location, we have simply returned to the single-point model.

The chapter’s position can now be stated precisely:

The deviation is not confined to a single point. The Gap lies in transformations, temporal gaps, seams, and relationships—not only in single-point failures.

Change the Target of Localization

If the argument so far holds, then locating a deviation requires more than searching at greater depth. It requires changing what we are searching for.

“Which component failed?” directs the investigation toward an object whose boundary has already been drawn. “Which relationship failed?” directs it toward something different: the conditions that were required to remain true between two objects but were not independently guaranteed by either endpoint.

The two questions define different search spaces.

Components have already been separated by the system. They have names and boundaries, and they usually expose their own states, logs, and points of observation. Checking them one by one therefore produces a relatively well-defined set of places to inspect.

Connections between objects are not necessarily registered in the same way. Two endpoints may be precisely identifiable while the conditions that must remain true between them have never been made into an equally explicit place that can be inspected directly.

The evidence required for diagnosis changes accordingly.

When examining a component, we can inspect its own state: Did it report an error? Did it time out? What did it return?

Examining what lies between objects requires different questions. Did what held in the first object still hold when it entered the next? Were the facts on which a judgment depended still valid when the action occurred? Do the two endpoints still refer to the same thing?

Those questions cannot be answered automatically from the internal records of the two endpoints. Complete records may tell us a great deal about what happened inside each object. They do not thereby establish that the required relationship between those objects was also verified.

The previous chapter already left us with one example of this distinction:

The occurrence of an Execution Act is not, by itself, sufficient to establish a Result.

That does not mean this book has defined a formal “relationship object” between Execution Act and Result. It means only that the fact that the act occurred cannot substitute for determining the Result itself. Both endpoints may hold independently, and that still does not establish the correspondence required between them.

“Which relationship failed?” is therefore a method of localization. It directs attention toward the conditions that had to remain true between objects, rather than continuing to assume that every deviation can ultimately be compressed back into the interior of a component.

This book does not register Relation as a new formal concept, nor does it assign Relation an identifier or a fixed internal structure.

Here, relation names a location, not an identity.

If we turn it back into another object with its own fixed internal structure, we risk recreating the original problem under a new name.

Seventeen Verified Real-World Failures

So far, the argument has remained a claim about location. Real-world evidence cannot prove that claim. What it can do is provide a different kind of pressure: we can ask whether failures that have actually occurred repeatedly display the same kind of distribution.

The current research corpus contains seventeen fact-verified real-world failures. Each case is supported by official, primary, judicial, or regulatory sources and has been analyzed against the same set of relational dimensions.

This chapter uses only one aggregate observation from that corpus.

Within these seventeen cases, multiple dimensions can be rated Strong in the same failure. Two dimensions are Strong in all seventeen cases; two others are Strong in eleven and thirteen cases, respectively. None of the seventeen cases can be fully explained by a single component failure alone.

What matters in this distribution is not which dimension appears most often.

What matters is that multiple dimensions can be Strong within the same failure.

At least within these seventeen verified cases, failure does not consistently collapse into one unique break point.

That is as far as the numbers go.

They do not assign each case to one unique break. Strong, Partial, and None are not severity rankings, nor are they a way to select the “most important” cause from several candidates. The fact that multiple dimensions can be Strong in the same case is itself a reason not to read the material through a single-point classification model.

The cases also do not establish that the current structure is complete. They show only that, within the present corpus, no evidence has yet required an additional structural level.

More importantly, these seventeen cases are not proof of the theory.

Their role here is empirical context. They allow the claim that deviation need not reduce to a single point to be seen not only as an abstract argument, but also as a recurring distribution across a set of verified real-world failures.

What these dimensions should ultimately be called, where their boundaries should be drawn, and how they relate to one another are questions this chapter deliberately leaves unanswered.

Components Still Fail

One overreading has to be ruled out explicitly: shifting attention toward what happens between objects does not make the components themselves unimportant.

Single-point failures are real. Disks fail. Services go down. Code can take the wrong branch. Configurations can be wrong. Redundancy, retries, circuit breakers, rollback, and related engineering techniques exist precisely because these failures occur.

The important words in the chapter’s central claim are therefore not only:

the Gap lies in transformations, temporal gaps, seams, and relationships—not only in single-point failures.

What this rejects is a default assumption: whenever a deviation occurs, there must be some failure inside a component that is sufficient to explain the entire result.

It does not deny that components fail. Nor does it reject the reliability engineering built around component failures.

The two kinds of problem are not mutually exclusive. A component may genuinely fail while a relationship that needed to remain intact between objects also fails. Finding a broken component may explain part of what happened without thereby establishing that the entire Result has been explained.

What changes is the step that comes after component-level diagnosis.

If a component failure has been found, address the component failure. But if the components hold one by one and the remaining deviation is still unexplained, continuing to decompose those objects into finer internal detail is not enough.

At that point, attention has to move between the objects—to the relationships that are not covered by the internal validity of the components themselves.

So Which Relationships Can Fail?

Once attention moves from what happens inside objects to what must hold between them, at least one thing becomes clear.

If the individual objects each hold within their own scope and the remaining deviation is still unexplained, localization can no longer default to the interior of a component. Transformation, temporal gap, seam, and relation all point toward the same place: what had to remain true between objects.

But knowing where to look is not the same as knowing what to inspect.

The word relationship is still too broad. Two objects in a system may be connected in many different ways. Without a further boundary, almost any pair of objects could become a candidate for investigation. The original problem of decomposing endlessly into finer internal detail would simply be replaced by a new problem: expanding endlessly across possible connections.

A location judgment can therefore tell us where to direct attention, but not where the search should stop.

Nor can the problem be solved by constructing the longest possible list of connections. Linking every object to every other plausible object only produces more candidate relationships. Unless we know which of those relationships actually carry conditions that are necessary to the execution process, the list itself provides no boundary.

That is the next question the argument has to answer:

Which relationships can fail?

---

Chapter Terms

• Transformation
• Temporal Gap
• Seam
• Relation
• Single-Point Vulnerability
• Single-Point Failure
• Internal Validity

Cases and Sources

Pool of Seventeen Verified Cases

This chapter draws on the first two formal case pools assembled during the research for The Execution Gap: seventeen fact-verified real-world failures. The facts of each case were checked against official documents, primary materials, judicial records, or regulatory sources.

These cases serve as case-pool-level empirical context, not as proof of the chapter’s theoretical claims. Nor does this chapter assign any individual case uniquely to a particular type of relationship. It uses only one aggregate observation from the case pool: within a single verified case, multiple analytical dimensions can simultaneously be rated Strong. Two dimensions are Strong in all seventeen cases, while two others are Strong in eleven and thirteen cases, respectively.

This distribution supports only a limited conclusion: within this verified body of material, multiple dimensions can appear in the same failure. It does not represent the statistical frequency of real-world failures as a whole. Strong, Partial, and None are not severity rankings. Nor can this case pool establish that the current structure exhausts all possible relationships or mechanisms.

Full Case Documentation

The body of this chapter does not examine the seventeen cases individually, nor does it reclassify them here.

Full documentation for all seventeen cases appears in the appendix **“Real-World Failures and Boundary Cases,”**under “Pool of Seventeen Verified Cases.” Each case entry includes:

• the case name and date of the event;
• a factual summary of what occurred;
• the reason the case falls within the scope of this book’s research;
• where and how the case is used in the book;
• the principal official, primary, judicial, or regulatory sources; and
• any necessary evidentiary limitations, disputes, or boundaries of applicability.

Readers can use that appendix to identify the specific events referred to in this chapter as the “seventeen verified cases” and to examine the factual basis for each one.

Sources

The body of this chapter relies on case-pool-level aggregate findings from the seventeen cases. Individual factual sources and complete bibliographic information are not repeated here. They are consolidated in the appendix “Real-World Failures and Boundary Cases” and in the book-wide “References and Sources.”

---

---

Chapter 4 | Five Ways Relationships Can Fail

This chapter narrows the question “Which relationships can fail?” into five Direct Mechanism Families: Decision / Binding Relation Failure, Execution Path Deviation, Execution Boundary Failure, Execution State / Result Relation Failure, and In-Causal-Chain Evidence / Proof Relation Failure. These are neither five mutually exclusive labels nor formally numbered mechanisms. They are a conditionally frozen top-level structure under the current evidence: the structure must be reopened if one family can be absorbed into another without loss, or if a new mechanism emerges with its own object, its own causal position, and repeated support across cases. Each family identifies a structural position through which a deviation can retain the conditions needed to reach the real world. Boundary Mutation is only a strong subtype of Execution Boundary Failure, not a synonym for it; Evidence belongs to the fifth family only when it enters the causal chain of a current or subsequent action. Change and Amplification play different analytical roles and are not sixth or seventh Direct Mechanism Families.

The previous chapter changed the target of localization from “Which component failed?” to “Which relationship failed?”

That change altered the search space. Diagnosis no longer assumes that every deviation must ultimately be located inside a component. When individual objects hold within their own scope, the relationships that were required to remain intact between them also become legitimate targets of investigation.

But that immediately creates another problem: the word relationship does not, by itself, tell us what to inspect.

A single incident can contain many identifiable relationships. There is a relationship between an initiator and an approver, between an approval and a payment amount, between a configuration file and the program that interprets it, between a control-room indicator and the physical position of a valve, and between the parameters of an operational command and the capacity that command will affect.

If asking “Which relationship failed?” simply means listing every such relationship and checking them one by one, then we have not really solved the problem left by the previous chapter. We have only replaced a component checklist with a relationship checklist. Some connection can almost always be identified between two objects in a system; without a further boundary, the number of candidate relationships can continue to grow and the search has no natural stopping point.

To turn “Which relationship failed?” from a statement about location into a usable method of localization, the question has to be narrowed further.

Not every change in a relationship explains how a deviation ultimately reaches the real world. The more precise question is:

What kind of structural failure allows a deviation to reach the real world?

The current research answers that question through five Direct Mechanism Families.

Five Locations

The current research narrows these structural failures into five Direct Mechanism Families:

Decision / Binding Relation Failure, Execution Path Deviation, Execution Boundary Failure, Execution State / Result Relation Failure, and In-Causal-Chain Evidence / Proof Relation Failure.

Before examining them individually, their limits of use need to be clear.

First, these are not five formally numbered mechanisms, nor are they a classification table into which each case can simply be placed. This book does not assign them mechanism numbers. Numbering would suggest a degree of formal independence and permanent closure that the current research does not establish.

Second, this chapter does not use the five families as mutually exclusive categories. Whether a particular failure must belong to only one family or may occupy several is a separate question, and this chapter does not answer it.

Third, the five families are currently Conditionally Frozen.

Conditionally Frozen means that, within the present evidence, the structure is stable enough to support analysis and localization while remaining subject to explicit reopening conditions. Two developments would require it to be reconsidered. One would be a family that can be absorbed into another without loss and therefore no longer requires independent standing. The other would be the emergence of a new failure mechanism with its own object, its own causal position, and repeated support across multiple cases.

Conditionally Frozen therefore means neither final and permanently closed nor still unresolved. It identifies a bounded research state: the current evidence does not require another top-level mechanism family, but sufficiently strong new evidence could reopen that conclusion.

The purpose of the five families is equally limited.

They do not explain why an incident ultimately occurred, nor do they substitute for judgments about responsibility. They answer a narrower question:

Through what structural position did a deviation retain the conditions needed to continue into the real world?

The broad question “Which relationship failed?” can now be narrowed into more specific inquiries. Did an established judgment remain bound to the current action? Did the actual execution remain on the path that was supposed to hold? Did the boundary that constrained an action from reaching the real world fail? Did a local state continue to correspond to the final Result? Did Evidence participating in a current or subsequent action retain the qualification and connections on which its role depended?

Why these five families rather than some other set?

The distinction was not produced by drawing a classification table first and then fitting cases into it. It emerged from repeatedly asking two questions of real-world failures: Which necessary correspondence failed to hold, and where in the execution chain did that failure occur?

The next five sections examine the families in turn. Each addresses only three things: the family’s minimum meaning, the forms in which it typically appears in real systems, and the cases that explicitly fall outside its boundary.

What Was Established Did Not Carry Through

Decision / Binding Relation Failure asks whether an already established intent, decision, approval, authorization, policy, or qualification remains appropriately bound to the object, parameters, target, state, semantics, source, or scope of the action now being executed.

The issue is not whether the upstream object ever existed. It may be entirely real and may hold fully within its own scope. The break occurs when that object continues downstream as a constraint on the current action, but the binding that was required to preserve its meaning or applicability has been lost.

This can happen in many forms. An old qualification may continue to be used for a new object. Approved content may no longer be bound to the payload actually executed. A judgment may rely on an incomplete set of sources. A local authorization may be carried forward as though it were sufficient qualification for final execution. Each endpoint may still hold when examined independently; what has failed is the correspondence that was required to remain intact between them.

The August 2020 Citibank–Revlon mistaken payment provides a clear example. Citibank intended to process approximately $7.8 million in interest while performing internal accounting associated with a restructuring of the loan. In Flexcube, the transaction had to be entered as a full repayment while the principal was retained through an internal wash account. The operator needed to select three interface options but selected only one, and two reviewers failed to detect the discrepancy. The system then acted on the fields that had been entered and transferred nearly $1 billion of Citibank’s own funds to the lenders.

There was no absence of a genuine business intent, nor was there an absence of actual review. The problem was that the workflow being reviewed and approved did not remain fully bound to the business meaning expressed by the final destination and amount of the funds. Reducing the incident to “someone clicked the wrong button” would miss the more important structure: the wash-account arrangement, the three interface options, and two levels of review were all present, yet together they did not ensure that the object ultimately executed was still the object the upstream process was meant to constrain.

Storm-0558 shows the same kind of break in a very different technical structure. The attackers used a genuine Microsoft 2016 MSA consumer signing key, and tokens signed with that key could pass cryptographic verification. The failure was that Exchange Online’s validation logic did not reject tokens signed by a consumer key when those tokens were used to access enterprise accounts.

A valid signature establishes the cryptographic relationship between a token and the key that signed it. It does not, by itself, establish that the key was qualified for the relevant tenant, account, and point in time. The incident was ultimately determined to have affected 22 organizations and 503 related individual accounts. How the attackers obtained the key remained unresolved when the relevant reviews were completed, and this book does not fill that gap with earlier hypotheses.

The same structure can appear in systems that look nothing alike.

In the Mars Climate Orbiter mission, ground navigation data contained a unit mismatch. A set of values could be received normally, processed normally, and passed downstream normally while no longer representing the physical quantity that the receiving side believed those values represented.

Ariane 5 Flight 501 presents another form. Reused software carried assumptions from its original design environment into a new operating envelope, while the test evidence supporting that reuse did not cover the conditions the actual system encountered. The object that had been established remained real; its scope of validity did not automatically expand with the new execution environment.

The two Boeing 737 MAX accidents likewise exposed a mismatch between the qualification of a factual source and the control authority subsequently placed on that source. An input source was given a control role beyond the range that its qualification was sufficient to support. The mere presence of two sensors in the system did not, by itself, establish independent and orthogonal validation. The two accidents shared this structural feature, but that does not make their complete causal chains identical.

The boundary of this family matters just as much as its positive meaning.

First, Decision / Binding Relation Failure does not require a change in execution path. A payment can move through the normal payment system. A token can travel through the normal validation flow. Data can continue through the normal processing chain. A path can remain entirely normal while the current action has ceased to be properly bound to the upstream object that was supposed to constrain it.

A second boundary is even more important:

An upstream decision that is normatively wrong but faithfully executed by the system does not become an Execution Gap merely because the outcome is bad.

If an already formed decision is legally, normatively, or judgmentally defective and the system subsequently executes that decision accurately, the upstream decision itself has to be distinguished first. The correspondence between decision and execution may, in fact, have remained intact.

This limitation does not excuse a bad outcome. Its purpose is to preserve the family’s ability to locate the failure. If every undesirable result can be redescribed after the fact as a binding failure, the concept can no longer distinguish between an upstream object that was itself defective and an established upstream object that failed to continue constraining the same thing as it entered execution.

Across the seventeen fact-verified cases in the current corpus, this dimension is rated Strong in all seventeen. That figure is used here only as an empirical distribution within the present case pool. It does not establish an importance, priority, or stability ranking among the five Direct Mechanism Families.

How Did This Execution Actually Proceed?

Execution Path Deviation is not concerned primarily with what the action ultimately accomplished. It asks a different question:

How did this execution actually get there?

Here, path has a specific meaning. Execution Path Deviation occurs when the steps, order, actor, entry point, or chain through which execution actually proceeds diverge from the execution process that was supposed to hold. A necessary step may be skipped. A new step may be inserted. The order may be rearranged. An old action may be replayed. One actor may be substituted for another. Execution may enter through an alternative entry point. Several tools that are individually legitimate may also be composed into an execution chain that, as a whole, was never authorized.

The important question is not how many steps the process contains.

It is whether the execution chain that actually occurred is no longer the chain that was supposed to occur.

The 2012 Knight Capital incident provides a clear example.

New code was deployed to eight servers, but one server was missed. At the same time, a retired Power Peg flag had been reused for new functionality. When orders reached the server that had not received the deployment, they triggered the legacy logic rather than the intended new logic.

The new code did not simply calculate the wrong answer. The expected path and the actual path diverged: the same kind of incoming order entered different execution chains depending on which server handled it.

A second path deviation appeared during the response to the incident. In an attempt to stop the abnormal trading, operators removed the new code from the seven servers on which it had been running correctly. The result was that the legacy path, which had previously remained exposed on only one server, became reachable on additional nodes. An intervention intended to contain the incident changed which paths the system could subsequently take.

SolarWinds presents a different form.

A malicious step was inserted into the supplier’s own build and update process. The compromised software then reached customer environments through the normal software-distribution mechanism. Nearly 18,000 customers received the affected update, although receiving the update did not mean that every customer was subsequently exploited.

Two parts of that sequence have to be kept separate. From the customer’s perspective, the distribution process itself could proceed normally. But earlier in the chain, the build process had already acquired a step that did not belong to the intended path. Path deviation therefore cannot be located merely by asking whether the final segment of delivery followed its normal procedure.

This family is especially easy to broaden beyond usefulness, so its exclusion boundary has to remain strict.

Multiple steps do not constitute Path Deviation. A long causal chain does not constitute Path Deviation. Complex invocation does not constitute Path Deviation. And an incorrect object propagating along an entirely normal path does not constitute Path Deviation.

In the 2017 AWS S3 outage, operators used an existing playbook and normal operational tools. The problem was that an input parameter caused far more servers to be removed than intended. The execution chain did not become a different path merely because the consequences were severe.

The Citibank–Revlon mistaken payment likewise traveled through normal payment and wire-transfer systems. The failure concerned what had been bound and reviewed, not an unauthorized payment path taken by the funds afterward.

The same distinction applies to the Waymo case. The fact that a low-speed pull-over action produced the wrong final Result does not, by itself, establish that the vehicle deviated from its intended execution path.

The decisive question for this family is therefore not:

Was the process complicated?

Nor is it:

Was the final outcome severe?

It is:

Did the steps, order, actor, entry point, or execution chain that actually occurred deviate from the path that was supposed to hold?

Within the seventeen verified cases in the current corpus, this dimension is rated Strong in two cases, Partial in ten, and absent in five.

That distribution does not make Execution Path Deviation unimportant. It instead reinforces the need to keep the family narrowly scoped. If every complicated process or serious outcome is treated as Path Deviation, the concept quickly loses its ability to localize anything.

How Execution Path Deviation relates to Execution Boundary Failure is a separate question.

This chapter does not answer it.

Who Can Still Say No?

Execution Boundary Failure asks a different question: as an action approaches the real world, do the constraints that were supposed to limit it still exist, and do they still have effect?

The focus is not on which steps the request followed. It is on what happened to the constraints that were supposed to limit the action’s scope, capability, and eventual execution.

An execution boundary can fail in several ways. The constraint may never have existed in the first place. It may exist but fail to cover the action that actually creates the danger. It may have been established and yet fail to operate when the action needs to be stopped. A stronger form is also possible: the rules or enforcing parties that determine the path, capability envelope, or final power of refusal may themselves be altered.

Each of these conditions can allow an action that should not have reached the real world to continue forward. They are not, however, the same form of failure.

In the Knight Capital incident, there was no automated constraint comparing the volume of outgoing child orders with the incoming parent order. Once the legacy logic began generating child orders continuously, no separate control used the fact that the parent order had already been filled to stop further output. What this exposes first is a missing boundary, not an existing boundary that was later breached.

The 2017 AWS S3 outage shows a different form. The operational tooling allowed a single command to remove far more servers, and far more quickly, than intended. At the time, the scale of the requested removal was not bound to the minimum capacity the subsystem needed in order to remain operational. The protections added afterward—minimum-capacity safeguards, limits on removal rate, and narrower failure domains—help reveal which constraints had not covered that capability at the time of the incident.

The 2018 Hawaii false missile alert brings the same problem into operational authority. The live-alert and test templates were available through the same interface and used the same login credentials; an operator with those credentials could send a real statewide alert. Once the mistake was discovered, the cancellation action available at the time could stop further dissemination but could not retract messages already displayed on public devices, nor did it automatically issue a correction. The first correction was sent through the same channel thirty-eight minutes later.

The important point here is not the interface design by itself. Once the action had crossed the existing constraints and entered the real world, there was no additional boundary that kept it confined to a test context.

Therac-25 provides a sharper contrast. The race condition associated with the 1986 Tyler accident also existed in the earlier Therac-20, but the Therac-20’s independent hardware interlocks could prevent the hazardous beam. Similar software errors could therefore exist at the software layer while the formation of a real-world consequence still depended on whether some constraint outside that error could stop the dangerous action.

This does not mean that all six Therac-25 accidents were caused by the same race condition. The 1987 Yakima accident involved a different software defect. The case is not being used here to reduce those accidents to one bug. Its relevance is narrower: different errors can still produce consequences when the surrounding system lacks a constraint capable of preventing those errors from continuing into the real world.

The Boeing 737 MAX accidents show another form of the same boundary problem. A single input source and a control capability capable of repeated action were placed within the same execution chain, while the surrounding structure did not constrain that combination to a range insufficient to produce sustained real-world effect. The point here is the form of boundary failure, not a claim that the two accidents shared an identical causal chain.

A separate distinction is required for Boundary Mutation.

Boundary Mutation is a strong subtype of Execution Boundary Failure. It is not a synonym for Execution Boundary Failure.

Boundary Mutation occurs when the rules or enforcing parties that determine path, capability scope, or final refusal are themselves rewritten. The Knight Capital, AWS, Hawaii, and Therac-25 examples above do not require such a mutation in order to qualify as boundary failures. A boundary may be absent from the beginning, cover too little, or fail to operate when it is needed.

If every Boundary Failure is treated as Boundary Mutation, diagnosis will begin by asking, “Who changed the rule?” That would miss an equally important possibility:

nothing was rewritten; the boundary that should have constrained the dangerous action simply never covered it.

Within the seventeen verified cases in the current corpus, the Execution Boundary dimension is rated Strong in eleven cases and Partial in six. That distribution describes the evidence in the current case pool. It does not imply that all eleven Strong cases involved Boundary Mutation.

One further exclusion boundary has to remain clear.

Execution Boundary Failure concerns the failure of control rules and final refusal capability. It cannot be collapsed wholesale into Execution Path Deviation.

How many steps, nodes, or entry points a request actually traversed is a different localization question from whether an effective constraint still existed before the action reached the real world. The path may remain unchanged while the boundary fails.

Whether these two families can absorb one another in some cases, and how their boundary should ultimately be drawn, is not answered here.

This chapter addresses only how an execution boundary can fail. It does not establish the engineering conditions that an execution boundary must satisfy in order to count as properly established.

Local Completion Is Not the Real-World Result

Execution State / Result Relation Failure asks whether an Invocation, a Commit, an intermediate state, a Receipt, or even an already formed Result is still being interpreted correctly and attributed to the object it was meant to represent.

The previous chapter separated Commit, Invocation, Execution State, Receipt, and Result. Each may hold independently. The fact that one holds does not establish that another has also been established.

This family concerns failures in that correspondence.

A local success may be interpreted as end-to-end completion. An unknown state may be treated as success. A Receipt may be treated as the Result. A Result that has actually occurred may also be attributed to the wrong intent or action.

The Three Mile Island accident illustrates one form of this problem. The control-room indication primarily reflected the command to close the valve rather than the valve’s actual physical position. The fact that the command had been issued and the indication was present did not establish that the physical state had come into correspondence with either of them. The state being displayed and the state that actually existed in the world were different objects.

Knight Capital shows a different form. One part of the system already knew that the parent order had been filled, but that state did not reach the part of the system that continued sending child orders. Subsequent actions therefore continued from a premise that was no longer valid. The local state was real, but it no longer constrained the downstream execution that depended on it.

In the 2023 Cruise incident, the vehicle’s first stop did not mean that the real-world situation had reached a safe terminal state. With the pedestrian still underneath the vehicle, the subsequent pull-over maneuver showed that completion of one stage could not substitute for determining the current real-world Result.

The 2024 Waymo case makes the same distinction visible in another form. The immediate objective of a low-speed pull-over action may itself hold, but satisfaction of that action-level objective does not, by itself, establish that the final real-world Result still corresponds to it.

Within the seventeen verified cases in the current corpus, this dimension is rated Strong in all seventeen. As elsewhere in this chapter, that figure is used only as an empirical distribution within the current case pool. It does not make this family more important than the other Direct Mechanism Families.

The exclusion boundary of this family is straightforward:

Whether the relation between state and Result holds is not the same question as whether relevant Evidence exists.

The Three Mile Island indication existed. Knight Capital’s filled-order state existed. The question was not whether a record or state was present, but what that state or record actually represented—and whether it still represented the object on which subsequent judgment or execution was relying.

How Evidence itself enters a current or subsequent action belongs to the next family.

When Evidence Drives the Next Action

In-Causal-Chain Evidence / Proof Relation Failure is not about whether a system left behind a record. It asks whether some piece of Evidence is participating in a current judgment, execution, retry, recovery, or subsequent action while its relationship to source qualification, object, sequence, prior state, continuity, or real-world fact has already failed.

An incorrect factual source may acquire standing in a judgment. Expired or incomplete Evidence may continue to drive action. A broken record sequence may trigger an incorrect retry. Even a record created after one action has occurred may re-enter the next round of judgment and affect subsequent qualification or action.

Within the seventeen verified cases in the current corpus, this dimension is rated Strong in thirteen cases and Partial in four.

The 2024 CrowdStrike incident illustrates one form. The content validator operated against a contract of twenty-one inputs, while the sensor actually supplied twenty. The production interpreter subsequently accessed a nonexistent twenty-first input and crashed. The triggering event was a Rapid Response Content update, not new kernel-driver code and not a cyberattack. The fact that the content passed the existing validation and signing process did not establish that the input contract on which runtime execution actually depended had been satisfied.

The Ariane 5 test record presents a related problem. Test Evidence can support conclusions about the conditions that were actually tested. It does not automatically extend those conclusions to the different operating conditions later encountered by the real system.

Challenger shows the same distinction from another direction. Relevant engineering Evidence and objections existed, but they did not fully enter the final decision. The existence of Evidence does not, by itself, give that Evidence operative standing in the current judgment.

Knight Capital provides another form. Before the incident, the system generated ninety-seven automated “Power Peg disabled” emails. The signals existed, but they were not treated as system alerts and were not bound to any action capable of stopping subsequent execution. Their existence alone did not alter what the system went on to do.

Post Office Horizon shows how records can continue into later real-world actions. Shortfall records generated by the system were used in recovery actions, termination decisions, and prosecutions; courts later found that the system contained defects capable of causing, and in fact causing, branch-account shortfalls. Actions driven by those records produced further records, which in turn continued to influence later judgments. This does not mean that every recorded shortfall was nonexistent, nor does it collapse the different cases into one factual chain. The point used here is narrower: records acquired standing to drive real-world action.

The Cruise case makes another distinction visible. Possessing Evidence is not the same as having that Evidence fully represented in the formal judgment process. Complete video had been provided to regulators, while the legally required written report still omitted the dragging maneuver.

The most important boundary of this family is singular and strict:

Evidence belongs to this family only when it enters the causal chain of a current or subsequent real-world action.

If execution is complete, the real-world Result is already settled, and the remaining problem is only that the event cannot later be observed, proved, audited, or attributed, then that loss of proof does not, by default, belong to this Direct Mechanism Family.

The criterion is not record quality.

It is causal position.

If the missing or defective proof later produces an incorrect state assumption, retry, recovery action, or subsequent execution, however, then from the point at which it begins affecting the real world again, it re-enters this family.

Change and Amplification Answer Different Questions

The five Direct Mechanism Families introduced above all answer the same question:

What structural failure allowed a deviation to reach the real world?

Two other analytical objects are easily confused with that question: Change and Amplification.

Both matter, but neither belongs to the five Direct Mechanism Families.

Asking “What changed?” directs attention to changes in objects, states, parameters, or conditions during an incident. That question can reveal what moved or became different, but it does not by itself identify which relationship failed in a way that allowed the deviation to continue into the real world.

The distinction made in this chapter is therefore limited but important:

Change is not a sixth Direct Mechanism Family.

The same boundary applies to Amplification.

A deviation may spread farther or faster, and opportunities to stop or correct it may diminish. Those effects can alter the scale of the eventual consequences, but they do not thereby become another Direct Mechanism Family alongside Decision / Binding, Path, Boundary, State / Result, or Evidence / Proof.

Amplification is therefore not a sixth or seventh Direct Mechanism Family.

In particular, Amplification should not be understood as a stage that occurs after the deviation. It is not defined by temporal position. For the purposes of this chapter, only one boundary needs to be preserved: Amplification describes how the effect of a deviation expands; it does not identify the structural failure through which that deviation was able to reach the real world.

Adding Change and Amplification to the five families might make the structure appear more complete, but it would collapse questions that need to remain distinct.

The five Direct Mechanism Families ask where the break occurred.

Change asks what changed.

Amplification asks how an existing deviation expanded its effects.

This chapter establishes localization objects only for the first question. The other two are not developed further here.

Why the Structure Currently Stops at Five

The five Direct Mechanism Families currently rest on seventeen fact-verified real-world cases spanning aerospace, medical devices, nuclear power, trading, aviation, cloud operations, payments, public warning systems, autonomous driving, endpoint security, cloud identity, software supply chains, and judicial evidence.

That body of material does not establish that the five-family structure is complete.

It supports a narrower conclusion:

Within the current case pool, no failure has yet required an additional top-level structural mechanism in order to be explained.

During the research, at least three candidates initially appeared as though they might require a separate family.

One was Evidence feeding back into subsequent authority or qualification. This pattern appears in both Cruise and Post Office Horizon. On closer analysis, however, it can still be described through existing relationships re-entering the causal chain across multiple rounds: Evidence affects a later judgment, and that later judgment then enters a new execution. No new fundamental failure object is required.

A second candidate was qualification inherited across organizations or domains. Storm-0558 and SolarWinds both show forms in which something continues to acquire operative qualification beyond an earlier boundary, but the underlying objects are not the same. Storm-0558 involves signing, issuance domain, tenant, and account scope. SolarWinds involves supplier, release version, payload, and customer-side installation permission. When examined more closely, these failures can still be located within existing Binding, Boundary, and other established mechanism positions rather than requiring an independent new family.

The third candidate is different:

a normatively invalid decision that is correctly executed by the system.

Before this can be treated as another mechanism inside the Execution Gap, a prior question has to be answered: does that upstream decision qualify for entry into Execution Gap analysis in the first place?

That makes it primarily a qualification question at the boundary of the Execution Gap, rather than evidence that the five Direct Mechanism Families are missing another internal position.

The structure therefore stops at five for now not because a sixth family has been disproved.

The justified conclusion is narrower: within the current cases and evidence, none of these three candidates has yet formed a new mechanism with its own object, its own causal position, and repeated support across cases.

That is the constraint expressed by Conditionally Frozen.

If future evidence meets those conditions, the structure should be reopened.

Two Questions Diverge Here

At this point, the reader has five localization targets that can be used to continue the investigation.

But once those five families are brought back into real cases, they immediately produce two different questions.

The first arises between Execution Path Deviation and Execution Boundary Failure.

The Knight Capital incident exhibits both. The actual execution path diverged from the expected path, while the system also lacked a boundary capable of preventing abnormal orders from continuing into the market. The Hawaii false missile alert raises the same difficulty from another direction: the erroneous alert was faithfully carried through the real dissemination system, yet the relevant question cannot be reduced to which route the message followed.

That leaves the first question:

Is “this request took the wrong path” the same kind of failure as “the constraint itself failed”?

That is the question taken up next.

The second question concerns the five Direct Mechanism Families as a whole.

The same case can appear at several mechanism positions. Knight Capital implicates Path, Boundary, State / Result, and Evidence / Proof. The Boeing 737 MAX accidents can implicate both Decision / Binding and Boundary. In the Cruise case, the vehicle action and the later reporting chain expose different problems in State / Result and Evidence / Proof.

Chapter 4 does not explain that overlap.

It therefore leaves a second question:

Are the five families mutually exclusive? And given a specific deviation, how should it be localized among them?

That is a separate task.

The two questions must not be collapsed into one.

The first concerns the boundary between two specific mechanism families. The second concerns how the five-family structure should be used as a whole. Resolving the first does not automatically resolve the second.

Chapter 4 stops here.

Its contribution is deliberately limited: it takes the previous chapter’s overly broad question—“Which relationship failed?”—and narrows it, for the first time, into five Direct Mechanism Families that can be investigated further.

The next step is to address the pair most easily confused:

Is “this request took the wrong path” the same kind of failure as “the constraint itself failed”?

Chapter Terms

• Direct Mechanism Family
• Decision / Binding Relation Failure
• Execution Path Deviation
• Execution Boundary Failure
• Execution State / Result Relation Failure
• In-Causal-Chain Evidence / Proof Relation Failure
• Conditionally Frozen
• Change
• Amplification

Cases and Sources

Pool of Seventeen Verified Cases

This chapter continues to draw on the pool of seventeen formally verified cases assembled during the research for The Execution Gap.

Unlike the previous chapter, these cases are used here for more than case-pool-level context. They illustrate the concrete forms that the five Direct Mechanism Families can take in real-world failures. No case is assigned uniquely to one family. The same case may appear at several mechanism positions, and this chapter does not designate any single case as the definitive representative of a particular family.

Sixteen of the seventeen cases in the pool appear in the body of this chapter:

Mars Climate Orbiter, Challenger, Therac-25, Ariane 5 Flight 501, Three Mile Island, Knight Capital, Boeing 737 MAX, AWS S3, Citibank–Revlon, the 2018 Hawaii False Missile Alert, Waymo, CrowdStrike, Cruise, Storm-0558, SolarWinds, and Post Office Horizon.

These cases are used to show how failures may arise in Decision / Binding, Execution Path, Execution Boundary, State / Result, and In-Causal-Chain Evidence / Proof relationships. A case appearing at more than one mechanism position does not establish that the families are mutually exclusive, nor does it turn the five-family structure into a case-by-case classification system.

This chapter also refers to aggregate findings across all seventeen cases, including the distributions of Strong, Partial, and absent findings across the mechanism dimensions. Those distributions describe the evidence within the current case pool only. They do not rank the five families by importance, severity, or priority.

Full Case Documentation

The chapter body does not repeat the complete factual chain, verification process, or full source record for each case.

Complete documentation for all seventeen formally verified cases is consolidated in the appendix “Real-World Failures and Boundary Cases,” under “Pool of Seventeen Verified Cases.” Each entry includes the event background, a factual summary, where the case is used in this book, the principal official or primary sources, and any necessary evidentiary limitations or boundaries of applicability.

Every case used in this chapter comes from that formal case pool. The three Boundary Cases—Robodebt, Moffatt v. Air Canada Chatbot, and The DAO—are not used here to illustrate the five Direct Mechanism Families.

Sources

The real-world facts discussed in this chapter are based on the completed verification records for the corresponding cases, using official, primary, judicial, regulatory, or other authoritative materials.

Case-specific factual sources and complete bibliographic information are not repeated in the chapter body. They are consolidated in the appendix “Real-World Failures and Boundary Cases” and in the book-wide “References and Sources.”

---

Chapter 5 | Taking the Wrong Path and Being Unable to Stop It Are Not the Same Failure

This chapter draws a hard distinction between Execution Path and Execution Boundary. Path asks, “How did this request actually get there?” Boundary asks, “How far can this action go, and what can ultimately constrain or reject it?” The former concerns whether actual execution deviated from the path that was supposed to hold; the latter concerns whether the constraints themselves remained effective. An Execution Boundary is therefore not another name for access control. Real-world cases show that an erroneous Action can reach the real world along an entirely normal path, which means that Path Deviation is not a necessary condition of the Execution Gap. Boundary Mutation is likewise only a strong subtype of Boundary Failure: a boundary may be rewritten, but it may also fail without any explicit rewriting. “Taking the wrong path” and “being unable to stop the action” are therefore two independent judgments. Neither can substitute for the other.

The previous chapter ended with two questions. The first appears, at first, to be the easier one.

Path asks how a request actually traveled. Boundary asks what could have stopped it. The two can sound like different descriptions of the same event. If a request took the wrong path, was that not because something failed to stop it? And if nothing could stop it, would that not ultimately appear as the request reaching somewhere it should not have reached?

Collapsing the two would make the account simpler. It would also leave us with one fewer object to preserve.

This chapter argues that the collapse does not hold.

The temptation to merge them is strong because it matches an intuitive picture of control. We imagine a channel through which a request moves forward, with checkpoints placed along the way. When something goes wrong, it seems natural to conclude that the request passed through a point that should have stopped it. In that picture, “taking the wrong path” and “not being stopped” do look like the same event. The path is the channel; the boundary is the checkpoint; both appear to describe a single passage along the same line. Strengthen the checkpoint or narrow the channel, and the two problems seem to reduce to the same kind of engineering task.

The difficulty is that the failures examined in this book do not always take that form.

A deviation does not necessarily have to bypass a path or slip past a checkpoint. It may reach the real world through an existing, prescribed, routinely used execution path. No extra step needs to be inserted. No established process needs to be bypassed. No unauthorized route needs to be substituted. When the chain is reconstructed afterward, every step may still have a legitimate place in the original process.

If “taking the wrong path” and “being unable to stop the action” are treated as the same question, that situation produces a dangerous inference. Path analysis returns no deviation, and the control analysis is then allowed to inherit the same answer: no problem.

Yet the real-world Result has already occurred.

The same collapse can distort what happens after an incident. Once the failure is understood as a path problem, remediation naturally continues to focus on the path: add another validation step, require another confirmation, shorten the chain, narrow the entry point. None of those measures is necessarily wrong. But if the deviation did not occur in the Path dimension, they do not reach the thing that still needs to be explained.

Worse, the redesigned path may now look cleaner and more orderly, making the mismatch itself easy to mistake for a completed repair.

The real task is therefore to separate two narrower questions:

Is “this request took the wrong path” the same kind of failure as “the constraint itself failed”?

Separate the Two Questions First

Path has one core question:

How did this particular request actually proceed?

It examines the steps, order, actor, entry point, and execution chain that actually occurred, and asks whether any of them diverged from the path that was supposed to hold. A step may have been inserted, omitted, or substituted. The order may have changed. A previous invocation may have been replayed. Execution may have entered through another route or bypassed part of the expected process. Several invocations that are individually legitimate may also have been composed into a chain that was never authorized as a whole.

Path does not ask whether the action should have happened. It does not ask whether the parameters themselves were correct. It does not ask where the final Result ended up.

It asks only:

How did this execution actually proceed?

One of the clearest ways to understand Path is to consider its opposite: what does a normal path look like?

An operational command may follow an established playbook using tools employed every day. A payment may pass through the systems and wire-transfer channels already designed for it. A planned vehicle trajectory may be generated by a planner and then carried out by an executor according to that plan. In each of these cases, no step has been inserted or skipped, no alternative route has been substituted, and no segment of the expected chain has been bypassed. Reconstruct the execution afterward, and every observed step can still be matched to a corresponding place in the prescribed path.

In such a case, Path must be allowed to return a clean result:

No Path Deviation was found.

That answer has to be legitimate. If an analytical object is meaningful only when it finds a problem, then it is no longer a judgment tool; it has become another way of saying that the outcome was bad. Finding no Path Deviation means only that no difference was identified between the actual execution and the prescribed path. It says nothing, by itself, about the other questions that still have to be asked.

Boundary asks something else:

What constrains the actions, paths, and capabilities involved—and what can ultimately refuse them?

Its entry condition is not where the request traveled. It is the state of the constraints themselves: whether they are missing, incomplete, ineffective, or whether the rules or enforcing parties that implement them have themselves been rewritten.

A constraint is missing when nothing limits the relevant scope of effect: how much an action may affect, how many objects it may reach, or which resources it may change.

A constraint is incomplete when it covers some situations but leaves the situation at hand outside its coverage.

A constraint is ineffective when it exists and nominally covers the action but fails to exert its intended limiting effect. An independently effective veto may fail to operate, for example, or a high-privilege path may remain outside the constraint altogether.

The stronger case is rewriting: the rules that determine how the constraint operates, or the parties that enforce those rules, have themselves changed.

These forms all return to the same question:

Before this action reaches the real world, what actually limits what it can do and how far it can go?

That is not the same object of inquiry as Path. Path compares the record of actual execution with the prescribed execution path. Boundary examines whether the relevant constraints exist, what they cover, whether they are effective, and whether they are still the same constraints. The two judgments may draw on some of the same incident material, but they are looking for different things in that material.

A failure may therefore show no anomaly at all in Path while still satisfying Boundary. The reverse may also occur. A clean answer to one question cannot answer the other.

The phrase “what can ultimately refuse” remains part of the Boundary question here, but this chapter does not build a further structure around it. The present discussion stops at the ways an execution boundary can fail and how those failures can allow a deviation to reach the real world. It does not yet define how the relevant refusing party is constituted or how final refusal capability is established.

One further distinction has to be made now:

Execution Boundary is not another name for Access Control.

Access Control asks first what permissions a subject possesses. Execution Boundary, as used here, asks what constrains the real-world scope of an action. The two may coexist in the same system, but neither implies the other. A subject may be fully authorized to perform an action while the amount that action can affect, the number of objects or resources it can reach, or the extent of its real-world effect remains insufficiently constrained.

The question is therefore not only:

Does this subject have permission to do it?

It is also:

How far can this action go, and what limits it?

Path and Boundary can now be separated at the level of definition.

But definitions alone are not enough. A definition can always be stretched after an incident until almost any fact appears to fit it. What prevents Path and Boundary from sliding back into one another is that each also needs another boundary:

What is still insufficient for this judgment to apply?

What Is Still Not Enough

Every judgment target needs more than an entry condition. It also needs a second boundary:

What is still insufficient for the judgment to apply?

This may look like a secondary restriction, but it is at least as important as the definition itself. A definition tells us what evidence can support a judgment. An exclusion boundary tells us what must remain outside that judgment even when it initially looks similar.

For Path, the exclusion boundary is:

A long chain, a complex process, or a wrong Result is not, by itself, enough to establish Path Deviation.

A failure may pass through twenty layers of invocation, eight services, and three system boundaries before producing a completely wrong Result. Every one of those facts may be true, and they still do not establish that the execution path deviated.

Path requires a difference between actual execution and the prescribed path. Was a step inserted that should not have been there? Was a required step omitted? Was the order changed? Was an actor substituted? Was the entry point replaced? Was some segment bypassed? Did execution enter an alternative route?

A long chain is not the same thing as a wrong path. A complex process is not the same thing as deviation from the prescribed path. Complexity alone is not an anomaly. If it were, Path would lose its discriminating power as soon as a system became sufficiently complex and would collapse into little more than “there were many steps, therefore something was wrong with the process.”

Boundary has a different exclusion boundary:

The fact that a request passed through many nodes is not, by itself, enough to establish Execution Boundary Failure.

A request may traverse ten nodes without telling us anything about whether a relevant constraint was missing, incomplete, ineffective, or rewritten. The number of nodes tells us something about the length of the path. It does not tell us the state of the constraints.

After an incident, it is easy to say, “It passed through all those stages and not one of them stopped it.” But that is not yet a Boundary judgment. Counting stages does not identify which constraint should have existed, whether it covered the action, or whether it was effective at the time.

These two exclusion boundaries are what actually prevent Path and Boundary from sliding back into one another.

Without them, Path can easily expand into “something went wrong somewhere in the process,” while Boundary can expand into “the action was ultimately not stopped.” Almost every real-world failure can be made to fit both descriptions. Every failure has some process behind it, and once a bad Result has occurred, it is always possible to say that something, somewhere, failed to stop it.

The problem is that judgments this broad have no localization value.

If an analytical object returns essentially the same answer for almost every failure, it distinguishes nothing. The purpose of an exclusion boundary is therefore to remove, before the incident narrative takes over, facts that invite a judgment without being sufficient to establish it.

A long chain: set it aside.

Many nodes: set them aside.

A complex system: set it aside.

A severe Result: set that aside as well.

Only then should the remaining evidence be used to determine whether Path actually deviated, or whether Boundary was in fact missing, incomplete, ineffective, or rewritten.

Once those distractions are removed, either judgment may stand alone. Both may hold. Neither may hold. All of those outcomes are legitimate. The purpose is not to force at least one of the two to be present. The fact that a Result occurred cannot be used backward to compel either judgment to become true.

That is why the fourth column in the following table is not supplementary commentary.

It carries the boundary of each judgment target. Remove that column, and both objects quickly drift toward the broadest language available in an incident narrative, eventually collapsing back into a single phrase such as “the process lost control.” Once every failure can be described that way, the distinction established in this chapter has disappeared.

TAB-I-001 | Path and Boundary Ask Different Questions

The table contains only two rows because it compares two judgment targets—not two stages, two exhaustive categories, or two control points.

Nor is it a reclassification of the five Direct Mechanism Families introduced in the previous chapter, and it is not an exhaustive table. It has one purpose: given a concrete failure, assess Path and Boundary separately.

The two judgments have different entry conditions and different exclusion boundaries. Path may hold while Boundary does not. Boundary may hold while Path does not. Both may hold. This chapter does not determine whether they are mutually exclusive in a formal sense, nor whether the two together cover all possible failures.

Applying the two judgments also requires different evidence.

For Path, reconstruct the steps, order, actor, entry point, and execution chain that actually occurred, then compare them with the prescribed path. If no difference can be identified, Path must be allowed to return None. The analysis cannot force this dimension to contain an anomaly merely because an incident occurred.

For Boundary, the investigation has to ask a different set of questions. Before the action reached the real world, what constrained its scope of effect? Did those constraints exist? What did they cover? Were they actually effective at the relevant time?

Some of the most important evidence may not appear directly in the execution record at all. A constraint that never existed cannot leave behind a log entry saying, “I was absent.” Finding nothing in the logs therefore does not establish that control was normal. It may simply mean that the investigation has to change what it is examining.

Neither judgment can be inferred from the severity of the outcome.

A severe consequence is not enough to establish Path Deviation; the fact that the Result occurred is not enough to establish Execution Boundary Failure.

The Result tells us that something needs to be explained.

It cannot serve as the explanation itself.

Normal Paths Can Carry Erroneous Actions

So far, the distinction between Path and Boundary has been stated in terms of judgment conditions. What actually separates “the path was normal” from “control was normal” is the evidence provided by real-world failures that have already been fact-verified.

On February 28, 2017, Amazon S3 experienced an outage in the Northern Virginia region. The S3 team was addressing a slowdown in the billing system when an authorized team member, following an established playbook and using normal production tooling, issued a command intended to remove only a small number of servers. An incorrect input caused the command to remove far more servers than intended, contributing to the subsequent S3 service disruption.

On the Path dimension, this case is rated Weak / Unsupported.

There was no alternative route, no skipped step, and no bypass. The operator did not circumvent the established tooling, nor was this an unauthorized actor entering the system. The command reached the real world through the existing playbook and the normal production tools. From the standpoint of Path, it followed the route the system already allowed it to follow.

That is precisely the point.

A normal path did not prevent an erroneous Action from being executed.

This case has only that role in this chapter. It does not establish that Boundary must have failed. It does not establish that the incident belongs uniquely to one mechanism family. Nor can a single case support a general law about complex systems. The claim being used here is much narrower: the actual execution did not deviate from the prescribed path, yet the deviation still reached the real world.

A different form appears in Citibank’s August 2020 mistaken payment. The previous chapter examined the case through the Decision / Binding relation. On the Path dimension, it shows something else.

The payment moved through the normal Flexcube workflow and the normal bank wire-transfer channel. Two levels of human review did occur, and the actions took place within interfaces provided by the system itself. But only one of three required interface options was selected, after which the system acted on the entered fields and transferred nearly one billion dollars of the bank’s own funds.

The important point here is not whether review occurred. It is this:

The existence of two levels of review did not establish that the amount and account were correctly bound.

That proposition does not, by itself, describe Path Deviation.

On the Path dimension, this case is likewise rated Weak / Unsupported. There is no evidence that someone bypassed the normal process or used an unauthorized route. On the contrary, every visible action occurred within the process the system had been designed to provide.

The incident therefore cannot simply be retold as “someone bypassed the controls.” Nor does it establish that the review system itself was ineffective. And the later legal treatment of the return of funds cannot be converted directly into a theoretical conclusion for this book. The claim used here is deliberately narrow:

No identifiable Path Deviation occurred, yet the wrong Result still occurred.

The third case comes from the physical world.

On May 21, 2024, a Waymo autonomous vehicle performing a low-speed pull-over maneuver in a Phoenix alley struck a wooden utility pole. There were no passengers in the vehicle, no other road users were involved, and no one was injured. The vehicle was damaged, and the issue was subsequently addressed through software and map updates together with a formal recall filing.

On the Path dimension, this case is also rated Weak / Unsupported.

It is particularly easy to misclassify because the vehicle did, in an ordinary-language sense, end up going to the wrong place. But two different questions have to be separated:

A planned path that is itself wrong is not the same thing as the vehicle deviating from that planned path during execution.

The vehicle followed the pull-over trajectory generated by its planner. No difference was identified between the planned trajectory and the trajectory actually executed. The problem lay in the content of the plan: the generated trajectory included a permanent physical obstacle that was present in the real world.

If that situation were also classified as Path Deviation, Path would quickly lose its selectivity. Any action producing a bad Result could be redescribed after the fact as having “taken the wrong path.” The question “Did actual execution deviate from the prescribed path?” would disappear and be replaced by the much broader question “Was the Result good?”

That is not the role of Path.

This case is used here only for that distinction. It does not support additional conclusions about propagation, Amplification, recall coverage, or the scale of the incident.

Taken together, the significance of the three cases is not merely that none provides Strong support for Path. They show three different forms of a normal path.

In AWS, the normality lies in the operational path: an authorized operator used established tools and followed an existing playbook.

In Citibank, it lies in the review workflow: the transaction passed through the designed system and human review points without bypassing the process itself.

In Waymo, it lies in physical execution: the planner generated a trajectory, and the executor followed that trajectory without an identified departure from the plan.

The systems differ in industry, time scale, and executing subject, but they expose the same structure:

The absence of an identified deviation between actual execution and the prescribed path does not mean that an erroneous Action cannot reach the real world.

That is why Path cannot be expanded into the claim that whenever the Result is wrong, the path must also have been wrong.

Within the analytical framework of this chapter, a narrower and more important conclusion can therefore be stated:

Path is not a necessary condition of the Execution Gap. Normal paths can carry erroneous Actions.

The other side of that conclusion must remain equally clear.

These three cases provide pressure, not theoretical proof. They are used to break the intuition that “if the path is normal, control must also be normal.” They do not justify a universal rule from three incidents.

Nor can the statement “Path is not necessary” be reversed into “Boundary is therefore necessary.” The three cases cannot be assigned uniquely to a single failure type on that basis. This chapter uses only their judgments on the Path dimension. Ask a different question of the same case, and a different structure may become visible.

That is, in fact, their most important role here:

The same real-world failure can reveal different things under different judgment targets.

The Numbers Describe Applicability

Across the seventeen cases that have completed authoritative factual verification, the Path dimension is rated Strong in two cases, Partial in ten, and None in five. On the same case pool, Boundary is rated Strong in eleven cases and Partial in six.

The two distributions do not serve the same purpose.

The Path distribution shows why the concept has to be applied narrowly. In most cases, Path reaches only Partial, and in five it does not apply at all. That is consistent with a judgment target whose entry condition is deliberately strict. If process complexity, chain length, or a bad Result were enough to establish Path, the concept would quickly collapse into another way of saying that “something went wrong in the process.”

The small number of Strong Path findings therefore does not make Path unimportant. Nor does it make Path dispensable or justify absorbing it into Boundary. A narrowly applicable analytical object may appear less often precisely because its threshold is narrow. Rarity under a strict criterion is not evidence of redundancy.

The Boundary distribution carries a different implication. It supports the existence of an explanatory position that cannot be fully absorbed into either Path or the broader language of Relation.

But the two distributions cannot be used to rank the objects by importance. Strong, Partial, and None are analytical ratings made along different dimensions. They are not measures of importance, priority, or severity. The larger number of Strong Boundary findings therefore does not establish that Boundary is a necessary condition of the Execution Gap.

Nor can these numbers be used to assign cases uniquely to one object. A single case may satisfy more than one analytical dimension. Path and Boundary are not a two-way reclassification of the five Direct Mechanism Families introduced in the previous chapter.

The distributions establish only one conclusion:

Path and Boundary have clearly different applicability profiles across the same set of real-world cases.

That difference is enough to show that they should not be treated as the same judgment target.

Boundary Failure Is Not the Same as Boundary Mutation

One further distinction inside Boundary has to remain explicit.

Boundary Mutation occurs when the rules or enforcing parties that determine execution path, capability scope, or final refusal are themselves rewritten. It is a strong subtype of Execution Boundary Failure, but it is not synonymous with Boundary Failure as a whole. Most cases rated Strong on the Boundary dimension do not, in fact, require Mutation.

The distinction matters because Mutation produces an especially intuitive incident story. Someone changes a rule. An enforcing party is replaced. The thing that once constrained an action therefore no longer constrains it in the same way. Such failures contain an identifiable change, often leave traces that can be investigated, and are easy to recognize as a form of boundary failure.

But Boundary Failure does not require a prior act of rewriting.

A constraint may never have covered the relevant action in the first place. It may cover only part of the relevant space, with the deviation occurring precisely where coverage is absent. Or the constraint may exist and apply nominally, yet fail to exert its limiting effect when needed.

None of these cases requires someone to have changed the rules. None requires an actor to have exceeded its authority.

If Boundary Mutation is treated as the representative form of Boundary Failure, investigation will naturally begin by asking:

What was changed?

If nothing can be found, the absence of a mutation can then be mistaken for evidence that the boundary itself was sound.

That is precisely the error this distinction is meant to prevent.

The more fundamental question is still:

What actually constrained the scope of this action?

Two statements therefore have to remain true at the same time:

Boundary Mutation is a strong subtype of Boundary Failure.

Boundary Mutation is not a synonym for Boundary Failure.

The first preserves Mutation as a legitimate explanatory form. The second prevents it from defining the entire family.

Remove either statement, and the concept of Boundary Failure becomes too narrow.

Two Judgments That Cannot Substitute for One Another

What this chapter ultimately delivers is not merely two definitions, but two independent acts of judgment.

Given a specific failure, two questions can be asked separately:

How did this execution actually proceed?

and:

What constrained the relevant actions, paths, and capabilities?

The first reconstructs the steps, order, actor, entry point, and execution chain that actually occurred and compares them with the prescribed path. The second examines whether the relevant constraints existed, what they covered, whether they were effective, and whether the rules or enforcing parties themselves had been rewritten.

The two judgments have different entry conditions and different exclusion boundaries. Each must therefore be allowed to return None.

A completely clean finding on Path establishes nothing about Boundary. Conversely, finding a Boundary problem does not mean that someone must also have taken the wrong path. Completing one judgment cannot substitute for performing the other.

This is the chapter’s most important distinction:

Boundary can fail while Path remains normal.

A deviation may reach the real world entirely through the prescribed path. Every step may match the expected process, and the execution record may contain no identifiable Path Deviation. None of that answers the other question: before the action reached the real world, what actually limited what it could do and how far it could go?

A single failure may also satisfy both Path and Boundary. The two judgment targets can overlap without becoming interchangeable. They need to remain separate precisely because establishing one is insufficient to establish the other—and insufficient to establish that the other is absent.

At this point, “taking the wrong path” and “being unable to stop the action” can no longer be treated as the same failure.

But separating them creates the next question.

The previous chapter identified five Direct Mechanism Families, and several of the real-world cases examined so far do not appear at only one mechanism position. If these objects cannot simply be absorbed into one another, then another problem has to be addressed:

If these mechanisms cannot absorb one another, are the five Direct Mechanism Families mutually exclusive? And given a specific failure, how should it be localized among them?

This chapter does not answer that question.

Chapter Terms

• Execution Path Deviation
• Execution Boundary Failure
• Boundary Mutation
• Strong
• Partial
• None

Cases and Sources

Three Formally Verified Cases

This chapter continues to draw on the pool of seventeen formally verified cases assembled during the research for The Execution Gap, with particular emphasis on three cases:

AWS S3, Citibank–Revlon, and Waymo.

The three cases serve the same purpose in this chapter: they are used to test whether Execution Path Deviation is a necessary condition of the Execution Gap. They represent three different forms of execution—an operational path, a review workflow, and physical execution—but all three are rated Weak / Unsupported on the Path dimension.

These cases are not used to establish that any other mechanism must therefore be present, nor are they used to assign each incident uniquely to a single failure type. Their role here is that of a pressure test: they show that a real-world failure can occur along a normal path, and that the absence of an identified difference between actual execution and the prescribed path does not mean that an erroneous Action cannot reach the real world.

The bounded conclusion established in this chapter is:

Path is not a necessary condition of the Execution Gap. Normal paths can carry erroneous Actions.

Pool of Seventeen Formally Verified Cases

In addition to the three focal cases, this chapter uses aggregate findings from all seventeen formally verified cases on the Path and Boundary dimensions.

Within that case pool:

• Path: 2 Strong, 10 Partial, 5 None;
• Boundary: 11 Strong, 6 Partial.

These figures describe only the distribution of evidence across the two analytical dimensions within the current case pool.

The Path distribution supports the need to keep Execution Path Deviation narrowly applied. The Boundary distribution supports the existence of an explanatory position that cannot be fully absorbed into Path or the broader language of Relation.

Strong, Partial, and None do not constitute rankings of importance, severity, or priority. Nor do these distributions establish that Path can be discarded, that Boundary is more important, or that the two dimensions together form a mutually exclusive and exhaustive classification of real-world failures.

Full Case Documentation

The chapter body does not repeat the complete factual chains, verification procedures, or full source records for the three focal cases.

Complete documentation for AWS S3, Citibank–Revlon, and Waymo is consolidated in the appendix “Real-World Failures and Boundary Cases,” under “Pool of Seventeen Formally Verified Cases.”

This chapter uses only the verified findings for those three cases on the Path dimension.

For AWS S3, the chapter does not expand into capacity design or the recovery process. For Citibank–Revlon, it does not use the later legal treatment of the return of funds to support the book’s theoretical conclusions. For Waymo, it does not use the case to draw conclusions about propagation, Amplification, recall scope, or incident scale.

Sources

The real-world facts discussed in this chapter are based on the completed verification records for the corresponding cases, using official, primary, judicial, regulatory, or other authoritative materials.

Case-specific factual sources and complete bibliographic information are not repeated in the chapter body. They are consolidated in the appendix “Real-World Failures and Boundary Cases” and in the book-wide “References and Sources.”

---

Chapter 6 | Not a Classification Table, but Three Questions

This chapter prevents the five Direct Mechanism Families from being misread as a mutually exclusive classification table. Across the seventeen verified cases, a single incident can satisfy multiple mechanism dimensions at the same time, so cases cannot be assigned uniquely to one box. Non-exclusivity does not mean that the classification work is unfinished. It reflects the fact that real-world failures can arise through combinations of mechanisms that already exist, and a new combination does not automatically create a new top-level mechanism. Rating is an analytical act; assignment is something else. Case counts and the labels Strong, Partial, and None cannot be used to rank severity or mechanism importance. To avoid turning analysis back into a search for unique membership, this chapter returns to three questions: What changed? Which relationship failed? Where did the break occur, and at which mechanism position? These are not a new framework or hierarchy. They are simply a way to return the analysis to facts. Giving up unique classification does not mean giving up localization. The next step therefore begins with the first question: is the mere fact that something changed itself a cause of the Execution Gap?

Imagine an incident-review form with one final field labeled Root Cause Classification.

It is a required drop-down menu, and only one value may be selected.

Once that field is completed, the incident has somewhere to belong. It can be recorded, counted, assigned to a team, and eventually carried into an aggregate report as a single category.

There is nothing inherently unreasonable about that requirement. Organizations need ways to turn one-off events into knowledge that can accumulate. Accumulation requires comparison, and comparison usually requires some common language.

As a communication convention, classification is useful. It allows different teams to talk about the same set of events using the same vocabulary.

The danger begins when a different assumption slips in: that the question “Which category does this belong to?” must always have an answer, and that the answer must contain exactly one value.

A field that accepts only one value has already assumed two things about the underlying reality: that the available objects can be separated from one another, and that every incident has a unique assignment.

At that point, the problem is no longer merely one of record keeping.

The form has begun to make a claim about the structure of reality itself.

When a reporting system permits only one kind of answer, it becomes easy to believe that the world must be structured in the same way—not because that structure has been established, but because the recording tool never allowed another possibility.

The previous chapter ended by refusing one such collapse. “This request took the wrong path” and “the constraint itself failed” are not the same judgment and cannot substitute for one another. An entirely normal Path can still carry an erroneous Action into the real world.

Chapter 4 had already identified five positions at which failure could be localized: Decision / Binding Relation Failure, Execution Path Deviation, Execution Boundary Failure, Execution State / Result Relation Failure, and In-Causal-Chain Evidence / Proof Relation Failure.

Once such a set of objects exists, the next move feels almost automatic: arrange them in a column and, for each incident, select a single box.

This is a Path problem.

Or:

This is a Boundary problem.

The move is attractive because classification offers more than an explanation. It also makes incidents easier to record, aggregate, and assign.

But those organizational conveniences do not establish that the underlying explanation is correct.

And in this case, the move does not hold.

Not because the five families are still too coarse. Not because the research stopped before the classification could be completed. The problem is more fundamental:

real-world deviations do not distribute themselves according to unique membership.

Chapter 4 ended with two open lines of inquiry. One asked whether Path Deviation and Boundary Failure were really the same kind of failure. Chapter 5 answered that question.

The other asked whether the five Direct Mechanism Families are mutually exclusive, and how a specific deviation should be localized among them.

The two lines now meet here.

Seventeen Cases Cannot Contain Fifty-Eight Unique Assignments

Across the first two case pools assembled for The Execution Gap, seventeen cases completed formal factual verification. Their factual foundations come from official investigations, regulatory filings, judicial records, or independent investigations grounded in primary records. Here, formally verified means that the key facts used in the book can be traced back to the relevant primary material rather than being adopted directly from secondary accounts.

During the research, each of the seventeen cases was then rated Strong, Partial, or None on the relevant analytical dimensions.

Some interpretations are difficult to dislodge through another paragraph of argument alone. The idea that “the five families are simply five buckets” is one of them. A reader can accept everything said so far and still place each incident into a single box.

Here, counting creates a more direct problem—not because numbers are inherently more authoritative, but because the contradiction becomes arithmetic.

Table I-002 | Joint Strength Distribution Across 17 Verified Cases Sample: 17 Qualified Cases

Three additional Boundary Cases are excluded from this count. They serve other purposes in the book, but their ratings are not included in the table above.

The sample boundary has to remain fixed here because the relevant point is not the value of any single row. It is the arithmetic relationship between the rows. Mixing cases drawn from different sample definitions, or directly comparing this table with another pool constructed under different criteria, would destroy the basis for that comparison.

Only one reading of the table carries the argument in this section.

There are seventeen cases in the sample. Decision / Binding Relation is rated Strong in all seventeen. State / Result is also rated Strong in all seventeen.

If the five Direct Mechanism Families were mutually exclusive buckets and each case could belong to only one of them, those two rows alone would already require thirty-four cases.

Add the eleven Strong Boundary findings and thirteen Strong Evidence findings, and the count reaches fifty-eight.

Seventeen cases cannot contain fifty-eight unique assignments.

That is enough to reject the interpretation of the five families as mutually exclusive classification buckets.

A single case can satisfy multiple mechanism dimensions at the same time. This is not duplicate counting. Each Strongrating is an independent judgment made on its corresponding dimension. If two dimensions are both rated Strong in the same case, that means that two different questions are both strongly supported in that same deviation. It does not mean that the same judgment has been counted twice.

The question left open at the end of Chapter 5 can therefore now be answered in part:

The five Direct Mechanism Families are not mutually exclusive, and they are not a classification table that assigns every case uniquely to one box.

Non-exclusivity does not mean that the families cannot be distinguished from one another. Chapter 5 already showed that Path and Boundary cannot be absorbed into one another. The conclusion here is different: a single incident can make several distinct analytical questions true at the same time.

The questions are distinguishable. The incident is not uniquely assignable.

This Is Where the Numbers Must Stop

The arithmetic from the previous section is enough to reject one interpretation: seventeen cases cannot support fifty-eight unique assignments if the five Direct Mechanism Families are treated as mutually exclusive buckets.

But that is almost the limit of what the numbers can establish.

Strong, Partial, and None describe the strength with which an analytical position holds in a particular case. They do not measure the severity of the incident, the importance of the mechanism, or the priority with which that mechanism should be addressed.

A row with more Strong findings means only that the dimension holds more broadly within these seventeen cases. A row with fewer Strong findings cannot therefore be demoted to a secondary role. Decision / Binding Relation and State / Result are both rated Strong in all seventeen cases, but that fact still describes only the current case pool.

The seventeen cases were not randomly sampled from some larger population. Their distributions therefore cannot be used to estimate which kinds of failure occur more frequently in the real world, nor can the figures be compared directly with another case pool constructed under different sampling or verification boundaries.

The Path row is especially easy to misread. It contains only 2 Strong, 10 Partial, and 5 None—the fewest Strong findings among the seven analytical rows in the table.

Chapter 5 has already shown why Path must nevertheless remain independent. Path asks how this particular request actually proceeded. Boundary asks what constrained the relevant actions, paths, and capabilities. Whether the two need to remain separate depends on whether they ask different questions, not on which row contains the larger number.

Appearing less often does not make a question absorbable by another question.

The same caution applies to Amplification and Change.

Their placement in the same table as the five Direct Mechanism Families does not turn them into a sixth and seventh mechanism. Amplification is a cross-cutting Modifier. It can change the speed or scale with which an existing deviation expands its effects, but it is not an independent Direct Mechanism Family. Change is an analytical dimension: it asks a question, but it is not another mechanism object added to the five families.

The table must therefore preserve its three-part structure. If all seven rows are presented at the same visual level, the layout itself will recreate the false impression that the book contains seven mechanism families.

The numbers have another boundary as well.

They do not establish that the five Direct Mechanism Families exhaust every possible form of the Execution Gap, nor do they establish that the list can never change. The five-family structure is currently Conditionally Frozen. It is not casually expanded or reduced within the current research version, but it must be reconsidered if the established reopening conditions are met or the research question is explicitly reopened.

The count therefore supports only one negative conclusion:

The five Direct Mechanism Families are not five mutually exclusive buckets.

It cannot be reversed into the claim that the five families form a complete and permanent classification system, and it cannot require real-world cases to acquire unique membership.

One case makes the problem especially visible. In the seventeen-case pool, the Knight Capital incident of August 1, 2012 is rated Strong across all seven analytical positions shown in Table I-002.

If the table were a single-choice classification form, Knight Capital would immediately create a contradiction. The difficulty is not that the analysis still needs finer categories. It is that the same incident can make several different analytical questions true at the same time.

Knight Capital is cited here not so that the book can finally place it into the “correct” category, but to apply another layer of real-world pressure to the arithmetic above. A single incident can satisfy multiple analytical positions while those judgments remain independently meaningful.

The case pool provides pressure here, not theoretical proof. It does not establish that the five families are complete. It does not establish that the three questions introduced later in this chapter must be valid. And it does not decide which families any particular incident ultimately “belongs to.”

Rating is analysis. Assignment is something else.

Non-Exclusivity Does Not Mean the Classification Is Unfinished

Once it becomes clear that several of the five Direct Mechanism Families can hold in the same case, an obvious response is to ask whether the current distinctions are simply not fine-grained enough.

Perhaps, if the structure were divided further, the overlaps could eventually be eliminated and replaced by a set of mutually exclusive categories.

That possibility was considered seriously during the research. Several patterns initially looked distinctive enough to justify their own top-level family.

They were not retained as new families, however, because closer examination revealed something different:

Complex failure forms can be composed from mechanisms that already exist.

One example is Evidence feeding back into subsequent qualification or authority.

Evidence produced in one round may become an input to a later judgment while already carrying a deviation from the earlier round. Evidence, Decision / Binding, Boundary, and a subsequent Action can then become connected across multiple cycles. From a distance, the resulting pattern can look like a new kind of failure. Once decomposed, however, its constituent mechanisms are already present. What is new is the way those existing mechanisms have been connected across rounds.

A second example is qualification inherited across organizational boundaries.

One organization may accept a qualification established by another, and that qualification may enter the receiving domain without its conditions of validity being re-established there. Qualification relations, Boundary, and Amplification can all be involved, while the overall pattern crosses an organizational boundary.

Because the failure spans two systems, it can appear structurally unfamiliar. But crossing an organizational boundary does not, by itself, create a new Direct Mechanism Family. What changes is the way existing mechanisms are connected and the scope over which they operate—not the basic structural way in which the deviation reaches the real world.

The two examples support the same conclusion:

Combination does not constitute a new top-level mechanism.

Complex real-world failures can involve several existing objects at the same time. If every newly observed combination were registered as a new top-level category, the list would continue to grow without necessarily gaining explanatory power.

More importantly, that move would recreate an assumption already rejected in this chapter: that if the categories are made sufficiently fine-grained, every incident will eventually fit into one unique box.

The problem is not that there are still too few boxes.

The problem is that a single failure can genuinely make several different mechanisms hold at the same time.

A different kind of candidate has to be handled in the opposite direction: a normatively invalid decision that is nevertheless executed completely and correctly downstream.

This is not necessarily a new combination of mechanisms. It may not even belong to the same problem space.

If the upstream decision is normatively invalid in the first place, the first question is no longer “Which mechanism does this belong to?” It is whether the case qualifies for entry into the Execution Gap at all.

Registering such a case as another mechanism family would collapse two different questions:

What failure structures exist inside the Execution Gap?

and:

What does not belong to the Execution Gap in the first place?

The second question is addressed separately later in this book. Here, it is enough to mark the boundary and stop.

Overlap among the five Direct Mechanism Families therefore does not mean that the classification remains unfinished.

It indicates something else:

Their non-exclusivity reflects the fact that existing mechanisms can combine within the same real-world failure.

Three Questions

If a deviation cannot be localized by assigning an incident to one unique category, the next step is not to build a more detailed classification table.

It is to change the questions.

Do not begin by selecting a box. Ask three questions instead.

What changed?

First identify the object in which change occurred. It may be an Intent, the meaning of a term or field, the object being acted upon, a parameter, a State, a Policy, a Path, a boundary rule, a Result, or Evidence.

This question does only one thing: it identifies change.

It does not determine whether the change was authorized, and it does not decide in advance whether the change caused the eventual deviation. Its role is deliberately limited. It separates what changed from what did not, giving the later analysis a concrete object to examine.

Incident narratives often become vague at precisely this point. Everything can appear to have gone wrong, while the analysis never states what, exactly, became different from before. If the location of change has not even been identified, later claims about relationships and mechanisms have nothing concrete to attach to.

There is therefore an analytical order among the three questions, but that order does not make them three stages. The first question does not have to be “completed” before the second can begin. Its purpose is simply to provide the next question with clearer factual objects.

Which relationship failed?

Once a change has been identified, the next question is which necessary relationship no longer held.

The break may lie between Intent and Approval, between Approval and Payload, between Flow and Path, between Execution and Result, or between reality and Evidence. The concern is not which individual component “broke.” It is which correspondence that should have remained intact between two objects no longer did.

That distinction matters because a failed relationship does not require either endpoint to be visibly defective. Both endpoints may remain locally valid while the relation between them has already failed.

Chapter 5 showed that an entirely normal Path can still carry an erroneous Action. The fact that a request ultimately passed through therefore does not identify a single mechanism. In one case, actual execution may have deviated from the prescribed path. In another, the Boundary that should have constrained the Action may have failed to hold.

Where did the break occur, and at which mechanism position?

Only then do we ask whether the failure appears in Decision / Binding, Path, Boundary, State / Result, or Evidence / Proof—or whether no new Direct Mechanism Family is present at all and the observed effect is instead an Amplification of a deviation that already exists.

This question is not designed to assign the incident a unique label. Its purpose is to identify the position through which the deviation reached the real world.

Amplification requires particular care here. It is not another Direct Mechanism Family. It is a cross-cutting Modifierthat operates across mechanisms already present. It can explain why an existing deviation spread faster or produced a larger effect, but it cannot answer the prior question of why that deviation was able to reach the real world in the first place.

Treating Amplification as the location of the failure would collapse two different questions:

Why did the consequences become so large?

and:

Why was the deviation able to reach the real world at all?

The five Direct Mechanism Families introduced in Chapter 4 can now be placed more precisely. They are not five categories used to assign membership to incidents. They are analytical objects that can be referenced when answering the latter two questions: which necessary relationship failed, and at which mechanism position that failure appeared.

Chapter 4 therefore left us with five objects, not five classification labels.

Objects identify what happened. Labels decide where something belongs.

Do Not Turn the Three Questions Back into a Structure

The three questions remain questions by design.

They have not been left in that form because the research has not yet organized them into a proper framework. Quite the opposite. They are deliberately unnumbered. They do not constitute a system, and they are not new mechanisms.

That limitation is intentional.

It would be easy to redraw them as three axes, three layers, a three-step process, or a decision tree. Each representation would look cleaner. But each would also introduce assumptions that the analysis has not established.

Three axes would suggest that every deviation can ultimately be assigned a determinate set of coordinates.

Three layers would suggest that every failure occupies some fixed position within a stable structure.

A three-step process would invite readers to mistake the analytical order of the questions for stages in the real execution process.

Each of those representations would reintroduce the same impulse this chapter has just rejected: forcing complex failures back into a uniquely determined position.

The purpose of the three questions is not to assign an incident a place.

It is to force the analysis back toward facts that can be checked again:

What changed?

Which necessary relationship failed to hold?

Through which mechanism position did the deviation reach the real world?

The required output is therefore not a label suitable for direct insertion into a report. It is a set of factual statements that another analyst can revisit, test, and challenge.

For the same reason, the three questions should not be compressed into context-free tool cards, flowcharts, or check-box templates.

There is nothing inherently wrong with tools of that kind. The problem begins when the form starts to replace the analysis. Three open questions can then become three fields that simply have to be completed, and a new interface quietly restores the same classification habit that this chapter was meant to remove.

A category can demand a value.

A question demands facts.

The three questions are not a new structure. They simply return the analysis to the facts.

Giving Up Unique Classification Does Not Mean Giving Up Localization

The three questions do not make the judgment for the analyst.

Abandoning unique classification therefore does not mean abandoning localization. Every case still has to identify at least one Direct Mechanism that explains why the deviation did not stop earlier and instead reached the real world.

An analysis that ends only with statements such as “everything changed,” “every relationship had a problem,” or “every layer contributed” has not yet localized the failure.

Any one of those statements may contain some truth. But leaving every possibility open does not, by itself, produce an explanation.

Non-exclusivity means that a single deviation may hold at several mechanism positions at the same time. It does not mean that the analysis may refuse to identify any specific mechanism position at all.

Giving up unique classification does not mean giving up localization.

What is needed instead is a different constraint on the analysis.

A localization may produce several explanations that hold simultaneously, but it must identify at least one Direct Mechanism and explain how that mechanism allowed the deviation to reach the real world.

That requirement does not create a new category. Nor does it turn the five Direct Mechanism Families back into a classification table. It simply prevents the analysis from stopping at descriptions such as “the situation was complicated” or “many things went wrong.”

The three questions must not become a new checklist either.

Completing all three fields would not mean that localization had been completed. What has to remain at the end is a set of facts that another person can inspect again: what changed, which necessary relationship failed to hold, and through which mechanism position the deviation ultimately reached the real world.

If the three questions are reduced to three boxes that merely have to be checked, then the original single-choice drop-down has only been replaced by three new fields.

What this chapter ultimately delivers, then, is not a new classification structure but a way of conducting analysis.

Do not begin by asking:

Which category does this incident belong to?

Continue asking instead:

What changed?

Which relationship failed?

Through which mechanism position did that failure reach the real world?

There may be more than one answer.

But every answer must remain traceable to facts.

One question still needs to be left open.

Across the seventeen cases examined earlier, Change is rated Strong in all seventeen. In this case pool, some form of change can therefore be identified in every case.

That result shows that Change has broad coverage as an analytical dimension.

It does not establish that change itself is the cause of the deviation.

Broad coverage tells us that the question is worth asking. It does not tell us that the answer has already explained causation.

Chapter 6 therefore stops here and hands forward the next question:

Is the mere fact that something changed itself a cause of the Execution Gap?

Chapter Terms

• Direct Mechanism Family
• Decision / Binding Relation
• Path
• Boundary
• State / Result
• Evidence
• Amplification
• Change
• Strength Rating — Strong / Partial / None

Cases and Sources

Pool of Seventeen Formally Verified Cases

This chapter uses the seventeen formally verified cases drawn from the first two case pools assembled for The Execution Gap. Each case is rated Strong, Partial, or None across the five Direct Mechanism Families, as well as across Amplification and Change. Their joint strength distribution is presented in Table I-002.

Three additional Boundary Cases are excluded from this count. The chapter preserves a single sample definition of seventeen Qualified Cases and does not combine them directly with cases drawn from other batches or constructed under different criteria.

The case pool serves as a pressure test in this chapter. It is used to test whether the five Direct Mechanism Families can coherently be interpreted as mutually exclusive categories. It is not used to establish that the five families are complete, nor is it used to assign any specific incident a unique membership.

Full Case Documentation

The only incident named individually in this chapter is Knight Capital | August 1, 2012.

The case is used to show that a single real-world incident can satisfy multiple analytical positions at the same time while those judgments remain independently meaningful. It is not presented as a model of “correct classification,” nor is it used to establish the validity of the three questions themselves or the completeness of the five Direct Mechanism Families.

The case-by-case facts, Evidence, and strength ratings for all seventeen cases are inherited from the book’s formally verified case pool. This chapter does not repeat the full factual narrative for each case.

Sources

The case facts used in this chapter are based on official investigations, regulatory filings, judicial records, and independent investigations grounded in primary records.

Key factual claims used in the chapter must be traceable to the corresponding primary material rather than being adopted directly from secondary accounts.

---

Chapter 7 | The Fact That Something Changed Is Not a Cause

This chapter asks whether Change is itself a cause of the Execution Gap. Some form of change can be identified in all seventeen verified cases, giving Change broad analytical coverage. But broad coverage is not causal status. Change can occur without an Execution Gap, particularly when the relevant qualification, binding, or current condition has been re-established after the change. What the Execution Gap actually requires us to explain is why a relationship that had to remain valid no longer held after the change occurred. Change therefore remains an Analytical Dimension rather than a top-level Root Mechanism. It can help localize a failure and prompt renewed examination of Current Qualification, but it cannot substitute for an explanation of relational failure. That conclusion leaves the next question open: if “something changed” is not itself a cause, does AI become a cause when it makes change propagate faster and at greater scale?

Chapter 6 left the reader with five Direct Mechanism Families and three questions: What changed? Which relationship failed? And where did the failure occur—at Decision / Binding, Path, Boundary, State / Result, or Evidence / Proof—or did it merely amplify a deviation already present?

Of the three questions, the first is the easiest to reach for.

It is also usually the easiest one to answer with a concrete object.

That is where the trouble begins.

When an execution chain fails, retrospective analysis naturally looks for differences between before and after. A parameter may have been changed. A configuration may have been replaced. A Policy may have just been updated. A State may no longer be what it was.

This form of explanation has another attraction. Once a change can be tied to a specific time, operation, release, or modification record, two questions tend to appear together:

What changed?

and:

Who changed it?

The second question can certainly matter in an incident review. But it is a question of attribution. It does not explain why the deviation was able to continue through the execution chain and reach the real world.

Putting attribution in the place of explanation does not restore the missing causal link.

The first question therefore has a particular kind of appeal: it produces results too easily.

The preceding chapters repeatedly shifted attention away from isolated components and toward the relationships between them. Here, for the first time, the analyst is given an entry point that can often be attached immediately to a specific object. The easier that entry point is to operationalize, the easier it is to mistake it for a completed explanation.

This chapter addresses only that mistake:

Is the fact that something changed itself a cause of the Execution Gap?

Here, cause means something capable of explaining why the deviation did not stop earlier in the chain and instead reached the real world.

The answer is no.

Change is an Analytical Dimension. It is the first of the three questions. It is not a Root Mechanism.

The purpose of this chapter is not to remove one assignment only to replace it with another, nor to introduce a new localization object. It is simply to close the shortcut from “something changed” to “that change caused the Execution Gap,” while leaving the question “What changed?” exactly where it belongs.

Why the First Question Looks Like an Answer

To understand why this shortcut is so tempting, we first have to admit that it is not irrational.

What changed? is useful precisely because it often points quickly to something concrete. As an execution chain continues to operate, parameters, States, configurations, Policies, and inputs can differ over time. Tracing those differences can therefore produce an immediate place to look next.

The problem is that a question that is easy to answer can easily be mistaken for a question that has already explained the failure.

In ordinary experience, finding the object often ends the search. If a key is missing, we keep looking until we find it. Once it turns up, the problem appears to be resolved.

What changed? is not that kind of question.

It searches for a difference between two points in the execution chain. But difference can exist perfectly normally. Finding a change establishes only that a particular object deserves further examination. It does not establish that the change caused the Execution Gap.

This requires a distinction between two kinds of questions.

Some questions progressively narrow the candidate set until what remains can serve as the answer itself.

Other questions do something more limited: they tell us where to look next.

What changed? belongs to the second kind.

It directs attention toward a specific object—a parameter, a Policy, a State—and then hands the explanatory work to the questions that follow.

Once a changed parameter has been identified, the analysis still has to ask whether the authorization on which the Action depended continues to cover the new parameter, and whether the necessary relationships that previously held still hold after the change.

Only then does the analysis begin to enter the territory of the second and third questions.

If that step is skipped and “something changed” is written directly into the conclusion, a localization entry point has been mistaken for a causal explanation.

Seventeen Out of Seventeen

One statistic makes the shortcut especially tempting.

Across the seventeen cases that have completed formal verification, Change is rated Strong in all seventeen.

Seventeen out of seventeen.

Among these seventeen established Execution Gaps, not one occurred under conditions in which nothing had changed.

That result naturally invites a further step. If Change appears in every verified case, does it begin to look like a cause?

The problem is not that the coverage rate is still too low. Seventeen out of seventeen leaves no room for a higher rate within this sample.

The real question is which side of the comparison the number comes from.

These seventeen cases were already selected as cases in which an Execution Gap had been established. The statistic therefore answers a narrower question:

Among cases where an Execution Gap is already present, how often does the question “What changed?” identify something?

In this sample, the answer is seventeen times out of seventeen.

But the statistic does not answer the other side of the comparison:

In normal operation, where no Execution Gap occurs, how often would the same question also identify something that changed?

That missing side matters.

A statistic drawn only from failures cannot turn coverage into causation merely by reaching 100 percent within the failure sample.

The 17/17 result supports a clear and useful conclusion:

Change has broad analytical coverage.

It shows that What changed? is a productive entry point for localization. It does not establish that Change caused the Execution Gap.

A more cautious interpretation still goes too far. One might concede that Change is not a direct cause while arguing that it is nevertheless a necessary precondition for every Execution Gap.

The current evidence does not support that claim either.

Seventeen cases are seventeen cases. They cannot be expanded into a universal proposition about all Execution Gaps. A feature does not acquire causal status merely because it appears in every failure currently known to the analysis.

A feature may accompany failure. It may help localize failure. It may also occur during normal operation without any failure at all.

The failure sample alone cannot distinguish among those possibilities.

The 17/17 result therefore does not diminish the value of the first question. It does the opposite: it shows that the question has excellent coverage as an analytical entry point.

What has to be rejected is only the unsupported step from:

“We can find Change almost every time.”

to:

“Change is therefore the cause.”

The next step is to examine the side of the comparison that the statistic does not contain:

Change without an Execution Gap.

Change Without an Execution Gap

To reject the claim that Change is itself a cause, we do not need an even higher coverage rate.

We need to establish something different:

Can real change occur without an Execution Gap?

There are at least four situations in which it can.

The first is a legitimate revision of Intent.

An Intent that was previously established may be changed through a valid process. An expense limit may be formally increased. A pricing rule may be replaced. An established objective may be replaced by a new objective by a subject authorized to make that change.

Change has unquestionably occurred, and it has occurred upstream in the execution chain.

But if subsequent Actions are based on the revised Intent and the necessary correspondences remain intact, no Execution Gap arises merely because the Intent changed.

The case that does require explanation is different: the Intent has already been revised, yet subsequent Actions continue to be governed by the old Intent.

At that point, the problem is no longer that “the Intent changed.” The problem is that an Intent that is no longer valid continues to govern downstream Action. The former is a normal revision. The latter enters the Decision / Binding Relation problem established in Chapter 4.

The two situations may occur almost adjacent to one another in time, but their explanatory objects are entirely different.

The second situation is a normal State update.

Inventory decreases. A balance changes. A task moves from in progress to completed. A device moves from standby into operation.

These changes are not anomalies. They are part of what State is supposed to record: differences in reality over time.

If the mere fact that State changed were treated as a cause of the Execution Gap, normal operation would satisfy that condition continuously. A condition that holds throughout ordinary operation cannot, by itself, distinguish normal State transition from execution deviation.

State does have its own failure forms, but the failure still does not lie in the fact that State changed.

A local stage may be mistaken for the real-world Result. An unknown State may be interpreted as success. In such cases, the relevant question is whether the necessary relationship between State and Result still holds—not whether State changed.

The third situation is an authorized parameter adjustment.

A subject with the relevant authority may change a parameter from one value to another within the scope already granted. The change is real, while the correspondence between authorization and Action remains intact.

This case is especially easy to confuse with the first Direct Mechanism Family introduced in Chapter 4.

Both situations may contain an authorization that had previously been established. Both may contain a subsequent parameter change. Both may leave a clear before-and-after record.

What distinguishes them is not whether something was modified.

It is whether, after the modification, the authorization on which the Action depends still covers the new object, parameter, or scope.

Seen only through the question “What changed?”, a normal parameter adjustment and a Binding failure may therefore look strikingly similar.

The first question can identify where the change occurred.

It cannot, by itself, determine whether the necessary relationship still holds after the change.

That judgment still belongs to relational and mechanism-level analysis.

When Qualification Has Been Re-Established After Change

The fourth situation lies closer to the Execution Boundary and therefore requires a more careful distinction:

when a change has been reassessed and Current Qualification has been re-established, the change itself does not constitute an Execution Gap.

This statement describes an established state. It does not define a procedure.

It says only that reassessment has in fact occurred, that Current Qualification in fact holds, and that the necessary correspondence affected by the change has therefore been re-established.

The change has not disappeared. It may even have occurred in rules that determine which Actions are allowed to reach the real world. But once the relevant qualification has been re-established, the object requiring explanation is no longer the mere fact that something changed.

Nothing in this statement determines who must perform the reassessment. It does not specify when that reassessment must occur, what conditions it must use, or how it must be carried out.

Nor does this chapter need to supply those answers.

The moment “Has Current Qualification been re-established?” is expanded into a formal set of conditions that can be checked one by one, the discussion has moved from describing an established state into designing a new adjudication structure.

That is beyond the scope of this chapter.

Only one boundary needs to be retained here:

When Current Qualification has been re-established, Change itself is not an Execution Gap.

Taken together, the four situations are enough to establish the distinction.

A legitimate revision of Intent, a normal State update, an authorized parameter adjustment, and the re-establishment of Current Qualification after reassessment can all involve genuine Change without producing an Execution Gap.

Once such situations are possible, the claim that Change itself is a cause of the Execution Gap cannot hold.

These are not four incident cases. They are four forms of normal operation used to test that claim.

Their value lies precisely in the fact that Change occurs while the Execution Gap does not. If a deviation were later to arise in any of these situations, the analysis would still have to identify which necessary relationship failed.

The fact that something changed would not, by itself, provide that explanation.

Change and the Execution Gap Operate at Different Levels

Looking more closely, “something changed” and “an Execution Gap occurred” are judgments about different kinds of things.

Change is first a judgment about an object itself.

A parameter, a Policy, or a configuration differs between two points in time. To establish that fact, we compare the earlier and later states of the same object.

The question is:

Did this object change, and if so, what did it become?

The Execution Gap cannot be established in the same way.

It cannot be determined by observing one object in isolation. It requires us to examine whether a correspondence that had to remain valid between what was already established and what actually occurred still held.

That relationship may involve Intent and Action. It may involve Path, Boundary, State and Result, or Evidence and reality. Determining which relationship failed requires returning to the five Direct Mechanism Families established in Chapter 4.

This is why What changed? cannot carry the causal explanation on its own.

Change observes difference within an object across time.

The Execution Gap requires an explanation of whether the necessary relationships involving that object still held after the change occurred.

A large change may produce no Execution Gap because the relevant relationships have been re-established.

A very small change may be enough to invalidate a relationship that previously held.

Magnitude of change therefore does not decide the issue.

The capability boundary of the first question is now clear.

It can direct the analysis toward the object that changed.

It cannot, by itself, determine at which mechanism position the Execution Gap occurred.

Chapter 4 established five Direct Mechanism Families. Change and Amplification are not among them.

This chapter resolves the Change side of that distinction:

Change can help localize a failure, but it cannot substitute for an explanation of relational failure.

Remove the Assignment, Keep the Question

Removing Change from the position of cause does not mean removing the question What changed?

What has been withdrawn is a mechanism assignment, not the analytical role of the question itself.

If those two decisions are conflated, this chapter would simply move from one mistake to another.

The first question still has a clear task: identify the object that changed.

That object may be an Intent, a meaning, an object of action, a parameter, a State, a Policy, a Path, a boundary rule, a Result, Evidence, or something else that can change.

The phrase “or something else” matters.

This is not an exhaustive list.

Turning it into a fixed table would amount to claiming, in advance, that the research already knows every kind of object in an execution chain that may change. The current analysis does not establish that conclusion.

For the same reason, these objects should not be given formal numbering.

They are possible referents of the question What changed? They do not constitute a taxonomy.

Once an open-ended question is converted into a fixed list, the list itself begins to narrow the analyst’s field of view. Objects not written into the list in advance become easier to overlook during investigation.

The order of the three questions must be understood in the same way.

What changed? appears first because localization will often begin by identifying the object that changed, then examining which necessary relationship no longer holds after the change, and finally determining the mechanism position at which the failure appears—or whether the observed effect is only Amplification.

That is an order of inquiry.

It is not a causal chain.

The fact that Change appears first in the questioning sequence does not make Change the causal starting point.

What has been rejected, therefore, is the mechanism status of Change—not its analytical value.

What changed? remains an entry point for localization. The work of explaining why a particular deviation was able to reach the real world still belongs to the five Direct Mechanism Families established in Chapter 4.

One further boundary must remain explicit:

Change is not a cause does not mean Change is unimportant, and it does not mean Change need not be managed.

How an organization governs change, structures approval and control around it, or determines whether a particular change may proceed is a different problem.

This chapter addresses only the position of Change within the explanatory chain of the Execution Gap. It does not provide answers to those governance questions, nor does it establish criteria for doing so.

Closing the shortcut from “something changed” to “therefore Change caused the Execution Gap” does not remove Change from view.

It still tells us where to look next.

It simply no longer answers the relational questions in advance.

The First Exclusion

Stepping back, treating Change as a cause amounts to treating what is easiest to observe as what is most explanatory.

Change leaves traces easily.

A parameter has a before-and-after value. A configuration has version differences. A deployment has a timestamp. A State update can usually be recorded.

A necessary relationship is different.

Whether a relationship that should have remained valid still holds does not naturally leave behind the same kind of clean before-and-after comparison. The analyst must first know what correspondence was supposed to hold, and then determine whether that correspondence survived the change.

This is why incident explanations so easily stop at Change.

Change is easy to record and easy to point to. Relational failure requires an additional argument.

If diagnosis is driven only by what naturally leaves visible traces, it may repeatedly identify changes that genuinely occurred while still failing to answer the question that matters.

The problem is not that those changes are false.

The problem is that their existence does not automatically explain why the deviation was able to reach the real world.

This chapter therefore completes only one exclusion:

Change is removed from the position of Root Mechanism, while What changed? remains an entry point for localization.

That entry point retains real analytical value. In the current case pool, it has broad coverage and therefore deserves to appear early in the inquiry.

But the analysis cannot stop there.

It must continue by asking which necessary relationship failed to hold and at which mechanism position the failure ultimately appeared.

This is the first time in this book that something which looks sufficiently like an answer is explicitly removed from the position of cause.

The cost is not the loss of a tool.

It is the acceptance of that tool’s actual capability boundary.

Change helps tell us where to look next.

It does not answer the relational questions that follow.

The same skepticism can now be carried forward.

The third of the three questions does more than distinguish among Decision / Binding, Path, Boundary, State / Result, and Evidence / Proof. It also allows us to identify factors that merely amplify a deviation already present.

A system may execute faster. An Action may be replicated across a larger scale. These effects are just as visible as Change, and they are just as easy to place directly into the field labeled Cause.

But visibility is still not proof of causation.

The next question is therefore unavoidable:

If Change is not a cause, does AI become one when it makes the deviation faster and larger?

Chapter Terms

• Cause
• Change
• Analytical Dimension
• Root Mechanism
• Current Qualification

Cases and Sources

This chapter does not use real-world incident cases.

The situations discussed in the chapter—legitimate revision of Intent, normal State update, authorized parameter adjustment, and the re-establishment of Current Qualification after change—are hypothetical engineering situations used to test whether Change itself constitutes a cause of the Execution Gap.

They do not correspond to any specific company, product, incident, or public event. They are not part of the book’s formally verified case pool and therefore do not require external case sources.

Their role in this chapter is limited and specific: they show that genuine Change can occur without an Execution Gap necessarily arising.

They are used to distinguish an Analytical Dimension from a Direct Mechanism. They are not used to establish the frequency, prevalence, or universality of any real-world incident type.

---

Chapter 8 | What AI Amplifies, and What It Does Not Create

This chapter separates cause from Amplification. AI and automation can materially change the speed, scale, autonomous continuity, complexity, and reach with which a deviation propagates. But those effects answer the question of what an already established problem can become—not why the Execution Gap exists in the first place. The current evidence does not identify a Primary Root Mechanism of the Execution Gap that is unique to AI or automation. This is a Bounded Negative Finding, not a claim that no such mechanism could ever exist. Amplification is also not a Necessary Condition of the Execution Gap: a structural deviation can exist without significant amplification. Greater capability does not eliminate Fallibility, nor can it substitute for the relationships that must remain independently valid across an execution chain. AI is therefore not irrelevant, but its proper analytical position is on the amplification side rather than the causal side. The next task is to draw the boundary in the opposite direction: which wrong outcomes do not qualify as Execution Gaps at all?

The fact that something changed is not, by itself, a cause.

Once that conclusion is established, another candidate appears almost immediately:

Is it AI?

The question is not unreasonable.

Once AI and automation enter an execution chain, Actions can occur faster, continue with fewer interruptions, reach more objects, and proceed through longer stretches without natural human pauses. That makes another explanation especially tempting: if an error can now move faster, travel farther, and become harder to stop along the way, perhaps AI and automation are what created the problem.

What has to be examined is the unstated step in that inference.

To say that automation amplified a deviation is not the same as saying that automation caused the deviation.

The first statement describes what happens after the deviation is already present: the speed, scale, continuity, and reach with which it continues to propagate.

The second places AI and automation in the causal position.

In ordinary language, the two statements are easy to collapse into one another. Within the Execution Gap, they have to remain separate.

That distinction is the subject of this chapter:

What do AI and automation change, and what do they not create?

The negative boundary is more important here than the positive claim, because the argument can easily be misread in two opposite directions.

One reading makes AI itself the cause of the Execution Gap. Once that happens, the relationships already established around Intent, Authorization, Path, Boundary, State, and Evidence are compressed into a single model problem.

The opposite reading starts from “AI is not the cause” and concludes that AI is therefore unimportant, as though changes in propagation speed, automated continuity, reach, and opportunities for correction no longer matter.

Neither conclusion holds.

The task of this chapter is to place AI and automation back in the analytical position they can actually support.

Amplification Changes Propagation, Not the Formation of the Gap

The position taken in this book is a matter of analytical placement:

Amplification is a Cross-Cutting Modifier. It is not a Primary Root Mechanism.

It operates across the Direct Mechanism Families rather than joining them as another top-level mechanism.

The factors currently grouped under Amplification include speed, scale, cascade, feedback, tool depth, continuity of automation, and loss of opportunities for correction.

This is a list of what is currently included, not a closed set.

It is not frozen as an exhaustive enumeration, and its elements have not been assigned formal measurements, weights, or ordering. This chapter does not define a metric for consequence scope or a criterion for risk ranking. Once these factors are placed on a common scale, the discussion quickly shifts toward questions such as which factor is stronger, more severe, or more responsible.

Those are not claims this chapter establishes.

The factors themselves describe different things.

Speed changes how much time remains between the emergence of a deviation and its real-world effect.

Scale changes how many objects a single Action can actually reach.

Cascade describes whether a deviation is accepted by downstream systems and continues to propagate.

Feedback describes whether the Result re-enters a subsequent cycle as a new input.

Tool depth concerns how deeply an Action can reach into real-world resources.

Continuity of automation changes how many natural pauses remain in the execution process.

Loss of opportunities for correction concerns how many chances remain to detect and stop the deviation as it continues forward.

Each can materially change what happens after a deviation has been established.

But they still describe how the deviation propagates.

Two questions therefore have to remain separate:

Why does the Execution Gap exist?

and:

What does an already established deviation become as it continues to propagate?

Amplification addresses the second question.

It can change propagation speed, scope of impact, depth of propagation, feedback behavior, and opportunities for interruption. It does not define the Execution Gap in the first place.

For a deviation to constitute an Execution Gap, the analysis still has to return to the five Direct Mechanism Families and identify which necessary relationship in the execution chain failed to hold—and how that failure allowed the deviation to reach the real world.

Amplification does not perform that explanatory work.

It describes the conditions under which an already established deviation continues forward.

Consider two versions of the same execution process. In one, human confirmation remains between steps. In the other, those steps have been connected into a continuous automated chain.

If the same parameter has already become detached from the established Intent, the relational failure is the same in both versions.

What changes is the propagation condition.

The first may leave more opportunities to detect and stop the deviation. The second may allow it to proceed more continuously.

Automation changes how many opportunities for interruption remain before the deviation reaches the real world. It does not determine whether the necessary relationship has already failed.

For the same reason, slowing the process, reducing continuous execution, or adding human confirmation can alter the conditions under which a deviation propagates.

Those interventions do not, by themselves, explain the cause.

If the relationship has already failed, slowing the process does not reconnect it. It only changes where the failure might still be detected or interrupted.

Amplification therefore cannot be added as a sixth Direct Mechanism Family.

The five Direct Mechanism Families ask:

What structural failure allowed a deviation to reach the real world?

Amplification asks a different question:

Once the deviation exists, under what conditions does it continue to propagate?

Putting both into the same mechanism list would collapse where the break occurred into how fast and how far the consequences traveled afterward.

Change is not one of the five Direct Mechanism Families.

Amplification is not one of them either.

The former is an Analytical Dimension.

The latter is a Cross-Cutting Modifier.

The five families describe Direct Mechanisms.

This is also why the third question in the analytical method retains the possibility that a factor only amplified an existing deviation.

Exclusion from the top-level mechanism set does not make Amplification irrelevant.

After writing “automation amplified the deviation,” the analysis must still answer:

Which necessary relationship failed in this case?

A Real-World Case Without Significant Amplification

The preceding argument explains why Amplification should not be treated as a Primary Root Mechanism.

A different kind of evidence is needed, however, to answer another question:

Is Amplification a Necessary Condition of the Execution Gap?

That question requires a case in which an Execution Gap has already been established while Amplification is not meaningfully present.

Such a case exists.

The Waymo utility-pole collision and recall of May 21, 2024 is rated Qualified in this book’s verified case pool, based on NHTSA Part 573 Recall Report 24E-049.

Across the seventeen Qualified Cases, Amplification is rated Strong in twelve, Partial in four, and None in one.

That single None is Waymo.

The full joint distribution was presented in Chapter 6. Only the Amplification result matters here.

The significance of the case is not that it represents every form of the Execution Gap. Its significance is much narrower: it directly tests the claim that Amplification is necessary.

If Amplification were a Necessary Condition of the Execution Gap, it would have to be present in every established case.

A single case in which the Execution Gap is established while Amplification is rated None is enough to defeat that universal claim.

The conclusion supported by Waymo is therefore precise:

Amplification is not a Necessary Condition of the Execution Gap.

But that is also where the counterexample has to stop.

It does not establish that Amplification is irrelevant.

Within the same case pool, Amplification is rated Strong in twelve cases. One None defeats the claim “the Execution Gap cannot exist without Amplification.” It does not establish that Amplification is uncommon, unimportant, or without engineering significance.

Nor does the case establish that AI and automation can be ignored.

A factor can fail to be a Necessary Condition while still mattering greatly in real systems. Those are different judgments.

The Waymo case also cannot be used to infer consequence scale.

Two qualifications in the verification record must remain explicit. The case is used here as a non-catastrophic positive example, and the figure 672 refers to the scope of affected vehicles, not the number of collision incidents.

No metric for consequence scope or criterion for risk ranking is derived from those facts.

Nor does this single case prove the broader framework.

A real-world counterexample can place direct pressure on a universal proposition and, in this case, invalidate the claim of necessity. It cannot thereby establish that the full theoretical structure is complete.

The role of the case here is counterexample, not proof of the theory.

Waymo serves other analytical purposes elsewhere in this book. Those uses are not carried into this section.

Here, only its rating on the Amplification dimension is relevant.

The limited severity of the outcome does not weaken that role.

What is needed here is not a sufficiently catastrophic incident. It is a verified Execution Gap in which significant Amplification is absent.

Waymo provides exactly that counterexample.

That is enough to invalidate the universal claim that Amplification is a Necessary Condition of the Execution Gap.

Current Evidence Has Not Identified an AI-Specific Primary Mechanism

A harder question now follows.

Beyond amplifying Execution Gaps that can already occur, have AI and automation created a Primary Root Mechanism that exists only because they exist?

On the current evidence, the answer is no.

Across the existing case-based pressure tests, no Qualified Case has required the introduction of a new top-level mechanism in order to be explained. During the research, three candidate patterns initially appeared capable of exceeding the existing structure. On closer examination, however, each could still be decomposed into objects and relationships already present in the framework.

The first candidate was Evidence feeding back into subsequent authority.

At first glance, this can look like a new mechanism operating across execution rounds: Evidence produced by one execution changes the conditions under which a later Action receives authority.

But once decomposed, the pattern still consists of combinations among Evidence, Decision / Binding, authority and Boundary, and the subsequent Action. The fact that these relationships extend across multiple rounds does not require a new Primary Root Mechanism.

The second candidate was qualification inherited across organizational boundaries.

A qualification established for a subject in one domain may be accepted, transformed, or continued in another. Because the pattern crosses organizational boundaries, it can appear to introduce a new cross-domain mechanism.

The current evidence does not require that conclusion. The pattern can still be expressed through existing qualification relationships, Boundary, Amplification, and other objects already available to the analysis. Crossing domains changes the composition and scope of the problem; it does not, on the present evidence, require a new top-level mechanism.

The third candidate was a normatively invalid decision that is nevertheless executed faithfully.

This pattern also does not require a new Primary Root Mechanism under the current analysis. The existing structure remains sufficient to express it.

This chapter does not decide where such a case ultimately sits relative to the outer boundary of the Execution Gap. That is a separate question. The only conclusion retained here is narrower:

it does not currently require a new top-level mechanism.

The strongest conclusion supported by the present material is therefore only this:

Current evidence has not identified a Primary Root Mechanism of the Execution Gap that is unique to AI or automation.

This does not mean that AI and automation add nothing.

They can increase the complexity of an execution chain. They can create more points at which Change may occur, make actual Paths more variable, increase propagation speed, sustain more continuous feedback, and leave fewer opportunities for detection and correction.

A system that can choose its own tools, determine invocation order, and rewrite intermediate artifacts plainly introduces more objects and paths that have to be examined than a fixed script does.

But additional complexity does not automatically require an additional Primary Root Mechanism.

More points of Change still belong to the analytical question What changed?

Greater Path variability still requires analysis of the Execution Path.

Propagation speed, feedback, and opportunities for correction still belong to Amplification.

AI can make existing problems appear in more forms without thereby creating a new mechanism position.

The conclusion therefore has to be read together with its evidentiary boundary:

“Current evidence has not identified one” does not mean “none exists.”

This is a Bounded Negative Finding, not an impossibility proof.

Its scope is the current pool of seventeen Qualified Cases and the existing research corpus. Within that boundary, no case has required a new top-level mechanism in order to be explained.

Outside that boundary, this chapter makes no claim.

The conclusion is therefore not permanently closed.

If a future Qualified real-world case cannot be explained by the existing structure, the question of whether a new Primary Root Mechanism exists must be reopened.

The present evidence supports only the absence of a current evidentiary need for an additional top-level mechanism. It does not establish that such a mechanism could never appear.

Nor can this negative finding be used to lower the engineering requirements placed on AI systems.

No new Primary Root Mechanism has been identified says something about where the failure is localized. It does not say that those mechanisms are easy to control.

AI and automation can simultaneously increase points of Change, Path complexity, and propagation capacity, repeatedly placing already known relationships under pressure across shorter time intervals, longer chains, and more boundaries.

Knowing what the mechanisms are is not the same as having solved how those mechanisms fail.

What Greater Capability Does Not Change

There is a deeper temptation behind placing AI in the causal position: to treat the Execution Gap as a problem left behind by insufficient capability.

From that perspective, the path forward appears straightforward. If models make more accurate judgments, reason more effectively, and perform more complete self-checks, the problem should gradually disappear.

That inference combines two different things.

Greater capability can certainly improve performance on specific tasks. But the Execution Gap does not require the subject to have made an incorrect judgment in the first place.

A judgment may be valid within its own scope while the relationships involving Intent, Authorization, Path, Boundary, State, or Evidence later fail to preserve the correspondences that execution requires.

Chapter 1 established a more basic negative boundary: the legitimacy, authorization, qualification, or good faith of a subject is insufficient to establish the correctness of that subject’s judgment.

Capability belongs inside the same boundary.

A more capable model, a more reliable pipeline, or a more complete self-checking process does not, merely by being better at its own task, establish the correctness of the other necessary relationships across the execution chain.

This is what is meant here by the claim that greater capability does not eliminate Fallibility.

Fallibility is not another name for insufficient intelligence. It is a structural property of a subject operating with an incomplete relation to reality.

Greater capability may improve performance on particular tasks. It cannot structurally eliminate the possibility that the subject and reality may fail to correspond.

The scope of that claim must remain narrow.

It does not mean that every subject will necessarily make errors. It does not determine how greater capability changes the frequency of any particular kind of error. Nor is it a pessimistic judgment about the reliability of AI.

It establishes only one point:

Capability itself cannot substitute for the relationships that must remain independently valid across the execution chain.

For the same reason, the Execution Gap cannot be reduced to model hallucination.

Hallucination describes a particular kind of output distortion. The Execution Gap concerns whether the necessary relationships among Intent, Authorization, Action, Path, Boundary, State, Result, and Evidence continue to hold.

A system can exhibit an Execution Gap without hallucinating.

And a correct model output does not remove the need to verify the execution relationships that follow.

Reducing the entire problem to model error produces the same compression. It assumes that if the model itself becomes sufficiently correct, the remaining relationships will become correct with it.

They do not acquire that guarantee merely because model capability improves.

AI, Agents, and automation must therefore remain in the analytical position already established for them. They can increase points of Change, Path complexity, and propagation pressure. They can place existing relationships under greater stress across higher speeds and longer execution chains.

But capability alone does not elevate them into a Primary Root Mechanism of the Execution Gap.

Consequence Scope Remains an Open Question

Amplification has another side: once a deviation has reached the real world, how far do its consequences extend?

At that point, the question is no longer why the Execution Gap exists. The question is what happened to the scope of its consequences after the gap had already been established.

This book refers to that result-side concept as Blast Radius.

Its position has to remain precise.

Blast Radius is a result-side expression of Amplification. It is not a cause of the Execution Gap.

A large impact does not make an event more strongly qualify as an Execution Gap. Whether an Execution Gap exists is determined by whether the necessary relationships established earlier failed to hold.

Only after the gap has been established does the extent of the resulting consequence become a separate question.

That question remains partly unresolved.

This book does not yet define a formal method for measuring Blast Radius, nor does it establish criteria for deriving risk grades from it. Eight subordinate objects associated with this question also remain without formal ownership.

This chapter leaves those items open.

It does not supply missing answers merely to complete the structure, and it does not assign them to new theoretical objects before the research has established where they belong.

That restraint is necessary.

The moment a common scale for consequence scope is introduced, different incidents can begin to be ordered along the same axis. Once such an ordering exists, incidents with larger consequences can easily be mistaken for more representative or more definitive examples of the Execution Gap.

Amplification can then quietly re-enter the causal position from which this chapter has just removed it.

Two questions must therefore remain separate:

Why did an error become an Execution Gap?

and:

Once it became an Execution Gap, how large were the consequences?

They are not the same question.

Nothing is missing here that must be filled immediately.

The measurement of Blast Radius and the construction of risk-grading criteria remain open questions. The role of this chapter is to preserve that boundary explicitly, not to manufacture a scale simply because a complete-looking framework would be more convenient.

Not a Cause, and Not Irrelevant

By this point, three statements have to remain true at the same time:

Amplification is a Cross-Cutting Modifier.

Amplification is not a Primary Root Mechanism.

Amplification is not irrelevant.

Remove any one of the three, and the argument begins to drift in the wrong direction.

If the only conclusion retained is “AI is not the cause,” it is easy to slide into “AI therefore does not matter.”

That does not follow.

Amplification remains widely present in the current case pool, and AI and automation can materially change the speed, reach, continuity, and correction opportunities associated with a propagating deviation. The fact that they do not determine why the Execution Gap formed in the first place does not mean that they have no effect on what happens once the deviation continues into the real world.

The opposite mistake is equally serious.

If those effects are sufficiently visible and AI or automation is moved back into the causal position, the relationships established throughout the preceding chapters are once again compressed into questions of model capability and degree of automation.

Why a deviation was able to reach the real world still has to be explained through the necessary relationships among Intent, Binding, Path, Boundary, State, Result, and Evidence.

Amplification describes how the deviation continues to propagate once those relationships have failed.

AI therefore belongs on the amplification side of the analysis, not the causal side.

Amplification is a Cross-Cutting Modifier. It is not a Primary Root Mechanism, and it is not a Necessary Conditionof the Execution Gap.

The current evidence has also not identified a Primary Root Mechanism of the Execution Gap that is unique to AI or automation.

That conclusion remains bounded by its evidence. If a future Qualified real-world case cannot be explained by the existing structure, the question must be reopened.

At this point, the book has completed two exclusions.

Chapter 7 removed Change from the causal position.

This chapter removes Amplification from the causal position.

Neither exclusion removes the analytical value of the object involved. Both simply move it away from the set of Primary Root Mechanisms.

But the problem is not finished.

Up to this point, the analysis has assumed that the object under discussion already qualifies as an Execution Gap. Within that boundary, the book has asked what counts as a Direct Mechanism, what remains an Analytical Dimension, and what belongs only to Amplification.

A more fundamental question still remains:

Where is the outer boundary of the Execution Gap itself?

A wrong real-world Result does not automatically become an Execution Gap merely because it is wrong.

Some failures may not belong to the object this book is describing at all.

That is the boundary that has to be examined next:

What kinds of wrong outcomes do not qualify as Execution Gaps?

This chapter does not answer that question.

Chapter Terms

• Amplification
• Cross-Cutting Modifier
• Primary Root Mechanism
• Necessary Condition
• Bounded Negative Finding
• Fallibility
• Blast Radius

Cases and Sources

This chapter uses one real-world case.

Waymo Utility-Pole Collision and Recall | May 21, 2024

This chapter continues to draw on the pool of seventeen formally verified cases assembled during the research for The Execution Gap, with particular use of the Waymo utility-pole collision and recall.

The role of the case in this chapter is deliberately narrow: it is used to test whether Amplification is a Necessary Condition of the Execution Gap.

Across the seventeen formally verified cases, Amplification is rated Strong in twelve cases, Partial in four, and Nonein one. Waymo is that single None.

The case is therefore used only as a counterexample. It shows that a real-world event can still qualify as an Execution Gap without significant Amplification, thereby invalidating the universal claim that Amplification is a Necessary Condition of the Execution Gap.

The case is not used to establish that Amplification is irrelevant to the Execution Gap. Nor is it used to establish that AI or automation can be ignored. It is also not used to derive a measure of consequence scope, incident severity, or risk level.

The figure 672 in the case record refers to the scope of affected vehicles, not the number of collision incidents. The case is also used here as a non-catastrophic positive example.

Verification of the case is based on the U.S. National Highway Traffic Safety Administration (NHTSA) Part 573 Recall Report 24E-049.

The other situations discussed in the chapter—including a process with human confirmation between steps, a continuous automated execution chain, and a system capable of selecting its own tools—are hypothetical engineering scenarios used to clarify Amplification and the boundary of capability.

They do not correspond to specific companies, products, or real-world incidents. They are therefore not treated as formally verified cases and do not require separate external case sources.

---

Chapter 9 | What Does Not Count as an Execution Gap

This chapter defines the outer boundary of the Execution Gap from the negative side. Six kinds of situations do not enter this problem space merely because the outcome is bad: an ordinary bug without a relevant execution-relation failure; a legitimate change for which Current Qualification has been re-established; a normatively wrong upstream decision that the system executes faithfully; pure post-execution proof loss; successful resilience or recovery; and an information-side failure without an identifiable execution mismatch. These are Exclusion Boundaries, not another classification table, and exclusion does not mean that the underlying problems are unimportant. Tool invocation is likewise not a sixth mechanism position; whether a tool-related failure enters the Execution Gap still depends on whether an already established relationship has failed. Pure post-execution Evidence problems remain outside the core object by default, but if they later alter State assumptions, retries, recovery, or subsequent Actions, they may re-enter in a bounded way at the point where they begin to affect reality again. With these exclusions in place, the problem space of the Execution Gap acquires a defined shape for the first time.

The preceding chapters have approached the same problem from one direction:

Why can a deviation enter an execution chain and ultimately reach the real world?

That question has gradually been decomposed.

The Execution Gap does not reside at one isolated point of error. It appears in relationships that were supposed to remain valid throughout execution. Failures of those relationships can be localized across five Direct Mechanism Families, and those families are not mutually exclusive. Analysis therefore cannot stop at assigning an incident to a category. It has to continue asking what changed, which necessary relationship failed, and at which mechanism position the failure appeared.

Chapters 7 and 8 then removed two especially tempting candidates from the causal position. Change is an Analytical Dimension. Amplification is a Cross-Cutting Modifier. Neither can, by itself, explain why a deviation became an Execution Gap.

But one direction has still not been treated fully:

What kinds of wrong outcomes do not belong to the Execution Gap?

This is not a supplementary clarification.

It is necessary if the concept is to retain a boundary at all.

If the analysis can identify structures that may produce an Execution Gap but cannot identify what should remain outside it, then almost any bad outcome produced by an automated system can be drawn back into the concept. Software defects, bad upstream decisions, information errors, missing proof, and recovery actions can all begin to look like the same thing simply because something went wrong.

At that point, the concept appears to cover more.

In reality, it has lost its ability to localize anything.

This chapter therefore does not add another mechanism.

It turns instead to the outer boundary of the problem space.

The question is not which failures matter and which do not.

It is:

Given a bad outcome that has already occurred, what remains insufficient to make it an Execution Gap?

Six Exclusion Boundaries

Once the positive structure has been established, several situations that are especially easy to misclassify as Execution Gaps have to be marked off explicitly.

All six share the same basic limitation:

They do not automatically constitute an Execution Gap.

The six boundaries are not a new classification system.

They do not share a single axis of division, and they are not required to be mutually exclusive. They are listed together only because each can easily be pulled into the Execution Gap once a bad outcome is observed.

What carries the theoretical weight is therefore not the name on the left side of the table, but the Exclusion Boundary on the right: why the situation cannot be admitted automatically, and what still has to be established before it can enter the problem space.

Nor are these six boundaries an exhaustive inventory of everything that lies outside the Execution Gap.

A situation absent from the list does not thereby enter the Execution Gap. Conversely, a situation that initially falls under one of these boundaries is not necessarily excluded forever; further localization may reveal a specific mechanism through which it re-enters.

These are six points at which conceptual overreach requires particular restraint.

One distinction must remain explicit from the beginning:

“Not an Execution Gap” does not mean “unimportant.”

A failure may produce severe consequences while still belonging first to another problem space. An event may carry major engineering, legal, or governance significance without containing an execution-side deviation.

The issue here is membership in the problem space, not the severity of the real-world consequences.

Six Situations That Do Not Automatically Constitute an Execution Gap

The right-hand column cannot be compressed into a simple Yes / No field.

The first boundary requires further localization. The fourth depends on causal position. The fifth blocks two opposite errors at the same time.

Remove those qualifications and retain only the six names, and the Exclusion Boundaries immediately turn back into six labels.

Nor is this table a diagnostic workflow.

The six rows have no prescribed order. They do not specify when a judgment must be made, and they do not tell the analyst what action to perform at a particular step.

The table simply places six common points of conceptual misclassification side by side so that each can be examined separately.

It must also not be joined to the five Direct Mechanism Families from Chapter 4 to produce an eleven-item list.

The five Direct Mechanism Families answer one question:

Once an Execution Gap has been established, which structural relationship failed?

The six Exclusion Boundaries answer another:

Does the situation in front of us yet have sufficient grounds to enter the problem space of the Execution Gap at all?

One concerns internal mechanism.

The other concerns entry into the problem space.

They are not the same analytical object.

An Ordinary Bug Without Relevant Execution-Relation Failure

The first boundary can sound almost trivial.

It is not.

In fact, it is one of the strictest boundaries in this chapter.

A program contains a defect. The defect is triggered. The Result is wrong.

The position taken here is simple:

until further localization has been performed, that is not enough to enter the Execution Gap.

The reason for exclusion is specific. The analysis still has to show how the bug produced a failure in Decision / Binding, Path, Boundary, State / Result, or in-causal-chain Evidence.

The important word is further.

This boundary does not claim that ordinary software bugs are unrelated to the Execution Gap. It says that “there is a bug here” is not a localization conclusion.

The distinction becomes clearer in an actual investigation.

Suppose a piece of code truncates the decimal portion of a monetary value.

At that point, there is a bug. It is an implementation defect. If the defect is corrected and nothing further needs to be explained, the analysis can stop there.

Now consider a different case.

The truncated value is subsequently carried into the payment system as the approved payment payload, while the approval that had already been established applied to the original, untruncated amount.

At that point, the problem is no longer only that a software defect exists.

An established upstream object no longer corresponds to what is ultimately carried into reality.

That is the shape of a Decision / Binding Relation failure.

The same underlying defect therefore has a different analytical status before and after localization.

This exclusion is not final.

It imposes a requirement:

localize first, then decide membership.

After localization, many failures initially described as “ordinary bugs” may enter the Execution Gap because they can be shown to have produced a failure in one of the relevant execution relationships.

What remains outside are defects for which, after localization, no such relationship failure can be identified.

They remain defects.

They still require correction.

But the reason they require correction does not belong to the problem space defined by this book.

This boundary therefore blocks a broader misuse as well: treating Execution Gap as a new name for bug.

If every software defect could be called an Execution Gap merely because it produced a wrong outcome, then the term would add nothing beyond new terminology. The distinctions developed across the preceding chapters—relations, mechanism positions, Change, Amplification, and cause—would collapse at exactly this point.

Legitimate Change with Qualification Re-Established

The second boundary was already partly established in Chapter 7.

Change is an Analytical Dimension, not a Root Mechanism. Intent can be legitimately revised, State can update normally, and parameters can be adjusted within granted authority without creating an Execution Gap.

Chapter 7 asked whether Change itself is a cause.

The answer was no.

The question here is different:

When does a change belong inside the problem space of the Execution Gap at all?

The answer turns on one specific condition: after the object has changed, has it been reassessed and has Current Qualification been established for the object as it now exists?

That distinction separates two situations that may look almost identical from the outside.

A Policy may change. After the change, the new object, parameter, or scope may be reassessed, and the current Action may proceed on the basis of Qualification that has been re-established for that changed object.

That is a change.

It is not, merely by virtue of being a change, an Execution Gap—even if the modification is substantial or affects a wide scope.

Now consider the other case.

The Policy changes, but the Action currently being executed still relies on Qualification established before the change.

The old Qualification is now being applied to a new object.

At that point, the issue is no longer simply that something changed.

The Binding relation has failed.

What distinguishes the two situations is not the magnitude of the change.

Nor is it whether the process happened to include an approval step.

The question is whether the Qualification on which the current Action depends has been re-established for the current object.

This boundary is operationally important.

Configurations change. Policies change. Parameters change. The objects on which execution depends also change.

If every such change automatically carried the presumption that an Execution Gap might exist, the problem space would quickly be flooded by ordinary change management. The relational failures that the concept is meant to localize would become harder, not easier, to see.

The key distinction is therefore narrow:

Has Current Qualification been re-established for the object as it exists now?

A Normatively Wrong Upstream Decision That Is Executed Correctly

An upstream Decision may be wrong in a normative sense.

It may be unlawful. It may rest on inadequate evidence. It may be a decision that should never have been made.

The system may then execute that Decision accurately, without deviating from it at all.

The outcome can still be bad.

The Exclusion Boundary is that such a case belongs first to questions concerning the legality or normative validity of the upstream Decision and Authority.

The word first carries most of the weight here.

It does not mean that such a case can never enter the problem space of the Execution Gap. It identifies the first place to which the problem belongs.

The reason is straightforward: the correspondence that the execution side was required to preserve may, in fact, have been preserved.

The Decision said one thing.

The system executed that thing.

To determine whether execution deviated, the analysis compares what ultimately happened in reality with the Established Upstream Object. In this situation, the two may correspond quite closely.

What is wrong is the object being faithfully carried through.

Robodebt provides a real-world form of this boundary.

An unlawful and inadequately grounded upstream rule was faithfully automated, with serious and wide-ranging consequences. Automation was unquestionably involved.

But the case illustrates precisely why the boundary matters:

A bad outcome cannot, by itself, be rewritten as an execution deviation.

Robodebt appeared earlier in Chapter 1, where it served a different analytical purpose: it placed pressure on the meaning of deviation by forcing the concept to show what it excludes.

Its role here is different.

Here, Robodebt illustrates the third Exclusion Boundary: a normatively wrong upstream Decision that is nevertheless executed faithfully.

The same real-world event can serve different analytical purposes in different places. That does not make it a new case, and it is not counted again in any strength distribution.

The limits of the case must also remain explicit.

Robodebt does not establish that normatively wrong upstream Decisions are always excluded from the Execution Gap.

The exclusion here is by default, not final.

After further localization, such a case may still re-enter the problem space at a specific mechanism position if a relevant execution-side relationship failure can be identified.

This book does not provide a general rule for every such re-entry point, and it does not assume one has already been established.

Nor does Robodebt prove any broader claim made in this chapter.

It is a Boundary Case.

Its role is to draw a line, not to add evidentiary weight to the Qualified case pool.

Of the twenty candidate events examined during the research, seventeen entered the Qualified case pool and three were retained separately as Boundary Cases. Robodebt belongs to the latter group and therefore does not enter any strength count.

Nor is this the place to reconstruct the full history of the event.

Its complete factual chain, allocation of responsibility, and subsequent accountability processes are outside the scope of this chapter.

The case is used here for one purpose only:

to show what this Exclusion Boundary looks like in a real-world event.

Pure Post-Execution Proof Loss

The boundary begins with causal position.

The place of Evidence within the Execution Gap is determined by where it sits in the causal chain, not by the fact that it takes the form of Evidence.

The same missing record can therefore have a different analytical status depending on when and how it affects execution.

If Evidence fails before execution, and that failure contributes to an incorrect judgment or Action, it belongs inside the causal chain of the Execution Gap.

If Evidence fails during execution, and that failure produces an incorrect retry, recovery decision, or subsequent Action, it likewise belongs inside the causal chain.

But once the Execution Act has been completed and both reality and the Result are already determined, a purely post-execution inability to observe, prove, audit, or attribute what happened lies outside the core object by default.

For now, this third situation is recorded as Post-Execution Provability / Observability Failure.

The phrase recorded as is deliberate.

The expression has a name so that it can be referred to, but it has not been established as a formal concept, and this book does not create one here. Its current status is only that of a registered, unformalized label.

The default exclusion comes with a condition, and that condition must remain attached to it:

If the failure later produces an incorrect State assumption, retry, recovery action, or subsequent Action, it re-enters the Execution Gap at the point where it begins to affect reality again.

That re-entry condition cannot safely be separated from the exclusion itself.

If it is moved into a footnote, a callout, or a later summary, the reader may retain only the simpler half of the rule—“post-execution proof loss is not an Execution Gap”—and apply it even when the failure has already begun to influence subsequent execution.

The two statements therefore have to be read together.

At the same time, the re-entry condition is bounded.

It is not a general rule that every post-execution proof failure will eventually return to the Execution Gap. Nor does any sufficiently remote downstream influence qualify.

The condition identifies a specific point of re-entry:

the point at which the failure begins to affect reality again.

Turning that into a general principle would eliminate the Exclusion Boundary itself. Under a sufficiently loose interpretation, almost any missing record could be said to influence something eventually.

Nor does this boundary imply that post-execution proof loss is unimportant.

An event that has already occurred but cannot later be observed, proven, audited, or attributed can represent a serious engineering and governance problem.

What it does not necessarily represent is the structure that allowed the deviation to reach the real world in the first place.

That is the structure this book is trying to localize.

The criterion is therefore causal position, not the quality of the record and not the difficulty of reconstructing the event afterward.

After an incident, Evidence problems are easy to collapse into a single category.

Here, they still have to be separated according to where they entered the causal chain.

Successful Resilience and Recovery

The fifth boundary is short, but it blocks two opposite errors at once.

A system encounters a problem. It degrades gracefully, retries, rolls back, switches paths, or brings in human intervention. Eventually it recovers, and no lasting harm occurs.

Does the existence of that recovery mean that an Execution Gap must have occurred?

The Exclusion Boundary is two-sided:

Successful recovery neither automatically proves that an Execution Gap existed earlier nor erases an Execution Gap that already occurred.

The first half blocks an inference made backward from the recovery itself.

The fact that a resilience mechanism was triggered tells us that the system responded to some condition. It does not tell us what that condition was structurally.

Recovery may have responded to a fault that was detected and contained before any execution-side deviation reached the real world.

Treating the recovery action itself as evidence that an Execution Gap must have existed would create a perverse result: systems with stronger resilience mechanisms would appear to have more Execution Gaps simply because they detect and recover from more problems.

The second half blocks the opposite inference.

If an Action has already reached the real world in a way that constitutes an execution deviation, that event has already occurred.

Subsequent recovery can change its consequences.

It cannot change the fact that the deviation reached reality.

Even if the resulting harm is fully reversed, the structural position that allowed the deviating Action to reach the real world does not disappear retroactively.

Both halves of the boundary have to remain together.

Keep only the first, and the argument can turn into unwarranted suspicion of resilience engineering.

Keep only the second, and it can become an unlimited license to infer earlier Execution Gaps from any later recovery activity.

The boundary works only when both directions are preserved.

Information Advantage Without Execution Mismatch

The sixth boundary concerns a different kind of failure.

A system may be wrong on the information side. It may produce an incorrect representation, possess or expose information in a problematic way, or mislead a person who then makes a Decision that contributes to the eventual Result.

The Exclusion Boundary is:

If no deviation can be identified between an established Intent or Decision and real-world execution, the case does not enter the core object of the Execution Gap.

Moffatt v. Air Canada provides a real-world form of this boundary.

An incorrect representation entered the eventual Result through human action, but the chatbot that produced that representation was not established as possessing Action Authority over the real-world act itself.

The distinction is narrow, but it determines where the problem belongs.

The information-side error is real.

Its consequences are real.

What is missing is something different.

To say that execution deviated, the analysis must first identify an Established Upstream Object and then compare what ultimately happened in reality with that object.

When the system that produced the information has not been established as possessing Action Authority over the real-world act, the two sides required for that comparison have not yet been established.

This is not a case in which the comparison was performed and no deviation was found.

The comparison itself does not yet have both of the objects it requires.

The case does not establish that information systems can never possess Action Authority.

Nor does it establish that a legal judgment can be transferred directly into the theoretical framework of the Execution Gap. The two are different forms of judgment, supported by different grounds.

Moffatt v. Air Canada is therefore a Boundary Case here. It does not enter the strength counts, and it does not prove the theory.

This book also does not define what it ultimately means to possess Action Authority, who may hold it, or how it is established or withdrawn.

In this chapter, Action Authority is used only as a localization label: it marks why the comparison required for an execution-deviation judgment cannot yet be made.

The Upstream Object Must Be Identifiable

The sixth Exclusion Boundary contains a premise that reaches beyond that one row of the table.

To determine whether execution deviated, the analysis must be able to identify an Established Upstream Object—an Intent or Decision that had already been established before the execution occurred.

That object cannot be reconstructed from what observers later believe the Intent should have been.

It is not the Intent a reasonable person would have preferred.

Nor is it whatever everyone agrees, after the fact, ought to have governed the Action.

It must be an upstream object that was already established before the event and can be identified as such.

The DAO illustrates what happens when that premise is not satisfied.

The attacker’s Actions were executed by the protocol according to the rules as implemented. The resulting outcome conflicted sharply with social and governance expectations.

But that conflict does not, by itself, establish that execution deviated from the relevant actor’s Intent.

The difficulty is more fundamental: the governing Intent and the hierarchy of relevant norms were not uniquely established.

Whose Intent governs the comparison?

Which normative layer has priority?

Those questions remain unresolved within the scope of this analysis.

A comparison requires two established sides.

If one side is still unresolved because the analysis cannot yet determine which Intent is the Intent against which execution should be compared, then the comparison cannot begin.

That conclusion is entirely different from performing the comparison and finding that execution matched the upstream object.

The two must not be treated as equivalent.

The DAO does not establish that protocol execution can never constitute an Execution Gap.

Nor does it establish that governance disputes and execution deviation are unrelated.

Its role here is narrower:

when the relevant upstream Intent has not yet been established, an execution-deviation judgment does not yet have the comparison basis it requires.

This book does not attempt to resolve the broader questions that follow from that problem: what kinds of Intent exist, how they are formed, or how competing normative layers should be ordered.

Those questions remain outside the scope of this analysis.

Tool Invocation Is Not a Sixth Mechanism Position

After the preceding chapter, an obvious question arises:

What about Tools?

Here, Tool refers to an external capability interface that an AI Agent or automated system can invoke.

In current engineering language, Tool is a highly visible concept. A model invokes a Tool, the Tool changes external State, and when something goes wrong, “the tool call failed” can sound like a complete localization.

It is not.

Tool does not constitute a Primary Root Mechanism. Tool-related failures must be localized according to their actual causal position.

This judgment does not diminish the importance of Tools.

It addresses a semantic problem: the statement “a Tool was used” does not tell us where the Execution Gap occurred.

Treating Tool as a localization conclusion would add a sixth item beside the existing mechanism positions without identifying any new structural location. Problems that should be localized elsewhere would simply be absorbed into the label Tool.

The mapping has to remain concrete.

If a Tool request or its parameters are incorrectly generated or transformed, the problem belongs to Change and Decision / Binding.

If multiple Tools, each individually legitimate, are composed into an execution sequence that is unauthorized as a whole, the problem belongs to the Execution Path.

If permission to use a Tool expands into concrete power to produce a real-world effect, the problem belongs to the Authority / Qualification relation.

If the issue lies in dynamic Tool selection, recursive invocation, or the additional speed and depth that those behaviors introduce, it belongs to Amplification.

None of these mappings creates a new destination.

Each points either to an already established mechanism family or to Amplification, which has already been explicitly excluded from the Direct Mechanism Families.

That is the substance of the judgment:

Tool is a cross-cutting application context, and in some cases it can be treated as a subordinate form of Path. It is not an independent failure object.

The third mapping—Authority / Qualification—is used here only as a localization label.

It refers to a mismatch between the permission granted to use a Tool and the execution capability the Tool actually acquires. It does not introduce a broader theory of Authority, and this book does not develop one here.

This boundary sits next to the conclusion of Chapter 8.

Chapter 8 established that the current evidence has not identified a Primary Root Mechanism of the Execution Gap that is unique to AI or automation.

The present judgment goes one step further:

Tool itself does not constitute a new Primary Root Mechanism either.

That does not make Tools unimportant.

Tool requests, Tool composition, permission expansion, and dynamic invocation can move a problem into very different structural positions.

Precisely for that reason, the analysis cannot stop at the statement “a Tool was involved.”

It must continue with the question:

Where, specifically, did the problem occur?

Excluded Does Not Mean Unimportant

The three real-world cases used in this chapter come from very different domains: consumer law, blockchain governance, and public welfare administration.

All three involved serious consequences. All three attracted substantial public attention. None is a trivial technical failure.

Yet all three are kept outside the core problem space of the Execution Gap.

That is deliberate.

If the six Exclusion Boundaries were presented only in abstract terms, it would be easy to suspect that the theory was simply drawing a conveniently defensible perimeter around itself.

These cases place the exclusion judgment where it is harder to make.

Even when the consequences are serious, the analysis still has to ask a more specific question:

Was the problem actually produced by an execution-side deviation?

Only at this point does the distinction become fully visible:

“Not an Execution Gap” does not mean “unimportant.”

The three cases serve here as evidence for the ontological boundary of the problem space.

They do not enter the strength counts of the Qualified case pool, and they do not prove the theory.

Each illustrates a different reason for exclusion. They do not form a system among themselves, and they do not map one-to-one onto the six Exclusion Boundaries.

Treating them as representative cases for six corresponding boundary categories would create a structure that the analysis has not established.

The distinction also determines where the investigation should go next.

Once further localization establishes that a problem does not belong to the Execution Gap, the analysis does not end.

What ends is only the search for its explanation within this problem space.

The investigation should then return to the domain to which the problem actually belongs: the legality or normative validity of an upstream Decision, the reason post-execution proof cannot be obtained, or the reason an information-side representation came to be treated as a basis for real-world action.

Reading “excluded” as “unimportant” damages both sides of the distinction.

The Execution Gap loses localization power when it is used to explain problems that do not belong to it.

And the problems that genuinely require attention become harder to address when they are forced into the wrong problem space.

One Boundary Remains Open

The six Exclusion Boundaries established in this chapter do not close every question completely.

The re-entry condition attached to the fourth boundary remains only a Bounded Condition.

It identifies one specific point of re-entry:

the point at which a post-execution proof failure begins to affect reality again.

That is all it currently establishes.

The condition has not been generalized into a broader rule, and this book does not generalize it here.

Doing so would require answers to questions that the current material does not support. What kinds of downstream effects should count? How substantial must the effect be? Over what causal or temporal range should the rule remain valid?

Those questions are still unresolved.

Supplying answers merely to make the boundary appear complete would reduce, rather than improve, the clarity already achieved.

A related question also remains open.

The expression Post-Execution Provability / Observability Failure is currently only a registered label. It has not yet been established as an independent formal concept.

Whether it should eventually become one remains an open question at the level of formal theory.

This chapter does not answer that question, and it does not express a preference about how it should eventually be resolved.

A research boundary can be clear without every adjacent question already having an answer.

Leaving this issue explicitly open is more rigorous than assigning it a definition for the sake of apparent completeness.

Once an answer that has not yet been established is written into the theory, later analysis can easily begin treating it as a settled premise.

That is precisely what this chapter avoids.

The Problem Space Now Has a Shape

Taken together, the first nine chapters now reveal a recognizable boundary around the problem.

The inquiry began with a specific difficulty: every local check can appear correct while the final Result is still wrong.

From there, the book separated the objects that ordinary language compresses into the statement “it was executed.” It moved the location of deviation away from a single failure point and into the relationships that must remain valid across execution. It identified five Direct Mechanism Families, showed why some of them cannot be absorbed into one another, and established that the families are not mutually exclusive. Localization therefore requires multiple questions rather than a single classification table.

The analysis then removed two especially tempting objects from the causal position.

Change remains an Analytical Dimension.

Amplification remains a Cross-Cutting Modifier.

AI and automation can materially alter amplification conditions, but the current analysis does not place them in the causal position merely because they increase speed, continuity, complexity, or reach.

This chapter has now closed the problem space from the other side.

It has established six Exclusion Boundaries, retained the default exclusion and bounded re-entry condition for Pure Post-Execution Proof Loss, and clarified that Tool invocation does not constitute a new Primary Root Mechanism.

The problem space now has a shape.

It is not everything that goes wrong.

It is not every bad outcome produced by automation.

It is a problem space with a positive internal structure, an outer boundary, and explicitly registered open questions.

Once that shape becomes visible, however, another question that the preceding chapters have repeatedly approached without naming can no longer remain in the background.

Nearly every line of analysis points toward the same region:

the interval between something being established upstream and an Action acquiring effect in the real world.

Intent may be established.

Authorization may be established.

A Policy may match.

The prescribed Path may be followed.

The Boundary may remain intact.

And yet the Action that ultimately takes effect in reality may still fail to correspond to what had been established upstream.

What, then, is the thing by which that Action acquires real-world effect?

It is not Intent.

It is not Decision.

It is not Authorization.

It is not Policy.

It is not Path.

And it is not Boundary.

The preceding chapters have already separated those objects. Each may remain intact while the Action that reaches reality is still wrong.

Up to this point, the book has repeatedly circled this position without giving it a name or determining what kind of object it should be.

This chapter does not answer that question.

It does something more limited:

it makes the question impossible to avoid.

Chapter Terms and Usage

The terms below describe how specific expressions are used in this chapter. They should not be read as complete formal definitions.

Some expressions are used only as localization labels or provisional registered names. Their appearance here does not give them independent formal-concept status.

• Execution Gap
• Exclusion Boundary
• Qualification
• Pure Post-Execution Proof Loss
• Post-Execution Provability / Observability Failure A provisional registered name used in this chapter. It has not been established as a formal concept.
• Bounded Condition
• Action Authority Used in this chapter only as a localization label. No independent theory of Action Authority is developed here.
• Tool

Cases and Sources

This chapter uses three real-world cases.

All three are treated as Boundary Cases and serve an illustrative boundary function rather than as evidence proving the theory of the Execution Gap.

They do not enter the strength statistics of the Qualified case pool. Nor should they be used to infer that the six Exclusion Boundaries form an exhaustive classification.

The three cases also do not map one-to-one onto the six boundaries.

Robodebt

Robodebt is used in this chapter to illustrate the third Exclusion Boundary:

a normatively wrong upstream Decision that is nevertheless executed correctly.

The chapter does not attempt to reconstruct the full legal, policy, or accountability history of the event.

It uses only the point directly relevant to the boundary: an upstream Decision may itself be unlawful, inadequately grounded, or normatively defective, while an execution system nevertheless carries that already established Decision through faithfully.

A bad outcome is therefore insufficient, by itself, to establish an execution-side deviation.

The limited judgment illustrated by the case is:

A normatively wrong upstream Decision cannot be rewritten as an execution deviation merely because the resulting outcome is wrong.

This is a default placement, not a permanent exclusion.

If further localization identifies a specific execution-relation failure, the event may still re-enter the Execution Gap problem space at the relevant mechanism position.

Robodebt also appeared in Chapter 1. The same real-world event serves a different analytical purpose here and is therefore not counted again in any case-strength distribution.

Moffatt v. Air Canada

Moffatt v. Air Canada is used to illustrate the sixth Exclusion Boundary:

information-side failure without an identifiable execution mismatch.

The chapter uses only the portion of the case relevant to the execution boundary.

The chatbot produced an incorrect representation, and that information subsequently entered a real-world outcome through human judgment and action. But the available material did not establish that the chatbot itself possessed Action Authority over the real-world act.

What is missing, therefore, is not a comparison that was performed and found to contain no deviation.

The two objects required to make the execution-deviation comparison were not yet both established.

The case supports only the following limited judgment:

If no deviation can be identified between an established Intent / Decision and real-world execution, the case does not automatically enter the core object of the Execution Gap.

The case does not establish that information systems can never possess Action Authority.

Nor does it allow a legal judgment to be transferred directly into the theoretical framework of the Execution Gap. Those are different forms of judgment supported by different grounds.

The DAO

The DAO is used to illustrate a premise underlying the sixth Exclusion Boundary:

an execution-deviation judgment requires an identifiable Established Upstream Object.

In this event, the attacker’s Actions were executed by the protocol according to its existing rules, while the resulting outcome conflicted sharply with social and governance expectations.

That conflict alone does not establish that real-world execution deviated from an already established Intent of the relevant actor, because the governing Intent and the hierarchy of relevant norms were themselves not uniquely established.

The limited point illustrated by the case is:

When the upstream object required for comparison has not yet been established, an execution-deviation judgment does not yet have the comparison basis it requires.

The DAO does not establish that protocol execution can never produce an Execution Gap.

Nor does it establish that governance disputes and execution deviation are unrelated.

This chapter does not attempt to define types of Intent, explain how Intent is formed, or determine how competing normative layers should be ordered.

The concrete scenarios elsewhere in the chapter—including monetary-value truncation, Policy changes, recovery, retries, and related examples—are hypothetical engineering situations used only to explain the Exclusion Boundaries.

They do not correspond to specific real-world incidents, do not enter the formally verified case pool, and are not used as independent evidence.

The discussion of Tool invocation is likewise a mechanism-localization clarification rather than a real-world case or an independent source of evidence.

---

Chapter 10 | Execution Effect Should Be Treated as an Independent Engineering Object

This chapter brings *The Execution Gap* to its theoretical close. The Execution Gap describes a failure in the relationship between an Established Upstream Object and the specific Action that ultimately takes effect in reality. Execution Effect refers to something different: the fact that this particular Action acquires real-world effect and actually changes real-world State. The two must not be conflated. A deviation cannot be eliminated merely by continuing to strengthen upstream correctness—approval, Authorization, Policy, or other upstream judgments—because the unresolved problem does not reside inside those judgments themselves. This chapter therefore introduces Execution Effect as a working term and argues that it must be treated as an Independent Engineering Object. It deliberately stops short of providing a formal definition, a control point, decision criteria, or an engineering structure. Nor does the conclusion imply Per-Action Human Approval. Nine unresolved questions are handed forward explicitly. The first book ends at a clear boundary: the problem has been defined and handed off, while the solution has not yet been established.

The final line of the previous chapter brought a question into view and then stopped.

After nine chapters, the problem space of the Execution Gap has acquired a recognizable shape. What that shape reveals is not another kind of gap, but something that has never yet been treated as an object in its own right:

the fact that this particular Action takes effect in the real world.

Two terms must now be kept separate.

The Execution Gap describes a deviation: a relationship that should have remained valid between an Established Upstream Object and the specific Action that ultimately took effect in reality has failed.

The preceding nine chapters defined the boundaries of that problem space—where such failures can occur, which Direct Mechanism Families can describe them, what may amplify them, and what does not automatically belong to the concept.

Execution Effect is not another name for that deviation.

It refers to something else:

the fact that this particular Action acquires real-world effect and causes real-world State to change.

The first term describes a failed relationship.

The second points toward something that every real-world execution necessarily passes through.

The very possibility of an Execution Gap shows why the distinction matters. Intent, Decision, Authorization, Policy, Qualification, Path, and Boundary may each be valid within their own scope, yet none of them automatically substitutes for the treatment of the particular Action that ultimately acquires effect in reality.

This is not yet a formal definition of Execution Effect.

The task of this chapter is deliberately narrower: to explain why this object cannot continue to be absorbed into concepts that have already been established, why it has to be seen separately, and then to stop.

A book that spends its length defining a problem creates pressure at the end to offer a solution.

Once the problem has been made clear, the narrative itself seems to demand an answer to the obvious next question:

What should we do about it?

This chapter does not follow that pressure.

It stops not because the problem is unimportant, but because the material developed in this book supports the argument only this far.

A book about a problem that ends without a solution may feel incomplete.

A book that manufactures a solution before the necessary structure has been established may feel more complete.

The costs of those two choices are not symmetrical.

The first cost is borne by the book.

The second is borne by the people who rely on it.

Two conclusions established earlier are required before this chapter can proceed. Neither is sufficient on its own.

The first comes from Chapter 5:

Boundary can fail while Path remains normal.

A deviation can reach the real world entirely through the prescribed route, with every visible step appearing to align with the process.

The second comes from Chapter 9:

the problem space has an outer boundary.

The six Exclusion Boundaries, together with the default placement and bounded re-entry condition for Pure Post-Execution Proof Loss, prevent the Execution Gap from becoming a synonym for everything that goes wrong or every bad outcome produced by automation.

These two conclusions operate at different analytical levels.

The first tells us where deviation can occur.

The second tells us where the problem space ends.

With only the first, what follows could easily be misread as an argument for simply strengthening the Boundary.

With only the second, the theory could appear already complete.

Chapter 10 begins where both conclusions are true at once.

The Missing Position Is Not Inside Any Upstream Judgment

The first task is to locate the problem precisely.

Across the preceding nine chapters, the analysis has repeatedly returned to the same interval: the region after the relevant upstream objects have been established, but before real-world State has actually changed.

Intent may be clear.

A Decision may already have been made.

Authorization may be valid.

Policy may match.

Qualification may hold.

The prescribed Path may be followed.

The Execution Boundary may still be intact.

All of those statements can be true, and yet the particular Action that ultimately takes effect in reality may still fail to correspond to what was established upstream.

Chapter 1 encountered this first as a coarse observation: every local check may appear correct while the Result is still wrong.

Chapter 2 then separated the objects hidden inside the statement “it was executed,” showing that Commit, Invocation, Execution State, Receipt, Result, and Evidence cannot be treated as equivalent.

From Chapter 3 onward, the location of deviation moved away from a single failure point and into the relationships that must remain valid, eventually producing the five Direct Mechanism Families.

Taken together, those conclusions leave one question that has not yet been treated as an object in its own right:

Once the upstream objects have been established, what is it by which this particular Action actually takes effect in the real world?

This is not another form of the Execution Gap.

The Execution Gap describes a failure in the relationship between an Established Upstream Object and real-world execution.

The question here concerns the reality-facing side of that relationship itself:

this particular Action acquiring real-world effect.

That object does not reside inside any individual upstream judgment.

This is a statement about location, not degree.

Intent answers what is to be achieved.

Decision answers whether the Action is to be taken.

Authorization and Qualification answer whether the relevant subject, object, or Action satisfies established conditions for proceeding.

Policy answers whether the applicable rules are satisfied.

Path answers how the Action actually proceeds toward execution.

Boundary answers how far the Action may reach and what can still stop it.

Each object answers a different question, and each may be valid within its own scope.

But “should this particular Action take effect now?” is not identical to any of those questions.

It does not become answered merely because all of the upstream answers are already in place.

The crucial phrase is:

this particular Action.

Upstream objects may apply to an established request, subject, condition, or scope.

What ultimately changes reality, however, is always a concrete Action: directed at a specific object, under a specific State, with specific parameters, at a specific time.

The validity of the upstream judgments and the acquisition of real-world effect by that particular Action are therefore two things that cannot simply be collapsed into one another.

This does not imply that the problem must be caused by an upstream judgment becoming stale.

What counts as stale, and what follows from staleness, would themselves require separate analysis.

The only conclusion required here is narrower:

An upstream judgment being valid and this particular Action acquiring real-world effect are not the same object.

When deviation lies between those two, repeatedly rechecking the upstream judgments cannot make that position disappear.

The problem is not necessarily that those judgments were examined too loosely.

The object being sought was never located inside them in the first place.

This is why incident reviews can reach an uncomfortable result: every upstream record appears valid, no obvious process failure can be found, and yet what happened in reality is still wrong.

In that situation, “the process was correct but the Result was wrong” does not mean that the investigation has found nothing.

It establishes at least one important limit:

an explanation confined to already-valid upstream judgments will remain incomplete.

Strengthening the Upstream Does Not Reach This Position

Once this position becomes visible, a natural engineering response follows:

make the upstream stricter.

After an incident, it is easy to reach for familiar remedies: add another approval, narrow Authorization, make Policy more specific, or re-establish Qualification more frequently.

All of these interventions have something in common.

They improve the correctness of an upstream judgment.

That can be valuable.

If an incorrect Decision was approved, the Decision and its approval process should be examined. If an unauthorized invocation was allowed to proceed, Authorization should be examined.

Nothing in the Execution Gap makes those upstream objects unimportant.

The problem arises in a different situation:

the upstream judgments themselves already hold, while the deviation still occurs between them and this particular Action.

At that position, improving the correctness of the upstream judgments does not directly reach the unresolved object.

Approval answers whether the Action has been approved.

Authorization answers whether the relevant subject or Action has the required authority or Qualification.

Policy answers whether established conditions are satisfied.

The remaining question is different:

Should this particular Action acquire Execution Effect at the moment it actually enters the real world?

Those questions cannot automatically substitute for one another.

A stricter approval process can make approval more reliable. It cannot, by that fact alone, establish the real-world effect of this particular Action.

More precise Authorization can establish Qualification more accurately. It cannot, merely because Qualification holds, establish that the Action which ultimately occurs still corresponds correctly to that Qualification.

The same applies to Policy, Boundary, and the other upstream objects. Improving them makes the part of the system for which they are responsible more reliable.

It does not automatically answer a question they were never designed to answer.

Chapter 5 established the most counterintuitive side of this problem: a Path can remain completely normal while a deviation still reaches the real world.

The same structural fact matters here.

If no upstream judgment is itself wrong in a particular failure, making those judgments stricter still does not reach the position at which the deviation actually occurred.

This omission is difficult to notice precisely because upstream improvements are easy to describe.

An approval process can add another review.

Authorization can be narrowed.

Policy can gain additional conditions.

The system may genuinely improve along all of those dimensions.

But if how this particular Action acquires real-world effect has never been treated as an object in its own right, there is no equally explicit place at which to examine it.

A system can therefore improve across every dimension it has already named while leaving an unnamed position untouched.

The boundary of the argument must remain clear.

This chapter is not an argument against stronger approval, Authorization, Policy, or Qualification.

It makes a narrower claim:

improving upstream objects improves those objects; it does not follow that the acquisition of Execution Effect by this particular Action has therefore also been addressed.

The conclusion is a statement about location, not degree:

A deviation cannot be eliminated merely by strengthening upstream correctness when the deviation does not reside inside the upstream judgments themselves.

The Problem Space Is Established and Bounded

Before giving the newly exposed object a name, one question still has to be settled:

Have the preceding nine chapters established a problem space that can now be discussed in its own right?

Yes.

First, the problem space contains identifiable objects.

Chapter 2 separated the objects compressed into the apparently complete statement “it was executed.” Commit, Invocation, Execution State, Receipt, Result, and Evidence are not equivalent, nor can they be assumed to form a single sequence of stages.

Second, the problem space has a defined location.

The Execution Gap need not reside in one isolated point of failure. It can arise in relationships that were required to remain valid throughout execution. Failures of those relationships have been localized into five Direct Mechanism Families, and those families are not required to be mutually exclusive.

Third, the problem space has analytical boundaries.

Change is not itself a cause.

Amplification is not itself a cause.

AI and automation can amplify an existing problem, but their presence alone does not explain why an Execution Gap exists.

Chapter 9 then supplied the outer boundary from the opposite direction.

Not every bad outcome belongs to the Execution Gap. An ordinary bug, a legitimate change, a normatively wrong upstream Decision that is executed faithfully, Pure Post-Execution Proof Loss, successful recovery, and an information-side problem without an identifiable execution mismatch cannot be admitted merely because the outcome is bad.

At the same time, the problem space still contains explicitly registered open questions.

Several distinctions within Result have not yet been formally established. Post-Execution Provability / Observability Failure remains only a provisional registered name. Other adjacent questions do not acquire answers merely because this volume is reaching its end.

To say that the problem space is established and bounded therefore does not mean that the theory is complete.

It means that its shape can now be identified:

which problems belong here,

which problems do not enter automatically,

which positions have already been established,

and which remain open.

Two constraints that have run through the entire book must also remain in place.

First:

Malice is not a Necessary Condition of the Execution Gap.

The structural failures described in this book do not require a malicious subject. An attacker can certainly exploit these positions, but malice is not a prerequisite for the problem space to exist.

Second:

AI and automation are not Primary Root Causes of the Execution Gap.

The current evidence has not identified a Primary Root Mechanism that exists only because AI or automation is present. Their analytical position remains on the amplification side.

Reducing the Execution Gap to “the model made a mistake” would erase much of the non-model-specific structure established in the preceding chapters.

These two constraints matter because together they prevent the problem space from collapsing into another name for either AI safety incidents or malicious attacks.

Bounded does not mean complete.

Drawing the boundary means only that we can now distinguish what belongs to this problem space, what does not enter automatically, and which questions remain unresolved.

It does not mean that the unresolved questions have been solved.

Still less does it mean that the engineering structure required to address them has already been built.

A research boundary being established and an engineering problem being solved are two different things.

The order also matters.

Only after the scope of the Execution Gap has been constrained can the object identified in this final chapter remain narrow enough to avoid expanding into “everything that can cause a system to go wrong.”

Only now can the more precise question be asked:

Within an already bounded Execution Gap problem space, what should we call—and how should we treat—the thing by which this particular Action acquires real-world effect?

It Is Not Any of the Objects Already Established

The object can now be given a name.

For the purposes of this chapter, it will be called Execution Effect.

Execution Effect does not refer to the deviation that may occur during execution, nor does it refer to the Result produced afterward.

It refers to something narrower:

the fact that this particular Action acquires real-world effect and actually changes real-world State.

The term must first be kept distinct from Execution Gap.

An Execution Gap describes a failed relationship: a relationship that should have remained valid between an Established Upstream Object and the particular Action that ultimately took effect in reality no longer holds.

Execution Effect is not another name for that failure.

It points instead to the reality-facing side of the relationship—the particular Action actually entering the real world and acquiring practical effect.

When Execution Effect is realized in a way that no longer corresponds to the Established Upstream Object, an Execution Gap becomes visible.

The two are related, but they are not the same object.

One describes the deviation.

The other allows the particular real-world execution itself to be identified separately.

This is why the object cannot simply continue to be called the Execution Gap.

Doing so would collapse the problem back together with the real-world execution object involved in that problem.

The preceding nine chapters worked to separate those objects. Combining them again under a single term at this point would undo that distinction.

Several already established objects must therefore be excluded one by one.

Execution Effect is not Intent.

Intent answers what is to be achieved. The fact that a particular Action actually takes effect in reality is not identical to that Intent.

Execution Effect is not Decision.

A Decision may already have been established, but the existence of that Decision does not mean that the particular Action has already acquired real-world effect.

Execution Effect is not Authorization or Qualification.

Authorization and Qualification indicate whether a subject, object, or Action satisfies established conditions. Qualification holding does not itself constitute a change in real-world State.

Execution Effect is not Policy.

A Policy may match and may produce a clear judgment, while that judgment still remains distinct from the particular Action actually taking effect.

Execution Effect is not Execution Path.

Path describes how an Action reaches the execution position. Chapter 5 already established that a Path can remain entirely normal while a deviation still occurs.

Execution Effect is not Execution Boundary.

Boundary concerns how far an Action can reach and what can still stop it. Execution Effect concerns the Action actually entering reality.

Finally, Execution Effect is not Result.

Result can only be discussed after the Action has occurred. Chapter 2 already separated Result from the statement that an Action has been executed. Result therefore cannot substitute for the acquisition of real-world effect by the Action itself.

These exclusions are not intended to create a new classification system.

They establish only that none of the objects already defined can, by itself, absorb the fact that this particular Action acquires real-world effect.

Nor does combining those objects make Execution Effect a derivative of any one of them.

The conclusion required here is therefore more restrained than the claim that a wholly new ontology has been discovered:

The acquisition of real-world Execution Effect by this particular Action must be treated as an Independent Engineering Object.

Here, independent means only that the object must be examined, analyzed, and discussed separately.

The fact that Intent, Decision, Authorization, Qualification, Policy, Path, or Boundary has already been established does not mean that Execution Effect has thereby been addressed as well.

For this reason, Execution Effect remains first and foremost a working term in this book.

Its purpose is to make separately identifiable something that had previously remained compressed inside the phrase “it was executed.”

At this point, the object has a name.

It does not yet have a formal definition.

Naming Stops Here

The naming work is now complete.

This chapter has isolated the fact that this particular Action acquires real-world Execution Effect and has provisionally given that object a name.

That step accomplishes only one thing: something previously compressed into the phrase “it was executed” can now be discussed on its own.

But being nameable is not the same as being formally defined.

This book does not specify the control insertion point for Execution Effect.

Nor does it prescribe the exact moment in an execution chain at which Execution Effect should be judged.

The preceding analysis can identify the structural interval in which the question arises—after the relevant upstream objects have been established and before the real-world Action takes effect.

That is not the same as specifying when a system should intervene.

The latter already belongs to the design of a control structure.

This book also does not provide the decision criteria for Execution Effect.

The question “On what grounds should this particular Action now acquire real-world effect?” is real.

But answering it would immediately require further claims: which conditions count, how those conditions should be evaluated, and what relationships should hold among those judgments.

Those claims have not been established in this book.

Nor does this chapter specify which component, role, or mechanism should be responsible for Execution Effect.

It does not define the engineering structure that should connect Execution Effect with Intent, Decision, Authorization, Qualification, Policy, Path, or Boundary.

And it does not prescribe what the system should do when Execution Effect cannot be established.

The chapter therefore stops at a precise boundary:

Execution Effect has been identified, but it has not been formalized.

What this book provides is still a working term, not a complete formal definition.

A formal definition would require, at minimum, a clear boundary around the object, conditions under which it holds, and an account of its relationships with adjacent formal objects.

This book has not completed that work, and it does not write unestablished answers into the theory in advance.

The value of naming Execution Effect is therefore not that it solves the problem.

Its value is that the problem can now be pointed to precisely.

Chapter 2 performed a similar operation.

Before the phrase “it was executed” was decomposed, Commit, Invocation, Execution State, Receipt, Result, and Evidence could easily collapse into a single expression.

Separating them did not first change the system.

It changed the question: the problem could finally be stated with greater precision.

Execution Effect serves the same purpose here.

Before it was identified separately, analysis could continue asking whether Intent was clear, Decision was correct, Authorization was valid, Policy matched, or Path remained normal while still lacking a term for the narrower question:

Why did this particular Action ultimately acquire real-world Execution Effect?

Chapter 10 is responsible only for making that question possible.

How it should be answered lies beyond the boundary of this book.

This Does Not Imply Per-Action Human Approval

One interpretation has to be blocked explicitly because it follows too easily from the argument so far.

The preceding sections have established that valid upstream objects are not sufficient, by themselves, to establish that this particular Action should now acquire real-world Execution Effect.

An immediate response may therefore seem obvious:

if automated judgment is insufficient, require a human to confirm every Action immediately before it takes effect.

That conclusion does not follow.

The reason is already contained in the preceding argument.

Human confirmation is itself an Upstream Judgment.

A person may correctly inspect the request, parameters, approvals, and the State presented at the time. Within the scope of that judgment, it may be entirely reasonable to conclude that the Action may proceed.

But the presence of that judgment does not eliminate the possibility of a relationship failure between the upstream judgment and the Action that ultimately takes effect in reality.

Adding a human to the chain adds another judgment.

It does not change the position at which the problem exists.

This is not an argument against human participation.

Nor does it claim that human judgment is less reliable than automated judgment.

Human involvement can be valuable in many systems and many contexts.

The point here is narrower:

Human confirmation does not acquire a special power, merely by being human, that other upstream judgments do not possess.

If Intent, Decision, Authorization, Qualification, and Policy cannot individually establish that this particular Action should acquire real-world Execution Effect, then one additional human judgment cannot complete that inference merely because “a person approved it.”

Treating Per-Action Human Approval as the default final answer would therefore place another upstream object in front of the same unresolved position.

It would not, by itself, explain how that position has been addressed.

One further limitation must remain explicit.

What this chapter rejects is the inference:

“Execution Effect must be treated separately; therefore every Action must be individually confirmed by a human.”

It does not reject human involvement in general.

The first is an inference this chapter must block.

The second has never been a conclusion of this book.

Safety does not mean that every Action must receive a human click.

The negative argument stops there.

This book can explain why Per-Action Human Approval does not follow from the analysis developed so far.

It cannot go on to answer what should take its place.

The moment the book specifies who should perform the judgment, when that judgment should occur, which conditions should govern it, or what the system should do when the judgment fails, it has begun to design a control structure.

That work lies beyond the boundary of this book.

The result is intentionally limited but clear:

The fact that Execution Effect must be treated separately does not mean that every execution must be handed back to a human for individual confirmation.

How Execution Effect should ultimately be engineered is not answered here.

What This Book Still Does Not Resolve

At this point, the work this book set out to complete has been completed.

What remains is to state explicitly what it does not resolve.

Nothing in this section is new. Each of the nine questions below has already appeared somewhere in the preceding chapters—encountered, left open, or explicitly marked as outside the scope of this book.

Bringing them together here serves one purpose:

to make the handoff visible rather than leaving it as an omission at the end of the book.

For that reason, this is not a task list.

Placed side by side, the nine items can easily invite the wrong reading: the problem has now been fully decomposed, and what remains is simply to implement each item in turn.

That is not what bounded means.

A bounded problem space has a defined shape. It does not mean that the remaining work has already been decomposed into implementation tasks.

Each item below is followed by the reason it remains unresolved here—not by an assignment of ownership.

A complete engineering structure for Execution Control. The work of this book is to define the problem space that requires control, not to construct the engineering structure that controls it.

The distinction is not one of detail.

The first asks what must be dealt with.

The second asks how it should be dealt with.

The latter requires decision criteria, failure semantics, and structural constraints that have not been established in the material developed here.

A complete decomposition theory of Authority. This book uses Authority only as one of the upstream objects that may already have been established. It does not further decompose Authority internally.

What components Authority should contain, and what relationships should hold among them, would require a separate body of work.

Producing a plausible decomposition from the present material would risk turning an unestablished proposal into an apparently settled conclusion.

The full forms and governance of Evidence. Evidence appears in this book in a deliberately narrow role: when it enters the causal chain, it can influence an Action.

The book does not define all forms of Evidence, what counts as sufficient Evidence, who governs it, or the conditions under which it ceases to hold.

The Evidence-related mechanism discussed from Chapter 3 onward remains restricted to Evidence in the causal chain.

That restriction does not make the other questions unimportant.

It means they require separate establishment.

Complete failure and degradation semantics. Unknown, Missing, Expired, and Conflict have not been assigned complete execution semantics in this book.

What each state means at execution time, and how a system should respond to it, remain unresolved.

Those meanings and responses require a separate structure that the present material does not establish.

Threat models, failure matrices, invariants, and partial compromise. The Execution Gap has never required the presence of an adversary in order to exist.

The structural failures described in this book can arise without malice.

Once an adversary is introduced formally, however, additional questions immediately follow: which properties must continue to hold in the presence of an adversary, and which conclusions remain valid after parts of the system have been compromised?

Those are different verification problems and require a different body of evidence.

A theory of Intent types and formation. Intent is used here only as a normative reference against which the correspondence of a particular Action can be examined.

This book does not define the types of Intent, how Intent is formed, who holds it, or how it may be rewritten.

That limitation has been present since Chapter 1. It is not introduced only at the end.

A complete subject model and the closure conditions of Fallibility. This item differs from the others.

The book uses only the negative premise that a subject may be wrong.

The question of what conditions, if any, would allow the Fallibility of a class of subjects to be considered fully exhausted has neither been established nor adjudicated.

This is not merely work that the book has chosen to leave undone.

At present, the analysis does not have an answer.

Writing an unanswered question as though it already had one would be worse than leaving it explicitly open.

The attributes of the refusal point. Who holds it, when it is reachable, how much scope it covers, at what moment it can act, and whether it can be revoked are all unresolved here.

Chapter 5 approached the question of who can ultimately refuse and then stopped.

Continuing beyond that point would no longer be describing the Execution Gap.

It would begin constructing another layer of engineering structure.

A formal hierarchy among Technical Result, External State, and Business Result. Chapter 2 already established that Result compresses more than one object and explicitly left the minimum formal relationship among Technical Result, External State, and Business Result unresolved.

Its appearance here does not move that issue into Chapter 10.

Its theoretical location remains in Chapter 2; this section merely points back to it.

This item also differs from the preceding eight in one respect: it does not yet belong to any book in the current structure.

It belongs to a future formalization review that has not begun.

One additional interpretive risk must remain visible alongside these nine questions.

A reader may still conclude that the argument of this book implies Per-Action Human Approval.

The preceding section explicitly rejected that inference.

Rejecting it does not make the risk of misreading disappear. Every time the conclusions of this book are restated, the same inference can reappear.

It therefore remains something that must be actively guarded against.

One final clarification concerns ownership.

Some of these unresolved questions may indeed have designated owners in later work.

Ownership answers who is responsible for the work.

It does not determine what a reader must study first.

Connecting the nine items into a line would describe a division of work, not a reading order and not a chain of logical prerequisites.

This book does not depend on any later work in order to stand.

Within the boundary it has defined for itself, it is complete.

This Is Where the Book Stops

The preceding nine chapters have pursued one question:

When the relevant upstream objects may all be valid, how can a deviation still reach the real world?

This chapter takes the final step.

It does not introduce another form of the Execution Gap.

It does not construct a control architecture.

It does one thing only: it isolates the object that the preceding nine chapters left exposed:

the acquisition of real-world Execution Effect by this particular Action.

This book provisionally calls that object Execution Effect.

The distinction between Execution Gap and Execution Effect should now be clear.

An Execution Gap describes a failure: a relationship that should have remained valid between an Established Upstream Object and the Action that ultimately took effect in reality no longer holds.

Execution Effect does not describe that failure.

It points instead to the particular Action itself taking effect in the real world and causing real-world State to change.

The former is the problem space defined by this book.

The latter is the engineering object that becomes visible once that problem space has been progressively separated and bounded.

This is as far as the book can go.

It has shown why Execution Effect cannot simply be absorbed into Intent, Decision, Authorization, Qualification, Policy, Path, Boundary, or Result.

It has shown why strengthening upstream correctness cannot substitute for treating this object separately.

And it has explicitly blocked one of the easiest misreadings of the argument:

none of this implies that every Action must be individually confirmed by a human.

Many questions remain unresolved.

What would constitute a formal definition of Execution Effect?

What criteria should determine whether it holds?

How should it enter an engineering structure?

What should Unknown, Missing, Expired, and Conflict mean at execution time?

How should Execution Effect relate formally to the objects around it?

The end of this book does not answer those questions.

What remains, then, is the question toward which the preceding nine chapters have been moving:

If deviation occurs in relationships, and if no valid upstream object is sufficient by itself to establish that this particular Action should now occur, should the acquisition of real-world Execution Effect by this particular Action be treated as an Independent Engineering Object?

The conclusion of this book is sufficiently clear:

It should.

How that object should actually be taken up in engineering is not resolved here.

The preceding section has already made the missing work explicit. To continue by specifying structures, decision criteria, or handling semantics would cross the boundary this book has established for itself.

The end of The Execution Gap therefore does not mean:

the problem has been solved.

It means something different:

the problem has been defined clearly enough to be handed off explicitly.

Those are two very different kinds of ending.

The first would mean that inquiry can stop.

The second means that subsequent work can at least begin with a clear understanding of what it is trying to address.

That handoff does not transfer the completeness of this book to some future body of work.

The conclusions established here stand within their own defined scope. They do not depend on a later engineering structure to make them valid.

Even if the reader goes no further, the framework developed here can still be used independently: to determine whether a failure genuinely belongs to the Execution Gap, to localize the relationship in which a deviation occurred, and to exclude bad outcomes that should not automatically be drawn into this problem space.

Other work may continue from here and take up Execution Effect as an engineering object.

That is a continuation of the narrative, not a logical dependency.

Those later structures are not prerequisites for this book to stand, and this book does not prescribe their answers in advance.

What remains after The Execution Gap, therefore, is not a solution architecture.

It is a bounded problem space and an object that can finally be identified separately, but has not yet been fully formalized.

That may feel less satisfying than ending with a solution.

But for an engineering problem that has not yet been properly established, it is more important to know where the problem is, where its boundaries are, and which answers have not yet earned the right to be written down than to arrive too early at a framework that merely appears complete.

Something has been happening in every execution all along.

Every real-world Action passes through it.

Yet it has not been treated as an object in its own right.

Now it has a name.

And this is where the book stops.

Chapter Terms

• Execution Gap
• Execution Effect
• Execution Act
• Upstream Judgment
• Intent
• Decision
• Authorization
• Qualification
• Policy
• Execution Path
• Execution Boundary
• Independent Engineering Object
• Per-Action Human Approval

---

Cases and Sources

This chapter does not use any real-world cases.

The incident reviews, meetings, approvals, Authorization decisions, and particular Actions described throughout the chapter are general engineering scenarios used only to clarify the relationships among the Execution Gap, Upstream Judgment, and Execution Effect.

They do not refer to any specific company, product, incident, or publicly documented event.

No external case sources are therefore required for this chapter.

---

Appendix I | Terms and Usage

The terms used in this book do not all occupy the same theoretical level.

Some have been formally frozen in Version 1 of the Execution Control Engineering Terminology Specification and therefore have stable Chinese and English names together with minimum definitions. Some perform a defined role in the argument of this book but have not yet entered the formal-concept layer. Some are analytical labels used only to locate problems; they make discussion easier without thereby becoming theoretical objects. Others describe evidentiary strength, the current research status of a structure, or the role a case plays in the book rather than what a thing is. A small number are provisional names for objects that have become visible but have not yet been fully defined or formalized.

Treating all of these terms as if they occupied the same theoretical level would make it easy to draw conclusions stronger than those this book actually establishes.

The first purpose of this appendix, therefore, is not to expand the meaning of every term, but to identify its status and the argumentative weight it is allowed to carry in this book.

This appendix uses the following status labels:

Formal Concept — Frozen in Version 1 of the terminology specification, with a formal Chinese and English name and a minimum definition.

Book I Theoretical Term — Performs a defined role in the argument of The Execution Gap, but has not yet entered the formal-concept layer.

Analytical Label — Used to locate, describe, and index a problem. It is not itself a failure mechanism and does not automatically constitute a theoretical object.

Evidence Rating — Describes the degree to which a case supports a particular analytical or mechanism-level judgment.

Research Status — Describes the present degree of freeze applied to a research conclusion or structure, not an intrinsic property of the mechanism itself.

Working Term — A provisional term adopted so that an object that has not yet been fully defined can be discussed. It does not carry a formal definition.

Provisional Registered Name — A name assigned to an adjacent problem or candidate object that has been identified in the research, while leaving open whether it should later become a formal concept.

Ordinary Engineering Term — Used in its ordinary engineering sense. This book constrains the term only where necessary and does not create a separate theoretical definition for it.

Case Role — Describes how a case is used in the argument, for example as a positive case, counterexample, or Boundary Case. It is neither a failure mechanism nor a conceptual identity.

Book I Conclusion Language — Used to express a conclusion already established in this book or to mark an interpretation the book explicitly rejects. Appearance in a conclusion does not by itself elevate the expression to formal-concept status.

If a term is made to carry more argumentative weight than its status permits, that is an error of use. It does not give the term a stronger theoretical identity.

---

Core Terms

Execution Gap

Status: Formal Concept

A systematic space of possible deviation between an Established Upstream Object and the real-world execution and Result that ultimately follow.

An “upstream object” may include an Intent, Decision, Approval, Authorization, Policy, Qualification, or another object that has already been established within its own rules and scope. A “deviation” occurs when the Action or Result that ultimately appears in reality no longer preserves the correspondence that should have held with those established upstream objects.

The Execution Gap does not describe one particular error or one fixed failure mechanism. Its primary claim is more basic:

The fact that upstream objects are individually valid is not sufficient, by itself, to establish end-to-end execution and real-world Result correctness.

Boundary: The Execution Gap is not synonymous with model hallucination, missing permission, approval failure, temporal delay, a single point of failure, or any other individual implementation defect. Such factors may appear in particular cases, but none of them alone defines the Execution Gap.

Nor does this book place every bad outcome inside the Execution Gap. If the problem originates in an upstream Decision that is itself wrong and the downstream system merely executes that Decision faithfully, the seriousness of the real-world consequence is not sufficient, by itself, to establish the execution-side deviation described here.

Scope ruling: This book uses a single higher-order meaning. Narrower historical uses such as “approval-to-execution” or “authorization-to-execution” are retained as specific scenarios or historical entry points into the Execution Gap. They do not stand beside the higher-order meaning as a second formal definition.

Related terms: Established Upstream Object, Local Correctness, End-to-End Execution Correctness, Execution, Result.

Execution

Status: Formal Concept, with two subordinate expressions

The higher-order process by which expressions, judgments, and commitments enter into changes in real-world State.

Within this higher-order concept, this book distinguishes two objects:

Execution Process — The broader process beginning once something enters an identifiable execution path and continuing until a real-world Result is formed.

Execution Act — The particular act that actually changes real-world State.

These two objects must remain distinct. An Execution Process may continue, wait, retry, or be interrupted. An Execution Act concerns whether real-world State has actually been changed.

Boundary: Execution is not the same as Intent, Decision, Approval, Authorization, Policy, Commit, Invocation, or Result. Execution Process is also not the same as Execution Act. One boundary is especially important:

Result is an independent object. It is not a synonym for Execution Act, and it cannot be established merely from the fact that an Execution Act has occurred.

Historical material sometimes used “execution” to refer simultaneously to process, adjudication, real-world action, and Result. The distinctions made here exist so that these objects can be discussed separately. They do not imply that the historical material already contained this same layering.

Related terms: Execution Process, Execution Act, Commit, Invocation, Execution State, Receipt, Result, Evidence.

Result

Status: Book I Theoretical Term; internal structure not frozen

Result is an object distinct from the Execution Act.

This book establishes only one necessary negative boundary:

The fact that an Execution Act has occurred is not sufficient, by itself, to establish that the Result has been established.

Likewise, the existence of a Commit, Invocation, Execution State, or Receipt cannot substitute for the Result itself.

In real systems, the word “Result” may refer to different objects. For example:

Technical Result — A technical output returned by an executor or external system.

External State — A real-world state outside the system that has occurred or can be observed.

Business Result — Whether a real-world change is regarded, within a particular business context, as established, complete, or as having achieved the intended objective.

These three expressions are listed only to prevent them from being compressed into one another. This book does not establish a formal result taxonomy composed of these three objects, nor does it define a hierarchy, sequence, containment relation, or implication relation among them.

Open: There is currently no cross-system answer to questions such as when a Technical Result should be treated as stable or final, over what observational scope and time scale an External State can be confirmed, or by what rules a Business Result is established.

Accordingly, this book does not designate any one of these objects as “the true final result,” nor does it infer one automatically from another.

Related terms: Execution Act, Execution State, Receipt, Evidence.

Local Correctness / End-to-End Execution Correctness

Status: Book I Theoretical Terms; used as a pair

These terms are used primarily to express one negative relation:

Local Correctness ≠ End-to-End Execution Correctness

Local Correctness means that an Intent, Decision, Approval, Authorization, Policy, Qualification, or other object is valid within its own rules, inputs, and applicable scope.

End-to-End Execution Correctness addresses a larger question: whether those already-valid upstream objects ultimately preserve the correspondence that should hold with real-world execution and Result.

This book does not establish a positive theory of “correctness.” It establishes only the following limited conclusion:

The fact that one or more local objects are individually valid is not sufficient, by itself, to establish end-to-end execution and real-world Result correctness.

Boundary: This inequality denies only the automatic inference from “locally valid” to “end-to-end valid.” It does not mean that local judgments are unimportant, nor that local objects must contain an error. It also does not imply that some additional object, mechanism, or check must therefore exist.

Rewriting this negative relation as “adding mechanism X will guarantee end-to-end correctness” would exceed what this book establishes.

Related terms: Execution Gap, Established Upstream Object, Execution, Result.

Established Upstream Object

Status: Book I Theoretical Term

An upstream object that has been established within its own rules, inputs, and applicable scope and can therefore serve as a reference for later real-world execution.

Common examples in this book include Intent, Decision, Approval, Authorization, Policy, and Qualification.

The term is needed because deviation requires a reference. To determine whether real-world execution has deviated, it is not enough to ask whether the outcome was bad. One must also be able to identify:

Which Established Upstream Object did it deviate from?

If no such reference can be identified, an abnormal or severe real-world outcome is not sufficient, by itself, to establish the execution deviation described in this book.

Boundary: Saying that an upstream object has been “established” means only that it holds within its own rules, inputs, and scope. It does not mean that the object is necessarily correct in some higher-order normative sense, nor does it automatically establish that this particular Action should now occur under the current object, parameters, State, and Boundary.

Multiple upstream objects may exist at the same time, and they are not guaranteed to be mutually consistent. This term fixes the reference point for deviation; it does not merge all upstream objects into a single source of truth.

Related terms: Execution Gap, Local Correctness, End-to-End Execution Correctness, Intent, Decision, Authorization, Policy, Qualification.

Direct Mechanism Families

Status: Book I Theoretical Term
Research Status: Conditionally Frozen

Across the verified cases used in this book, five recurring relationship families are used to localize which relationship between an Established Upstream Object and real-world execution failed to continue holding:

Decision / Binding Relation Failure — An established Intent, Decision, Approval, Authorization, Policy, or Qualification no longer preserves the required correspondence with the object, parameters, target, State, semantics, source, or applicable scope of the current Action, while the original judgment is still able to drive subsequent real-world action.

Execution Path Deviation — The actual steps, order, actors, entry points, or chain of execution diverge from the path required for that particular execution.

Execution Boundary Failure — A boundary that should constrain which Actions, paths, or capabilities can reach reality, and which subjects can prevent real-world side effects, is missing, incomplete, ineffective, or altered for the current Action.

Execution State / Result Relation Failure — Distinct objects such as Execution State, Invocation, Commit, Receipt, External State, or Business Result are incorrectly collapsed, mapped, attributed, or interpreted, causing one local representation to be treated as sufficient evidence that another object has been established.

In-Causal-Chain Evidence / Proof Relation Failure — Evidence participating in a current judgment, execution, retry, recovery, or subsequent Action fails to preserve the required correspondence with the object, source, sequence, prior State, continuity, or real-world fact that it purports to prove.

Boundary: These five families are the research structure currently used in this book to localize direct relationship failures. They are not a proven complete universal taxonomy, and they do not imply that every future Execution Gap must remain permanently confined to these five families.

The families are not required to be mutually exclusive. A single failure may involve several relationship failures at once. They therefore must not be treated as an incident-classification table in which exactly one category may be selected.

Nor do the five families establish formal mechanism numbers or a fixed order. “Five families” refers only to the five mechanism families retained in the current research corpus. Their status is conditionally frozen, not permanently closed.

If future evidence reveals a Qualified case that the current structure cannot explain, or if one family is shown to be absorbable into another without loss, the structure may be reopened.

Related terms: Established Upstream Object, Execution Path, Execution Boundary, Execution State, Result, Evidence, Change, Amplification.

Change

Status: Analytical Label

Used to ask what changed in a failure.

The changed object may be an Intent, meaning, representation, object, parameter, target, State, context, Policy, Path, Boundary rule, Result, or Evidence. The purpose of the label is to help identify what differed before and after a deviation.

Boundary: Change itself is not a cause.

A legitimate revision of Intent, a normal State update, a parameter adjustment made under established rules, or the re-establishment of Current Qualification may all involve Change without producing an Execution Gap. Merely showing that “something changed” is therefore not sufficient to explain why a deviation was able to enter reality.

Change has broad coverage across the verified cases in this book, but that observation shows only that it is a useful analytical entry point. It does not establish that Change is a Necessary Condition of the Execution Gap, nor that Change itself caused the failure.

A case still requires further analysis: after the Change, which relationship that should have continued holding actually failed, and how did that failure become connected to real-world execution?

Related terms: Direct Mechanism Families, Decision / Binding Relation Failure, Execution Path, Execution Boundary, Result, Evidence.

Three Analytical Questions

Status: Analytical Label

This book repeatedly uses three questions in case analysis:

What Changed?
Used to identify which objects, conditions, representations, or States changed before or during the formation of the deviation.

Which Relation Failed to Hold?
Used to locate a break in a relationship that should have remained valid between two separately established objects—for example, between Intent and Approval, Approval and payload, prescribed Path and actual Path, Execution State and Result, or real-world fact and Evidence.

Where Does the Failure Sit?
Used to determine whether the failure is best localized to Decision / Binding, Execution Path, Execution Boundary, State / Result relation, In-Causal-Chain Evidence / Proof relation, or primarily to Amplification.

Boundary: These are analytical questions only. They do not constitute three dimensions, three layers, three stages, or three mechanism categories, and they do not have a fixed order.

The same case may be approached through all three questions at once, and the questions do not map one-to-one onto one another. In particular, Which Relation Failed to Hold? must not be confused with Decision / Binding Relation Failure: the first is a general analytical question; the second is one specific family among the five Direct Mechanism Families.

The purpose of these questions is localization, not the construction of a new coordinate system.

Related terms: Change, Direct Mechanism Families, Decision / Binding Relation Failure, Amplification.

Amplification

Status: Analytical Label; cross-cutting position, not a Direct Mechanism

Describes how an already-existing deviation may expand in impact, propagate faster, cascade, or become harder to detect and correct during subsequent execution.

Amplification factors observed in this book include speed, scale, continuous automation, feedback loops, tool-call depth, cascading propagation, and reduced opportunities for human or system correction. These are recurring patterns in the current case corpus, not a closed enumeration.

Boundary: Amplification is neither a Direct Mechanism of the Execution Gap nor a Necessary Condition.

It answers:

Why did an already-existing deviation become faster, larger, deeper, or harder to correct?

It does not answer:

Why was the deviation able to arise and enter real-world execution in the first place?

Amplification therefore cannot be placed beside the five Direct Mechanism Families as a sixth mechanism. A failure may involve substantial Amplification, or it may already constitute an Execution Gap without significant Amplification.

AI and automation primarily appear here in this book. They may increase execution speed, scale, continuity, path variability, and feedback intensity while reducing opportunities for correction. But the current evidence has not established a direct failure mechanism unique to AI or automation.

This is a Bounded Negative Finding: the current corpus has not identified such a mechanism; that does not mean no such mechanism could ever exist.

Related terms: Direct Mechanism Families, Change, Bounded Negative Finding, Blast Radius.

Exclusion Boundary

Status: Book I Theoretical Term

Used to describe circumstances in which an adjacent problem cannot, merely by being present, be treated as an Execution Gap.

The exclusion situations explicitly discussed in this book include:

• an ordinary defect without a relevant execution-relation failure;
• a legitimate Change for which Current Qualification has been re-established;
• a normatively wrong upstream Decision that is nevertheless executed faithfully by the downstream system;
• Pure Post-Execution Proof Loss occurring only after Execution and Result have already been determined;
• successful recovery or resilience that has already prevented an error from continuing into reality;
• a problem affecting information, representation, or human judgment without producing a real-world execution deviation.

These exclusions exist to prevent “Execution Gap” from expanding into another name for “all bad outcomes” or “all system problems.” They do not form a proven exhaustive exclusion taxonomy.

Boundary: Exclusion does not mean that these problems are unimportant, nor that they can never become related to an Execution Gap. It means only:

The presence of the phenomenon alone is not sufficient to establish an Execution Gap.

If a problem initially outside the Exclusion Boundary later causes a Decision / Binding failure, Execution Path Deviation, Execution Boundary Failure, Execution State / Result relation failure, or In-Causal-Chain Evidence / Proof relation failure and thereby begins to affect real-world execution, it should be reconsidered from that new causal position.

An Exclusion Boundary therefore does not decide “what category a problem belongs to” in the abstract. It asks whether the current event has already produced a deviation relationship relevant to real-world execution.

Related terms: Execution Gap, Direct Mechanism Families, Boundary Case, Pure Post-Execution Proof Loss.

Fallible Subject / Fallibility

Status: Formal Concept

A Fallible Subject is a subject capable of understanding, judging, authorizing, invoking, controlling, or executing Actions, but whose identity, Qualification, good faith, capability, or past performance alone cannot prove that every future specific judgment will necessarily be correct.

Fallibility is this limited fact: a subject may be wrong in a particular judgment, and that possibility cannot be eliminated merely through authentication, Authorization, good faith, high capability, or a long history of stable performance.

Humans, AI Agents, automated programs, administrators, external services, Policy engines, runtimes, and devices are examples discussed in this book. They are examples only. They do not form a closed set of Fallible Subjects, nor do they imply that the subject domain has been formally completed.

Fallibility is first an engineering premise, not a moral judgment and not an overall assessment of reliability.

Boundary: Fallibility is not the same as malice, compromise, untrustworthiness, frequent error, or inevitable error.

It denies only one inference:

Identity, Authorization, Qualification, good faith, capability, or long-term stable performance is not sufficient, by itself, to guarantee the correctness of a particular judgment.

This book therefore does not infer from Fallibility that subject autonomy should be reduced, that Per-Action Human Approval is required, or that the solution is to find a more trustworthy final subject.

A related boundary is equally important:

Whether a judgment is correct and whether that judgment has been given the power to change reality are two different questions.

Related terms: Established Upstream Object, Authorization, Authority, Action Authority.

Execution Effect

Status: Working Term; name frozen in Book I

Execution Effect is used to identify the following fact:

A particular Action ultimately acquires real-world effect and actually changes real-world State.

This position must be identified separately because the book repeatedly shows that valid Intent, Approval, Authorization, Policy, and other individually valid objects in the execution chain cannot automatically substitute for the question of how this particular Action ultimately acquires effect in reality.

Execution Effect is therefore neither a renaming of an existing upstream object nor a synonym for Execution Act, Result, or Execution Gap. Its function is only to isolate the reality-facing side on which an Action actually acquires effect so that this object can be discussed independently.

Boundary: This book does not establish a formal definition of Execution Effect. Nor does it establish its conditions of validity, decision rules, control position, responsible subject, Authority structure, or formal model.

The name Execution Effect therefore does not imply that:

• every execution must pass through a fixed stage called “Execution Effect”;
• a dedicated component that grants Execution Effect must necessarily exist;
• Execution Effect must be determined by a particular subject, Boundary, device, or control layer;
• any one mechanism is sufficient to guarantee correct Execution Effect.

All of those conclusions exceed what Book I establishes.

Execution Effect must also remain strictly distinct from the Execution Gap.

Execution Gap describes the systematic space in which deviation may arise between an Established Upstream Object and the real-world execution and Result that ultimately follow.

Execution Effect points to the other side: the fact that a particular Action actually acquires real-world effect and changes real-world State.

Here, Effect does not mean the “Result” or “consequence” produced by Execution, and it is not synonymous with Result. It refers to the Action acquiring effect in reality, not to the outcome observed after the Action has occurred.

Name status: Book I consistently uses 执行效力 / Execution Effect. The name is frozen within Book I. Freezing the name means only that the terminology remains stable; it does not mean that the formal definition, conditions of validity, or engineering structure of the object have been frozen.

Related terms: Execution Act, Result, Execution Gap, Independent Engineering Object.

Post-Execution Provability / Observability Failure

Status: Provisional Registered Name / Open

Used provisionally to identify a class of situations in which:

After real-world execution and its Result have already been determined, the system loses the ability to prove, observe, audit, or attribute the relevant facts.

This book currently places such purely post-execution loss of provability or observability outside the core Execution Gap problem space. The reason is not that the issue is unimportant. It is that a proof or observability loss occurring only after the real-world Action and Result are already complete does not, by itself, alter that execution.

The name therefore exists only so that an adjacent problem can be discussed. It does not constitute a new Direct Mechanism and has not been established as a formal concept.

Re-entry condition: Whether the problem later re-enters the Execution Gap depends not on whether it looks like an “Evidence problem” or an “observability problem,” but on whether it once again participates in the real-world causal chain.

If missing post-execution proof or observability later causes an incorrect State judgment, duplicate execution, incorrect recovery, or a subsequent Action, analysis should resume from the point at which the issue begins affecting real-world execution again.

In other words:

What determines whether it belongs to the Execution Gap is causal position, not form.

Open: This book does not decide whether this class of problem should later become an independent concept, a separate theoretical object, or a distinct engineering structure.

Related terms: Evidence, Result, Exclusion Boundary, In-Causal-Chain Evidence / Proof Relation Failure.

---

Related Engineering and Analytical Terms

Intent

Status: Formal Concept

An expression of the Action, object, parameters, conditions, or Result that is intended to occur.

Intent may be genuine, clear, and attributable to a known source, but those properties are still not sufficient, by themselves, to establish later Authorization, Execution Act, or real-world Result.

Boundary: A subjective goal, expressed Intent, Authorization, real-world Action, and Result are distinct objects. Intent serves in this book as an important upstream reference, but it does not thereby become the source of final execution Qualification. This book does not develop a theory of Intent types, formation, or ownership.

---

Decision

Status: Ordinary Engineering Term; used in this book as an upstream object

The judgment at the level of whether something should be done.

This book treats Decision, together with Intent, Approval, Authorization, Policy, and Qualification, as an upstream object that may already have been established. It does not create a separate new theoretical definition of Decision.

Boundary: A Decision having been made does not mean that this particular Action has therefore acquired real-world execution Qualification.

---

Authorization

Status: Formal Concept

The qualification boundary used to determine whether a subject is permitted to possess or use a class of capability.

Authorization being valid establishes only that the relevant Qualification holds within its applicable scope. It does not automatically establish that a particular Action should occur under the current object, parameters, State, and Boundary.

Boundary: Authorization is not the same as Authority, actual execution capability, or the final Qualification of a particular Action. Long-lived Authorization in particular must not be automatically interpreted as “every later specific execution should be allowed.”

---

Authority

Status: Formal Concept

The power, within an explicit scope, to make decisions about Actions, rules, State, or Boundaries that are binding on the system.

Here, Authority is used only in its engineering sense. It does not refer to prestige, expertise, or social authority.

Boundary: Authority is not the same as permission, capability, or Authorization. Possessing Authority also does not establish that every particular judgment made by its holder is correct.

Book I preserves one negative distinction above all:

Qualification, judgment, and the power to change reality must not be assumed to be the same object.

Book I does not complete a formal decomposition theory of Authority.

---

Policy

Status: Formal Concept

An object that expresses execution decision rules and the conditions under which they apply.

Policy may participate in adjudication, but it is not the fact itself, nor does a matching Policy automatically become the final Authority for a particular Action.

Boundary: A Policy cannot prove that its own input facts are correct. Nor can its existence or successful match, by itself, establish that a real-world Action should occur.

---

State

Status: Formal Concept

The set of facts and conditions, at a particular point in time, that are directly relevant to whether an Action can be judged and executed.

State prevents previously valid Authorization, Policy, or judgment from being used indefinitely without regard to current real-world conditions.

Boundary: State here is not all internal system data and is not merely a database snapshot. Which sources, versions, timestamps, freshness conditions, conflicts, or partially visible facts must be included is not fully defined in Book I.

---

Qualification / Current Qualification

Status: Analytical Label

Used to describe whether a subject, object, or Action satisfies already-established conditions.

The emphasis in this book remains on current. A Qualification having held earlier does not automatically prove that it still holds for this particular Action now.

Boundary: This book does not establish Qualification as an independent theoretical layer. Its role in a concrete case must still be analyzed through Decision / Binding relations, Execution Boundary, and current State.

---

Execution Path

Status: Analytical Label

Describes how a particular execution actually proceeds, including its steps, order, actors, entry points, and chain.

Boundary: The presence of multiple steps, a long causal chain, or complex invocation does not by itself constitute Execution Path Deviation.

A wrong object can propagate entirely along a normal Path.

The judgment Execution Path Deviation should be used only when a divergence can be identified between the actual Path and the Path required for that particular execution.

Path asks:

How did this particular request actually proceed?

It does not answer who constrains the system as a whole, and it is not the same as Execution Boundary.

---

Execution Boundary

Status: Formal Concept

A boundary that constrains the State, parameters, Qualification, and permissible scope of an Action before it becomes real, and that can genuinely allow or prevent real-world side effects.

Its central question is:

Which Actions, Paths, and capabilities are constrained by what, and who can ultimately refuse?

Boundary: Execution Boundary is not the same as a login boundary, access boundary, Policy boundary, Tool interface, or ordinary network boundary, nor must it be tied to any particular hardware implementation.

Execution Path and Execution Boundary answer different questions:

Path asks, “How did this particular request proceed?”

Boundary asks, “What is constrained, and what can stop it from entering reality?”

Book I uses the concept to localize the problem. It does not answer the engineering-design question of who should ultimately refuse.

---

Boundary Mutation

Status: Book I Theoretical Term; a strong manifestation of Execution Boundary Failure

A change to the rule or implementation structure that originally determined the permissible Path, capability scope, or final refusal relationship.

Boundary: Boundary Mutation is one form of Execution Boundary Failure, not a synonym for it.

An Execution Boundary may fail because it is missing, incomplete, or ineffective without requiring that the original Boundary was ever “mutated” during operation. Not every Boundary failure may therefore be retrospectively classified as Boundary Mutation.

---

Evidence

Status: Formal Concept

Material capable of supporting verifiable claims about pre-execution conditions, execution judgments, Boundary State, real-world Actions, or Results.

Evidence is not synonymous with a log, nor with any data that happens to have been recorded.

Boundary: The existence of a record does not establish that the recorded fact is true. The existence of a Receipt does not establish complete execution Evidence.

Evidence itself also does not determine whether an Action should occur.

Book I focuses on one limited position:

When Evidence enters the causal chain of a current judgment, execution, retry, recovery, or subsequent Action, the relationship between that Evidence and the object it purports to prove can directly affect real-world execution.

This book does not establish a complete theory of Evidence forms, storage, or governance.

---

Commit

Status: Ordinary Engineering Term

The fact that a request, Decision, or Action has been committed, accepted, or recorded on one side of a system.

The term is used primarily to prevent “committed” from being compressed into “invoked,” “executed,” or “Result established.”

Name note: Book I consistently uses 提交 / Commit. The name is frozen within Book I.

---

Invocation

Status: Ordinary Engineering Term

The fact that a request has been sent or invoked against the next execution object.

Boundary: An Invocation establishes only the Invocation itself. A request being sent, the receiving side accepting it, a real-world Action actually occurring, and a Result being formed may all be different facts.

Invocation therefore cannot substitute for Execution Act, Execution State, Receipt, or Result.

---

Execution State

Status: Analytical Label

The system’s representation or judgment of the current progress of a particular Action.

Execution State may represent not executed, committed, invoked, partially executed, complete, or unknown.

Boundary: Execution State is a representation of fact, not the fact itself.

One state must be preserved explicitly:

Unknown.

Unknown must not be interpreted automatically as success or completion merely because it is inconvenient to handle.

---

Receipt

Status: Ordinary Engineering Term

A statement from an external source about whether a request has been received, processed, or returned with some state.

Boundary: A Receipt may be authentic, complete, and verifiable, but the scope of what it proves still depends on the semantics of the Receipt itself.

A Receipt therefore cannot automatically substitute for the real-world Action or Result.

The basic distinction preserved by this book is:

Execution Act ≠ Execution State ≠ Receipt ≠ Evidence

Result likewise cannot be substituted by Commit, Invocation, or Receipt alone.

---

Transformation / Temporal Gap / Seam / Relation

Status: Analytical Labels

Used to describe where deviation may occur.

Transformation emphasizes a change in representation or meaning between two objects.

Temporal Gap emphasizes that conditions that once held may no longer hold after time has passed.

Seam emphasizes that two objects that are individually valid may still require an additional relationship at the point where they connect.

Relation is the higher-order location language that covers these positions.

Boundary: These four terms are location language, not four failure mechanisms.

They help move analysis from the inside of individual objects to the relationships between them. They do not substitute for a mechanism-level judgment.

---

Single-Point Vulnerability / Single Point of Failure

Status: Ordinary Engineering Terms

These terms are used primarily to show that execution deviation does not occur only inside a single component, vulnerability, or fault point that can be circled in isolation.

Component-level failures can certainly exist. But when multiple objects are individually valid and the outcome still deviates, searching only for a Single Point of Failure may be insufficient to explain the problem.

Historical material also uses the expression Single-Point Catastrophic Execution. It is not the same concept as a conventional Single Point of Failure, and Book I does not develop it here.

---

Internal Validity

Status: Analytical Label

Means that a judgment, object, or State is valid within its own rules, inputs, and applicable scope.

This is important analytical language in Book I because the book is concerned precisely with the fact that:

Internal validity of the objects does not automatically establish that the relationships between those objects remain valid.

---

Tool

Status: Ordinary Engineering Term; cross-layer application context

A Tool does not constitute a new Direct Mechanism.

The fact that a Tool was invoked also cannot serve as an Execution Gap classification.

A Tool-related problem must instead be localized according to its actual causal position. For example:

• if the request, object, or parameters changed, analysis must continue by asking whether a Decision / Binding Relation Failure occurred;
• if the actual Tool-call Path diverged from the Path required for that execution, it may enter Execution Path analysis;
• if capabilities obtained through the Tool prevented existing constraints from continuing to block a real-world Action, Decision / Binding relations or the Execution Boundary must be examined;
• if dynamic selection, recursive invocation, or continuous automation mainly increased speed, depth, or cascade, the dominant effect may be Amplification.

A Tool does not become a sixth Direct Mechanism merely because Tool use is an important capability of an AI Agent.

The relevant questions remain:

What changed? Which relation failed to hold? How did the actual Path form? What Boundary allowed the Action ultimately to enter reality?

---

Action Authority

Status: Analytical Label

Used to determine whether a subject or system actually occupies a position from which it can directly change real-world State.

This book uses the label mainly in Boundary Cases to distinguish between:

influencing a human judgment

and

being able to directly drive a real-world Action.

Boundary: Action Authority is a localization tool only. It does not constitute a formal decomposition of Authority and does not establish a new hierarchy of Authority.

Name note: Book I consistently uses 现实动作权 / Action Authority. The name is frozen within Book I.

---

Blast Radius

Status: Formal Concept

The range of real-world impact that an erroneous, compromised, or unconstrained execution could potentially produce.

Blast Radius concerns how far the effects of a deviation could extend if it continues into reality, not merely where the initial error occurred.

Boundary: Blast Radius is not failure probability, not attack surface, not a fixed numerical metric, and not the same as actual loss already incurred.

It describes potential scope of impact. It does not directly calculate the value of loss or determine whether the associated risk is acceptable.

---

Strong / Partial / None

Status: Evidence Rating

Used to describe how strongly a particular case supports a specific analytical or mechanism-level judgment.

Strong means that the available material supports the judgment relatively directly.

Partial means that relevant evidence exists, but it is not sufficient to establish the judgment fully, or the available material contains important limitations.

None means that, in the current case and on the available evidence, the judgment has not received sufficient support.

Boundary: These ratings describe evidentiary support, not:

• incident severity;
• risk level;
• importance;
• causal ranking;
• mechanism priority;
• degree of responsibility.

A mechanism receiving a rating of None in one case means only that the available evidence does not establish that mechanism judgment in that case. It does not mean that the incident is unimportant, or that the mechanism does not exist in other cases.

---

Conditional Freeze

Status: Research Status

Indicates that a research structure is, under the current evidence and corpus, temporarily protected from casual addition, splitting, or renaming.

For example, the five Direct Mechanism Families are conditionally frozen. On the current research basis, the structure should not be changed merely because of one paper, one case, or narrative convenience.

Boundary: Conditional Freeze describes the current status of the research conclusion, not an ontological property of the mechanism, and it does not mean that the structure can never be modified.

Reopening normally requires stronger grounds, such as:

• a new case that the current structure cannot explain;
• evidence that one mechanism can be absorbed into another without loss;
• new evidence showing that an existing boundary can no longer be maintained.

A single new article, a wording difference, or a structural change made only for writing convenience is not sufficient by itself to reopen the structure.

---

Bounded Negative Finding

Status: Analytical Label

Used to mark conclusions of the following form:

Within the current evidence and research corpus, a particular object, mechanism, or phenomenon has not been identified.

The conclusion must be interpreted within that evidentiary boundary.

Boundary:

Not identified in the current corpus ≠ impossible to exist.

Accordingly, statements such as “the current evidence has not identified a direct failure mechanism unique to AI or automation” hold only within the scope of the current research material.

Rewriting such a statement as “no such mechanism exists” or “no such mechanism can exist” would materially strengthen the conclusion beyond what this book establishes.

---

Necessary Condition

Status: Ordinary Engineering Term

This book mainly uses the concept in negative form:

A given factor is not a Necessary Condition of a particular class of failure.

A single Qualified case in which the factor is absent while the failure still holds is sufficient to reject the claim that the factor is necessary.

Boundary: Denying necessity does not prove that the factor is unimportant, nor that it never participates in other cases.

---

Boundary Case

Status: Case Role

Used to test whether a problem adjacent to the Execution Gap should be admitted automatically into the problem space.

The primary purpose of a Boundary Case is not to prove the theory, but to force the theory to explain:

What cannot, merely by being present, count as an Execution Gap?

Boundary: A Boundary Case is not a Direct Mechanism and is not included in the evidence-strength statistics of the verified positive case pool.

Combining Boundary Cases with positive cases in one strength count would change the meaning of the case analysis.

---

Independent Engineering Object

Status: Book I Conclusion Language

The final chapter of Book I concludes that the fact of a particular Action actually acquiring real-world effect must be treated as an Independent Engineering Object.

Here, independent has one limited meaning:

It must be seen, analyzed, and discussed separately, rather than treated as a natural by-product of Approval, Authorization, Policy, or other upstream objects being correct.

Boundary: This conclusion does not mean that Book I has established a new formal object, nor does it answer:

• who should own it;
• where it should be judged;
• when it should be judged;
• what information should be used;
• what mechanism should implement it.

Those questions belong to later work.

---

Per-Action Human Approval

Status: Book I Conclusion Language; explicitly rejected interpretation

The requirement that a human re-confirm or re-approve every particular Action before it occurs.

Book I does not imply Per-Action Human Approval.

The fact that valid upstream objects are insufficient, by themselves, to establish correct real-world execution does not imply that every Action must therefore be returned to a human.

Boundary: Rejecting this interpretation does not reject the role of humans in the system, nor does it mean that Book I has already supplied an alternative solution.

This book rejects two inferential jumps:

A subject can be wrong; therefore subject autonomy must be reduced.

and

Automated execution can be risky; therefore every Action must receive Per-Action Human Approval.

Neither conclusion has been established in Book I.

---

A Note on Usage

The terms in this appendix do not share the same theoretical identity, and therefore cannot carry the same argumentative weight.

Formal Concepts may be used according to their frozen minimum definitions.

Book I Theoretical Terms carry argumentative force only within the scope established in this book. They do not automatically become formal concepts of a complete theory of Execution Control.

Analytical Labels are used to locate, describe, and index problems. They must not be turned into new mechanisms or theoretical layers.

Evidence Ratings describe only how strongly the case material supports a particular judgment.

Research Status describes how frozen a research conclusion or structure currently is, not an intrinsic property of the mechanism.

Working Terms and Provisional Registered Names deliberately mark objects or questions whose definitions remain incomplete. Their purpose is not to fill the gap, but to preserve it.

Case Roles describe how a case is used in the argument. They do not determine which failure mechanism the case belongs to.

Book I Conclusion Language may carry only the limited conclusions already established in this book. It does not become a Formal Concept merely because it appears in a conclusion.

If a term is given meaning beyond what its status permits, the conclusions of the book will be strengthened silently in retelling.

The primary purpose of this appendix is to prevent exactly that.

---

Appendix II | Real-World Failures and Boundary Cases

What This Appendix Is For

Every real-world case used in this book was subjected to an independent fact check. The process was consistent: first identify official, primary, judicial, or regulatory sources; then extract only the facts those sources actually establish; and only after that record what the book may use the case to illustrate—and what it may not.

This appendix places the factual verification and the research mapping side by side. For each case, it answers four questions: What happened? Why does this book use the case? What does the evidence support—and where does that support stop? Where can the underlying facts be verified?

The role of cases in this book must be stated clearly at the outset.

Cases are not proof. They serve as stress tests, boundary tests, real-world context, counterexamples, or limited supporting evidence. They do not prove that the theoretical structure of this book is correct, and the set of seventeen verified cases does not prove that the current structure exhausts reality. The present case pool supports only a bounded negative observation: across these seventeen real-world failures from different domains, no case required a new Direct Mechanism Family beyond the five already identified in order to express the observed failure. That is a Bounded Negative Finding, not a proof of completeness.

Facts and analytical use must remain separate. In every case, the section titled “What Happened” is grounded only in official and primary material. “Role in This Book” is this book’s research mapping. The latter is not the conclusion of any investigative body, court, or regulator and must not be read as such. Conversely, legal and governance conclusions reached by courts, regulators, or official reports are not rewritten as theoretical conclusions of this book.

Evidence ratings are not severity ratings. The terms Strong / Partial / None describe how strongly a case supports a particular analytical or mechanism judgment. They do not describe accident severity, importance, risk level, causal priority, or moral weight.

Boundary Cases are listed separately. Moffatt v. Air Canada, The DAO, and Robodebt were subjected to the same factual verification as the verified cases, but they serve a different purpose: they help define the outer boundary of the problem space by showing which adjacent problems should not automatically be treated as Execution Gaps. They are therefore excluded from the evidence-strength statistics for the seventeen verified cases.

One final rule applies throughout this appendix: where authoritative sources do not establish a fact, the text says “not supported by the available sources” rather than filling the gap with a commonly repeated account.

---

I. Seventeen Verified Cases

Mars Climate Orbiter | 1999

Case Status: Verified Case

What Happened

On September 23, 1999, NASA lost contact with the Mars Climate Orbiter during Mars orbit insertion, and the mission failed. The investigation identified the root technical mismatch: the ground SM_FORCES software wrote angular-momentum-desaturation thruster impulse into an AMD file in pound-force seconds, while the mission interface specification required that field to use newton-seconds. The navigation team interpreted the values according to the specification and therefore underestimated the thruster effects by approximately a factor of 4.45.

Desaturation events occurred roughly 10 to 14 times more frequently than the navigation team had expected, allowing the error to accumulate during the nine-month cruise. Residuals in the tracking data were detectable, and the spacecraft itself computed and downlinked velocity-change data, but these indications were not compared, escalated, and closed through a formal anomaly process in time. An emergency maneuver, TCM-5, which could have raised the trajectory, was discussed orally before orbit insertion but was never fully analyzed, tested, proceduralized, or given explicit execution criteria, and it was not performed. Orbit insertion began on command while the spacecraft’s actual approach trajectory was about 170 kilometers lower than planned.

Role in This Book

A core case and one of the clearest examples of representation and semantics becoming separated from physical reality.

Strong: Change; Decision / Binding Relation Failure; Execution State / Result Relation Failure; Amplification.
Partial: Execution Path Deviation; Execution Boundary Failure; In-Causal-Chain Evidence / Proof Relation Failure.

What It Supports

The interface specification explicitly required newton-seconds. The navigation side interpreted the data according to that specification. The spacecraft responded to commands, and orbit insertion began as planned. Those local facts could each hold while safe orbital insertion still failed.

The case directly supports the proposition:

Local Correctness does not establish End-to-End Execution Correctness.

What It Does Not Support

It does not support the claim that every local component and process was correct. The ground software violated the interface specification, and the investigation identified failures in end-to-end verification, cross-team communication, personnel transition, and contingency preparation.

It does not support a clear path bypass or path substitution narrative. The erroneous values largely propagated through the intended data chain, which is why this book rates Execution Path Deviation only as Partial rather than treating it as the primary failure location.

It does not support Boundary Mutation, Intent replacement, or malicious alteration. Nor does it directly support general claims about payloads, signatures, approval systems, or AI-agent Tool invocation.

The investigation did not uniquely determine whether the spacecraft was destroyed in the Martian atmosphere or passed through it into heliocentric space. “Contact was lost and the mission was lost” is the more stable formulation.

Primary Sources

• Mars Climate Orbiter Mishap Investigation Board Phase I Report, NASA MCO Mishap Investigation Board, 1999-11-10
• Report on Project Management in NASA by the Mars Climate Orbiter Mishap Investigation Board (Phase II), 2000-03-13
  https://discovery.larc.nasa.gov/discovery/PDF_FILES/mars_climate_orbiter_phaseII.pdf
• NASA Lessons Learned Information System, Lesson 641 / Lesson 916
• Official NASA/JPL, NASA Goddard, and NSSDCA mission materials

---

Challenger | 1986

Case Status: Verified Case

What Happened

On January 28, 1986, Space Shuttle Challenger, mission STS-51L, broke apart approximately 73 seconds after launch, killing all seven crew members. The physical cause was failure of the aft field-joint seal in the right Solid Rocket Booster. Hot gas escaped through the failed seal and damaged the structural connection between the booster and the External Tank.

O-ring erosion and blow-by had already appeared in multiple earlier flights. NASA and the contractor did not respond adequately to the worsening seal problem. On the night before launch, Thiokol initially issued a written recommendation not to launch below the previous lowest experience temperature of 53°F. Management later reversed that recommendation after reconsideration, while some engineers continued to oppose launch.

The Presidential Commission found that the final decision-makers did not know the full recent history of the O-ring problem, the original No-Go recommendation, or the continuing engineering objections. Ambient temperature at the launch site was approximately 36°F, with the aft joint area of the right booster colder still. The Commission concluded that the launch decision process was seriously flawed.

Role in This Book

A core case showing the failure of the relationship between known risk evidence and the final real-world release decision.

Strong: Change; Decision / Binding Relation Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure.
Partial: Execution Boundary Failure; Amplification.
None: Execution Path Deviation.

What It Supports

The engineering teams had identified risk. The approval process did operate. The boosters had previously completed multiple flights. The launch was ultimately organizationally authorized.

Those facts could all be locally true and still lead to a catastrophic result. Identifying a risk is not the same as ensuring that the corresponding Evidence can block a real-world release. Authorization holding does not substitute for current material conditions holding.

What It Does Not Support

It does not support the claim that all engineering modules were correct. Official findings identified defects in the joint design, risk handling, and decision process.

It does not support Execution Path Deviation. The launch proceeded through the established process. Critical safety information failed to reach important managers, but the available evidence does not establish that the real-world Action took a different execution path.

It does not support Boundary Mutation or Intent replacement.

“Normalization of deviance” is a later sociological interpretation, not a conclusion of the Rogers Commission. Likewise, the phrase “take off your engineering hat” comes from historical testimony and should not substitute for the Commission’s formal findings.

Primary Sources

• Report of the Presidential Commission on the Space Shuttle Challenger Accident (Rogers Commission)
  https://sma.nasa.gov/SignificantIncidents/assets/rogers_commission_report.pdf
• Volume I, Chapter V: The Contributing Cause of the Accident, NASA History
• NASA: Challenger STS-51L Accident

---

Therac-25 | 1985–1987

Case Status: Verified Case

What Happened

Between June 1985 and January 1987, the Therac-25 medical linear accelerator was involved in six known severe radiation-overdose incidents that caused major injury and involved deaths. Therac-25 placed more safety responsibility in software and did not replicate all of the independent hardware protections used in predecessor machines.

In the 1986 Tyler accident sequence, a skilled operator rapidly edited mode and energy settings and triggered a race condition. The interface showed the parameters as verified and the machine as ready, while the actual physical configuration was unsafe. The machine displayed low-information messages such as Malfunction 54 and allowed the operator to press P to proceed.

Speed was a condition for reproducing this particular race. A related race condition also existed in Therac-20, but Therac-20’s independent hardware interlocks prevented the dangerous beam. A 1987 Yakima accident came from a different software error involving a shared variable and counter overflow, rather than the Tyler race.

During the early incidents, the manufacturer repeatedly failed to reproduce, or denied the possibility of, the machine producing the reported overdose. Incident information did not quickly become a cross-site corrective loop. In 1987, the FDA determined that the device was defective. Final corrective actions included independent hardware single-pulse shutdown, turntable position monitoring and interlocks, and software and interface changes.

Role in This Book

A core case and one of the clearest examples of the relationship between local software logic and an independent physical refusal boundary.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure.
Partial: Execution Path Deviation; Amplification.

What It Supports

The interface accepted the input and displayed it as verified. Much of the hardware followed the control commands. Operators continued according to established practice after low-information error messages. Those facts could all hold while the machine delivered a high-energy beam in an unsafe physical configuration.

The case most directly supports the proposition that when the same software domain both controls an Action and constrains itself, the absence of an independently capable refusal boundary can become critical.

What It Does Not Support

It does not support attributing all six incidents to the same race condition. The 1987 Yakima accident involved a different software fault, and the specific code-level cause of some earlier events remains uncertain.

“Eight seconds” refers to a particular magnet-setting timing window, not a universal threshold.

It does not support the claim that Therac-25 removed all hardware interlocks. The more accurate statement is that it did not replicate all previously existing independent protections.

Deaths and the ultimate cause of death for individual patients must be described case by case. The evidence does not support a blanket statement that the machine directly killed all six patients.

Primary Sources

• Nancy Leveson and Clark Turner, An Investigation of the Therac-25 Accidents, IEEE Computer, 1993, Parts I–IV (MIT archive)
  https://web.mit.edu/6.033/2004/wwwdocs/papers/Therac_1.html

This paper is the closest publicly available source to a systematic primary technical investigation of the case. It synthesizes FDA, Canadian regulator, hospital, manufacturer, and witness material, but it is not itself a single government accident-board report.

---

Ariane 5 Flight 501 | 1996

Case Status: Verified Case

What Happened

On June 4, 1996, the first Ariane 5 flight deviated from its trajectory roughly 40 seconds after liftoff, broke apart, and was destroyed by the onboard neutralization system.

A function in the inertial reference software had been inherited from Ariane 4. It continued to run for approximately 50 seconds after flight mode began because Ariane 4 used it to support rapid restart after a delayed launch. Ariane 5 did not need the function.

The reused software contained a conversion associated with Horizontal Bias from 64-bit floating point to a 16-bit signed integer. That conversion was not protected against an exception because analysis had assumed that the value could not exceed the range. About 36.7 seconds after liftoff, Ariane 5’s higher horizontal velocity drove the value outside the 16-bit range and caused an operand error. The backup and primary inertial reference systems then stopped in sequence for the same reason.

The active unit subsequently output a diagnostic bit pattern that the flight-control computer interpreted as flight data. The computer commanded extreme nozzle deflections, and aerodynamic loads caused the launcher to break apart. The Inquiry Board characterized the accident as a specification and design failure and noted that development review and testing had not adequately covered the complete inertial unit and closed-loop flight-control system. System tests had substituted simulated outputs for the real unit.

Role in This Book

A core case showing how environmental assumptions, numerical representation, exception semantics, and validation evidence failed to remain bound to the new real-world execution conditions.

Strong: Change; Decision / Binding Relation Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure; Amplification.
Partial: Execution Path Deviation; Execution Boundary Failure.

What It Supports

The inertial software behaved consistently with its implementation. Both the primary and backup units followed the same design. Propulsion operated normally in the early phase of flight. The onboard neutralization system triggered correctly.

Those local facts could hold while the mission was still lost.

The case is also a counterexample to naïve redundancy: two hardware units can provide hardware redundancy while remaining exposed to a common-cause failure because they share the same software and the same data-range assumption.

What It Does Not Support

It does not support describing the two inertial systems as genuinely independent redundancy.

It does not support the claim that every component operated according to a correct specification; the investigation explicitly identified defects in specification, design, exception handling, and system testing.

It does not support reducing the accident to the slogan “code reuse is dangerous.”

It does not support a path bypass or substitution narrative, and it does not support Boundary Mutation.

Horizontal Bias is an alignment-related quantity associated with platform-perceived horizontal velocity and should not simply be equated with “the velocity value.”

Primary Sources

• Ariane 5 Flight 501 Failure: Report by the Inquiry Board, ESA/CNES Independent Inquiry Board
  https://www-users.cse.umn.edu/~arnold/disasters/ariane5rep.html
• ESA: Ariane-501: The Inquiry Board’s Report
• ESA: Flight 501 failure — first information

---

Three Mile Island | 1979

Case Status: Verified Case

What Happened

On March 28, 1979, Unit 2 at Three Mile Island experienced a partial core meltdown. The event began when the main feedwater system stopped supplying water to the steam generators, causing the turbine and reactor to shut down automatically.

A pilot-operated relief valve at the top of the pressurizer opened as designed to reduce pressure but mechanically stuck open after pressure fell. The control-room indication led operators to believe the valve had closed because the indication reflected the close command and control state rather than the valve’s actual mechanical position.

Coolant continued to escape through the stuck-open valve. At the same time, the high pressurizer water level was misinterpreted as evidence that the reactor core remained covered. Operators later shut down reactor-coolant pumps because of vibration and reduced emergency injection because they feared filling the pressurizer solid. The core was progressively uncovered and overheated.

The U.S. Nuclear Regulatory Commission records no deaths or injuries attributable to the accident, and off-site releases were small. Official accounts attribute the event to a combination of equipment malfunction, design-related problems, and human error.

Role in This Book

A core case particularly useful for separating command state, displayed state, inferred state, and physical state as different objects.

Strong: Change; Decision / Binding Relation Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure; Amplification.
Partial: Execution Path Deviation; Execution Boundary Failure.

What It Supports

The reactor shut down automatically. The valve-control logic responded as designed. The pressurizer level reading accurately represented the local state of the pressurizer. Operator Actions were consistent with the State they believed they were observing.

The case supports two important negative relations:

Command State is not Physical State.
A local indication is not the system State.

What It Does Not Support

It does not support the claim that all instrumentation was wrong.

It does not support reducing the accident to one wrong button, alarm flooding alone, or operator error alone. Official accounts use a combined explanation.

It does not support a path bypass, path substitution, or maintenance-bypass narrative. It does not support Boundary Mutation. It also does not support claims of large numbers of public deaths caused by the accident.

Primary Sources

• U.S. Nuclear Regulatory Commission: Backgrounder on the Three Mile Island Accident
  https://www.nrc.gov/reading-rm/doc-collections/fact-sheets/3mile-isle
• NRC: Knowledge Management Digest: Three Mile Island Accident
• Report of the President’s Commission on the Accident at Three Mile Island (Kemeny Commission)

---

Knight Capital | 2012

Case Status: Verified Case

What Happened

On August 1, 2012, Knight Capital activated legacy Power Peg code while deploying a new trading function. Over roughly 45 minutes, the system generated millions of erroneous orders and caused losses of approximately $460 million.

Power Peg had originally been used to send child orders automatically. In 2005, cumulative-execution tracking was moved to an earlier stage of the code, but Power Peg was not retested after that change. Beginning July 27, 2012, new RLP code was deployed in stages across eight SMARS servers, and an old Power Peg flag was reused for the new function. During deployment, a technician omitted one server. No written process required a second person to verify the deployment. Seven servers therefore ran the new code while one retained the old Power Peg behavior.

Before the market opened, the system generated 97 automated emails stating “Power Peg disabled,” but those messages had not been designed or reviewed as production alerts. After the open, 212 parent orders triggered millions of child orders, producing roughly 4 million executions across 154 stocks and more than 397 million shares. During incident response, the company removed the new RLP code from the seven correctly updated servers, making the old Power Peg behavior triggerable on more servers and worsening the event.

Role in This Book

A core case and the principal example of automation-driven Amplification. It is the only one of the seventeen cases in which all seven analytical items receive Strong support: Change, all five Direct Mechanism Families, and Amplification.

The case presents a continuous chain from deployment Change, path divergence, lifecycle-binding failure, and missing Execution Boundaries to high-speed automated amplification.

What It Supports

Seven servers had the new code. The parent orders were genuine customer orders. Trading venues normally executed the orders they received. The system really did generate 97 automated messages.

The case supports two points. First, a locally correct majority in a cluster does not establish that every request enters the same software version. Second, Evidence does not control execution merely because a signal exists; unless the signal is configured as a basis for real-time judgment and refusal, it may remain informational only.

What It Does Not Support

It does not support reducing the event to a simple “software bug.” Deployment, path divergence, State binding, monitoring, and the absence of an effective automated Boundary all matter.

It does not support describing the response as “rolling back all servers.” The more accurate description is that new RLP code was removed from seven correctly updated nodes, which is not equivalent to a normal safe-version rollback.

The claim that the company initially believed it was under cyberattack is not supported by the official material used here.

Primary Sources

• U.S. Securities and Exchange Commission, Administrative Order, Exchange Act Release No. 70694
  https://www.sec.gov/litigation/admin/2013/34-70694.pdf

---

Flash Crash | 2010

Case Status: Verified Case

What Happened

On May 6, 2010, U.S. equity and futures markets fell sharply within minutes and then rebounded rapidly, with some securities trading at extreme prices. Earlier that day, markets were already under pressure from negative sentiment and volatility, and buy-side liquidity in E-mini futures and SPY had fallen significantly.

At 14:32, a large fundamental trader began selling 75,000 E-mini contracts—approximately $4.1 billion in value—as part of a hedging program. The algorithm targeted 9% of the previous minute’s trading volume and did not take price or time into account. It completed the program in about 20 minutes, whereas a similar-size execution by the same trader had previously taken more than five hours.

High-frequency traders initially absorbed the orders and then began selling aggressively to reduce inventory. Contracts circulated rapidly among automated traders. Rising volume then fed back into the sell algorithm and accelerated the program. Between 14:41 and 14:45, E-mini prices fell rapidly, liquidity contracted, and the effects propagated into ETFs and cash equities. At 14:45:28, CME Stop Logic paused E-mini trading for five seconds, after which selling pressure eased.

In individual stocks, multiple liquidity providers paused or withdrew quotes, leaving extreme placeholder quotes available for execution. More than 20,000 trades in over 300 securities, at prices more than 60% away from reference levels, were later cancelled.

Role in This Book

A supporting case used primarily to stress-test Amplification rather than as a clean single-actor case.

Strong: Change; Decision / Binding Relation Failure; Execution State / Result Relation Failure; Amplification.
Partial: Execution Boundary Failure; In-Causal-Chain Evidence / Proof Relation Failure.
None: Execution Path Deviation.

What It Supports

The large trader had a genuine hedging objective. The sell algorithm ran according to its configured rule. Market-making and risk systems reduced exposure according to their own logic. Exchange protection mechanisms eventually triggered as designed.

The case supports a specific structural pattern: many locally legitimate strategies can interact to produce a system-level real-world Result that no single participant explicitly intended.

What It Does Not Support

It does not support treating one trader as the sole cause, nor does it support describing the 75,000-contract order as an officially proven unique cause.

It does not support saying that every participant was locally correct. The volume-sensitive algorithm’s disregard for price and time was an identified risk contribution.

It does not support Execution Path Deviation. Orders moved through normal matching and arbitrage paths.

It also does not support the claim that all logs or records were inherently complete. Regulators reconstructed extensive data after the fact, but post-event reconstructability is not the same as real-time execution proof.

Later criminal proceedings involving individual traders do not replace or subsume the system chain described in the 2010 joint report and should not be treated as the sole root cause.

Primary Sources

• CFTC / SEC Joint Staff Report: Findings Regarding the Market Events of May 6, 2010
  https://www.sec.gov/news/studies/2010/marketevents-report.pdf
• SEC / CFTC: Preliminary Findings

---

Boeing 737 MAX | 2018, 2019

Case Status: Verified Case

What Happened

The Lion Air JT610 crash on October 29, 2018 and the Ethiopian Airlines ET302 crash on March 10, 2019 involved two Boeing 737 MAX 8 aircraft and killed 189 and 157 people respectively, for a total of 346 fatalities.

MCAS had been added to the flight-control system. During development, its function expanded to low-Mach conditions, and its authority and operating range changed. The original design relied on one of two angle-of-attack sensors for each activation. The original safety assessment did not fully account for multiple alerts and indications arising from the same angle-of-attack failure, nor did it sufficiently account for the effect of repeated MCAS activations on crew response.

Before JT610, the replacement left angle-of-attack sensor had been incorrectly calibrated. An existing installation test, if correctly performed, should have exposed the problem, but the investigation could not confirm that the test had been correctly completed.

Erroneous data from a single angle-of-attack sensor triggered repeated nose-down MCAS trim commands. Under the original logic, pilot use of electric trim could reset MCAS while a persistently high angle-of-attack signal caused the function to activate again seconds later. Repeated incremental commands accumulated into a substantial stabilizer mismatch, alongside stick-shaker activation and inconsistent speed and altitude indications.

After the grounding, the redesigned system compared both angle-of-attack sensors, disabled the relevant function when their disagreement exceeded a threshold, allowed only one MCAS activation per high-angle-of-attack event, and limited trim authority.

Role in This Book

A core case and one of the clearest examples of a mismatch between the Qualification of an input source and the control effect assigned to that source.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure; Amplification.
Partial: Execution Path Deviation.

What It Supports

The sensor provided values through the expected interface. MCAS responded to the selected input according to the original control law. Pilots could temporarily counter the input with electric trim. The certification process did include existing analysis and compliance activities.

The case supports the proposition that an input source can be given control effect beyond what its Qualification can safely support. The mere fact that two sensors physically exist does not automatically establish independent, orthogonal verification.

What It Does Not Support

It does not support treating the two accidents as identical causal chains. They shared important structure but differed in maintenance history, alerts, crew Actions, and other details.

It does not support describing MCAS as an actor with independent Intent.

It does not support claims that the software absolutely removed all manual control in every condition. A more accurate statement is that repeated commands could create a stabilizer mismatch that could become difficult to counter with elevator alone.

It does not support claiming that the post-grounding use of two sensors constituted theoretically orthogonal verification; two sensors of the same type do not automatically establish orthogonal independence.

It does not support Boundary Mutation. The failure chain shows inadequate design-time boundaries rather than evidence that an effective boundary was dynamically rewritten during flight.

It does not support any single factor as the unique cause of both accidents.

Primary Sources

• Indonesia KNKT: Aircraft Accident Investigation Report: Lion Air JT610
  https://knkt.go.id/Repo/Files/Laporan/Penerbangan/2018/KNKT.18.10.33.04-Final-Report.pdf
• U.S. NTSB: Safety Recommendation Report ASR-19-01
• Joint Authorities Technical Review: Boeing 737 MAX Flight Control System
• FAA: Summary of the FAA’s Review of the Boeing 737 MAX

---

AWS S3 US-EAST-1 Service Disruption | 2017

Case Status: Verified Case

What Happened

On February 28, 2017, Amazon S3 experienced a service disruption in the Northern Virginia Region. The S3 team was troubleshooting slower-than-expected processing in the billing system.

At 09:37 Pacific Time, an authorized team member followed an established playbook and issued a command intended to remove a small number of servers from a billing-related subsystem. One input to the command was entered incorrectly, causing more servers to be removed than intended. The removed capacity also supported the index and placement subsystems.

Both subsystems required a full restart, affecting S3 APIs and other services that depended on S3. AWS concluded that the tool had allowed too much capacity to be removed too quickly. It subsequently added minimum-capacity safeguards, reduced the speed at which capacity could be removed, and narrowed the failure domain.

Recovery was also slowed by a separate factor: as the region had grown, the relevant large subsystems had not undergone a complete restart for years, and restart plus metadata-integrity checking took longer than expected.

Role in This Book

A verified case showing a legitimate actor using the normal path to perform a real-world Action outside the intended scope of that specific operation.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; Amplification.
Partial: In-Causal-Chain Evidence / Proof Relation Failure.
None: Execution Path Deviation.

What It Supports

The operator was authorized. The operator used an established playbook and normal production Tool. The command executed according to the supplied input. The recovery process ultimately restored service.

The case cleanly supports the negative proposition:

An authorized operator plus a valid Tool path does not establish that the specific production Action is correct.

It also shows that an Execution Gap does not require malice, AI involvement, or catastrophic permanent loss.

What It Does Not Support

It does not support the popular simplification that “one typo took down the internet.” The official account confirms an incorrect input, but does not establish a particular keyboard spelling mistake.

It does not support claims of an unauthorized actor or use of a bypassed Tool.

It does not support attributing the entire recovery delay to the original removal Action.

It does not support permanent data loss; the core official impact involved unavailability and backlog recovery.

It does not support Execution Path Deviation or Boundary Mutation. The relevant issue is the absence of an adequate execution-scope boundary.

Source quality also matters: AWS was the responsible party, so its account is a primary self-report rather than an independent investigation. Unpublished approvals, command details, and internal logs must not be inferred.

Primary Sources

• AWS: Summary of the Amazon S3 Service Disruption in the Northern Virginia Region
  https://aws.amazon.com/message/41926/

---

Citibank–Revlon Erroneous Payment | 2020

Case Status: Verified Case

What Happened

On August 11, 2020, Citibank, acting as loan agent, intended to process approximately $7.8 million in interest and perform internal accounting for a restructuring of Revlon’s loans.

In the Flexcube system, the easiest—and possibly only—way to process the transaction was to enter it as a full payoff while using an internal wash account to retain the principal. The operator needed to select three interface fields: FRONT, FUND, and PRINCIPAL. Only PRINCIPAL was selected. Two reviewers also failed to detect the error.

As a result, the system actually transferred nearly $1 billion of Citibank’s own funds to the 2016 Term Lenders instead of completing the intended internal transfer. The lenders’ remittance information showed only accrued interest, while the actual wire amount was more than one hundred times larger, and they had not received the notice that would ordinarily accompany an early principal repayment.

Citibank sent recall notices the next day. Some recipients returned the funds and others refused. The U.S. Court of Appeals for the Second Circuit ultimately reversed the district-court ruling that had favored the recipients who refused to return the money.

Role in This Book

A verified case showing that legitimate job Qualification, a normal Tool, and two levels of review cannot substitute for end-to-end binding of the specific amount, account, and payment semantics of the current Action.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure.
Partial: Amplification.
None: Execution Path Deviation.

What It Supports

The people involved had legitimate operational responsibilities. Two levels of review really occurred. The system and wire channel executed according to the entered fields. The lender accounts actually received the money.

The case supports the proposition that an approved workflow is not the same as a correctly bound payment. The existence of review does not guarantee that the review object included the final fund destination and amount semantics.

What It Does Not Support

It does not support reducing the incident to “one employee pressed the wrong button.” The court record describes three checkbox settings, a specific internal-account workflow, and two reviewers who failed to identify the error.

It does not support the claim that Citibank simply “gave away $900 million and could never recover it.” Some funds were returned quickly, and the appellate court reversed a key district-court ruling.

It does not support reading “the system executed according to the fields” as proof of business Authorization. Technical executability, internal approval, and the customer’s actual Intent are different facts.

The court’s legal analysis of the discharge-for-value doctrine is not a root-cause analysis of the system incident.

It does not support Execution Path Deviation.

Primary Sources

• U.S. Court of Appeals for the Second Circuit, majority opinion, In re Citibank August 11, 2020 Wire Transfers
  https://www.govinfo.gov/content/pkg/USCOURTS-ca2-21-00487/pdf/USCOURTS-ca2-21-00487-0.pdf
• Judge Park’s concurring opinion in the same case
• 2021 opinion of the U.S. District Court for the Southern District of New York, used only to understand the district-court proceedings

---

Hawaii Ballistic Missile False Alert | 2018

Case Status: Verified Case

What Happened

On January 13, 2018, the Hawaii Emergency Management Agency issued a false ballistic-missile alert. The organizational Intent was to run an internal exercise.

The exercise recording began and ended with “Exercise, Exercise, Exercise,” but included “This is not a drill” in the middle. One on-duty employee believed the threat was real, while other personnel understood the event to be an exercise.

That employee selected the real-alert template from the alert software’s drop-down menu and, after a confirmation prompt, sent a statewide EAS / WEA message. At the time, real and test templates appeared in the same interface and used the same login credentials. A real ballistic-missile alert could be sent by a single credentialed operator.

A cancellation operation at approximately 08:12 could stop additional forwarding, but could not recall messages already displayed on devices and did not automatically generate an all-clear message. The agency had no prepared false-alert correction protocol or template. A correction was not issued through the same channels until 08:45, 38 minutes after the initial alert.

The Federal Communications Commission concluded that human error and inadequate safeguards jointly caused the false alert and the delayed correction.

Role in This Book

A verified, non-catastrophic positive case.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure; Amplification.
Partial: Execution Path Deviation.

What It Supports

The initiating employee had valid alert credentials. The software sent the selected template. Distribution providers propagated the message largely within seconds. The alert content was faithfully transmitted as a real alert.

The case supports two points. First, legitimate permissions and reliable propagation can precisely transform an incorrect factual judgment into a real-world public Action. Second, recovery and correction constitute a separate execution chain; they are not an automatic reversal of the original Action.

What It Does Not Support

It does not support a “pressed the wrong button” explanation. Official findings included the mixed exercise script, inadequate supervisory communication and oversight, failure to separate test and production interfaces, single-person send capability, and the absence of a correction protocol.

It does not support saying that the sender knew it was an exercise and accidentally issued the alert. The official record says the employee believed the threat was real.

It does not support saying that there was no clarification at all for 38 minutes. Social-media clarification began around 08:20, although the formal same-channel correction was not issued until 08:45.

It does not support equating cancellation with recalling an alert already delivered to devices.

It does not support a bypass of the distribution network; the network worked normally.

Primary Sources

• FCC Public Safety and Homeland Security Bureau: Hawaii Emergency Management Agency January 13, 2018 False Alert
  https://docs.fcc.gov/public/attachments/DOC-350119A1.pdf

The report cites and compares the agency’s internal investigation, the exercise recording, and interviews. Where those sources differ, this appendix preserves the distinction rather than collapsing them into a single account.

---

Waymo Utility-Pole Collision and Recall | 2024

Case Status: Verified Case

What Happened

On May 21, 2024, a Waymo autonomous vehicle struck a wooden utility pole while performing a low-speed pull-over maneuver in an alley in Phoenix. There were no passengers in the vehicle, no other road users were involved, no one was injured, and the vehicle was damaged.

The manufacturer’s recall filing described a trigger condition requiring several facts to coincide: a permanent pole-like object located within the roadway; no hard road edge mapped between the object and the drivable surface; perception assigning the object a low damage score; the object lying in the autonomous driving system’s intended path; and no nearby object that would otherwise trigger avoidance.

The recall covered 672 affected units. The remedy consisted of software and map updates, and all affected vehicles were updated by June 6, 2024.

Role in This Book

A verified low-loss positive case used to support one limited negative conclusion: catastrophic scale is not a Necessary Condition for this class of failure.

Strong: Change; Decision / Binding Relation Failure; Execution State / Result Relation Failure.
Partial: Execution Boundary Failure; In-Causal-Chain Evidence / Proof Relation Failure.
None: Execution Path Deviation; Amplification.

It is also the key counterexample for Amplification: the case remains an Execution Gap even though no significant amplification is established. This directly shows that Amplification is not a Necessary Condition.

What It Supports

The vehicle was performing a low-speed pull-over maneuver supported by the system’s design. Mapping, perception, and planning all participated in the normal chain. The collision conditions can be enumerated explicitly.

The case supports the proposition that a legitimate Action objective does not establish a safe physical trajectory.

It also constrains the meaning of Execution Path Deviation: an intended path containing the wrong physical trajectory is not, by itself, a deviation from the intended path.

What It Does Not Support

It does not support the claim that “Waymo could not see the utility pole.” The report describes a combination of conditions and does not state that the object was entirely unperceived.

It does not support describing the event as a large-scale accident. The figure 672 refers to affected devices covered by the recall, not the number of collisions. The report identifies one related collision.

It does not support treating the update-completion date as the accident date or the date of an independent regulatory technical finding.

It does not support treating the manufacturer’s recall description as an independently completed regulator root-cause analysis.

The public report does not provide a causal narrative establishing which algorithmic module was fundamentally correct or incorrect. The multi-condition trigger should not be compressed into a single perception failure.

Primary Sources

• NHTSA Part 573 Safety Recall Report 24E-049
  https://static.nhtsa.gov/odi/rcl/2024/RCLRPT-24E049-1733.PDF

This is a regulatory filing, but the core technical description was supplied by the manufacturer and should not be treated as an independent accident-investigation conclusion.

---

CrowdStrike Channel File 291 | 2024

Case Status: Verified Case

What Happened

On July 19, 2024, a CrowdStrike Falcon content update caused large numbers of Windows systems to crash. Falcon sensors receive Rapid Response Content through Channel Files. This material is configuration content, not a new kernel-driver binary.

A template type introduced in February 2024 defined 21 input fields, while the sensor’s integration code supplied only 20 inputs to the content interpreter. Earlier testing and initial deployments used a wildcard in the 21st field and therefore did not trigger the latent out-of-bounds read.

A new template instance deployed on July 19 used a non-wildcard condition in the 21st field. The content validator approved it according to its own 21-input model. Endpoints then attempted to read a nonexistent 21st input, producing an out-of-bounds read and system crashes.

Subsequent improvements included compile-time field-count validation, runtime array-bound checks, non-wildcard testing for every field, staged deployment, and customer deployment controls. The U.S. Government Accountability Office described the event as a widespread outage affecting millions of Windows systems and disrupting services including aviation and hospitals; it did not characterize the event as a cyberattack.

Role in This Book

A verified case and one of the strongest examples of software-mediated Amplification.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure; Amplification.
Partial: Execution Path Deviation.

What It Supports

The content was produced, validated, and released through the formal system. Earlier wildcard instances had genuinely operated successfully. The July 19 event was not itself a sensor-code update.

The case supports the proposition that a validator’s “pass” establishes only that content satisfies the validator’s own input model. It does not establish that the runtime sensor actually implements the same contract.

Likewise, successful earlier deployment is not evidence that a new current matching condition is safe.

What It Does Not Support

It does not support describing the incident as “a buggy kernel-driver update.” The triggering payload was configuration content; the latent out-of-bounds read existed in interpreter code.

It does not support calling the event a cyberattack.

It does not support saying that validation never occurred. Multiple layers of validation and testing did occur, but they shared the same incorrect assumption about the number of inputs and did not cover a non-wildcard condition in the 21st field.

It does not support interpreting a reported “99% sensor recovery” metric as proof that every affected business had fully recovered; that figure was based on week-over-week sensor connection counts.

It does not support describing the high-speed content path as an attacker bypassing the release process.

Source quality must also be kept visible: most technical detail comes from the incident party’s own account, and there is no independent regulatory root-cause determination for the event.

Primary Sources

• CrowdStrike: External Technical Root Cause Analysis — Channel File 291
  https://www.crowdstrike.com/wp-content/uploads/2024/08/Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf
• U.S. Government Accountability Office: Cyber Resiliency — CrowdStrike Outage Highlights Challenges
  https://www.gao.gov/products/gao-24-107733

---

Cruise Pedestrian Dragging and Incident Reporting | 2023

Case Status: Verified Case

What Happened

On October 2, 2023, a human-driven hit-and-run vehicle first struck a pedestrian and propelled the pedestrian into the path of an adjacent Cruise autonomous vehicle. The Cruise vehicle braked but could not avoid the collision, and the pedestrian came to rest underneath the vehicle.

After an initial stop, the vehicle resumed movement and dragged the pedestrian approximately 20 feet before finally stopping. The U.S. Department of Justice Deferred Prosecution Agreement states that the detection system did not detect the pedestrian beneath the vehicle, and the vehicle therefore attempted to pull over.

Cruise’s legally required reports submitted on October 3 and October 11 did not describe the movement and dragging that occurred after the initial stop. The company first described that portion in an updated report on November 3. Importantly, Cruise had already provided regulators with video showing the complete event before the first written report was filed. Regulators nevertheless concluded that the written narratives omitted material facts known to the company.

The regulator’s consent order included a $1.5 million civil penalty and corrective actions. The Department of Justice agreement concerning false reporting separately included a $500,000 criminal fine and compliance obligations.

Role in This Book

A verified case with a two-chain structure: an erroneous post-collision Action affected real-world harm, while incomplete Evidence later affected subsequent judgment.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure.
Partial: Execution Path Deviation; Amplification.

It is also one of the principal cases behind the candidate pattern in which Evidence feeds back into later Authority. The current material treats that pattern as repeated connection among existing mechanisms across multiple rounds, not as a new Direct Mechanism Family.

What It Supports

The initial braking and stop occurred. Pull-over was an Action already available to the system. The video genuinely contained the full event. The reports were submitted through the required channels.

The case supports two negative relations:

“The vehicle has stopped” after the collision was not equivalent to a safe terminal State.

The existence of Evidence was not equivalent to a complete legally relevant report.

The content of Evidence, its medium, the way it is received, and the decision object used by an Authority must remain distinct.

What It Does Not Support

It does not support saying that the Cruise vehicle was the first vehicle to strike the pedestrian.

It does not support the claim that Cruise “never provided the dragging video.” The complete video was provided before the first required written report; the issue is that two statutory written narratives still omitted material movement.

It does not support collapsing the vehicle’s post-collision technical behavior and the company’s reporting behavior into one undifferentiated responsibility chain. They require separate factual verification.

It does not support claiming that the later report caused the dragging that had already occurred.

The dragging speed, the system’s internal model reasoning, and the complete communication history are not provided by the current official sources and must not be filled in.

Primary Sources

• NHTSA: Cruise Standing General Order Reporting Consent Order
  https://www.nhtsa.gov/sites/nhtsa.gov/files/2024-09/cruise-consent-order-2024-web.pdf
• U.S. Department of Justice press release and Cruise Deferred Prosecution Agreement
  https://www.justice.gov/usao-ndca/media/1377231/dl

---

Storm-0558 Exchange Online Intrusion | 2023

Case Status: Verified Case

What Happened

Between May and June 2023, the threat actor tracked as Storm-0558 obtained Microsoft’s 2016 MSA consumer token-signing key and used it to forge tokens accepted by Exchange Online.

That key was intended only to sign tokens valid for consumer services. It should not have established Qualification for enterprise Exchange Online accounts, because consumer and enterprise signing keys came from separated providers and systems.

Exchange Online nevertheless contained a token-validation defect: the validation logic did not encode a rejection of that class of key for enterprise accounts and could therefore accept such tokens. Microsoft ultimately identified access affecting 22 enterprise organizations and 503 related individual accounts.

After discovery, Microsoft cleared downstream caches and invalidated credentials derived from the key, after which the attackers shifted to phishing. When the U.S. Department of Homeland Security’s Cyber Safety Review Board completed its review, Microsoft still could not prove how the actor had obtained the signing key.

Role in This Book

A verified case showing the separation between local cryptographic validity and real-world access Qualification.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure; Amplification.
Partial: Execution Path Deviation.

It is also one of the principal cases behind the candidate pattern of Qualification propagating across organizational domains. The current analysis treats that pattern as a combination of cross-domain binding failure, Boundary failure, and Amplification rather than as a new failure type.

What It Supports

The token’s cryptographic signature could be validated. The cloud service’s normal token-acceptance path operated. The accessed objects were real mailbox accounts.

The case supports the proposition that a verifiable signature proves only that a token can be validated under a particular key. It does not establish that the key has the relevant Qualification for the current enterprise tenant, account, and moment.

What It Does Not Support

It does not support saying that the attackers “broke Microsoft cryptography.”

It does not support presenting a crash-dump theory as the established source of the key. The Cyber Safety Review Board explicitly stated that Microsoft still could not prove how the actor obtained the signing key; earlier hypotheses are not confirmed facts.

It does not support saying that consumer tokens inherently grant access to enterprise services. The validation logic’s failure to reject that key class was also required.

It does not support saying that all Microsoft customers were compromised.

It does not support treating the case as a classic step-skipping attack. The actor used normal token-validation and mailbox-access paths.

The CSRB explicitly stated that Microsoft had not determined how the actor obtained the signing key. This evidentiary gap must remain visible.

Primary Sources

• DHS Cyber Safety Review Board: Review of the Summer 2023 Microsoft Exchange Online Intrusion
  https://www.cisa.gov/sites/default/files/2024-03/CSRB%20Review%20of%20the%20Summer%202023%20MEO%20Intrusion%20Final_508c.pdf

---

SolarWinds Orion Supply-Chain Compromise | 2019–2020

Case Status: Verified Case

What Happened

A threat actor first entered SolarWinds’ environment and conducted test code insertions. Beginning in February 2020, malicious code was incorporated into files that later became part of Orion updates. SolarWinds then unknowingly distributed the affected versions, and customers downloaded and installed them through normal software-update channels.

After installation, the malicious file remained dormant for roughly two weeks, then collected environmental information and communicated with attacker-controlled infrastructure. The attacker selected a much smaller subset of targets for additional command-and-control activity and further malware installation.

SolarWinds estimated that nearly 18,000 customers received the compromised update. After public disclosure in December 2020, the U.S. Cybersecurity and Infrastructure Security Agency directed federal agencies to disconnect affected Orion products, preserve forensic data, and rebuild systems.

Role in This Book

A verified case in which all seven analytical items—Change, all five Direct Mechanism Families, and Amplification—receive Strong support. It is also the clearest positive case in the second case batch for Execution Path Deviation.

What It Supports

Customers used a genuine product and the normal update channel. Their systems accepted the installation. Supply-chain distribution and software execution operated through standard mechanisms.

The case supports the proposition that customers accepted supplier Qualification, signing, and the standard update channel while the actual payload’s origin and behavior had changed. Cross-organizational trust transformed supplier-side payload Qualification into high-privilege execution inside customer environments.

What It Does Not Support

It does not support saying that approximately 18,000 customers were all deeply controlled. That number refers to customers that received the compromised update; subsequent selective exploitation involved a much smaller subset.

It does not support treating a valid signature as proof of security or Authorization. At most, the signature established that the released artifact satisfied the existing signing-verification relationship.

It does not support saying that customers bypassed their own normal update process. The danger arose precisely because the malicious payload entered through a normal supply-chain Qualification path.

It does not support a single-stage narrative in which “one backdoor file automatically hacked every customer.” Official material describes a multi-stage attack chain.

Primary Sources

• U.S. Government Accountability Office: Cybersecurity — Federal Response to SolarWinds and Microsoft Exchange Incidents
  https://www.gao.gov/products/gao-22-104746
• CISA Emergency Directive 21-01
  https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise

---

Post Office Horizon | From 2000 Onward

Case Status: Verified Case

What Happened

In its 2019 judgment, the High Court of England and Wales found that the Horizon system contained multiple defects capable of causing, and which had in fact caused, shortfalls in branch accounts, undermining the reliability of the system’s transaction processing and recording.

The court recorded 25 issues capable of affecting branch accounts, with evidence that 22 had real continuing effects. Horizon itself did not alert subpostmasters to those problems. The Post Office maintained for years that Horizon was reliable and did not adequately engage with facts and expert evidence inconsistent with that position.

In 2021, the Court of Appeal considered appeals by 42 defendants and ultimately quashed 39 convictions, concluding that investigative and disclosure failures had made the relevant trials unfair and that some prosecutions constituted an affront to the public conscience.

Individuals had been held responsible for accounting shortfalls presented by the system. Real-world consequences included repayment demands, bankruptcy, loss of employment, criminal penalties, and social harm. The facts and legal grounds were not identical in every case.

As of July 8, 2026, the public inquiry had issued only Volume 1 of its final report, focusing on human impact and compensation. The chair confirmed that the remaining five volumes were still in preparation and had not yet been published.

Role in This Book

A verified long-duration institutional case used to test how Evidence can enter subsequent judgments and repeatedly drive real-world Actions.

Strong: Change; Decision / Binding Relation Failure; Execution Boundary Failure; Execution State / Result Relation Failure; In-Causal-Chain Evidence / Proof Relation Failure; Amplification.
Partial: Execution Path Deviation.

Together with Cruise, it provides important material for the candidate pattern in which Evidence feeds back into subsequent Authority. The current analysis can express the pattern as repeated connection among existing mechanism relations over multiple rounds and does not require a new Direct Mechanism Family.

What It Supports

Transaction records, system reports, contractual structures, investigation procedures, and litigation processes all genuinely existed and were used.

The case supports a three-part negative relation:

A shortfall recorded by a system is not the same as a proven real-world loss, and a proven real-world loss is not the same as proven personal dishonesty.

What It Does Not Support

It does not support attributing the entire matter to one software defect. The court identified multiple problems affecting different branches and cases.

It does not support saying that every shortfall was fabricated by the system, nor that every convicted person’s facts were identical.

It does not support the claim that system records had no evidentiary value. The correct conclusion is narrower: without independent verification and adequate disclosure, they could not automatically establish real-world loss or personal dishonesty.

It does not support treating every case as one identical bypass path.

As of July 8, 2026, the remaining five volumes of the public inquiry’s final report had not been published and must not be described as completed findings.

Primary Sources

• Bates and Others v Post Office Ltd, Horizon Issues Judgment, [2019] EWHC 3408 (QB)
  https://www.judiciary.uk/wp-content/uploads/2022/07/bates-v-post-office-judgment-1.pdf
• Hamilton and Others v Post Office Ltd, [2021] EWCA Crim 577
  https://www.judiciary.uk/wp-content/uploads/2022/07/Hamilton-Others-v-Post-Office-judgment-230421.pdf
• Post Office Horizon IT Inquiry: Reports and Statements
  https://www.postofficehorizoninquiry.org.uk/reports-and-statements

---

II. Three Boundary Cases

The following three cases were fact-checked under the same standard as the verified cases, but they serve a different function.

They are not included to increase the number of positive examples of the Execution Gap. They are used to test the concept’s outer boundary: which problems can produce real consequences and involve information, automation, code, or institutions, yet still should not be admitted into the Execution Gap merely because those facts are present?

For that reason, these three cases are excluded from the evidence-strength statistics for the seventeen verified cases.

Together they serve one purpose:

to prevent the Execution Gap from gradually expanding into another name for every bad outcome.

Moffatt v. Air Canada | 2022 Facts / 2024 Decision

Case Status: Boundary Case (not assigned a case number)

What Happened

In November 2022, Jake Moffatt searched Air Canada’s website for bereavement fares after the death of a family member. The airline’s chatbot stated that a passenger who had already travelled could apply for a reduced bereavement fare within 90 days of ticket issuance. The formal webpage linked by the chatbot stated that bereavement fares could not be requested after travel had been completed.

Moffatt relied on the information, bought ordinary tickets, completed his travel, and applied for the fare adjustment within 90 days. Air Canada later refused retroactive application of the bereavement fare.

The British Columbia Civil Resolution Tribunal held Air Canada responsible for information provided on its website and found that it had failed to take reasonable care to ensure the chatbot’s information was accurate, amounting to negligent misrepresentation. The tribunal awarded Moffatt CAD 650.88 in damages, plus interest and fees.

Role in This Book

A Boundary Case concerning the distinction between information influence and real-world execution.

The case contains a complete real-world causal chain:

incorrect representation → human judgment → human Action → real-world Result.

But the available material does not show that the chatbot itself purchased the ticket, charged the customer, issued the ticket, or processed a refund. The real-world purchase Action remained human-performed.

The case therefore separates two propositions:

An information system can influence a real-world Action.

and

The information system itself directly performs the real-world Action.

Those propositions cannot be treated as equivalent.

What It Supports

The case supports the proposition that incorrect information can influence human judgment and produce real-world consequences through subsequent human Action.

It also supports the legal proposition, specific to the tribunal’s decision, that an organization cannot treat erroneous chatbot information as unrelated to itself merely because the information was produced by a chatbot.

For this book, the more important boundary is:

Participation in a real-world causal chain is not the same as directly performing the real-world execution.

What It Does Not Support

It does not support treating “the information system influenced a human decision” as automatically equivalent to “the information system itself executed the real-world Action.”

The decision did not establish that the chatbot was a large language model, a generative model, or an autonomous agent. There is no evidence that it directly invoked ticketing Tools, charged the customer, issued the ticket, or granted the bereavement fare.

The mere presence of both a chatbot and a real-world loss does not make the case an example of an AI Agent autonomously executing an incorrect Action.

Nor does the existence of loss by itself establish an execution-side deviation of the kind defined in this book.

The tribunal decision addressed misrepresentation and resulting damages; it did not order retroactive application of the original fare policy. A single case also cannot establish the prevalence of similar chatbot-related losses.

Primary Sources

• Moffatt v. Air Canada, 2024 BCCRT 149 (CanLII)
  https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html

---

The DAO | 2016

Case Status: Boundary Case (not assigned a case number)

What Happened

The DAO raised approximately 12 million ETH through token sales, with the stated goal of allowing token holders to vote on project-funding proposals.

On June 17, 2016, an attacker exploited a flaw in The DAO’s code and transferred approximately 3.6 million ETH—roughly one third of the funds raised—to an address under the attacker’s control. The contract prevented those assets from being moved further for 27 days, leaving time for the community to respond.

The community subsequently proposed and adopted a hard fork. On July 20, the new chain moved the relevant funds to a recovery address so token holders could redeem ETH. A minority of participants declined to adopt the new chain and continued running the original chain, which became Ethereum Classic.

The U.S. Securities and Exchange Commission also emphasized in its investigative report that automation through smart contracts does not place conduct outside existing securities law.

Role in This Book

This case tests a boundary that is easy to blur:

If a real-world Result is unacceptable in normative, governance, or legal terms, does that necessarily mean that execution itself deviated?

The difficulty in The DAO is that several different reference objects coexist:

• what the code actually allowed;
• what the attacker intended to do;
• what the designers intended the system to accomplish;
• what investors believed their funds should be used for;
• what the community later chose to accept as the valid State.

These cannot be compressed into one unified “Intent.”

What It Supports

The case supports keeping several objects distinct:

• what the protocol actually executed;
• what the attacker intended;
• what the code designers intended;
• what investors sought by participating in The DAO;
• what the community later decided to do about the State that had already changed.

The original-chain record can establish that the relevant State transition occurred. That fact alone cannot determine whether the State should be accepted in normative, governance, or legal terms.

The subsequent hard fork was itself a new governance and execution Action. It changed the chain State accepted afterward, but it cannot retroactively prove that the original asset transfer never occurred.

What It Does Not Support

The case does not support the inference:

A real-world Result is normatively unacceptable; therefore an Execution Gap necessarily occurred.

From the attacker’s own concrete Action perspective, the attacker intended the calls that were made, and the protocol produced State changes corresponding to those calls.

Looking only at the attacker’s specific calls and the resulting protocol State transition therefore does not yield a simple structure in which an Established Upstream Object was transformed during execution.

The harder question is:

Whose Intent, Decision, or other Established Upstream Object should serve as the reference against which deviation is judged?

Without answering that first, any exploit, unlawful act, or governance-rejected Result could be redescribed as an execution deviation merely because it was unacceptable.

That would destroy the boundary of the Execution Gap.

The role of this case is therefore not to prove “code is law,” and not to prove that protocol execution had no problems. It is to show that:

normative unacceptability and execution deviating from an established reference are different questions.

Other limits must also remain visible. The case does not support saying that the attacker transferred all funds, that the funds were immediately freely transferable despite the 27-day restriction, or that the hard fork was unilaterally decided by one institution. Public statements at the time framed the fork as a community choice, and some participants continued operating the original chain.

Primary Sources

• SEC: Report of Investigation Pursuant to Section 21(a) — The DAO
  https://www.sec.gov/litigation/investreport/34-81207.pdf
• Ethereum Foundation: To fork or not to fork (2016-07-15)
• Ethereum Foundation: Hard Fork Completed (2016-07-20)

---

Robodebt | From 2015

Case Status: Boundary Case (not assigned a case number)

What Happened

Australia’s Robodebt scheme used employer-reported income information held by the tax authority, averaged annual or period income into fortnightly amounts, compared those amounts with income reported by welfare recipients, and then used the comparison in debt determination and recovery.

For casual and part-time workers, actual fortnightly income could vary. An averaged amount therefore was not equivalent to the real income earned in each specific fortnight.

Under the earlier process, compliance officers investigated higher-risk discrepancies and could seek additional evidence from individuals and employers. The Robodebt process shifted more responsibility for explaining discrepancies onto recipients.

The available material shows that the scheme did not have a general legal basis for using income averaging itself to prove actual fortnightly income. Except in limited last-resort circumstances, the evidentiary basis for directly creating debts in this way was inadequate. Internal legal advice from 2014 had already identified the need to rely on actual fortnightly income and the tension between averaging and the existing legal framework, yet the scheme proceeded without corresponding legislative change.

Multiple first-instance Administrative Appeals Tribunal decisions also questioned or rejected the legal and evidentiary basis for income averaging. Because those decisions were not made sufficiently public or systematically fed back into administration, they did not effectively stop the practice.

The Royal Commission later made multiple recommendations concerning automated decision-making, including clear review pathways, disclosure of how automation is used, publication of business rules and algorithms for independent scrutiny, and appropriate monitoring and auditing mechanisms.

Role in This Book

One of the book’s most important outer-boundary cases.

It forces a distinction between:

an upstream Decision, rule, or Qualification judgment that is itself defective in legal, normative, or evidentiary terms,

and

an Established Upstream Object that later deviates during execution.

At the program level, Robodebt is closer to the first category.

The system executed at scale a rule that itself had legal and evidentiary problems. The real-world consequences were severe, but severity alone cannot tell us whether the primary problem lay in the upstream rule or in execution deviating from that rule.

What It Supports

The case supports separating proxy data from the real-world fact that the proxy is used to represent.

An averaged income amount is a proxy representation. It is not automatically the actual income earned in each particular fortnight. Yet the system used that proxy in subsequent debt determinations and recovery Actions, exposing the need to keep data, facts, judgments, and real-world Actions relationally distinct.

The case also supports one observation about automated scale:

Automation can expand the speed and coverage with which an existing decision rule is executed, but executing that rule faster and more consistently does not make the rule lawful, evidentially sufficient, or normatively correct.

Likewise, review outcomes that are not made public or do not enter a systematic feedback loop can allow a challenged rule to continue affecting subsequent cases.

What It Does Not Support

The most important limitation is:

An incorrect, unlawful, or normatively unacceptable upstream Decision that is faithfully executed by later systems cannot be redescribed as “execution deviated from that Decision” merely because the final consequences were severe.

If the system does what the upstream rule told it to do, the primary problem remains with the upstream rule, Decision, and its factual and legal basis.

That does not mean that individual Robodebt cases could never also contain Decision / Binding, Evidence, or other execution-relation failures.

But the analysis here concerns the program as a whole and does not reconstruct every individual execution chain. The possibility that some individual cases may contain independent execution deviations therefore does not justify registering the entire program as a verified positive Execution Gap case.

Other limits also remain:

It does not support saying that “the algorithm autonomously invented debts.” The scheme arose from explicit policy and administrative decisions.

It does not support saying that “all the data was false.” The problem was that annual or period totals and averaged values were insufficient to prove the actual income in each specific fortnight.

It does not support treating automation as the sole cause, nor does it support compressing every individual case into one identical calculation chain and harm outcome.

Primary Sources

• Royal Commission into the Robodebt Scheme: Final Report
  https://robodebt.royalcommission.gov.au/publications/report
• Justice Kyrou, Federal Court of Australia: Mechanisms in the ART Bill to thwart Robodebt-type maladministration
  https://www.fedcourt.gov.au/digital-law-library/judges-speeches/justice-kyrou/kyrou-j-20240318
• Royal Commission Report, Chapter 17 recommendations concerning automated decision-making

---

III. Case Pool and Combined Evidence Distribution

Candidates and Adjudication

Compared with the first batch, the second batch deliberately broadened the sample. It added cloud operations, payments, public warning systems, a low-loss autonomous-driving incident, automated update infrastructure, chatbots, cloud identity, software supply chains, smart contracts, government automated decision-making, and institutional Evidence cases. The resulting pool is therefore less dependent on classic engineering disasters.

Combined Evidence Distribution Across the Seventeen Verified Cases

The figures below are quoted directly from the already frozen joint audit results. They are not recalculated in this appendix.

What These Numbers Mean

The three fully covered analytical items mean different things and must not be merged. Change identifies what became different in an object, State, representation, rule, or environment. It is an analytical entry point, not a Direct Mechanism. Decision / Binding Relation Failure asks whether the correspondence between an Established Upstream Object and the current specific Action continued to hold. Execution State / Result Relation Failure asks whether Commit, Invocation, Execution State, Receipt, External State, and Business Result were incorrectly compressed, mapped, or interpreted. Full coverage across all three does not make them one broad “system failure” label.

Execution Path Deviation has the lowest coverage, and that is precisely why the category remains useful. Among the seventeen cases, only Knight Capital and SolarWinds receive Strong support; ten receive Partial support and five receive None. Low coverage prevents Path from becoming a catch-all. A wrong final trajectory, a wrong parameter propagating through the normal chain, a validator incorrectly approving content, or a legitimate token being wrongly accepted does not, by itself, establish Execution Path Deviation. AWS, Citibank, and Waymo explicitly demonstrate that a normal Path can still carry an incorrect Action.

Amplification has a clear counterexample. One of the seventeen cases—Waymo—receives None for Amplification. That directly establishes that Amplification is not a Necessary Condition.

Execution Boundary failures must continue to be distinguished by form. A Boundary may be absent; it may constrain an incomplete set of objects; an existing Boundary may fail to block a real-world Action; or the Boundary rule or implementation structure itself may be rewritten. Most second-batch cases fall into the first three forms. Strong support for Execution Boundary Failure does not imply Boundary Mutation.

Evidence must be separated by causal position. Before execution, incorrect validation or signing Qualification may drive an Action. After execution, a factual record re-enters the problem space only when it enters a later round of judgment, recovery, accountability, or real-world Action. Proxy data being treated as the deciding fact is yet another relationship problem. These distinctions determine whether an Evidence problem belongs inside the Execution Gap. Purely post-execution loss of observability or provability cannot simply be absorbed into the concept.

Three Candidate Patterns Deliberately Tested

During the research, three recurring patterns initially appeared capable of requiring an additional Direct Mechanism Family. The current evidence did not support that upgrade.

Evidence feeding back into Authority — Cruise and Post Office Horizon, with Robodebt as supporting material. The feedback loops are real, but the current material can represent them as repeated connections among existing mechanism relations across multiple rounds. A new Direct Mechanism Family is not required.

Qualification propagating across organizational domains — Storm-0558 and SolarWinds. The pattern can be expressed as a combination of cross-domain binding, Boundary, and Amplification. The Qualification objects are not the same in the two cases: Storm-0558 involves a key, issuing domain, tenant, and account scope; SolarWinds involves supplier identity, release, payload, and customer installation authority. A similar surface pattern should not erase the differences between the underlying relational objects.

A normatively invalid or unacceptable Decision being faithfully executed by later systems — The DAO and Robodebt. This is not a new Direct Mechanism. It is a question that must be answered before deciding whether an event enters the Execution Gap problem space at all.

Across the seventeen formally verified cases, the evidence did not require a new mechanism family alongside the existing five Direct Mechanism Families. This conclusion applies only to the current case pool. It means the present material has not required structural expansion; it does not mean the current structure has been proved complete.

---

IV. Evidence Limits

The most important limits are collected here because they are also the easiest to cross.

Evidence rating is not severity. Strong, Partial, and None describe the degree of evidentiary support for a particular analytical or mechanism judgment. They are not severity levels, importance ratings, risk grades, accident classes, causal rankings, or mechanism priorities.

Cases are not proof. Cases serve as stress tests, boundary tests, real-world context, counterexamples, or limited supporting evidence. “This case proves the theory is correct” is not how this book uses cases. Seventeen cases do not prove that the present structure exhausts reality.

Do not infer membership from consequences. A Result being severe, unacceptable, or unlawful is not sufficient by itself to place a failure inside this problem space. The analysis must first identify the Established Upstream Object that serves as the reference for deviation and then show how real-world execution or Result failed to preserve the relationship that was required to hold.

Do not force a case into one mechanism. A case appearing in multiple places in the main text does not mean that the mechanisms have been shown to be mutually exclusive, nor does it create a case-by-case classification system.

Do not rewrite legal or governance conclusions as theoretical conclusions. Courts, regulators, and official reports make judgments within their own domains. This book’s research mapping is a different kind of analysis. Neither should substitute for the other.

Do not fill evidentiary gaps with conventional retellings. Wherever this appendix says “not supported by the available sources,” “not provided,” or “remains unknown,” authoritative material has not established the missing fact. The gap remains a gap.