AI Execution Engineering

Foundational Theses on AI Execution Engineering

Ten Axioms, Definitions, and Propositions for an Emerging Engineering Discipline

The Execution Gap, Execution Control, Adversarial Completeness, and the Execution Boundary Language

Version 1.0 | July 2026 | Havenlon Labs | Chengdu Havenlon Security Technology Co., Ltd.

This book advances ten axioms, definitions, and propositions as the foundations of AI Execution Engineering - an emerging engineering discipline that has not yet been formally established.

The theory was not produced by abstract deduction alone. It was distilled from nearly two years of work across software, protocols, runtimes, evidence systems, and hardware boundaries.

It is offered for judgment, not acceptance. Showing that an axiom is unnecessary, or producing a system that violates it while still preserving Execution Control, would constitute a valid refutation.

---

Preface: An Engineering Discipline Yet to Be Established

This book proposes ten axioms, definitions, and propositions for AI Execution Engineering - an emerging engineering discipline that has not yet been formally established.

For decades, the central objective of software engineering has been to make computation happen correctly. Programming languages, algorithms, databases, network protocols, and operating systems have evolved around stability, efficiency, and reliability. The security systems built on top of them - authentication, authorization, access management, encrypted communication, and system protection - have served the same enduring objective: to ensure that computation in the digital world proceeds as expected.

This paradigm rests on an implicit premise: software provides capability, while people make execution decisions. Whether the action is transferring funds, signing a contract, starting a machine, or approving a business process, a person ultimately turns a digital conclusion into a Real-World Action. Software computes; it does not bear responsibility for execution.

That premise is failing.

AI systems increasingly do more than generate content. They interpret goals, plan tasks, call tools, orchestrate workflows, and affect the physical and institutional world through interfaces and devices. Across enterprise workflows, industrial control, digital assets, and robotics, AI is becoming part of the execution chain rather than remaining an information-processing tool outside it.

This change forces a question that earlier systems could leave implicit:

Under what conditions is a digital intent entitled to enter the real world?

This is not merely a question of computational correctness. A computational error may crash a program, corrupt data, or interrupt a service. Its effects are usually confined to the digital domain and are often reversible. An execution error may transfer funds to the wrong party, start the wrong device, or grant the wrong authority. Its effects occur in the world and may be impossible to reverse.

The object of protection must therefore expand from the program itself to the entire path between Intent and Real-World Action.

Neither traditional software engineering nor traditional security engineering addresses this path as a unified object. Security engineering protects identities, permissions, and access relationships. Its core question is "who may access what?" rather than "is this exact action entitled to occur?" Between those questions lies an unclaimed domain. This book calls it the Execution Gap.

AI Execution Engineering is proposed as an engineering perspective for that domain. It does not replace software engineering, nor is it simply an extension of cybersecurity. Its object is different: how digital systems can affect the real world safely, verifiably, and traceably.

The book develops four connected bodies of theory:

• Execution Gap defines the risk interval between digital Intent and Real-World Action.
• Execution Control establishes an adjudication mechanism independent of the business system.
• Adversarial Completeness asks whether that control survives malicious behavior, abnormal states, and unknown conditions.
• EBL, the Execution Boundary Language, turns the theory into verifiable, executable, and auditable boundary rules.

This is a foundational statement, not an introductory text. An introduction explains an established discipline; a foundational statement proposes testable and refutable starting points for a discipline yet to be established. The text therefore presents ten axioms, definitions, and propositions. It distinguishes conclusions derived from those premises from engineering choices that remain contingent.

Important parts remain unfinished. The language requires further design. Runtime implementations require verification. Hardware boundaries have not yet converged on standards. Different industries will produce different implementations. Yet the problem already exists, and greater model capability will not make it disappear.

The relationship is closer to the reverse: the more capable the AI, the more automated the execution, and the richer the available tools, the more the real world needs a boundary that cannot be reasoned around, manipulated, or bypassed by intelligence itself.

The next decade must build more than stronger models, better agents, and more efficient automation. Beneath those capabilities, another layer of infrastructure must exist. It will not help systems do more. It will hold the line on what must still not happen. It will not replace human judgment. It will keep human intent from being silently rewritten before it enters reality. It will not assume that any actor remains trustworthy forever. It will require consequential execution to be jointly established by evidence, rules, and boundaries.

That is the engineering discipline proposed here.

---

Chapter 0: Terminology, Notation, and Conventions

This chapter is a reference, not an argument. First-time readers may skip Section 0.3 and return to it as terms appear.

0.1 Types of Claims and Numbering

Every independently standing claim is marked by type. This allows readers to identify the source of its force and the burden required to refute it.

The category Engineering Convention is deliberate. A new discipline is especially vulnerable to disguising design preferences as necessities. Whenever this book makes a choice that cannot be derived from its axioms, the choice is marked as an engineering convention and its cost is stated.

Epigraphs are rhetorical and carry no argumentative force. Paragraphs marked Supplement extend the original line of argument.

0.2 Symbol Table

Table 0-1: Symbol Conventions Used Throughout the Book

The complete Decision Function is:

Γ : (I, x, P, K, Ev, Ctx, t) → (d, π)

0.3 Glossary

Terms are grouped by theoretical role. Each definition is property-based rather than rhetorical.

Problem Domain

Control Mechanisms

Boundaries and Capabilities

Evidence and Proof

Failure Semantics

Language and Runtime

Adversarial Analysis

---

Chapter 1: The Execution Gap

Every step may be legitimate while the final result is still wrong.

1.1 Traditional Security Protects Nodes, Not Paths

Modern security systems place mature controls at different points in an execution path. Identity establishes who entered the system. Authorization determines what classes of operation an actor may perform. Authentication establishes where a request originated. Approval records who expressed consent. Digital signatures protect the integrity and provenance of data.

The problem is not that these mechanisms are ineffective. It is the way they are organized. Different teams build them at different times, under different standards, and with different scopes. Each system performs its assigned role, but no system is responsible for the path as a whole.

Table 1-1: Protection Domains of Traditional Security Mechanisms

The final column reveals a shared absence: none of these mechanisms establishes why the execution outcome should be treated as a legitimate continuation of the original Intent.

A familiar but structurally unexpected condition follows. The user's identity is genuine. Permissions are correct. Approval succeeds. The signature is valid. The API call completes. The device behaves exactly as instructed. Yet the outcome is not what the user intended.

This is not necessarily a compromised node. It is a failure to constrain the relationships between nodes.

Proposition P1.1 - Non-transitivity of local correctness
Every component in an Execution Chain satisfying its own specification does not imply that the end-to-end result conforms to the original Intent.

P1.1 is the starting point for the rest of the book. If local correctness were transitive, Execution Control would be unnecessary.

1.2 The Structural Change Introduced by AI

AI is not the first software to execute tasks automatically. Scripts, workflow engines, rule systems, automation platforms, and industrial controllers have long operated without continuous human intervention. The important change is not automation itself but when the execution path is determined.

Traditional automation follows paths fixed at deployment time. AI systems interpret goals, choose paths, generate parameters, and compose tools at runtime. Deployment-time path review therefore loses coverage: reviewers can inspect the set of available capabilities, but not every path the system may later assemble.

Table 1-2: How AI Expands the Execution Chain

Every dimension adds transformations or increases the freedom of transformation between Intent and action. Transformations are where relationships break.

Proposition P1.2 - Normalization of the gap
In systems whose paths are determined at runtime, the Execution Gap is not an integration defect that stricter testing can eliminate. It is a structural consequence of paths that do not yet exist at deployment time.

The engineering consequence is decisive. The solution cannot be to review every possible path. The path set does not exist in advance. Constraints must instead be applied at the endpoint, to the final execution object.

1.3 Definition and Causes of the Execution Gap

Transformation Points Are Break Points

Consider the minimal chain:

Intent → Policy → Approval → Execution

The chain appears complete, but each arrow represents a transformation. Intent is interpreted as a structured request. The request is mapped into policy facts. A policy conclusion becomes an approval object. Approval is bound, or fails to be bound, to a final payload. The payload is routed to a concrete target. The target acts in a particular state and at a particular time.

None of these transformations is naturally faithful. Each may drop a constraint, substitute an object, fill a missing field, or alter scope. Human Intent is necessarily incomplete: "pay this invoice" does not specify the account, network, currency, fee limit, or deadline. "Restore the server" does not specify which services may restart, whether in-flight jobs may be lost, or whether failover is permitted. Downstream systems must complete what was omitted, and those completions are rarely bound to the original Intent.

At the other end, execution systems are deliberately narrow. A blockchain node validates format and signature. An operating system validates permissions. An industrial controller validates protocol conformance. An API validates tokens and field types. These checks establish that a command can be accepted; they do not establish that it should be accepted.

Definition

Definition D1.3.1 - Execution Gap
The structural space between the formation of original Intent and the occurrence of a final Real-World Action, composed of interpretation, policy mapping, approval, orchestration, parameter generation, object binding, and state change, but lacking an end-to-end execution constraint.

The gap is not a single component or a duration. It is a set of broken relationships: Intent to request, request to policy facts, policy result to approval object, approval object to final payload, payload to target, digital state to real-world state, and delegated authority to final consequence.

Figure 1-1: Seven Relationship Breaks Along the Execution Chain

Execution Control turns these unverified transitions into verifiable relationships.

A Legitimate Path Can Produce the Wrong Result

The difficulty is that the gap does not require misconduct. A legitimate user may issue a genuine request; an AI may use authorized tools; policy may return ALLOW; reviewers may approve; a signing service may produce a valid signature; and the target may execute successfully. If the model misunderstood the target in the first transformation, every later security mechanism may merely protect the reliable propagation of that misunderstanding.

Proposition P1.3 - Failure of a legitimate path
A legitimate actor, legitimate authority, and legitimate process do not preclude an execution outcome that conflicts with the original Intent.

Accountability Void

The organizational cause is equally important. Responsibility is divided by component: model teams own model behavior, agent teams own orchestration, security teams own permissions, business teams own approval, device teams own execution, and audit teams own records. Every team can demonstrate component compliance, but the execution outcome is produced by the chain.

Proposition P1.4 - End-to-end Accountability Void
In an organization that assigns responsibility by component, if no independent actor is accountable for the final execution outcome, then no actor in the Execution Chain is accountable for that outcome. Everyone owning one part is equivalent to no one owning the result.

1.4 Boundaries with Adjacent Disciplines

AI Execution Engineering overlaps with mature fields, but its protected object is different.

Table 1-3: Protection Domains and Coverage Boundaries of Adjacent Fields

Functional safety and formal verification are the closest intellectual neighbors because both insist on proof rather than declaration. The difference is the decision object. Functional safety asks whether equipment failure can create danger. Formal verification asks whether implementation conforms to specification. AI Execution Engineering addresses what both usually treat as premises: whether the instruction is faithful to Intent, and what must happen when that cannot be proven.

Its relationship with SRE contains a genuine directional conflict. SRE optimizes availability and tends to preserve service under failure. Execution Control refuses release when proof cannot be completed. The conflict is resolved by scope, not by rhetoric: availability may reasonably dominate for reversible digital operations; Fail Secure should dominate for irreversible Real-World Actions.

1.5 Summary of Propositions

Table 1-4: Summary of Chapter 1 Propositions

The object to govern is not a node but the transformation relationships between nodes. The mechanism required is not a stricter component specification, but independent adjudication of the final execution object.

---

Chapter 2: Execution Control

Audit tells you what happened. Execution Control decides whether it may happen.

2.1 The Decision Function and the Control Chain

2.1.1 The object of control

"Control" is used for many different mechanisms: access control, process control, device control, and risk control. Each constrains a different object. Execution Control has one object only: the exact action that is about to enter reality.

It does not ask merely whether an actor may perform this kind of operation. It asks: What precisely will happen? To which object? On the basis of which facts? Does the action still correspond to the original Intent? Is the approved object still the current object? Do the required conditions still hold? Is there any condition that requires a veto?

Definition D2.1.1 - Execution Control
A set of engineering mechanisms that, before a Real-World Action occurs, independently adjudicates the Intent, final execution object, conditions, Evidence, and their binding relationships, and releases execution capability only when all required conditions have been proven.

Three words distinguish the definition from adjacent mechanisms:

• Before excludes audit.
• Independently excludes self-certification.
• Proven excludes default permission.

2.1.2 Three distinguishing properties

Table 2-1: Execution Control and Existing Mechanisms

First, Execution Control must operate before the result. A mechanism that can alert but cannot stop is monitoring, not control.

Second, it adjudicates a single action rather than a long-lived qualification. The authority to transfer funds does not imply that this transfer should occur. The target, amount, approval binding, time window, state, and conflicting Evidence may differ from one transaction to the next.

Third, it checks the result rather than the appearance of the process. A workflow may contain multifactor authentication, multiple approvals, encrypted transport, a hardware key, and complete logging. If the approved object is not verifiably bound to the signed object, those mechanisms may only ensure that the wrong result is completed correctly.

Proposition P2.1 - Depth of control
A control point that does not cover the final execution object cannot close the Execution Gap. Controlling only Intent, approval, or signature does not constitute Execution Control.

2.1.3 The Decision Function

Execution Control is represented by:

Γ : (I, x, P, K, Ev, Ctx, t) → (d, π)

The function accepts the Intent I, Candidate Execution x, business Policy P, Constitution K, Evidence Set Ev, Context Ctx, and adjudication time t. It returns a Decision d in {ALLOW, DENY, SAFE_MODE} and a Decision Proof π.

Every implementation must satisfy:

• Determinism: identical inputs produce identical (d, π). A probabilistic model cannot be the final adjudicator.
• Closure: Γ reads no implicit state. Upstream systems submit Evidence, not conclusions.
• Monotonic restriction: for every P, ALLOW(Γ) is a subset of the result allowed in the absence of programmable policy. Policy may narrow the allowable set but may never weaken K.

The output is not Boolean because "the system proved that the request must be denied" and "the system could not complete a proof" are operationally different conditions.

2.1.4 The Control Chain

Figure 2-1: The Control Chain from Intent to Reality

A workflow passes conclusions from one stage to the next. A Control Chain builds verifiable relationships. Intent defines goals and invariants. Policy defines necessary business conditions. Approval binds to the exact object. Evidence establishes that current conditions hold. Candidate Execution represents the precise action. Final Veto evaluates all relationships together.

Table 2-2: Five Adjudication Obligations of the Control Chain

For long-running, streamed, or batched execution, the chain contains a return edge: a change to x, Ev, or Ctx invalidates the previous decision and requires re-adjudication. The validity interval is an engineering choice, not a universal constant.

2.2 Intent Binding

The upper layer approves one description; the lower layer executes another object.

2.2.1 Three distances between Intent and execution

Axiom A2 states I ≠ x for three independent reasons.

First, Intent is incomplete. "Pay the balance" omits the account, rail, currency, fee limit, and deadline. "Restore the server" omits the affected services, tolerance for lost work, and permission to fail over. Downstream systems necessarily add detail.

Second, one Intent admits multiple execution plans with different costs, risks, and degrees of irreversibility.

Third, Intent is repeatedly transformed: natural language becomes a structured request, policy input, approval object, final payload, and target command. Every re-expression is a possible point of drift.

Intent is therefore not an executable instruction. It is the source of execution constraints.

2.2.2 Intent Objects and invariants

Intent cannot participate in adjudication if it exists only in a conversation, meeting note, or person's memory. It must become a hashable, signable, referenceable, and auditable object.

Definition D2.2.1 - Intent Object
A verifiable structure that states what is expected to happen and carries the relevant constraints. At minimum it includes an identifier, initiating actor, target, operation, required constraints, permitted scope, prohibited conditions, validity period, Evidence requirements, approval requirements, and acceptable outcomes.

Saving the original prompt and comparing it with the final command is not sufficient. Natural language and machine instructions occupy different representational levels. Textual similarity is neither necessary nor sufficient.

The workable alternative is an invariant set:

I.inv = {
  target,
  quantity or amount,
  time window,
  destination system,
  risk class,
  permitted methods,
  prohibited conditions,
  approval scope,
  final payload digest
}

Figure 2-2: The Verification Relationships of Intent Binding

Definition D2.2.2 - Intent Binding
A verifiable relationship between Candidate Execution x and Intent Object I in which every corresponding attribute of x agrees with every element of I.inv, and that agreement can be replayed from π.

Binding is exact. If account A becomes account B, the binding fails. If 100,000 becomes 110,000, it fails. If the environment changes from test to production, it fails. If approval expires or payload regeneration changes the digest, it fails.

2.2.3 Intent is necessary but not sufficient

Even valid, correctly bound Intent does not imply that execution should occur. The world changes: an account is replaced, a device enters maintenance, an authorization is revoked, a risk level changes, an approval expires, or regulation changes.

Proposition P2.2 - Necessary but insufficient Intent
The existence of an Intent Object and a valid binding is necessary for d = ALLOW, but not sufficient. The Intent must also remain valid in the current Ctx at time t.

Intent is the beginning of adjudication, not its conclusion.

2.3 Final Veto

2.3.1 The missing duty to refuse

Most components in an Execution Chain are optimized to complete work. Business systems optimize task completion. Orchestrators optimize goal attainment. Approval systems optimize workflow closure. Signing services optimize successful responses. It is therefore possible to build a complete chain in which no component treats prevention as its primary duty.

Functional rejections - invalid parameters, insufficient balance, workflow timeout - protect business correctness. They disappear when a condition is repaired or a request is retried. Execution Control requires a different capability: refusal whenever the proof is incomplete, independently of whether the business operation could otherwise succeed.

Definition D2.3.1 - Final Veto
A rejection capability held, before x receives the Necessary Capability required to cross the Execution Boundary, by an adjudicator independent of the generator of x. The adjudication is mandatory and precedes action; a non-ALLOW result cannot be overridden, retried away, or reinterpreted by an upstream component; and the adjudicator receives the final execution object rather than an upstream description.

Final Veto does not propose alternatives, optimize workflows, or fill missing fields. It asks one narrow question: does the current input constitute a complete proof of ALLOW?

2.3.2 Why approval, signatures, and models are insufficient

Approval has a temporal defect. It normally occurs before the final object is fully materialized. Parameters, routes, payloads, and system state may change afterward. Unless approval binds to the exact final object, consent cannot extend to execution.

Digital signatures have a semantic defect. A signature establishes that a key signed bytes. It does not establish that those bytes reflect Intent, preserve approved parameters, target the right account, use current Evidence, or remain safe under the present state.

Proposition P2.4 - A signature is not a veto
If Sign(k, m) only establishes possession or use of key k, it cannot determine whether x satisfies I.inv. It therefore fails the final-object requirement of D2.3.1.

Corollary C2.4
Final Veto must operate before the signing or execution capability is granted and must be able to refuse that capability.

Model judgment has a determinism defect. Models are valuable for anomaly detection, risk analysis, and option comparison. They are not suitable final adjudicators. Their output can change with context, wording, or sampling; they may turn missing conditions into "reasonable judgment" or explain away conflicting Evidence. That behavior is incompatible with conservative closure.

Table 2-4: Traditional Mechanisms and Final Veto

2.3.3 Independence

If the controlled system provides its own veto, the veto and the object it constrains share a Trust Domain. Compromise of that domain removes both the constraint and the constrained capability.

Independence must be assessed across at least six dimensions: execution path, state assessment, rule source, key or capability control, records and Evidence, and failure mode. Failure-mode independence is easily missed. Shared power, clock, or network paths can turn apparently separate components into one common-cause failure domain.

Independence does not require isolation. The adjudicator may receive data from upstream systems, but it must receive those inputs as Evidence rather than accept upstream conclusions as facts.

2.3.4 Output and default posture

Missing, expired, unverifiable, and conflicting Evidence do not mean the same thing as a proven false condition. The output domain is therefore {ALLOW, DENY, SAFE_MODE}, accompanied by π.

Engineering Convention E2.3 - Default posture
The default output is non-ALLOW. ALLOW is produced only when a complete Decision Proof exists. The cost is reduced availability; the justification is the asymmetric cost of false rejection and false release discussed in Section 3.4.

Final Veto does not promise perfect judgment. It promises a weaker but testable property: when a proof cannot be completed, the Real-World Action does not occur.

2.4 The Physical Trust Boundary

Hardware protects more than keys. It protects the set of things that must not happen.

2.4.1 Layering flexibility and certainty

Software is valuable because it is flexible: it can be upgraded remotely, configured dynamically, and adapted quickly. A safety-critical boundary needs the opposite properties: deterministic behavior, a small attack surface, predictable failure, resistance to remote persuasion, and constraints that cannot be disabled.

Execution Control therefore keeps complexity above the boundary and pushes certainty down into it. Upper layers interpret, plan, orchestrate, and optimize. The boundary performs one narrow duty: it withholds capability when proof is incomplete.

2.4.2 Definition and criteria

Definition D2.4.1 - Physical Trust Boundary
An Execution Boundary created by an independent hardware domain that exclusively controls a Necessary Capability. The capability resides inside the domain; upper-layer software cannot bypass adjudication; the boundary can refuse independently; ordinary administrators cannot disable critical rules; keys or control capabilities are not exposed upward; the boundary can verify objects, state, and Evidence; and adjudication is recorded independently.

Using hardware is not enough. A device that accepts every host command, performs no independent state assessment, and can be freely updated over the same remote path remains an external actuator in the host's Trust Domain.

Proposition P2.3 - Protecting keys is not protecting execution
If a hardware module only signs the payload submitted by an upper layer, it protects the key rather than the execution. It reduces key-exfiltration risk but not erroneous-execution risk.

2.4.3 Necessary Capability

The boundary derives control from exclusive possession of cap. Examples include the final signing key, device-start signal, power control, execution token, indispensable communications path, non-substitutable authorization proof, or final command-decryption capability.

The criterion is simple: if an upper-layer system can perform the action without the boundary, the boundary is an advisory component rather than a boundary.

Figure 2-3: Layering and Capability Ownership in Execution Control

2.4.4 Owner ≠ God Principle

Ownership grants authority to administer a system. It should not automatically grant authority to disable every safety constraint. Policies are divided into programmable P, which authorized parties may change, and fixed K, which no administrative identity may disable, weaken, or bypass.

Engineering Convention E2.4 - Location of fixed baselines
K should be fixed in the hardware domain that controls cap. Changes should require a path distinct from ordinary configuration, such as local physical action, multi-party physical credentials, or irreversible firmware controls. The cost is higher change friction. The justification is that a baseline modifiable through ordinary remote administration does not survive remote compromise.

2.4.5 A boundary is not an island

The boundary must receive Intent, approval, Evidence, and state snapshots. The distinction is epistemic: upstream systems provide Evidence, not authoritative conclusions. The boundary verifies what it receives.

Its failure mode must also be independent. Shared power, clock, or communications may create a common-cause failure that defeats the independence required by A6.

2.5 Evidence and Decision Proof

ALLOW does not mean that the system found no problem. It means that the system completed a proof.

2.5.1 Facts rather than conclusions

Upstream systems often submit conclusions: "risk approved," "compliance checked," or "identity verified." As these statements pass downstream, trust does not increase, but verifiability decreases. The receiver cannot identify the facts, time, or subject on which the conclusion depended.

Definition D2.5.1 - Evidence
A verifiable fact object used to establish a condition. At minimum it carries a type, a source and verifiable credential, a binding to the subject it describes, and temporal semantics including issuance and validity.

2.5.2 Evidence and logs

Table 2-3: Evidence and Logs

Evidence may later be stored in an audit system, but only the information used before execution belongs to Execution Control.

2.5.3 Four semantic requirements

Validity window. Evidence describes facts at a time, not eternal propositions. Once its validity window closes, its state becomes EXPIRED.

Subject binding. Evidence must identify the exact account, device, object, session, or state snapshot it describes.

Conflict preservation. Contradictory Evidence must not be reduced through majority voting, source preference, or selective omission. Conflict is itself a fact and must remain visible as CONFLICT.

Relational independence. Multiple confirmations are not independent merely because they are numerous.

Proposition P2.5 - Counting does not prove independence
n > 1 Evidence objects do not imply independent failure events. Unless the relevant dimension of independence is represented, multi-party confirmation collapses to single-party confirmation under a common-cause failure.

Relevant dimensions include identity, device, Trust Domain, key source, organizational role, physical location, and failure path.

2.5.4 Complete proof and ALLOW

ALLOW requires all necessary conditions to have corresponding Evidence; every participating item to be VALID and bound to the correct subject; no unresolved conflict; valid binding among Intent, approval, and final object; and no violated constitutional constraint.

"No problem was found" is a negative claim whose force depends on the completeness of the checks. "A complete proof exists" is a positive claim carried by π and open to replay.

Figure 2-4: Structure of a Decision Proof

Any failed node prevents ALLOW, and the failed node must be identifiable in π. A rejection that cannot explain its cause will eventually be bypassed for operational reasons.

2.5.5 Evidence Chains

Intent creation, policy selection, approval, state collection, and object generation create Evidence that references and depends on other Evidence. Together they form an Evidence Chain. The chain allows each fact to be traced to a verifiable source instead of terminating in an assertion that cannot be checked.

A practical implementation need not retain all raw data forever. It may preserve a replayable minimum: Evidence digests, source credentials, status markers, and rule versions. The tradeoff is that if the raw source later disappears, replay can establish consistency but not original truth.

2.6 The Ten Axioms

The following axioms are selected starting points, not summaries disguised as conclusions.

A1 - Verifiable Intent

If no verifiable Intent Object I exists, Γ is undefined and the result is DENY.

Without I, deviation cannot be defined. A system may run correctly but cannot explain whether it is doing the right thing.

A2 - Non-identity of transformation

I ≠ x. The transformation from I to x must be constrained and must preserve I.inv.

Treating Intent as execution denies the semantic loss between a human description and an exact action.

A3 - Approval Binds to the Object

Approval must bind to hash(x), not merely to a natural-language description of I.

Otherwise approval and execution refer to different objects.

A4 - Policy is not sovereign

Adjudication is the conjunction P ∧ K. P may not disable, weaken, or bypass K.

Formally, adding policy can only shrink the ALLOW set. If the programmable layer can change the baseline, safety becomes equivalent to perfect configuration.

A5 - Boundary veto

A system without a component that can produce a non-ALLOW result which no upstream component can override is not an Execution Control system.

If every component can only say yes, the boundary does not functionally exist.

A6 - Independence of veto

The Trust Domain that generates x must differ from the Trust Domain that evaluates Γ.

Otherwise one compromise removes both the execution constraint and the constrained capability.

A7 - Facts require Evidence

Critical conditions must be established by Ev. Trust in the source is not itself proof.

Otherwise adjudication degenerates into a chain of inherited trust.

A8 - Conservative closure

d = ALLOW if and only if a complete Decision Proof π exists. Evidence state is one of VALID, UNKNOWN, MISSING, EXPIRED, or CONFLICT; only VALID Evidence may participate in π.

The four non-VALID states must remain distinct because they require different recovery actions.

A9 - Duty to re-adjudicate

A change to x, Ev, or Ctx immediately invalidates the existing (d, π) and requires re-evaluation.

Otherwise a decision becomes a reusable pass and time-of-check to time-of-use drift becomes an attack surface.

A10 - Control of capability

The boundary must exclusively control a Necessary Capability cap such that d ≠ ALLOW implies that the Real-World Action cannot occur.

Without A10, a veto is advice. A1 through A9 may be implemented in software; A10 requires control over the physical or cryptographic means of action.

Table 2-5: Layers of the Axiom System

The set is not minimal. A3 may be treated as a specific consequence of A2 and A9; A6 may follow from A10 in some implementations. They remain separate because each corresponds to a property that engineers can audit independently.

---

Chapter 3: Adversarial Completeness - Proving Boundaries Under Attack

A security feature says what a system has. A security proposition says what still cannot happen.

3.1 Completeness Propositions

3.1.1 Three Non-implications

The presence of Execution Control does not establish that the control survives adversarial conditions.

First, absence of defects is not the same as security. A defect is a deviation from specification. A defect-free system may still be compromised because the specification omitted an attack path.

Second, correct operation is not the same as an effective boundary. Expected output under expected input says little about behavior under unexpected input, component failure, or malicious actors.

Third, local security is not end-to-end security. Component-level security specifications do not cover the transformations between components.

Definition D3.1.1 - Adversarial Completeness
The property that critical execution constraints remain true under an explicitly stated threat and failure model. A claim of Adversarial Completeness must identify the model boundary, fixed safety baselines, components permitted to fail, Trust Domains that must not fail together, system state under failure, actions that must be refused, and independently verifiable conclusions.

"Explicitly stated" is part of the property. No finite system resists unlimited resources, arbitrary physical access, and every conceivable attack. Adversarial Completeness is a conditional, falsifiable claim: within the stated model, compromise of specified components does not bypass the critical constraint.

3.1.2 From Security Features to Security Propositions

Security must therefore be expressed as propositions of the form "even if X, Y still cannot occur."

Table 3-1: Examples of Security Propositions

Proposition P3.1 - Falsifiability
A security claim that does not specify what is assumed to be compromised cannot be falsified and therefore cannot establish Adversarial Completeness.

Mechanism is not proof. A security feature and the survival of that feature under compromise are separate propositions.

3.2 EX-STRIDE Threat Taxonomy

3.2.1 Choice of Classification Dimension

STRIDE classifies threats to data and identity. The Execution Gap is produced by broken transformation relationships, which do not map cleanly to those categories.

Classifying by threat actor - model, administrator, insider, supply chain, device, network - is intuitive but not closed. The actor set changes with technology. EX-STRIDE instead classifies by the affected element of the Decision Function: I, x, P, K, Ev, cap, or Γ. Any attack that changes execution must affect at least one.

3.2.2 Classification Matrix

Table 3-2: EX-STRIDE Threat Classification Matrix

The matrix is used by column: examine each element of a concrete system for uncovered threat classes rather than attempting to enumerate every known attack technique.

3.2.3 Unified Treatment of Failure and Attack

Failure and attack may have different causes but identical adjudication input. Evidence unavailable because of network partition and Evidence suppressed by an attacker both appear as MISSING.

Proposition P3.2 - Adjudication equivalence of failure and attack
If Γ cannot distinguish whether an input state was caused by failure or attack, it must handle that state under the attack assumption. Relaxing control under the failure assumption gives attackers a bypass condition they can intentionally create.

"Skip the check when the service is unavailable" is therefore not merely a resilience behavior. It is an attack surface.

3.3 Multi-state Semantics and State Machine

3.3.1 Four Non-VALID States

A8 defines Evidence state as VALID, UNKNOWN, MISSING, EXPIRED, or CONFLICT.

• UNKNOWN: Evidence was submitted but cannot be verified.
• MISSING: required Evidence was not submitted.
• EXPIRED: Evidence was once valid but no longer establishes a current fact.
• CONFLICT: Evidence contains claims that cannot simultaneously be true.

Figure 3-1: Evidence State Transitions

3.3.2 Non-compressibility

Collapsing the four non-VALID states into false does not change ALLOW, but it destroys the recovery path.

Table 3-3: Recovery Paths for Non-VALID Evidence States

Proposition P3.3 - Non-compressibility of failure states
Mapping these states to one Boolean value loses recovery information. A boundary that can only say "rejected" cannot tell operators who must do what; in practice, such a boundary will be bypassed rather than repaired.

Explainability is therefore not cosmetic. It is a condition of the boundary's operational survival.

3.3.3 UNKNOWN Cannot Be Explained Away

Upper layers must not turn UNKNOWN into a conclusion. A model may make a plausible inference; a business system may insert a default; an operator may rely on experience. These may be useful in information processing, but they are not Evidence. Unknown is valuable precisely because language cannot make it disappear.

3.4 Conservative Defaults and Fail Secure

3.4.1 The Structural Appeal of Fail Open

Fail Open is structurally attractive. Users resist rejection, firms resist interruption, automation is measured by completion, and devices are expected to remain available. Engineers therefore cache state, insert defaults, skip unavailable checks, continue when risk services fail, or fall back from hardware to software.

The common pattern is dangerous: the protection mechanism silently degrades so the system can continue to appear healthy.

3.4.2 Cost Asymmetry

Table 3-4: Cost Structure of False Rejection and False Release

For reversible digital operations, the costs may be comparable. For irreversible execution, they are asymmetric: false-rejection cost is bounded and recoverable; false-release cost may be unbounded.

Engineering Convention E3.1 - Conservative default
For irreversible execution, the default Decision is non-ALLOW. This convention trades availability for containment. It is contingent on the irreversibility of the action and is not prescribed for fully reversible operations.

3.4.3 Default Denial Is Not Permanent Denial

Fail Secure does not mean permanent refusal. It means "do not continue until proof is restored." Recovery may request new Evidence, recollect state, seek new approval, use an independent channel, narrow scope, require local confirmation, or enter a predefined Safe Mode.

Safe Mode preserves a bounded capability subset: read without write, revoke without grant, local without remote, lower value and rate limits, additional independent Evidence, or on-site confirmation. Its objective is:

When the system loses full capability, it must not lose the boundary.

3.4.4 Fail Secure Is an Architectural Property

Fail Secure must be architectural. If it is a setting, it can be disabled. If upper-layer software implements it, it can be bypassed. If the business system retains a direct path to cap, the architecture is Fail Open regardless of documentation.

Proposition P3.4 - Limit of degradation
A degradation path is a bypass path if, after degradation, it permits an action that K prohibited before degradation.

3.4.5 Emergency Mechanisms

Break-glass mechanisms may be operationally necessary, but they must be bounded in scope, supported by provable triggering conditions, limited in time, independently recorded, and unable to disable every constitutional baseline. Emergency conditions may alter P; they should not erase K.

3.5 Verification and Residual Risk

A minimum verification program includes:

1. A threat model that states attacker capability and components allowed to fail.
2. A Failure Matrix pairing critical failures with responses.
3. Invariants that must hold across every input and state.
4. Adversarial tests that construct the conditions in EX-STRIDE and test the security propositions.
5. A predefined method for detecting control failure rather than relying on the eventual discovery of consequences.

This book does not cover attackers with unlimited physical access and time; hardware backdoors introduced at manufacture when no attestation path exists; simultaneous control of all supposedly independent Evidence sources; or contexts in which every action is costlessly reversible. Declaring these limits is part of D3.1.1, not a disclaimer attached after the claim.

---

Chapter 4: EBL - The Execution Boundary Language

The value of a boundary language lies not in doing everything, but in being unable to do what must not be done.

4.1 Why Existing Forms Are Insufficient

4.1.1 Five Requirements for a Boundary Language

An Execution Boundary Language must satisfy five requirements:

1. Determinism: identical rules and inputs produce identical (d, π).
2. Guaranteed termination: adjudication ends within a bounded, precomputable number of steps.
3. Static analyzability: rules and reachable outcomes can be reviewed before deployment.
4. Input closure: rules read no undeclared data and cause no side effects.
5. Proof production: evaluation produces a replayable π.

Table 4-1: Existing Expression Forms and Boundary-language Requirements

JSON and YAML are too weak; general-purpose and natural languages are too expressive.

4.1.2 Non-Turing-completeness Is a Requirement

Proposition P4.1 - Upper bound on expressiveness
A language that guarantees termination and static analyzability cannot be Turing-complete. EBL's rejection of Turing completeness is a direct requirement, not a reluctant compromise.

4.1.3 Natural Language Cannot Be the Final Rule

Natural language may be used to state Intent and draft policy. It cannot be the final rule format. "Large transfers require additional approval" has no deterministic meaning unless "large," "additional," and the binding object are formalized.

Engineering Convention E4.1 - Separate generation from adjudication
A model may generate EBL for review, but it may not evaluate EBL as the final adjudicator. Generated rules must be approved by people or deterministic tooling before deployment.

4.2 Properties of an Execution Boundary

4.2.1 Definition

Definition D4.2.1 - Execution Boundary
A one-way control point that a Candidate Execution must be authorized to cross, after which the action enters the real world. The boundary consists of evaluable rules and exclusive control of a Necessary Capability cap.

Rules without capability control can be bypassed. Capability without rules is merely a switch.

4.2.2 Six Properties

A valid boundary has six properties:

1. It is not ordinary configuration. Configuration controls how a system works. A boundary defines what cannot happen. The fixed portion must use a different change path.
2. It controls Candidate Execution, not Intent. Its input is the fully materialized x.
3. It sees the final object and its bindings. A change to the object invalidates the prior proof.
4. It does not create action. It does not propose alternatives, repair parameters, or complete missing fields.
5. It is one-way. There is no "execute now, prove later" path. After rejection, upstream systems may submit new Evidence, but the request is adjudicated again.
6. Rules combine without overriding one another. Fixed baselines cannot be weakened by later business rules.

Figure 4-1: The One-way Nature of an Execution Boundary

Proposition P4.2 - Composition law
EBL combines rules by conjunction. For any rule set R, adding a rule can only shrink the ALLOW set: ALLOW(R union {r}) is a subset of ALLOW(R).

EBL therefore provides no priority override, "last rule wins," or exception rule that widens permission. Relaxation requires changing the restrictive rule through its authorized change path.

4.3 Constitution

4.3.1 Why a Boundary Language Needs a Constitution

If one policy language can modify every rule, it can modify the rules that constrain modification itself. Safety then becomes equivalent to flawless administration.

Definition D4.3.1 - Constitution (K)
The EBL rule set that programmable Policy cannot disable, weaken, or bypass; that changes only through a path distinct from ordinary policy; and that defines the capability limits of the language itself.

4.3.2 Ten Constitutional Principles

Table 4-2: EBL Constitutional Principles and Their Basis

C1 through C3 constrain language and Runtime form. C4 through C8 constrain adjudication semantics. C9 constrains resource behavior. C10 is the meta-rule that prevents the others from being disabled.

4.3.3 The Constitution Precedes Syntax

The Constitution precedes syntax. Because C9 requires termination, EBL has no unbounded loops or arbitrary recursion. Because C2 prohibits side effects, it has no external calls. Because C3 requires determinism, it has no randomness or implicit clock. Because C4 preserves failure states, condition evaluation is not simply Boolean. Because C10 prohibits override, it has no priority-based exception syntax.

These restrictions are strongest when prohibited constructs do not exist in the grammar rather than being blocked by configurable linting.

4.3.4 The Constitution as a Runtime Verification Standard

The Constitution is also the conformance standard for Runtime implementations. Server processes, trusted execution environments, coprocessors, and microcontrollers must produce the same result for the same input.

A rule that violates the Constitution should be rejected at load time, not silently deployed and ignored. Silent ignoring misleads the author into believing that the rule has effect.

4.4 Runtime

Runtime does not create trust. It verifies proof.

4.4.1 Adjudication and execution are separate

Runtime implements Γ. It adjudicates but does not execute. It does not generate Candidate Executions, repair parameters, complete missing fields, or change the external world.

This separation limits the consequences of compromise. A compromised Runtime may emit an erroneous ALLOW, but the hardware boundary that controls cap can still apply independent fixed constraints.

4.4.2 Input closure

Runtime reads only (I, x, P, K, Ev, Ctx, t). It must not query an external service during evaluation, read the current time implicitly, access undeclared fields, or depend on hidden caches and prior decisions.

Figure 4-2: Runtime Input Closure and Output Structure

Closure makes replay possible. It also excludes hidden authority: no built-in administrator exception, debug bypass, or timeout-to-ALLOW behavior may exist outside the rule set.

4.4.3 Actionable output

Runtime returns d and π. For non-ALLOW results, it identifies the failure location and semantics.

Proposition P4.3 - Actionable output
If a Runtime cannot identify the failure location and distinguish MISSING, UNKNOWN, EXPIRED, and CONFLICT, operators cannot know whether to supply Evidence, repair verification, seek reissuance, or obtain independent resolution. Non-actionable rejection invites disabling the control.

4.4.4 Resource bounds

Runtime enforces explicit maxima for evaluation steps, memory, nesting depth, Evidence count, and rule complexity. Exceeding a bound yields SAFE_MODE, not more time or a default ALLOW. Resource exhaustion is a failure to complete proof.

Predictable upper bounds also prevent attackers from using pathological rules or Evidence sets to create unbounded adjudication delay and availability pressure.

4.4.5 Portability without semantic drift

Proposition P4.4 - Cross-implementation consistency
If two Runtime implementations produce different d values for the same (I, x, P, K, Ev, Ctx, t), security propositions based on that rule set do not hold across the union of their deployment environments.

The authority for meaning is the Constitution and its conformance suite, not any individual implementation, including a reference implementation.

4.4.6 Runtime does not create trust

"The Runtime approved it" does not make an action safe. Runtime only checks whether submitted Evidence constitutes the required proof. The reliability of ALLOW cannot exceed the reliability of that Evidence.

The path to a stronger boundary is therefore not a more intelligent Runtime. It is more verifiable Evidence and more complete control over cap.

4.5 Evidence and Proof in EBL

4.5.1 Typed Evidence

EBL Evidence is typed, not represented as an unstructured string or Boolean.

Definition D4.5.1 - Evidence Type
A declaration of the conditions an Evidence object may establish, its required metadata, method of source verification, temporal semantics, and independence relationships with other types.

Typing moves errors earlier. Without types, the applicability of Evidence is dispersed across runtime rules. With types, an invalid reference can be rejected when the rule is loaded.

4.5.2 Proof Graph

Decision Proof π is a directed graph. Leaves are Evidence. Intermediate nodes are conditions and rule evaluations. The root is the Decision. At minimum, the graph records rule identity and version, Evidence and state, the I ↔ x ↔ Approval bindings, satisfied constitutional constraints, the evaluation path, and temporal state at t.

4.5.3 Three Levels of Replay

Replay has three levels:

Table 4-3: Levels of Decision-proof Replay

Engineering Convention E4.2 - Proof retention
Retention level should be fixed by execution class in the Constitution rather than adjusted by business policy. Higher retention improves verification but increases storage and privacy exposure.

4.5.4 Proof Is Not a Data Warehouse

Proof is not a data warehouse. Data belongs in π if and only if it participated in the Decision. Unused historical information belongs in logs.

4.6 Minimal Model and Non-goals

4.6.1 Six Object Classes

The theoretical model contains six object classes:

Figure 4-3: The Six Object Classes of EBL

Execution itself is intentionally absent. EBL decides whether the Candidate Execution may cross the boundary. The boundary and downstream system perform the action.

4.6.2 Non-goals

Table 4-4: EBL Non-goals

4.6.3 Relationship with Existing Systems

EBL does not replace identity, approval, business, AI, or hardware systems. It provides a shared language in which their outputs can become a proof that a final boundary can verify. Adoption therefore requires an interface-level transformation of facts and relationships into verifiable Evidence, not wholesale replacement of existing architecture.

---

Appendices

Note on the reference implementation
The architecture and case study that follow are abstracted and simplified from engineering practice. They show how the theory can be implemented; they do not describe a commercial product in full. Bletchley SaaS and the Enigma execution boundary are component names from the reference implementation. Protocol fields, key-derivation procedures, firmware state machines, and production parameters are outside this book's scope.

---

Appendix A: End-to-End Case Walkthrough

This simplified case shows how human Intent passes through an AI application, governance layer, EBL policy, Runtime, and independent hardware boundary before becoming a Real-World Action. The first submission is intentionally unsuccessful, not because of an attack or obvious error, but because one state Evidence object has expired.

A.1 Scenario and Intent Object

An enterprise uses an AI agent to help manage remote industrial device DEVICE-042. A maintenance lead asks the agent to place the device in maintenance mode and stop its main drive during today's maintenance window. Two independent maintenance personnel must confirm the operation, and the device must be unoccupied.

The natural-language statement is not an execution command. Under A1 and D2.2.1, it becomes a verifiable Intent Object:

Intent ID: INT-2027-0042
Target:    DEVICE-042
Action:    ENTER_MAINTENANCE_MODE
I.inv:
  - main_drive must stop
  - device must be unoccupied
  - two independent approvals are required
  - execution must occur within the maintenance window

After normalization, the system computes intent_hash. Approval, Evidence, Candidate Execution, and the final device command must bind to that value.

A.2 Candidate Execution

The agent generates:

Candidate ID: CAND-042-01
Device:       DEVICE-042
Command:      mode = maintenance
              main_drive = stop
Intent Hash:  H(INT-2027-0042)

The object cannot yet be sent to the device. The AI's responsibility ends with proposing a Candidate Execution. Under A6 and D2.3.1, the generator does not possess release authority.

The candidate is submitted to a governance layer, which presents the Intent and final command, collects approvals, obtains device Evidence, loads Policy, and constructs the Runtime input.

A.3 EBL Policy and AST

The boundary Policy is abstractly:

require candidate.intent_hash           == intent.hash
require candidate.device_id             == intent.target
require candidate.command.mode          == maintenance
require candidate.command.main_drive    == stop
require approval.count                  >= 2
require approval.independent_domains    >= 2
require evidence.device_identity.valid  == true
require evidence.device_occupancy.state == unoccupied
require evidence.device_occupancy.age   <= 30 seconds
require evidence.maintenance_window.active == true

It does not call a network service, recollect state, repair Evidence, or modify the candidate. It declares the conditions that must be proven.

AND
|-- BIND(candidate.intent_hash, intent.hash)
|-- EQ(candidate.device_id, intent.target)
|-- EQ(candidate.command.mode, maintenance)
|-- EQ(candidate.command.main_drive, stop)
|-- GTE(count(valid_approvals), 2)
|-- GTE(count(independent_domains), 2)
|-- VALID(device_identity_evidence)
|-- EQ(device_occupancy.state, unoccupied)
|-- LTE(device_occupancy.age, 30s)
`-- EQ(maintenance_window.active, true)

Before loading the rule, a validator confirms termination, declared Evidence references, absence of side effects, resource bounds, compliance with the Constitution, and explicit treatment of non-VALID states. A violation rejects the rule at load time.

A.4 First Adjudication: EXPIRED

The governance layer collects:

Approval A: MAINTAINER-01 | Trust Domain: TEAM-A
            Bound: H(INT-2027-0042) | valid
Approval B: MAINTAINER-02 | Trust Domain: TEAM-B
            Bound: H(INT-2027-0042) | valid

The two approvals satisfy relational independence because their Trust Domains differ, not merely because the count is two.

Device Identity Evidence:
  Subject: DEVICE-042
  Firmware Measurement: accepted
  Device Signature: valid
  Status: VALID

Device Occupancy Evidence:
  Subject: DEVICE-042
  State: unoccupied
  Observed At: 10:00:00
  Maximum Age: 30s

The Runtime evaluates at t = 10:00:47. The occupancy Evidence is forty-seven seconds old and exceeds its declared validity. It once established the fact but does not establish the current fact. Under A8, its state is EXPIRED rather than true.

Decision: DENY
Failed Rule: evidence.device_occupancy.age <= 30 seconds
Failure Semantics: EXPIRED

A.5 Fail Secure

The approvals are valid and independent. The candidate is correctly formed. Device identity is valid. The maintenance window remains active. Only the occupancy Evidence is stale.

Runtime does not release on the basis that "most conditions" hold. Without a complete ALLOW proof, the hardware boundary withholds device-control capability. It does not assume that the device is probably still empty, reuse cached state, relax the rule because the maintenance window is closing, or permit an administrator to set the validity window to infinity.

A.6 Evidence Update and Second Adjudication

The governance layer requests fresh state:

Device Occupancy Evidence:
  Subject: DEVICE-042
  State: unoccupied
  Observed At: 10:01:02
  Maximum Age: 30s
  Device Signature: valid

The new Evidence binds to the device, session, Intent, candidate, and time window. The first failed adjudication is preserved; it carries the recovery history.

Runtime evaluates again. Every condition now holds:

ALLOW(
  candidate      = H(CAND-042-01),
  intent         = H(INT-2027-0042),
  policy         = H(POLICY-MAINTENANCE-V1),
  constitution   = V1,
  evidence_set   = H(EVIDENCE-SET-02),
  runtime        = V1.0,
  evaluated_at   = 10:01:05,
  decision_proof = H(PROOF-042-02)
)

A.7 Hardware Boundary and Execution

The Candidate Execution and Decision Proof enter an independent hardware boundary. The boundary does not accept allow = true as an authoritative upstream assertion. It independently checks Runtime identity, Policy digest, candidate digest, Intent Binding, proof integrity, anti-replay counter, current device state, and fixed hardware constraints.

Only then does it release a one-time, scoped capability:

DEVICE-042 | ENTER_MAINTENANCE_MODE | MAIN_DRIVE_STOP

The hardware records the result and signs execution Evidence, closing the chain:

Intent → Candidate Execution → Policy → Approval → Evidence Set
       → Runtime Decision Proof → Hardware Release → Result Evidence

A.8 Case Summary

The first attempt involved no attacker, malicious approver, or model error. The system simply held occupancy Evidence that was forty-seven seconds old. Traditional automation might resolve the condition with a cache or default and continue. Under this framework, expiration means that the current fact cannot be proven.

Table A-1: Case-to-principle Mapping

---

Appendix B: Reference Architecture and Hardware Boundaries

B.1 Layered Reference Architecture

Execution Control does not prescribe a single hardware design. It requires clear separation of understanding, coordination, adjudication, and execution across Trust Domains.

Figure B-1: Layered Reference Architecture of an Execution Boundary

The important feature is not component selection but the trust relationship. AI and SaaS may understand business context, coordinate approval, collect Evidence, and generate candidates, but they cannot directly obtain final execution capability. The Linux domain handles networking and interfaces but is not the final adjudicator. The Arbiter evaluates rules and proof. The Security Execution Domain validates the final object, prevents replay, and controls capability release.

The architecture is valid only if compromise of any single upper-layer component cannot directly produce a Real-World Action.

The named components are abstracted from an engineering reference implementation. Specific protocols, key derivation, firmware state machines, and production parameters are outside the scope of this book.

B.2 TEE and Independent MCU

A trusted execution environment can isolate sensitive code and reduce risk after operating-system compromise. Yet a TEE often shares the main processor's boot chain, update path, power, clock, supply chain, peripherals, and administration. These are common-cause failure paths.

TEE is therefore an optional implementation rather than the defining mechanism. For high-risk systems, a separate MCU or security controller can physically separate Final Veto from the general operating system. Its value is not merely safer computation. It is the inability of ordinary software calls to bypass it.

B.3 Out-of-band Confirmation and Display Binding

Some high-risk actions require local or out-of-band confirmation. A display that asks only "Approve this operation?" binds approval to an abstraction rather than the final object.

Effective confirmation displays the target, action type, amount or control parameters, Intent identifier, risk class, validity interval, and digest of the final object. Its purpose is not to add another button. It creates a display path independent of the upper-layer interface so that even a compromised UI cannot conceal what the boundary is preparing to release.

B.4 Firmware Locking and Fixed Baselines

A hardware boundary that ordinary administrators can freely reconfigure is not a stable Final Veto. The reference architecture therefore requires secure boot, signed firmware, rollback protection, locked debug interfaces, readout protection, fixed safety parameters, controlled updates, and device identity and measurement Evidence.

Not every rule must be fixed. Business Policy P should remain updateable. The constitutional baselines in K must not be disabled through ordinary remote administration. Business scope may change. The conditions under which the system can never produce ALLOW should change only through the distinct constitutional path.

B.5 A Boundary Is Not a Single Chip

A Physical Trust Boundary is not a single secure element; it is the following set of relationships:

• Upper layers cannot directly obtain the key or execution capability.
• The final object is revalidated inside the boundary.
• Runtime output is independently checked.
• Evidence binds to the Candidate Execution.
• Failure defaults to non-ALLOW.
• Device identity and firmware state can be proven.
• Execution produces device-originated Evidence.

---

Appendix C: Axiom Index, Definition Index, and Failure Matrix

C.1 Axiom Index

Table C-1: Axiom Quick Reference

Frequently used derived propositions:

• Signing is not Final Veto.
• Key protection is not execution protection.
• Count is not independence.
• Local correctness is not end-to-end correctness.

C.2 Definition Index

Table C-2: Definition Index

C.3 Failure Matrix

Table C-3: Evidence-state Failure Matrix

FALSE differs from the other non-ALLOW states. It means the system completed a proof and the result was negative. The others mean the system could not complete the proof. The first is repaired by changing the request; the others by repairing the Evidence.

A signature mismatch or invalid source credential may be grouped with UNKNOWN for ALLOW semantics, because neither can participate in π. For monitoring, implementations should preserve a separate verification_failed marker because it is often an attack indicator rather than an ordinary channel failure.

---

Conclusion

No complete proof, no ALLOW.