
Adversarial Completeness
Designing Systems That Remain Safe When Trust Fails
Published · 2026
Adversarial Completeness asks what must still hold when the subjects, components, and control planes that a system depends on can themselves fail, become compromised, or cease to be trustworthy. It examines why one compromise can neutralize several controls at once, why the constraints consulted for an Action may not be the ones that Action required, how the same protected result can be reached by another path, why a boundary-defining rule can itself become an object of change, and why intact records can outlive the fact they were meant to establish. It does not claim to guarantee that every attack will be blocked, and it holds its own conclusions inside a declared Threat Model, Trust Root, and Constraint-Layer Set.
Lin Wang, Mengting Wu, Yong Zhang, Jiang Deng · 2026
Summary
Adversarial Completeness is the third volume of the Execution Engineering Trilogy and begins where Execution Control Engineering stopped. If execution cannot safely depend on Intent, Authorization, Approval, and Policy alone, a system needs an Execution Boundary that can still constrain reality before an Action takes effect. The harder question is what happens when the subjects, components, and control planes responsible for judgment, constraint, and execution can themselves fail or become compromised. The book's answer is not to build a system that trusts nothing. It asks instead what must still hold once something the system originally depended on can no longer be depended upon, and it names that question Adversarial Completeness. Adversarial does not require an identified attacker: compromise is first of all a condition, and reliability can be lost through error, state change, shared dependency, recovery behaviour, or other failure as much as through malice. From there the book separates a set of specific structural relations rather than assembling a security checklist. It examines why several nominal controls can rest on one control root or one update path and fail together; why the constraint set actually consulted for a given Action can differ from the set that Action requires while every required constraint still exists; how a protected result can be reached through another path; why the rule that defines a Boundary can itself become an object of change at event time; how individually insufficient capabilities can become sufficient in combination; why a judgment valid upstream may fail to remain valid downstream; and why records can remain complete and unaltered while the evidence–fact relation needed by the current decision no longer holds. Real-world failure cases serve as stress tests throughout, under an explicit rule that a case is not a proof and that absent support is not disproof. The book applies that rule to itself: it tracks eight candidate structures, retains five within stated boundaries, leaves two explicitly unfrozen, and downgrades one for insufficient real-world support, then states which conclusions therefore cannot currently be claimed. It separates a failure to complete the task from a failure of the security boundary, holds that stopping does not automatically mean failure while contraction does not automatically mean safety, and closes by declaring the outer boundaries of its own scope—Threat Model, Trust Root, Full Collusion, Goal Correctness, and Real-World Irreversibility—which it declares but does not solve, stating plainly that it does not guarantee every attack will be blocked, nor safety when all legitimate constraining layers are in full collusion.
About This Book
Book III of the Execution Engineering Trilogy examines what must still hold when the components that enforce execution control can themselves be compromised. It develops its structures from engineering practice and verified real-world failures, distinguishes compromise from attributed attack, refuses to present its findings as a security checklist, and closes by declaring the boundaries of its own claims rather than extending them.
Key Topics
- Adversarial Completeness as the condition that remains after Compromise
- Shared failure sources, control roots, and update paths across nominal layers
- Required-constraint path bypass and alternative paths to the same protected result
- Rule and implementation rewriting, capability composition, and downstream requalification
- Evidence–fact relation failure, evidence status, and the declared outer boundaries