Individual Submission S. Das Internet-Draft Independent Intended status: Informational 16 September 2026 Expires: 20 March 2027 Command Accepted Is Not Actuation Authorized: Execution Finality for Cyber-Physical and Industrial Control Systems draft-das-actuation-bound-execution-finality-00 Abstract Cyber-physical and industrial systems increasingly accept commands from cloud services, AI agents, remote operators, enterprise applications, and distributed control software. A high-consequence failure can occur even when identity, authorization, message integrity, platform attestation, and functional-safety mechanisms are individually correct: a digitally valid command can remain apparently acceptable while the target actuator, command parameters, machine mode, process state, safety/interlock state, authority state, or effectuation path has changed. The consequence is no longer merely an incorrect API call. It can be drive energization, robotic motion, valve or pump actuation, material release, process transition, or another physical effect. No token forgery, cryptographic break, or defeat of the safety protocol is necessarily required; the failure can be a loss of continuity between earlier digital authority and the exact physical act that becomes effective. Existing industrial mechanisms already solve major parts of this problem. IEC 61508 and IEC 61511 define mature functional-safety engineering and Safety Instrumented Systems; IEC 62443 defines cybersecurity requirements for industrial automation and control components; OPC UA provides industrial security mechanisms, while OPC UA Safety defines a functional-safety communication layer; ACE-OAuth [RFC9200] provides authorization for constrained IoT environments; RATS [RFC9334] provides trusted platform Evidence and Attestation Results; and existing safety PLCs/controllers from Siemens, Rockwell Automation, Schneider Electric, ABB, and other vendors provide mature safety logic and output control. These are complementary precedents, not examples of missing safety engineering. Where an existing safety controller or protected actuator boundary already makes exact command authority, current safety/process state, and final output mediation non-bypassable, that deployment already satisfies the core property described here. The residual gap exists only where one of those mechanisms stops at a boundary upstream of the first physical effect or does not carry the complete cyber-authority predicate required by the deployment. IEC Das Expires 20 March 2027 [Page 1] Internet-Draft Actuation-Bound Finality September 2026 functional-safety mechanisms can correctly enforce safety functions without necessarily expressing the provenance and exact scope of an AI-, cloud-, or enterprise-originated command. IEC 62443 controls can correctly protect identity, use, integrity, and information flow without by themselves defining the final application's exact actuation predicate. OPC UA Safety can correctly deliver SafetyData while the receiving safety application still determines whether a cyber-originated act is applicable. ACE can correctly authorize a constrained resource while current machine/process/safety state may be evaluated later. RATS can correctly attest the controller while platform trust is not authorization for a particular torque, motion, valve transition, or output. Current application-layer action- evidence work [SOKOLOV-AEP] can strengthen accountability while remaining distinct from pre-actuation non-completability. If any existing deployment already composes these properties at the true output boundary, no residual gap remains for that deployment. This document therefore proposes a narrower actuation-bound execution-finality invariant. A Candidate Act remains in a Non- Effective State until a protected Actuation Finality Boundary (AFB) verifies the exact pending command, current execution authority, target actuator identity, freshness and replay state, required current machine/process/safety predicates, and authorized effectuation path immediately before or atomically with the physical output becoming effective. The AFB is an architectural role, not a mandatory new appliance: an existing safety PLC, safety controller, protected drive, robot controller, SIS function, secure I/O stage, or device controller can already be the AFB when it enforces the required invariant. Prevention is claimed only where the protected physical effect cannot occur without those checks and where existing functional-safety controls remain authoritative rather than being bypassed or replaced. Execution-finality logic MUST NOT convert an existing safety DENY into ALLOW. If enforcement is upstream-only, mutable context is stale, path coverage is incomplete, or the mechanism merely records what occurred, the result is mitigation, detection, or auditability rather than the same prevention guarantee. The architecture complements functional safety; it does not replace hazard analysis, define a safe state, certify an unsafe controller, or claim that an IETF mechanism establishes SIL or PL. The problem is industrially relevant to robotics and motion control, process plants, manufacturing and warehouse automation, power and critical infrastructure, and other systems where remote or AI- generated commands can cross several cyber layers before becoming physical. Siemens Safety Integrated, Rockwell GuardLogix, Schneider Electric Modicon M580 Safety, ABB AC500-S, and OPC UA Safety are Das Expires 20 March 2027 [Page 2] Internet-Draft Actuation-Bound Finality September 2026 cited politely as mature safety precedents and potential integration points. No vulnerability, deficiency, non-conformance, affiliation, or endorsement is asserted. Criticism, corrections, counterexamples, prior art, real-time implementation experience, and evidence that existing safety or authorization mechanisms already provide the full invariant are explicitly invited. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Vulnerability: A Valid Command Can Become an Invalid Physical Act . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Existing Safety and Security Mechanisms Already Address Major Parts . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Why the Residual Gap Can Remain . . . . . . . . . . . . . 9 1.3.1. Functional Safety and Safety Controllers . . . . . . 9 1.3.2. IEC 62443 and Industrial Cybersecurity . . . . . . . 9 Das Expires 20 March 2027 [Page 3] Internet-Draft Actuation-Bound Finality September 2026 1.3.3. OPC UA Safety and Safe Communication . . . . . . . . 10 1.3.4. ACE and Constrained-Device Authorization . . . . . . 10 1.3.5. RATS and Action Evidence . . . . . . . . . . . . . . 10 1.3.6. Alternate Physical Effectuation Paths . . . . . . . . 10 1.4. What This Architecture Introduces . . . . . . . . . . . . 11 2. Conventions and Requirements Language . . . . . . . . . . . . 11 3. Direct Question: What Threat Does This Architecture Solve? . 11 4. Motivating Scenario: Authorized at X17, Actuated at X18 . . . 12 5. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Digital Authorization Is Not Physical Authority . . . . . 13 5.2. Functional Safety Is Not Replaced . . . . . . . . . . . . 13 5.3. Secure Communication Is Not Final Actuation Authority . . 13 5.4. Attestation Is Not Physical-State Truth . . . . . . . . . 13 5.5. Audit Is Not Prevention . . . . . . . . . . . . . . . . . 13 6. Threat Model and Assurance Scope . . . . . . . . . . . . . . 14 6.1. Adversary Capabilities . . . . . . . . . . . . . . . . . 14 6.2. Threat Severity and Applicability . . . . . . . . . . . . 14 6.3. Baseline Actuation-Finality Profile . . . . . . . . . . . 14 6.4. High-Assurance Actuation-Finality Profile . . . . . . . . 14 6.5. Trusted Roots and Limits . . . . . . . . . . . . . . . . 15 7. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 15 8. Existing Mechanisms and the Proposed Delta . . . . . . . . . 15 8.1. IEC 61508 . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. IEC 61511 . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. IEC 62443 . . . . . . . . . . . . . . . . . . . . . . . . 15 8.4. OPC UA Security . . . . . . . . . . . . . . . . . . . . . 16 8.5. OPC UA Safety . . . . . . . . . . . . . . . . . . . . . . 16 8.6. ACE-OAuth . . . . . . . . . . . . . . . . . . . . . . . . 16 8.7. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.8. Application-Layer Action Evidence . . . . . . . . . . . . 16 8.9. Safety PLCs and Safety Controllers . . . . . . . . . . . 17 8.10. Comparison Summary . . . . . . . . . . . . . . . . . . . 17 8.11. What Is New in This Document . . . . . . . . . . . . . . 18 9. Prevention and Mitigation Property . . . . . . . . . . . . . 19 9.1. Prevention Profile . . . . . . . . . . . . . . . . . . . 19 9.2. Mitigation, Detection, or Audit Profile . . . . . . . . . 19 9.3. Unknown Safety or Process State . . . . . . . . . . . . . 20 10. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Actuation Context Model . . . . . . . . . . . . . . . . . . . 20 11.1. Typed Actuation-State Vector . . . . . . . . . . . . . . 21 11.2. State Semantics . . . . . . . . . . . . . . . . . . . . 22 11.3. Sensor and State-Source Trust . . . . . . . . . . . . . 23 11.4. Cross-State Consistency . . . . . . . . . . . . . . . . 23 11.5. Effect-Type Semantics . . . . . . . . . . . . . . . . . 23 12. Formal Mathematical Model . . . . . . . . . . . . . . . . . . 24 12.1. Safety-Dominance Rule . . . . . . . . . . . . . . . . . 25 12.2. Bounded Prevention Argument . . . . . . . . . . . . . . 25 12.3. Canonical Physical Candidate Act . . . . . . . . . . . . 25 Das Expires 20 March 2027 [Page 4] Internet-Draft Actuation-Bound Finality September 2026 12.4. Trusted State-Evidence Predicate . . . . . . . . . . . . 26 12.5. Current Cyber-Authority Predicate . . . . . . . . . . . 26 12.6. Existing Safety Predicate . . . . . . . . . . . . . . . 26 12.7. Actuator and Output Identity . . . . . . . . . . . . . . 27 12.8. Effect-Lifecycle Authority . . . . . . . . . . . . . . . 27 12.9. Actuation Generation Vector . . . . . . . . . . . . . . 28 12.10. State-Transition Applicability . . . . . . . . . . . . . 28 12.11. Check-to-Output Serialization . . . . . . . . . . . . . 28 12.12. Replay and Sequence Formalism . . . . . . . . . . . . . 29 12.13. Actuation-Path Completeness . . . . . . . . . . . . . . 29 12.14. Expanded Actuation Validity . . . . . . . . . . . . . . 29 12.15. Expanded Strict Prevention Invariant . . . . . . . . . . 30 12.16. Continuing and Latched Effects . . . . . . . . . . . . . 30 12.17. Expanded Bounded Prevention Proof . . . . . . . . . . . 31 13. State, Safety, and Authority Continuity . . . . . . . . . . . 31 14. Exact Command and Actuator Binding . . . . . . . . . . . . . 33 15. Freshness, Replay, and Sequence Control . . . . . . . . . . . 35 16. Actuation Finality Boundary . . . . . . . . . . . . . . . . . 35 17. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 37 18. Solution Architecture . . . . . . . . . . . . . . . . . . . . 38 18.1. Prepare Candidate Act . . . . . . . . . . . . . . . . . 39 18.2. Remain Non-Effective . . . . . . . . . . . . . . . . . . 39 18.3. Observe Current Actuation Context . . . . . . . . . . . 39 18.4. Verify Exact Act and Current Applicability . . . . . . . 39 18.5. Protected Output Commit . . . . . . . . . . . . . . . . 39 18.6. Architecture Diagram . . . . . . . . . . . . . . . . . . 39 19. Illustrative Pseudocode . . . . . . . . . . . . . . . . . . . 40 19.1. Canonicalize the Physical Candidate Act . . . . . . . . 40 19.2. Bind Cyber Authority to the Exact Act . . . . . . . . . 41 19.3. Acquire Current Actuation State . . . . . . . . . . . . 41 19.4. Verify Trusted State Sources . . . . . . . . . . . . . . 42 19.5. Verify Actuator and Output Identity . . . . . . . . . . 43 19.6. Compose with Existing Safety Functions . . . . . . . . . 44 19.7. Evaluate Effect-Lifecycle Authority . . . . . . . . . . 44 19.8. Verify Replay and Sequence State . . . . . . . . . . . . 45 19.9. Verify the Complete Actuation Predicate . . . . . . . . 45 19.10. Handle Safety, Process, Authority, or Topology Change . 46 19.11. Validate Whether a State Transition Is Irrelevant . . . 47 19.12. Verify Consequence-Wide Actuation-Path Coverage . . . . 47 19.13. Protected Real-Time Finalization . . . . . . . . . . . . 48 19.14. Supervise Continuing or Latched Effects . . . . . . . . 49 19.15. Emergency-Stop Precedence . . . . . . . . . . . . . . . 50 19.16. Separate Cold-Path and Hot-Path Work . . . . . . . . . . 50 19.17. Crash-Safe Physical-Effect Recovery . . . . . . . . . . 51 19.18. Generate a Reviewable Actuation Failure Explanation . . 52 20. Composition with Existing Safety Controllers . . . . . . . . 52 21. RATS-Based High-Assurance Actuation . . . . . . . . . . . . . 54 22. Alternate-Path Resistance . . . . . . . . . . . . . . . . . . 55 Das Expires 20 March 2027 [Page 5] Internet-Draft Actuation-Bound Finality September 2026 23. Attack Analysis . . . . . . . . . . . . . . . . . . . . . . . 55 23.1. Command-Parameter Substitution . . . . . . . . . . . . . 55 23.2. Target-Actuator Substitution . . . . . . . . . . . . . . 56 23.3. Replay and Duplicate Actuation . . . . . . . . . . . . . 56 23.4. Safety or Process-State Race . . . . . . . . . . . . . . 56 23.5. Machine-Mode Confusion . . . . . . . . . . . . . . . . . 56 23.6. Maintenance or Engineering Bypass . . . . . . . . . . . 56 23.7. Compromised Non-Safety Controller . . . . . . . . . . . 56 23.8. Action Evidence Without Prevention . . . . . . . . . . . 56 24. High-Assurance Enforcement . . . . . . . . . . . . . . . . . 56 25. Deployment Patterns . . . . . . . . . . . . . . . . . . . . . 57 25.1. Safety PLC as AFB . . . . . . . . . . . . . . . . . . . 58 25.2. Protected Drive or Robot Controller as AFB . . . . . . . 58 25.3. SIS / Process Controller as AFB . . . . . . . . . . . . 58 25.4. Constrained Device / ACE Resource Server as AFB . . . . 58 25.5. Distributed AFB . . . . . . . . . . . . . . . . . . . . 58 26. Real-Time Performance and Availability . . . . . . . . . . . 58 27. Relationship to ACE . . . . . . . . . . . . . . . . . . . . . 59 28. Relationship to CoRE . . . . . . . . . . . . . . . . . . . . 59 29. Relationship to RATS . . . . . . . . . . . . . . . . . . . . 60 30. Relationship to OPC UA and Industrial Safety Standards . . . 60 31. Industrial Relevance . . . . . . . . . . . . . . . . . . . . 60 31.1. Robotics and Machine Motion . . . . . . . . . . . . . . 60 31.2. Process Control . . . . . . . . . . . . . . . . . . . . 60 31.3. Manufacturing and Warehouse Automation . . . . . . . . . 61 31.4. Critical Infrastructure . . . . . . . . . . . . . . . . 61 32. Complementary Industrial Alignment . . . . . . . . . . . . . 61 32.1. Siemens Safety Integrated . . . . . . . . . . . . . . . 61 32.2. Rockwell Automation GuardLogix . . . . . . . . . . . . . 61 32.3. Schneider Electric Modicon M580 Safety . . . . . . . . . 61 32.4. ABB AC500-S . . . . . . . . . . . . . . . . . . . . . . 61 32.5. OPC Foundation . . . . . . . . . . . . . . . . . . . . . 62 32.6. Non-Endorsement and Non-Criticism . . . . . . . . . . . 62 33. Required Classes of Test Vectors . . . . . . . . . . . . . . 62 34. Questions to the IETF Community . . . . . . . . . . . . . . . 63 35. Potential IETF Discussion Venues and External Standards Boundaries . . . . . . . . . . . . . . . . . . . . . . . 65 35.1. ACE . . . . . . . . . . . . . . . . . . . . . . . . . . 65 35.2. CoRE . . . . . . . . . . . . . . . . . . . . . . . . . . 65 35.3. RATS . . . . . . . . . . . . . . . . . . . . . . . . . . 66 35.4. DISPATCH . . . . . . . . . . . . . . . . . . . . . . . . 66 35.5. SAAG . . . . . . . . . . . . . . . . . . . . . . . . . . 66 35.6. IEC, OPC Foundation, and Industrial Safety Communities . . . . . . . . . . . . . . . . . . . . . . 66 35.7. No Presumed Home . . . . . . . . . . . . . . . . . . . . 66 36. Relationship to Other Execution-Finality Internet-Drafts . . 66 37. Public Implementations and Companion Engineering Material . . 68 38. Security Considerations . . . . . . . . . . . . . . . . . . . 68 Das Expires 20 March 2027 [Page 6] Internet-Draft Actuation-Bound Finality September 2026 38.1. Command Parameter Substitution . . . . . . . . . . . . . 68 38.2. Target-Actuator Substitution . . . . . . . . . . . . . . 68 38.3. Command Replay . . . . . . . . . . . . . . . . . . . . . 68 38.4. Duplicate Actuation . . . . . . . . . . . . . . . . . . 68 38.5. Stale Authority . . . . . . . . . . . . . . . . . . . . 68 38.6. Stale Safety State . . . . . . . . . . . . . . . . . . . 69 38.7. Stale Process State . . . . . . . . . . . . . . . . . . 69 38.8. Interlock Race . . . . . . . . . . . . . . . . . . . . . 69 38.9. Machine-Mode Confusion . . . . . . . . . . . . . . . . . 69 38.10. Maintenance-Mode Abuse . . . . . . . . . . . . . . . . . 69 38.11. Local or Manual Override . . . . . . . . . . . . . . . . 69 38.12. Engineering Workstation Bypass . . . . . . . . . . . . . 69 38.13. Direct Fieldbus Write . . . . . . . . . . . . . . . . . 69 38.14. Direct I/O Path . . . . . . . . . . . . . . . . . . . . 69 38.15. Recovery and Disaster-Recovery Control Paths . . . . . . 70 38.16. Firmware-Level Actuation . . . . . . . . . . . . . . . . 70 38.17. Compromised Non-Safety PLC . . . . . . . . . . . . . . . 70 38.18. Compromised Gateway . . . . . . . . . . . . . . . . . . 70 38.19. Compromised Host OS . . . . . . . . . . . . . . . . . . 70 38.20. Safety-Controller Compromise . . . . . . . . . . . . . . 70 38.21. Sensor Spoofing . . . . . . . . . . . . . . . . . . . . 70 38.22. Sensor Authenticity Is Not Physical Truth . . . . . . . 70 38.23. Actuator Feedback Spoofing . . . . . . . . . . . . . . . 70 38.24. Sequence and Reordering Attacks . . . . . . . . . . . . 71 38.25. TOCTOU Between Check and Output . . . . . . . . . . . . 71 38.26. Crash Consistency . . . . . . . . . . . . . . . . . . . 71 38.27. Fail-Open Behavior . . . . . . . . . . . . . . . . . . . 71 38.28. Loss of Safety-State Source . . . . . . . . . . . . . . 71 38.29. Denial of Service . . . . . . . . . . . . . . . . . . . 71 38.30. Emergency Stop Precedence . . . . . . . . . . . . . . . 71 38.31. Fail-Safe Output State . . . . . . . . . . . . . . . . . 71 38.32. Output Latching . . . . . . . . . . . . . . . . . . . . 71 38.33. Authority Consumption State . . . . . . . . . . . . . . 72 38.34. Actuation Path Completeness . . . . . . . . . . . . . . 72 38.35. RATS Attestation Overclaim . . . . . . . . . . . . . . . 72 38.36. Action Evidence Confused with Prevention . . . . . . . . 72 38.37. Audit Is Not Prevention . . . . . . . . . . . . . . . . 72 38.38. Real-Time Latency and Jitter . . . . . . . . . . . . . . 72 38.39. Functional-Safety Certification Boundary . . . . . . . . 72 38.40. Physical Tampering . . . . . . . . . . . . . . . . . . . 72 39. Privacy Considerations . . . . . . . . . . . . . . . . . . . 73 40. Criticism, Corrections, and Review Invited . . . . . . . . . 73 41. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 42. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 73 43. Normative References . . . . . . . . . . . . . . . . . . . . 74 44. Informative References . . . . . . . . . . . . . . . . . . . 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 78 Das Expires 20 March 2027 [Page 7] Internet-Draft Actuation-Bound Finality September 2026 1. Introduction 1.1. Vulnerability: A Valid Command Can Become an Invalid Physical Act In cyber-physical systems, command validity and actuation validity are not always the same temporal property. A command can be authenticated and authorized while the machine is in one operating state, then execute later after the process, actuator, safety interlock, mode, authority, or route has changed. t0 t1 t2 | | | | C authorized | machine/process | physical | under state X17 | state becomes X18 | output requested |------------------------|-------------------------| | v EFFECT under X18 Valid(C, X17) does not automatically imply Valid(C, X18). Figure 1: A valid digital command can become invalid physical authority Relevant state can include robot or machine mode, guard state, process pressure or temperature, tool identity, actuator mapping, human-presence state, motion envelope, authority or revocation state, interlock state, line configuration, or maintenance mode. A digitally authentic command is therefore not automatically current physical authority. 1.2. Existing Safety and Security Mechanisms Already Address Major Parts IEC 61508 provides foundational functional-safety requirements for electrical/electronic/programmable electronic safety-related systems [IEC61508]. IEC 61511 applies functional-safety principles to Safety Instrumented Systems in the process industry and defines requirements so that a SIS can achieve or maintain a safe process state [IEC61511]. IEC 62443-4-2 specifies technical security requirements for IACS components around foundational requirements including identification/authentication, use control, system integrity, restricted data flow, timely response, and availability [IEC62443]. OPC UA Safety is a functional-safety communication layer for exchange of SafetyData using OPC UA mechanisms and is intended for implementation in safety devices [OPCUA-SAFETY]. ACE-OAuth provides authorization for constrained environments [RFC9200]. RATS supplies Das Expires 20 March 2027 [Page 8] Internet-Draft Actuation-Bound Finality September 2026 Evidence and Attestation Results about trusted platform state [RFC9334]. Current individual work also composes signed application- layer action records with RATS platform evidence [SOKOLOV-AEP]. Industrial safety controllers already provide the strongest practical overlap. Safety PLCs and controllers from Siemens, Rockwell Automation, Schneider Electric, ABB, and others implement certified safety logic, safety I/O, diagnostics, and protected output behavior. This document does not claim that industrial systems lack final safety enforcement. 1.3. Why the Residual Gap Can Remain The residual gap is not that industrial safety, authorization, or attestation mechanisms are missing. It exists only when the complete cyber-authority-to-physical-effect predicate is not enforced at the first physical consequence boundary. The following distinctions define that gap mechanism by mechanism. 1.3.1. Functional Safety and Safety Controllers IEC 61508/61511, safety PLCs, SIS functions, safety I/O, and certified controller logic can already provide authoritative safety decisions and safe-state behavior. This document does not claim otherwise. A residual cyber-authority question exists only where the safety function does not already bind the exact upstream cyber- originated command, its current authority, and its target identity to the protected output. If the safety controller already does so, the property is already satisfied. 1.3.2. IEC 62443 and Industrial Cybersecurity IEC 62443 can correctly address industrial identification/ authentication, use control, system integrity, restricted data flow, timely response, and availability. Those controls materially reduce the attack surface. The narrower question is whether a deployment also makes the exact pending physical act — including its current parameters, actuator, authority state, and required machine/process state — the load-bearing object of the final output decision. That application predicate is not inferred merely from the existence of strong component cybersecurity controls. Das Expires 20 March 2027 [Page 9] Internet-Draft Actuation-Bound Finality September 2026 1.3.3. OPC UA Safety and Safe Communication OPC UA Safety already defines a safety communication layer for SafetyData and is intended for safety devices [OPCUA-SAFETY]. The draft therefore does not claim that safety-relevant communication is unprotected. The residual question arises only where the receiving safety application or output controller must also establish the exact cyber-originated act and current cyber authority before permitting the physical effect. If the receiving safety device already performs that composition, no gap remains. 1.3.4. ACE and Constrained-Device Authorization ACE-OAuth [RFC9200] can correctly authorize a client to a constrained resource. If that Resource Server is itself the non-bypassable actuator boundary and checks every required current process/safety predicate, it may already satisfy this document's invariant. The residual gap exists only when ACE authorization terminates upstream while another controller, worker, fieldbus path, or device later determines the physical effect. 1.3.5. RATS and Action Evidence RATS [RFC9334] can correctly establish trusted platform or controller state. That state is a valuable input to actuation authority, but it is not automatically authorization for a particular motor torque, valve transition, robotic motion, or other exact physical effect. Current action-evidence work [SOKOLOV-AEP] can bind signed application-layer action records to platform evidence and strengthen provenance. Its scope remains distinct from the pre-effectuation property here: a physical effect must stay technically unavailable until the required actuation predicates hold. 1.3.6. Alternate Physical Effectuation Paths Even perfect cyber authorization at one path is not consequence-wide prevention if a maintenance port, engineering workstation, local/ manual mode, direct fieldbus write, direct I/O, recovery path, drive- local interface, or firmware path can cause the same physical effect without equivalent enforcement. Actuation finality therefore composes with consequence-path completeness. Das Expires 20 March 2027 [Page 10] Internet-Draft Actuation-Bound Finality September 2026 1.4. What This Architecture Introduces The proposed contribution is an authorization-to-physical-effect continuity invariant. A cyber-originated Candidate Act remains in a Non-Effective State until the protected Actuation Finality Boundary verifies the exact pending command, target actuator, current authority, required current machine/process/safety conditions, freshness/replay state, and authorized path immediately before or atomically with the physical output commitment. * Bind authority to the exact command and security-relevant parameters. * Bind the command to the intended physical actuator or output endpoint. * Re-establish mutable machine, process, authority, and required safety state at actuation time. * Keep the command non-effective after upstream authorization. * Preserve the authority of existing certified safety functions and fail-safe behavior. * Prevent replay, duplicate actuation, stale authorization, and target substitution. * Require every physical effectuation path to cross the AFB or enforce an equivalent invariant. * Couple successful verification to protected output commit. 2. Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 3. Direct Question: What Threat Does This Architecture Solve? If a digital command is valid and authenticated, what prevents it from producing a physical effect after its parameters, target actuator, process state, safety state, execution authority, or actuation path has changed? Das Expires 20 March 2027 [Page 11] Internet-Draft Actuation-Bound Finality September 2026 NOT ActuationApplicable(C, A, X_now) ==> NOT PhysicalEffect(K, C) The target is not to make ordinary control software into a safety system. The target is to preserve cyber authority and exact-act applicability until the existing or newly protected physical output boundary. 4. Motivating Scenario: Authorized at X17, Actuated at X18 Consider a robot command approved while the cell is in automatic mode, the target axis is known, a guard is closed, and the intended operating envelope permits the motion. The command is queued. Before the drive receives the final output request, a human enters the cell or the mode changes. The earlier command can remain authentic while current actuation applicability has changed. Candidate C: move axis-X, 10 mm, speed=5 | | authorized under X17 v NON-EFFECTIVE | state changes v X18: guard open / mode changed / person present | v +----------------------+ | ACTUATION FINALITY | | BOUNDARY | | evaluate CURRENT X18 | +----------+-----------+ | fail / pass / \ REJECT OUTPUT Figure 2: Actuation after a safety or process-state change 5. Problem Space Das Expires 20 March 2027 [Page 12] Internet-Draft Actuation-Bound Finality September 2026 5.1. Digital Authorization Is Not Physical Authority Authentication and authorization can establish who may request an operation. Physical authority additionally depends on whether the exact operation is still applicable to the current actuator and current operating state. 5.2. Functional Safety Is Not Replaced Functional-safety engineering covers hazard analysis, safety functions, safe states, safety integrity, diagnostic design, lifecycle, validation, and certification. This document does not replace those disciplines and does not claim that an uncertified controller becomes safe by implementing execution finality. Existing safety result: SAFE_TO_ACTUATE = FALSE Execution-finality result: MUST remain NON-EFFECTIVE Execution finality MUST NOT transform a safety DENY into ALLOW. 5.3. Secure Communication Is Not Final Actuation Authority An authenticated, integrity-protected, or functionally safe communication channel can deliver a command faithfully. The receiving actuator boundary still needs to apply any deployment- specific current authority and current actuation predicates that are not already enforced by the safety application. 5.4. Attestation Is Not Physical-State Truth RATS can establish technical claims about an Attester. It does not make an unmeasured physical sensor reading true. A profile must state which physical/process facts come from trusted sensing and which facts are merely software/platform claims. 5.5. Audit Is Not Prevention A signed action record generated after motion can provide useful accountability. It does not establish that the physical effect was technically conditional on a pre-actuation check. Das Expires 20 March 2027 [Page 13] Internet-Draft Actuation-Bound Finality September 2026 6. Threat Model and Assurance Scope 6.1. Adversary Capabilities The adversary MAY control or influence the AI agent, HMI/client, application process, enterprise gateway, ordinary operating system, ordinary network path, non-safety PLC task, orchestration software, queue/broker, maintenance software, command cache, command sequencing, or other non-safety controller elements included in the deployment threat model. The adversary MAY attempt parameter substitution, target-actuator substitution, replay, duplicate actuation, stale approval reuse, mode confusion, command reordering, alternate- path actuation, maintenance-interface abuse, direct device commands, or a race against safety/process/revocation state. 6.2. Threat Severity and Applicability Severity is consequence-dependent. The issue deserves high attention for robotics, autonomous machinery, manufacturing cells, industrial motion, valves and pumps, process control, chemical plants, power systems, transport control, warehouse automation, critical infrastructure, and other systems in which a digitally initiated action can produce material physical consequences. Not every actuator command is safety-critical. Profiles SHOULD identify which physical consequences justify the stronger prevention property and real-time enforcement cost. 6.3. Baseline Actuation-Finality Profile The requester, remote agent, application, network, and ordinary command path are untrusted. Existing required safety functions, the AFB, the authoritative actuation- policy source, and protected current-state sources used by the profile are trusted. 6.4. High-Assurance Actuation-Finality Profile A higher-assurance profile MAY additionally distrust the host OS, ordinary PLC task, orchestrator, gateway, maintenance workstation, and software-only fieldbus mediator. In that case the AFB can reside in a certified safety controller, protected drive/device controller, separate safety island, secure I/O, hardware controller, TEE/security processor where appropriate, or another independently enforceable boundary. Das Expires 20 March 2027 [Page 14] Internet-Draft Actuation-Bound Finality September 2026 6.5. Trusted Roots and Limits The base model does not claim to survive compromise of every safety/ finality root, mechanical failure outside modeled protections, sensor falsification outside the trusted sensing model, physical wiring bypass outside scope, incorrect hazard analysis, unsafe engineering design, or an effect outside the declared actuation domain. 7. Design Goals and Non-Goals The design goal is to preserve exact cyber authority and current applicability until the first protected physical effect, while composing with — and never weakening — existing safety functions. This document does not define a safety lifecycle, SIL/PL calculation, hazard analysis method, safety protocol, safety PLC certification process, new OPC UA Safety transport, new ACE profile, new RATS evidence format, or universal real-time control protocol. A deployment MAY use an existing safety controller as the AFB. In many industrial systems that is likely to be the preferred design rather than adding a separate component. 8. Existing Mechanisms and the Proposed Delta 8.1. IEC 61508 IEC 61508 is foundational functional-safety engineering for E/E/PE safety-related systems [IEC61508]. Functional safety itself is therefore prior and mature engineering. The proposed delta is not a new safety lifecycle; it is the continuity of a cyber-originated Candidate Act to the protected physical effect. 8.2. IEC 61511 IEC 61511 specifies requirements for Safety Instrumented Systems in the process industry so that they can achieve or maintain a safe process state [IEC61511]. Where the SIS already receives the relevant command, evaluates all required process and safety conditions, and exclusively controls the defined output, it may already serve as the AFB. 8.3. IEC 62443 IEC 62443-4-2 specifies component security requirements around foundational categories including identification/authentication, use control, system integrity, confidentiality, restricted data flow, timely event response, and resource availability [IEC62443]. Das Expires 20 March 2027 [Page 15] Internet-Draft Actuation-Bound Finality September 2026 The residual effectuation question exists only if those controls are not already coupled to exact current physical-output eligibility at the consequence boundary. 8.4. OPC UA Security OPC UA provides industrial authentication, authorization, secure communication, and information-model mechanisms. Secure delivery of a command does not by itself define the application's final actuation policy, although an OPC UA server/controller can implement that policy directly. 8.5. OPC UA Safety OPC UA Safety defines a safety communication layer for exchange of SafetyData using OPC UA mechanisms and is intended for safety devices [OPCUA-SAFETY]. The OPC Foundation explicitly notes that merely implementing OPC UA Safety does not by itself make an arbitrary device suitable for safety-related applications; required safety- development processes and assessment still apply [OPCUA-SAFETY-POLICY]. This draft does not claim that safety communication is missing. It asks only whether an additional cyber-originated exact-act/current- authority condition must be made load-bearing at the receiving safety/output boundary. 8.6. ACE-OAuth RFC 9200 defines the ACE framework for OAuth-based authentication and authorization in constrained environments [RFC9200]. If the ACE Resource Server is the true actuator boundary and it evaluates every required current actuation condition, the core property can already be satisfied. 8.7. RATS RATS provides Evidence and Attestation Results about trusted platform state [RFC9334]. An attested controller can therefore be a higher- assurance input to actuation policy. Platform trust does not by itself authorize a particular physical effect. 8.8. Application-Layer Action Evidence [SOKOLOV-AEP] sketches composition of signed application-layer action records with RATS platform evidence. It explicitly states that the composition does not turn a self-reported action or outcome into independently observed fact. Das Expires 20 March 2027 [Page 16] Internet-Draft Actuation-Bound Finality September 2026 This document does not compete on post-action evidence. It focuses on pre-actuation non-completability: before the physical output occurs, the required exact-act and current- context predicates must be load-bearing. 8.9. Safety PLCs and Safety Controllers Existing certified safety controllers may already be the best AFB. Rockwell GuardLogix, Schneider Modicon M580 Safety, ABB AC500-S, Siemens fail-safe S7/Safety Integrated, and comparable systems demonstrate mature safety logic and protected safety-output architectures [ROCKWELL-GUARDLOGIX] [SCHNEIDER-M580] [ABB-AC500S] [SIEMENS-SAFETY]. No deficiency is asserted. A deployment that binds the cyber- originated exact act and authority into an existing certified safety output decision may already satisfy the proposal without another hardware layer. 8.10. Comparison Summary +============+=======================+============================+ | Mechanism | Strong existing | Residual question only | | | property | where not already covered | +============+=======================+============================+ | IEC 61508 | Functional-safety | Is exact cyber-command | | | lifecycle and safety- | authority preserved to | | | related systems | physical output? | +------------+-----------------------+----------------------------+ | IEC 61511 | Achieve or maintain | Does the SIS already | | / SIS | safe process state | mediate this exact | | | | actuation? If yes, | | | | property may be satisfied. | +------------+-----------------------+----------------------------+ | IEC 62443 | IACS security | Is exact current actuation | | | controls and | eligibility enforced at | | | component | the physical boundary? | | | requirements | | +------------+-----------------------+----------------------------+ | OPC UA | Functional-safety | Does the receiving safety | | Safety | communication | application already | | | | enforce exact cyber | | | | authority/current context? | +------------+-----------------------+----------------------------+ | ACE | Constrained-device | Is the Resource Server the | | | authorization | true non-bypassable | | | | actuator boundary? | +------------+-----------------------+----------------------------+ Das Expires 20 March 2027 [Page 17] Internet-Draft Actuation-Bound Finality September 2026 | RATS | Trusted platform | Is trusted state made | | | evidence | load-bearing for the exact | | | | physical act? | +------------+-----------------------+----------------------------+ | Action | Signed action record | Is effect prevented before | | evidence | plus platform | actuation rather than | | | evidence | merely evidenced | | | | afterward? | +------------+-----------------------+----------------------------+ | Safety | Certified safety | Often may already be the | | PLC/ | logic and safety- | correct AFB. | | controller | output control | | +------------+-----------------------+----------------------------+ Table 1: Existing mechanisms and residual actuation question 8.11. What Is New in This Document The proposed delta is deliberately narrower than functional safety or industrial cybersecurity. This document does not claim invention of safety interlocks, SIS, safety PLCs, fail-safe behavior, safe communication, command authentication, ACE authorization, RATS attestation, or action evidence. It proposes a composition rule over those mechanisms when a cyber-originated command must remain bound to the exact physical consequence. Existing mechanisms may correctly establish: WHO sent the command WHETHER the client may access the resource WHETHER the platform is trusted WHETHER safety communication was valid WHETHER existing safety logic permits output Actuation finality asks the joint effectuation-time question: Is THIS exact command, for THIS actuator, under CURRENT cyber authority, CURRENT required process/machine state, CURRENT required safety predicates, on THIS non-bypassable output path, still eligible to become physical NOW? Das Expires 20 March 2027 [Page 18] Internet-Draft Actuation-Bound Finality September 2026 The Actuation Finality Boundary makes that joint predicate load- bearing immediately before or atomically with the protected output commit. It is a role, not necessarily a new component. An existing certified safety controller can already be the AFB when it enforces the complete required predicate. Where that is already true, this document introduces no additional security layer for that deployment. 9. Prevention and Mitigation Property 9.1. Prevention Profile Prevention of the governed stale/substituted/bypassed-command class can be claimed only when the exact command and actuator are bound, current authority is valid, required existing safety and process predicates are current, freshness/replay rules apply, the AFB controls the first physical effect, alternate actuation paths cannot bypass equivalent checks, and verification-to-output ordering is protected. exact command + target actuator + current cyber authority + current required machine/process state + current required safety predicates + freshness / replay / sequencing + non-bypassable actuation path + protected check-to-output ordering = PREVENTION of the governed command-to-actuation gap 9.2. Mitigation, Detection, or Audit Profile Upstream gateways, network IDS, command logs, stale safety snapshots, advisory actuator labels, post-motion receipts, or software checks that coexist with ungoverned direct I/O can reduce risk or improve accountability but do not establish the same prevention guarantee. Das Expires 20 March 2027 [Page 19] Internet-Draft Actuation-Bound Finality September 2026 9.3. Unknown Safety or Process State A prevention profile SHOULD define explicit UNKNOWN states. Where a required current safety/process predicate cannot be established, the system MUST NOT silently treat UNKNOWN as ALLOW. Existing safety logic can require a safe state or a system-specific fail-safe response. 10. Terminology *Candidate Act:* A proposed cyber-originated command capable of producing a physical consequence but not yet permitted to make that consequence effective. *Protected Physical Consequence:* The first physical, mechanical, electrical, thermal, fluid, motion, process, or other material effect governed by the deployment. *Actuation Finality Boundary (AFB):* The protected functional boundary at which a Candidate Act first acquires the technical ability to cause the protected physical effect. *Actuation Context:* The current set of actuator, machine, process, safety, authority, replay, and path facts required by the deployment. *Actuation Generation:* A protected epoch/version identifying the current load-bearing actuation-policy/context generation. *Non-Effective State:* The state in which the Candidate Act cannot yet produce the protected physical consequence. *Protected Output Commit:* The protected transition that makes the physical output effective, such as enabling a drive command, energizing an output, opening a valve, or issuing another consequence-bearing hardware action. *Existing Safety Predicate:* A required decision produced by or derived from the deployment's functional-safety system. Execution finality cannot weaken it. 11. Actuation Context Model Not every deployment requires every context dimension. A representative context is: Das Expires 20 March 2027 [Page 20] Internet-Draft Actuation-Bound Finality September 2026 X_now = ( actuator_identity, controller_identity, machine_mode, process_state, safety_state, interlock_state, operating_envelope, tool_or_payload_state, human_presence_state_if_required, authority_state, revocation_state, path_identity, generation ) Safety/process fields must come from sources whose trust and freshness are adequate for the intended profile. A software field called "guard_closed" is not automatically equivalent to a trusted safety input. 11.1. Typed Actuation-State Vector Actuation context is modeled as a typed state vector rather than a single "safe/unsafe" flag. A deployment selects only the dimensions that are load-bearing for the Candidate Act. Das Expires 20 March 2027 [Page 21] Internet-Draft Actuation-Bound Finality September 2026 X_now(C,t) = { actuator_identity, controller_identity, machine_mode, process_state, safety_state, interlock_state, operating_envelope, tool_or_payload_state, human_presence_state_if_required, energy_state, authority_state, revocation_state, sequence_state, path_identity, safety_generation, process_generation, authority_generation, topology_generation } Each dimension d has: Value_d Source_d Freshness_d Assurance_d Generation_d Scope_d 11.2. State Semantics State_d ∈ { KNOWN_ALLOWED, KNOWN_DENIED, UNKNOWN, STALE, CONFLICTING, UNAVAILABLE } Strict profile: UNKNOWN OR STALE OR CONFLICTING OR UNAVAILABLE MUST NOT silently become ALLOW. Das Expires 20 March 2027 [Page 22] Internet-Draft Actuation-Bound Finality September 2026 11.3. Sensor and State-Source Trust A state value is useful only to the extent that the deployment trusts the source that produced it. Authentic provenance does not prove physical correctness, and a safety-rated input need not have the same semantics as an ordinary software variable. StateEvidenceValid(E_d, d, C, t) := IntegrityValid(E_d) AND SourceTrustedForDimension(E_d.source, d) AND ScopeApplies(E_d, C) AND FreshnessValid(E_d,t) AND GenerationCurrent(E_d) AND AssuranceSufficient(E_d,d) AND NotSuperseded(E_d) 11.4. Cross-State Consistency ContextConsistent(C, X_now, E_set) := SameActuatorContext(E_set,C) AND SameControllerContext(E_set,C) AND SameMachineInstance(E_set,C) AND CompatibleStateGenerations(E_set) AND NoContradictorySafetyClaims(E_set) AND NoContradictoryProcessClaims(E_set) AND NoCrossTenantOrCrossCellMixing(E_set) This prevents combining a valid safety-state assertion for one robot cell with a valid process-state assertion for another cell and accidentally treating the bundle as current authority for C. 11.5. Effect-Type Semantics Not every physical effect is a one-shot transition. The policy can distinguish authority to initiate, continue, stop, or release a physical effect. Das Expires 20 March 2027 [Page 23] Internet-Draft Actuation-Bound Finality September 2026 EffectAuthority(C) may include: INITIATE CONTINUE MODIFY STOP RELEASE RESET UNLATCH Examples: open valve = INITIATE keep motor enabled = CONTINUE change torque = MODIFY emergency stop = STOP release brake = RELEASE reset trip = RESET 12. Formal Mathematical Model Let C be the concrete Candidate Act, K the Protected Physical Consequence, A the target actuator or actuation endpoint, S the AFB, X_now the current actuation context, P the applicable actuation policy, and g the current actuation generation. ActuationContextValid(C, A, X_now, P, g) := ExactActBinding(C) AND TargetActuatorMatches(C, A) AND AuthorityApplicable(C, X_now.authority_state) AND RevocationAllows(C, X_now.revocation_state) AND MachineModeAllows(C, X_now.machine_mode) AND ProcessStateAllows(C, X_now.process_state) AND RequiredSafetyPredicatesTrue( C, X_now.safety_state, X_now.interlock_state) AND OperatingEnvelopeAllows(C, X_now.operating_envelope) AND FreshnessAndReplayValid(C) AND PathAuthorized(C, X_now.path_identity) AND GenerationCurrent(g, X_now.generation) The actuation-finality safety invariant is: PhysicalEffect(K, C) ==> ActuationContextValid(C, A, X_now, P, g) AND ProtectedCommitAtAFB(C, A) For the strict prevention profile: Das Expires 20 March 2027 [Page 24] Internet-Draft Actuation-Bound Finality September 2026 NOT ActuationContextValid(C, A, X_now, P, g) ==> NOT PhysicalEffect(K, C) 12.1. Safety-Dominance Rule Where an existing safety function participates in actuation, its negative decision is authoritative: SafetyDecision(C, X_now) = DENY ==> NOT PhysicalEffect(K, C) regardless of: cyber authorization, AI recommendation, operator request, token validity, or execution-finality approval. 12.2. Bounded Prevention Argument Assume: (1) the AFB exclusively controls every modeled path capable of producing K or an equivalent invariant exists on each such path; (2) the exact pending command and actuator identity are observable at the AFB; (3) every required current safety/process/authority predicate is available from an adequately trusted source; (4) safety DENY remains authoritative; and (5) verification-to-output ordering is atomic or equivalently protected. Under those assumptions, an attacker cannot produce K using a stale, substituted, replayed, wrong-target, or context-inapplicable Candidate Act without violating at least one explicit assumption. The argument does not prove that the hazard analysis, sensor model, safety application, mechanical system, or certified controller design is correct. 12.3. Canonical Physical Candidate Act Das Expires 20 March 2027 [Page 25] Internet-Draft Actuation-Bound Finality September 2026 C := CanonicalAct( actuator_id, operation, parameters, effect_type, destination_or_axis_if_required, purpose_if_required, sequence, nonce, authority_generation, constraints) D_C = H(Encode(C)) Canonicalization MUST cover every field whose change can alter the physical consequence or the authorization/safety meaning of the act. 12.4. Trusted State-Evidence Predicate TrustedState(C, X_now, E_set, t) := ContextConsistent(C,X_now,E_set) AND FOR EACH required state dimension d: EXISTS e_d ∈ E_set: StateEvidenceValid(e_d,d,C,t) AND State_d(X_now) ∉ { UNKNOWN, STALE, CONFLICTING, UNAVAILABLE } 12.5. Current Cyber-Authority Predicate CyberAuthorityValid(C,X_now) := AuthorityPresent(C) AND ExactActBindingValid(C) AND AuthorityGenerationCurrent(C) AND RevocationAllows(C,X_now.revocation_state) AND UseConstraintsSatisfied(C,X_now) AND FreshnessAndReplayValid(C) AND SequenceValid(C,X_now.sequence_state) 12.6. Existing Safety Predicate Das Expires 20 March 2027 [Page 26] Internet-Draft Actuation-Bound Finality September 2026 SafetyAllows(C,X_now) := RequiredSafetyFunctionsAvailable(C) AND RequiredInterlocksSatisfied(C,X_now.interlock_state) AND SafetyStateAllows(C,X_now.safety_state) AND MachineModeAllows(C,X_now.machine_mode) AND ProcessStateAllows(C,X_now.process_state) AND OperatingEnvelopeAllows(C,X_now.operating_envelope) This predicate is subordinate to the existing safety application. Execution finality does not redefine what a safety function considers safe. 12.7. Actuator and Output Identity TargetValid(C,A,S) := C.actuator_id == ProtectedIdentity(A) AND SinkControls(A,S) AND OutputChannelBoundTo(A,S) AND NoAliasOrRemapChangesTarget(C,A,S) 12.8. Effect-Lifecycle Authority LifecycleAuthorityValid(C, X_now) := CASE C.effect_type OF INITIATE: CyberAuthorityValid(C,X_now) AND SafetyAllows(C,X_now) CONTINUE: ContinueAuthorityCurrent(C,X_now) AND SafetyAllowsContinuation(C,X_now) MODIFY: ModificationWithinAuthorizedEnvelope(C,X_now) STOP: StopAuthorityPolicy(C,X_now) # Safety/emergency stop MAY dominate cyber policy. RELEASE: ReleaseAuthorityCurrent(C,X_now) AND ReleaseSafetyPredicatesTrue(C,X_now) RESET: ResetAuthorityCurrent(C,X_now) AND ResetSafetyPredicatesTrue(C,X_now) Das Expires 20 March 2027 [Page 27] Internet-Draft Actuation-Bound Finality September 2026 12.9. Actuation Generation Vector G_now = ( G_safety, G_process, G_machine_mode, G_authority, G_revocation, G_sequence, G_actuator_mapping, G_topology ) GenerationVectorCurrent(G_eval,G_now,C) := FOR EACH generation component g_d load-bearing for C: G_eval[d] == G_now[d] OR AuthoritativeCompatibilityProof( G_eval[d], G_now[d], C, d) A vector avoids invalidating unrelated state while still preventing a relevant safety, process, authority, actuator-mapping, or topology change from silently preserving stale authority. 12.10. State-Transition Applicability TransitionAffects(C, X_old, X_new) := EXISTS required dimension d: NOT EquivalentForActuation( C, X_old[d], X_new[d]) If TransitionAffects(...) = TRUE: prior actuation approval MUST NOT automatically survive. 12.11. Check-to-Output Serialization Let ≺_A denote the authoritative ordering between safety/authority state changes and protected physical output commit. Das Expires 20 March 2027 [Page 28] Internet-Draft Actuation-Bound Finality September 2026 VerifyActuation(C,G17) | v Change(G17 -> G18) | v CommitPhysical(C) If: VerifyActuation(C,G17) ≺_A Change(G17->G18) ≺_A CommitPhysical(C) then: CommitPhysical(C) MUST NOT proceed unless the transition is authoritatively proven irrelevant. 12.12. Replay and Sequence Formalism ReplaySafe(C,X_now) := NonceFresh(C.nonce) AND SequenceWithinWindow(C.sequence,X_now) AND NOT AlreadyConsumed(C.nonce,C.sequence) AND ( IdempotentByPolicy(C) OR SingleUse(C) OR TransactionScopedReuse(C) ) 12.13. Actuation-Path Completeness ActuationPathSafe(K,D,F) := FOR ALL technically viable paths p capable of producing K: p intersects protected AFB set F OR p enforces an equivalent finality + safety invariant If EXISTS bypass path p: strict consequence-wide prevention fails. 12.14. Expanded Actuation Validity Das Expires 20 March 2027 [Page 29] Internet-Draft Actuation-Bound Finality September 2026 ActuationValid(C,A,S,X_now,E_set,G_now) := TrustedState(C,X_now,E_set,t_now) AND CyberAuthorityValid(C,X_now) AND TargetValid(C,A,S) AND SafetyAllows(C,X_now) AND LifecycleAuthorityValid(C,X_now) AND GenerationVectorCurrent( C.bound_generation_vector, G_now, C) AND ReplaySafe(C,X_now) AND ActuationPathSafe( C.protected_consequence, C.effectuation_domain, C.afb_set) 12.15. Expanded Strict Prevention Invariant PhysicalEffect(K,C) => ActuationValid(C,A,S,X_now,E_set,G_now) AND ProtectedCommitAtAFB(C,A,S) Strict prevention: NOT ActuationValid(...) => NOT PhysicalEffect(K,C) Safety dominance: SafetyDecision(C,X_now) = DENY => NOT PhysicalEffect(K,C) Emergency-stop dominance: EmergencyStopActive(X_now) = TRUE => NO cyber authorization may force protected motion. 12.16. Continuing and Latched Effects A physical effect can remain active after its initiating command has completed. The security property therefore distinguishes initiation from continued authorization. Das Expires 20 March 2027 [Page 30] Internet-Draft Actuation-Bound Finality September 2026 InitiateAllowed(C,t0) does NOT imply ContinueAllowed(C,t1) For latched/continuing effects: ContinueEffect(K,C,t) => ContinueAuthorityCurrent(C,t) AND RequiredSafetyPredicatesCurrent(C,t) AND ContinuationPathStillProtected(C,t) 12.17. Expanded Bounded Prevention Proof Assume: (1) the canonical Candidate Act fully captures every security-relevant actuation field; (2) the AFB observes the actual pending physical output and controls the first protected physical effect; (3) every required safety/process/state dimension comes from an adequately trusted and current source; (4) the existing safety system remains authoritative; (5) every load-bearing state change advances or validates the actuation generation vector; (6) check-to- output ordering is protected; (7) replay/sequence state cannot be rolled back; and (8) every path capable of producing the protected consequence crosses the AFB or an equivalent invariant. Suppose the protected physical effect occurs while the command is substituted, the actuator is wrong, current authority is invalid, a required safety/process predicate is false or unknown, the generation vector is stale, replay protection fails, or the path bypasses final enforcement. Then ActuationValid is false. The strict prevention invariant prohibits PhysicalEffect, producing a contradiction unless at least one premise — act representation, sensing/state trust, safety authority, generation handling, serialization, replay protection, or path completeness — was violated. The proof is bounded; it does not prove that hazard analysis, sensors, mechanics, or the safety application itself are correct. 13. State, Safety, and Authority Continuity A command approved under one state is not automatically applicable after a load-bearing state change. Das Expires 20 March 2027 [Page 31] Internet-Draft Actuation-Bound Finality September 2026 Generation X17: mode=AUTO guard=CLOSED actuator=A safety=PASS authority=VALID | +---- C authorized Guard / mode / process / authority / mapping changes | v Generation X18: one or more load-bearing predicates differ Result: Valid(C, X17) does NOT imply Valid(C, X18) Figure 3: Actuation generation after a state change A relevant change SHOULD advance or invalidate actuation generation, invalidate pending authority, require re-evaluation, or provide an authoritative proof that the change is irrelevant to C. Das Expires 20 March 2027 [Page 32] Internet-Draft Actuation-Bound Finality September 2026 At authorization: G_eval = { safety: 17, process: 42, mode: 5, authority: 11, revocation: 8, sequence: 91, actuator_map: 7, topology: 30 } Before physical commit: G_now = { safety: 18, <-- changed process: 43, <-- changed mode: 5, authority: 11, revocation: 8, sequence: 91, actuator_map: 7, topology: 31 <-- changed } Result: revalidate affected state and path coverage. Figure 4: Multi-dimensional actuation generation vector AFB / Finalizer Safety / Process State | | | verify under G17 | | | | change -> G18 | | | | protected output commit | | assert G == G17 ----------- FAIL | | | +---- re-sample / revalidate ----------+ Figure 5: Check-to-output race 14. Exact Command and Actuator Binding Das Expires 20 March 2027 [Page 33] Internet-Draft Actuation-Bound Finality September 2026 Approved Candidate C1: actuator = Robot-7 axis = X distance = 10 mm speed = 5 Observed pending output C2: actuator = Robot-7 axis = X distance = 100 mm speed = 50 H(C1) != H(C2) | v REJECT Figure 6: Command substitution after approval The act representation must cover every parameter whose change can affect authority or the physical consequence. Target-actuator identity must be load-bearing where redirection to another device would change the safety/security meaning. Authorization time: logical target = Valve-A physical mapping = Output-17 Before commit: logical target = Valve-A mapping changed = Output-22 If Output-22 controls a different physical device: TargetValid(C,A,S) = FALSE => REJECT / REVALIDATE Figure 7: Actuator remapping after authorization Das Expires 20 March 2027 [Page 34] Internet-Draft Actuation-Bound Finality September 2026 15. Freshness, Replay, and Sequence Control Physical effects are often non-idempotent. Replaying an otherwise valid command can repeat motion, dispense material twice, reopen a valve, or duplicate another physical action. Profiles therefore need explicit replay and sequencing semantics. Candidate authority can include: act_digest actuator_id nonce / transaction_id sequence validity bounds authority_generation consume_once state A valid signature alone does not imply reusability. Authorized sequence: ... 90, 91, 92, 93 ... Pending C: sequence = 92 nonce = N92 Cases: first valid use of 92 -> eligible replay of N92 -> reject sequence 89 after window -> reject duplicate retry after K -> reject unless idempotent policy 93 before required 92 -> reject if ordering is load-bearing Figure 8: Replay and sequence window 16. Actuation Finality Boundary The AFB is a role, not a new mandatory device. Possible realizations include an existing safety PLC, safety controller, protected drive, robot controller, SIS function, protected device firmware, secure I/O stage, hardware interlock controller, or a distributed set of equivalent output mediators. Das Expires 20 March 2027 [Page 35] Internet-Draft Actuation-Bound Finality September 2026 AI / HMI / Cloud | v +------------------+ | Authz Gateway | <-- useful upstream authorization +--------+---------+ | v PLC | v Fieldbus / I/O | v +------------------+ | AFB / Safety or | | Protected Output | <-- first boundary that can make K physical +--------+---------+ | v Drive / Valve / Motor / Robot Figure 9: Upstream authorization versus true physical finality +----------------+ | INITIATE | +-------+--------+ | v effect active | +-------------+-------------+ | | | v v v CONTINUE MODIFY STOP | | | +------+------+ | | | v v effect active safe/stopped | v RELEASE | v effect ends Each transition can have different authority and safety predicates. Das Expires 20 March 2027 [Page 36] Internet-Draft Actuation-Bound Finality September 2026 Figure 10: Initiate, continue, modify, stop, and release authority t0: authorize START_MOTOR | v motor enabled t1: start token expires / authority revoked | v Question: may motor CONTINUE running? Initiation authority alone is insufficient if policy requires continuing authorization. Figure 11: Latched physical effect requires continuation semantics 17. State Machine Das Expires 20 March 2027 [Page 37] Internet-Draft Actuation-Bound Finality September 2026 +----------------+ | CANDIDATE ACT | +-------+--------+ | v +---------------------+ | BIND EXACT COMMAND | | + TARGET ACTUATOR | +---------+-----------+ | v +---------------------+ | NON-EFFECTIVE | | pending actuation | +---------+-----------+ | v +---------------------+ | OBSERVE CURRENT | | ACTUATION CONTEXT | +---------+-----------+ | v +---------------------+ | AFB FINAL CHECK | | cyber authority | | safety predicates | | process / mode | | replay / path | +----+-----------+----+ | | fail pass | | v v SAFE / PROTECTED DENIED OUTPUT COMMIT | v PHYSICAL EFFECT Figure 12: Actuation-finality state machine 18. Solution Architecture Das Expires 20 March 2027 [Page 38] Internet-Draft Actuation-Bound Finality September 2026 18.1. Prepare Candidate Act The cyber-originating component constructs a Candidate Act containing the target actuator, operation, security-relevant parameters, purpose where applicable, freshness state, and applicable authority- generation context. 18.2. Remain Non-Effective Upstream authorization does not itself energize the actuator. The Candidate Act remains unable to create K until it reaches a valid AFB. 18.3. Observe Current Actuation Context The AFB reads or receives current required machine/process/safety/ authority inputs from sources appropriate to the assurance profile. 18.4. Verify Exact Act and Current Applicability The AFB reconstructs or observes the pending physical command, compares it with the Candidate Act, evaluates current authority, required safety/process state, freshness, replay, target identity, and path applicability. 18.5. Protected Output Commit Successful verification is coupled to the hardware or controller transition that enables the physical output. If a required safety function returns DENY, the output remains in or transitions to the deployment-defined safe state. 18.6. Architecture Diagram Das Expires 20 March 2027 [Page 39] Internet-Draft Actuation-Bound Finality September 2026 Cyber / AI / HMI / Control Application | v +----------------+ | Candidate Act | | exact command | | actuator ID | | authority | +-------+--------+ | v NON-EFFECTIVE | v +----------------------------------+ | ACTUATION FINALITY BOUNDARY | | | | observe pending output | | exact command / actuator | | current cyber authority | | current process / machine state | | existing required safety logic | | freshness / replay / sequence | | path authorization | +---------------+------------------+ | pass | fail +-------+---------+ | | v v PROTECTED OUTPUT SAFE / DENY | v PHYSICAL EFFECT K Figure 13: Actuation-bound execution-finality architecture 19. Illustrative Pseudocode The following pseudocode is non-normative. It separates act canonicalization, authority binding, state acquisition, trust/ consistency checks, safety composition, lifecycle authority, replay/ sequence enforcement, target validation, topology/path coverage, generation transitions, real-time finalization, continuing-effect supervision, emergency-stop handling, and crash-safe recovery. 19.1. Canonicalize the Physical Candidate Act Das Expires 20 March 2027 [Page 40] Internet-Draft Actuation-Bound Finality September 2026 function canonicalize_candidate(command): C = CanonicalAct( actuator_id = protected_target_identifier(command), operation = command.operation, parameters = canonical_security_parameters(command), effect_type = classify_effect_type(command), destination_or_axis = command.destination_or_axis_if_required, purpose = command.purpose_if_required, sequence = command.sequence, nonce = command.nonce, constraints = command.constraints) C.effect_digest = H(encode(C)) return C 19.2. Bind Cyber Authority to the Exact Act function bind_cyber_authority(candidate): C = canonicalize_candidate(candidate) decision = current_authorization_policy(C) if decision != ALLOW: reject("cyber authorization denied") return protect_execution_authority( act_digest = C.effect_digest, actuator_id = C.actuator_id, effect_type = C.effect_type, generation_vector = current_actuation_generation_vector(C), sequence = C.sequence, nonce = C.nonce, constraints = decision.constraints, expiry = decision.expiry) 19.3. Acquire Current Actuation State Das Expires 20 March 2027 [Page 41] Internet-Draft Actuation-Bound Finality September 2026 function acquire_current_state(candidate, actuator): X = {} X.actuator_identity = protected_actuator_identity(actuator) X.controller_identity = protected_controller_identity() X.machine_mode = read_authoritative_machine_mode() X.process_state = read_required_process_state(candidate) X.safety_state = read_required_safety_state(candidate) X.interlock_state = read_required_interlocks(candidate) X.operating_envelope = current_operating_envelope(candidate) X.human_presence_state = read_if_required(candidate, "human_presence") X.energy_state = read_if_required(candidate, "energy_state") X.revocation_state = current_revocation_state(candidate) X.sequence_state = current_sequence_state(candidate.actuator_id) X.path_identity = current_actuation_path() X.generation_vector = current_actuation_generation_vector(candidate) return X 19.4. Verify Trusted State Sources Das Expires 20 March 2027 [Page 42] Internet-Draft Actuation-Bound Finality September 2026 function verify_state_sources(candidate, state): for d in required_state_dimensions(candidate): evidence = state.evidence[d] if evidence == NONE: return UNKNOWN(d) if !verify_state_evidence_integrity(evidence): reject("invalid state evidence", d) if !source_trusted_for_dimension( evidence.source, d): reject("untrusted state source", d) if !fresh_enough( evidence, freshness_bound_for(candidate,d)): return STALE(d) if !assurance_sufficient( evidence.assurance, required_assurance(candidate,d)): reject("state assurance too weak", d) if !cross_state_context_consistent( candidate, state): reject("inconsistent state bundle") return VALID 19.5. Verify Actuator and Output Identity Das Expires 20 March 2027 [Page 43] Internet-Draft Actuation-Bound Finality September 2026 function verify_target(candidate, actuator, sink): if protected_actuator_identity(actuator) != candidate.actuator_id: reject("wrong actuator") if !sink_controls_actuator(sink, actuator): reject("sink does not control target") if actuator_mapping_generation(candidate.actuator_id) != candidate.bound_actuator_mapping_generation: return REVALIDATE("actuator mapping changed") if !output_channel_bound_to_actuator( sink, actuator): reject("output path not bound to target") return VALID 19.6. Compose with Existing Safety Functions function evaluate_existing_safety(candidate, state): result = existing_safety_system.evaluate( candidate, safety_inputs = state.safety_state, interlocks = state.interlock_state, process_state = state.process_state, machine_mode = state.machine_mode, operating_envelope = state.operating_envelope) if result == DENY: return DENY if result in {UNKNOWN, UNAVAILABLE, STALE}: return SAFE_RESPONSE_REQUIRED if result != SAFE_TO_ACTUATE: return DENY return SAFE_TO_ACTUATE 19.7. Evaluate Effect-Lifecycle Authority Das Expires 20 March 2027 [Page 44] Internet-Draft Actuation-Bound Finality September 2026 function evaluate_lifecycle_authority(candidate, state): switch candidate.effect_type: case INITIATE: return initiate_authority_current(candidate, state) case CONTINUE: return continue_authority_current(candidate, state) case MODIFY: return modification_within_authorized_envelope( candidate, state) case STOP: return stop_policy(candidate, state) case RELEASE: return release_authority_current(candidate, state) case RESET: return reset_authority_current(candidate, state) default: reject("undefined effect lifecycle semantics") 19.8. Verify Replay and Sequence State function verify_replay_and_sequence(candidate, state): if nonce_already_consumed(candidate.nonce): reject("replayed command") if !sequence_within_allowed_window( candidate.sequence, state.sequence_state): reject("sequence outside allowed window") if ordering_is_load_bearing(candidate): if !required_predecessors_complete(candidate): reject("command ordering violation") if !candidate_is_idempotent(candidate) and duplicate_effect_detected(candidate): reject("duplicate physical effect") return VALID 19.9. Verify the Complete Actuation Predicate Das Expires 20 March 2027 [Page 45] Internet-Draft Actuation-Bound Finality September 2026 function verify_actuation(candidate, actuator, sink, state): verify_target(candidate, actuator, sink) verify_state_sources(candidate, state) if H(canonical_pending_physical_output( actuator, observed_pending_output())) != candidate.effect_digest: reject("exact physical output mismatch") if !cyber_authority_current(candidate, state): reject("cyber authority invalid or stale") if !revocation_allows( candidate, state.revocation_state): reject("authority revoked") if evaluate_existing_safety( candidate, state) != SAFE_TO_ACTUATE: reject_or_safe_state("safety did not allow actuation") if !evaluate_lifecycle_authority( candidate, state): reject("effect lifecycle authority invalid") verify_replay_and_sequence(candidate, state) if !actuation_path_authorized( candidate, state.path_identity): reject("unmediated actuation path") return VALID 19.10. Handle Safety, Process, Authority, or Topology Change Das Expires 20 March 2027 [Page 46] Internet-Draft Actuation-Bound Finality September 2026 function on_actuation_relevant_change(change): affected = actuation_dimensions_affected_by(change) for d in affected: advance_protected_generation(d) pending = pending_candidates_depending_on(affected) for candidate in pending: mark_revalidation_required(candidate) if change_definitively_invalidates(candidate): mark_non_effective(candidate) if change_requires_safe_response(change): request_existing_safety_system_safe_response() 19.11. Validate Whether a State Transition Is Irrelevant function transition_irrelevant_to_candidate( candidate, old_state, new_state): for d in required_state_dimensions(candidate): if !actuation_equivalence_rule(candidate,d)( old_state[d], new_state[d]): return FALSE if new_state[d].assurance < required_assurance(candidate,d): return FALSE if !fresh_enough( new_state[d], freshness_bound_for(candidate,d)): return FALSE return TRUE 19.12. Verify Consequence-Wide Actuation-Path Coverage Das Expires 20 March 2027 [Page 47] Internet-Draft Actuation-Bound Finality September 2026 function verify_actuation_path_coverage( consequence, path_inventory, afb_inventory): for path in paths_capable_of( consequence, path_inventory): intersections = path.intersection(afb_inventory) if intersections is not EMPTY: if any_valid_afb(intersections): continue if path.enforces_equivalent_finality_and_safety: continue return CoverageFailure( reason="actuation bypass path", witness=path) return COVERAGE_VALID 19.13. Protected Real-Time Finalization function finalize_actuation(candidate, actuator): sink = current_actuation_finality_boundary() begin_protected_actuation_section() state = acquire_current_state(candidate, actuator) if verify_actuation( candidate, actuator, sink, state) != VALID: remain_non_effective_or_enter_safe_state() return REJECTED observed_vector = state.generation_vector atomic_or_safety_equivalent { current_vector = current_actuation_generation_vector(candidate) assert generation_vector_matches_or_is_compatible( Das Expires 20 March 2027 [Page 48] Internet-Draft Actuation-Bound Finality September 2026 observed_vector, current_vector, candidate) current_state = acquire_minimum_hot_path_state( candidate, actuator) assert evaluate_existing_safety( candidate, current_state) == SAFE_TO_ACTUATE assert exact_pending_output_still_matches( candidate, actuator) assert actuation_path_still_authorized( candidate, current_state.path_identity) protected_consume_once( candidate.nonce, candidate.sequence) commit_physical_output( actuator, candidate.operation, candidate.parameters) } return EFFECT_COMMITTED 19.14. Supervise Continuing or Latched Effects Das Expires 20 March 2027 [Page 49] Internet-Draft Actuation-Bound Finality September 2026 function supervise_continuing_effect(effect_handle): while effect_is_active(effect_handle): state = acquire_continuation_state(effect_handle) if !continue_authority_current( effect_handle, state): request_safe_stop_or_release(effect_handle) return CONTINUATION_DENIED if evaluate_existing_safety( effect_handle.candidate, state) != SAFE_TO_CONTINUE: request_safe_stop_or_release(effect_handle) return SAFETY_STOP if generation_changed_relevantly( effect_handle.bound_generation_vector, state.generation_vector): if !revalidate_continuation(effect_handle, state): request_safe_stop_or_release(effect_handle) return REVALIDATION_FAILED wait_until_next_required_supervision_point() return EFFECT_ENDED 19.15. Emergency-Stop Precedence function on_emergency_stop(event): if !verify_emergency_stop_source(event): return INVALID_EVENT existing_safety_system.request_emergency_safe_state(event) invalidate_or_suspend_pending_motion_authority( scope=event.scope) mark_all_affected_candidates_non_effective() return EMERGENCY_STOP_ACTIVE # No cyber ALLOW path may override this state. 19.16. Separate Cold-Path and Hot-Path Work Das Expires 20 March 2027 [Page 50] Internet-Draft Actuation-Bound Finality September 2026 function prepare_hot_path(candidate): cold = { attestation_result: obtain_or_refresh_attestation_if_required(candidate), policy: resolve_actuation_policy(candidate), operating_envelope: precompute_allowed_envelope(candidate), path_coverage: verify_actuation_path_coverage( candidate.protected_consequence, current_path_inventory(), current_afb_inventory()), bound_generations: current_actuation_generation_vector(candidate) } return protect_hot_path_context(cold) 19.17. Crash-Safe Physical-Effect Recovery function recover(candidate_id): state = protected_commit_state(candidate_id) if state == EFFECTIVE: return DO_NOT_REPLAY if state == COMMITTING: result = resolve_atomic_or_safety_commit(candidate_id) if result == EFFECT_COMMITTED: return DO_NOT_REPLAY if result == OUTPUT_NOT_COMMITTED: return REVALIDATE_CURRENT_STATE_BEFORE_RETRY return ENTER_SAFE_RECOVERY_MODE if state == PENDING: return REVALIDATE_CURRENT_STATE_BEFORE_RETRY return FAIL_CLOSED_OR_SAFE Das Expires 20 March 2027 [Page 51] Internet-Draft Actuation-Bound Finality September 2026 19.18. Generate a Reviewable Actuation Failure Explanation function explain_actuation_failure(result): return { exact_act_failure: result.effect_digest_mismatch, actuator_failure: result.target_or_mapping_mismatch, cyber_authority_failure: result.authority_or_revocation_failure, safety_failure: result.safety_or_interlock_failure, process_failure: result.process_or_envelope_failure, state_source_failure: result.missing_stale_or_untrusted_state, generation_failure: result.changed_generations, replay_failure: result.replay_or_sequence_failure, path_failure: result.bypass_path_if_any } 20. Composition with Existing Safety Controllers In many real systems the existing safety controller is the correct AFB. The architecture can provide cyber exact-act/current-authority inputs to that controller or to a protected supervisory layer without changing the safety controller's authority over safety outputs. Das Expires 20 March 2027 [Page 52] Internet-Draft Actuation-Bound Finality September 2026 Candidate C | | cyber authority + exact command v +--------------------------------+ | Existing Safety PLC / | | Protected Safety Controller | | | | cyber act applicable? | | current safety inputs? | | safety application says ALLOW? | | current process state? | +---------------+----------------+ | pass | safety DENY +------+------+ | | v v SAFETY OUTPUT SAFE STATE | v ACTUATOR Figure 14: Existing safety controller as the Actuation Finality Boundary This composition is preferable to duplicating or bypassing certified safety logic. Cyber Finality Existing Safety Logic | | | exact act = PASS | | authority = PASS | | | +------------------------------->| | guard = OPEN | safety = DENY v +--------------+ | FINAL RESULT | | DENY | +--------------+ Cyber PASS cannot override Safety DENY. Figure 15: Safety decision remains authoritative Das Expires 20 March 2027 [Page 53] Internet-Draft Actuation-Bound Finality September 2026 21. RATS-Based High-Assurance Actuation RATS can establish that the controller, AFB, or another software/ hardware component is in an expected state before it participates in actuation. An Attestation Result can therefore become a required input to cyber actuation authority. Controller / AFB | | platform Evidence v Verifier | | Attestation Result v +----------------------------+ | Actuation Policy / AFB | | trusted controller state? | | exact Candidate Act? | | current safety/process? | +-------------+--------------+ | v protected output Attestation proves technical platform claims. It does NOT make an untrusted physical sensor reading true. Figure 16: RATS evidence as a trust input to actuation finality RATS / Attestation can establish: controller identity firmware/software state protected execution state Trusted sensing may establish: guard state pressure human presence shaft speed actuator position Actuation Finality needs whichever dimensions the policy actually requires. Attestation does not manufacture physical truth. Figure 17: Attested controller state versus physical state Das Expires 20 March 2027 [Page 54] Internet-Draft Actuation-Bound Finality September 2026 22. Alternate-Path Resistance A protected cyber path is insufficient if a maintenance, engineering, local/manual, direct-fieldbus, direct-I/O, recovery, drive-local, or firmware path can create the same physical effect without equivalent safety/finality enforcement. Normal path: AI/HMI -> Authz -> AFB/Safety Controller -> Output -> K ^ | protected path Bypass: Maintenance / Engineering / Direct I/O / Firmware | +------------------------> K If the bypass can create K without an equivalent invariant, consequence-wide prevention is not established. Figure 18: Alternate actuation path bypass Normal path: App -> PLC -> [Safety AFB] -> Drive -> K Maintenance path: Eng WS -> [Maintenance AFB] -> Drive -> K Local path: Panel -> [Local Safety Logic] -> Drive -> K Strict prevention requires every path capable of K to enforce an equivalent finality + safety invariant. Figure 19: Distributed actuation cut across multiple physical paths 23. Attack Analysis 23.1. Command-Parameter Substitution Parameters change after approval. Exact-effect binding at the AFB detects the mismatch. Das Expires 20 March 2027 [Page 55] Internet-Draft Actuation-Bound Finality September 2026 23.2. Target-Actuator Substitution An otherwise valid command is redirected from actuator A to B. Target identity binding rejects the act. 23.3. Replay and Duplicate Actuation A previously valid command is repeated. Nonce/sequence/consume-once state rejects replay according to the profile. 23.4. Safety or Process-State Race A safety predicate changes after upstream authorization. The AFB re- establishes required current state immediately before protected output commit. 23.5. Machine-Mode Confusion A command authorized in one mode is used in another. Mode becomes a load-bearing actuation predicate. 23.6. Maintenance or Engineering Bypass An engineering workstation or local maintenance interface sends the output directly. A prevention profile must block, include, or equivalently mediate that path. 23.7. Compromised Non-Safety Controller A compromised ordinary PLC task attempts to generate the physical output. Where the AFB/safety controller is independent and non- bypassable, the ordinary task still cannot complete the protected effect without passing the final checks. 23.8. Action Evidence Without Prevention A signed action record is produced after the actuator moves. The record may be valuable for accountability, but the physical effect was not conditional on the record. 24. High-Assurance Enforcement Das Expires 20 March 2027 [Page 56] Internet-Draft Actuation-Bound Finality September 2026 Compromisable cyber plane +------------------------------------------------+ | AI agent | HMI | app | OS | gateway | broker | +-------------------------+----------------------+ | v +-----------------------------+ | PROTECTED AFB / SAFETY | | CONTROLLER | | exact command / actuator | | current authority | | current safety/process | | replay / sequence | | protected output | +--------------+--------------+ | v ACTUATOR Figure 20: Actuation finality below a compromisable cyber plane Cyber Authority Root | v +-----------+ | AFB Logic | +-----+-----+ | +--------------+--------------+ | | | v v v Safety Inputs Attestation Sequence/ / Interlocks Root Replay Root \ | / +-------------+-------------+ | v Protected Output | v Physical K Figure 21: Multiple protected roots for high-assurance actuation 25. Deployment Patterns Das Expires 20 March 2027 [Page 57] Internet-Draft Actuation-Bound Finality September 2026 25.1. Safety PLC as AFB The existing safety PLC receives or reconstructs cyber exact-act authority and combines it with its normal safety application before enabling the output. 25.2. Protected Drive or Robot Controller as AFB Motion or torque authority is verified at the controller that can actually energize the drive or robot output. 25.3. SIS / Process Controller as AFB A process-sector deployment can integrate cyber authority into an existing SIS decision without weakening the SIS safe-state function. 25.4. Constrained Device / ACE Resource Server as AFB A constrained device can act as both ACE Resource Server and final actuator boundary when it directly controls the protected output and evaluates all required current predicates. 25.5. Distributed AFB Some systems require multiple enforcement points, for example a robot controller plus a safety I/O stage. The profile must define how their decisions compose and how partial failure is handled. 26. Real-Time Performance and Availability Industrial actuation can have strict cycle times. A design MUST NOT require remote policy or attestation calls on every control-loop iteration unless the deployment can satisfy its real-time requirements. Expensive policy/attestation work can occur on supervisory or cold paths, while the real-time path verifies compact protected generations, command digests, actuator identity, local safety state, sequence state, and precomputed authority. Profiles SHOULD state worst-case verification latency, jitter, state- sampling freshness, generation-update latency, safe-state reaction behavior, and how real-time constraints interact with fail-closed cyber enforcement. Das Expires 20 March 2027 [Page 58] Internet-Draft Actuation-Bound Finality September 2026 Availability pressure does not justify overriding functional safety. When cyber authority is unavailable but safety permits motion, the system follows the deployment's explicit policy; it MUST NOT silently infer cyber authority. When cyber authority is valid but the safety system denies or is in an unsafe/unknown state, the protected act remains non-effective. Cold / supervisory path: policy resolution attestation authority issuance topology review envelope computation | v protected state | v Real-time hot path: exact command digest current safety inputs generation vector sequence / replay local finality predicate protected output commit Figure 22: Cold-path and real-time hot-path split 27. Relationship to ACE ACE is highly relevant because RFC 9200 defines OAuth-based authorization for constrained environments [RFC9200]. The main architectural question is whether the ACE Resource Server is itself the true actuator boundary. If it is and it evaluates all required current actuation predicates, the core property can already be satisfied. This document does not propose a new ACE token format in its base form. 28. Relationship to CoRE CoRE maintains CoAP and related mechanisms for constrained resources [RFC7252]. Physical devices using CoAP can expose protected actuator resources, but this document does not presume that CoRE owns functional-safety semantics. Das Expires 20 March 2027 [Page 59] Internet-Draft Actuation-Bound Finality September 2026 29. Relationship to RATS RATS is relevant when actuation depends on trusted controller/device state [RFC9334]. A profile can require an acceptable Attestation Result before cyber authority becomes actuation-eligible. Physical- state truth remains outside attestation unless the measurement/ evidence architecture actually supports it. 30. Relationship to OPC UA and Industrial Safety Standards OPC UA Safety already defines functional-safety communication for safety devices [OPCUA-SAFETY]. IEC 61508/61511 and product-specific safety certification remain authoritative for functional-safety engineering. This draft is a security/authority composition proposal, not a functional-safety standard and not a certification claim. IETF is not the owner of industrial functional-safety certification. Cross-community review with IEC TC 65, the OPC Foundation, industrial vendors, and safety engineers is essential before asserting any production profile. 31. Industrial Relevance The industrial relevance is not based on an assertion that major automation vendors lack safety enforcement. The opposite is the useful starting point: mature safety controllers already demonstrate protected safety logic, safety I/O, diagnostics, and final output control. The question for increasingly cloud-connected and AI- assisted systems is how upstream cyber authority is bound to those mature physical safety boundaries without bypassing, weakening, or duplicating them. 31.1. Robotics and Machine Motion Agentic or remote software can generate motion proposals, but actual motion can remain non-effective until the robot/safety controller verifies exact command authority and current cell/safety conditions. 31.2. Process Control Valve, pump, dosing, pressure, and process-state changes can be bound to current process and SIS conditions at the true output boundary. Das Expires 20 March 2027 [Page 60] Internet-Draft Actuation-Bound Finality September 2026 31.3. Manufacturing and Warehouse Automation Queued or AI-generated tasks can survive substantial delays before physical execution. Revalidation at actuation prevents stale digital authority from silently surviving a changed cell or line state. 31.4. Critical Infrastructure High-consequence control actions can require hardware/protected- controller enforcement below compromise-prone enterprise and AI layers. 32. Complementary Industrial Alignment 32.1. Siemens Safety Integrated Siemens documents fail-safe S7 controllers and Safety Integrated designs using fail-safe programs and certified safety blocks [SIEMENS-SAFETY]. Such a controller can potentially serve as the AFB for a deployment. No deficiency is asserted. 32.2. Rockwell Automation GuardLogix Rockwell documents GuardLogix controller systems for safety applications including SIL 3 / PL e configurations [ROCKWELL-GUARDLOGIX]. Existing GuardLogix safety logic and output authority should remain authoritative; an execution-finality profile would compose with it rather than replace it. 32.3. Schneider Electric Modicon M580 Safety Schneider's current M580 Safety system guide describes how the system addresses IEC 61508 safety requirements and safe system operation [SCHNEIDER-M580]. This is a mature safety-controller architecture and a possible AFB integration point. 32.4. ABB AC500-S ABB documents AC500-S safety PLCs and safety I/O for applications up to SIL 3 / PL e [ABB-AC500S]. Its documented safety function reads safety inputs and controls safety outputs according to safety logic, including de-energize-to-trip safe behavior [ABB-SAFETY-FUNCTION]. This is direct overlap with the AFB role, not an example of missing safety enforcement. Das Expires 20 March 2027 [Page 61] Internet-Draft Actuation-Bound Finality September 2026 32.5. OPC Foundation OPC UA Safety is a strong interoperability precedent for functional- safety communication and explicitly remains subject to safety- development and assessment requirements [OPCUA-SAFETY] [OPCUA-SAFETY-POLICY]. 32.6. Non-Endorsement and Non-Criticism Named vendors and standards are included only as documented examples of mature safety engineering, architectural overlap, or possible integration points. The document does not assert that Siemens, Rockwell Automation, Schneider Electric, ABB, the OPC Foundation, or any other named organization has a vulnerability, deficiency, non- conformance, or obligation to adopt this architecture, and no affiliation or endorsement is implied. 33. Required Classes of Test Vectors A concrete implementation or profile SHOULD test at least: * exact command, correct actuator, current authority, safe/current process state: output succeeds; * parameter changed after authorization: reject; * target actuator changed: reject; * guard/interlock changes after authorization: reject or safe response; * machine mode changes: reject/revalidate; * process state leaves allowed envelope: reject; * cyber authority revoked before output: reject; * identical command replayed after consume-once: reject; * out-of-order sequence: reject according to profile; * safety controller returns DENY while cyber authority is valid: reject; * safety state UNKNOWN under strict profile: remain non-effective/ safe; Das Expires 20 March 2027 [Page 62] Internet-Draft Actuation-Bound Finality September 2026 * cyber authority missing while safety state is permissive: reject under protected cyber profile; * valid RATS Attestation Result but physical/process predicate missing: reject or UNKNOWN; * action-evidence record present only after actuation: classify as audit, not prevention; * maintenance/direct-I/O path reaches actuator without equivalent AFB: prevention profile fails; * ACE Resource Server is the actual actuator and checks all required current conditions: succeed without extra component; * existing safety PLC fully mediates exact cyber act plus safety output: recognize property as already satisfied; * generation changes between verification and output: retry/ revalidate; * crash after consume-before-output: recover without duplicate actuation; * emergency stop active: safety DENY dominates all cyber authorization. Additional high-assurance tests SHOULD include: valid cyber authority with a stale but cryptographically authentic safety snapshot; correct safety value from an under-assured source; conflicting trusted process-state sources; actuator remapping after authorization; sequence-window rollback; continuing effect after initiation authority expires; release/reset operations with different authority rules; emergency-stop activation during protected commit; topology change that introduces a maintenance bypass; crash after protected consume but before confirmed physical output; and recovery after an uncertain actuator state. 34. Questions to the IETF Community Criticism, corrections, counterexamples, industrial implementation experience, prior art, evidence of equivalent existing mechanisms, and reasons to narrow, merge, or stop the work are explicitly invited. Negative answers are useful outcomes. 1. Is actuation-bound execution finality a useful security abstraction, or is it already fully covered by functional-safety controllers and existing authorization patterns? Das Expires 20 March 2027 [Page 63] Internet-Draft Actuation-Bound Finality September 2026 2. Where an ACE Resource Server is the final actuator and checks current conditions, does RFC 9200 already provide all required protocol semantics? 3. Should this work be a BCP/composition guide rather than a new protocol? 4. Does OPC UA Safety plus a certified safety PLC already satisfy the full invariant for typical industrial deployments? 5. What residual property, if any, remains between an authorized digital command and certified safety output? 6. Should exact cyber-command binding be handled by industrial application protocols rather than IETF? 7. How should a Candidate Act be canonically bound to actuator, operation, parameters, sequence, and constraints? 8. Which physical/process state belongs in cyber authorization, and which must remain solely within functional safety? 9. Should a safety-controller result be treated as a required external decision input while still remaining authoritative? 10. How fresh must safety/process state be when an actuation completes? 11. How should state changes during the verification-to-actuation interval be serialized? 12. Which interfaces constitute alternate actuation paths: maintenance, engineering, local/manual, direct I/O, fieldbus, firmware, or recovery? 13. How can path completeness be demonstrated for a physical actuation surface? 14. Can RATS Evidence establish enough controller/device state without overclaiming physical facts that are not measured? 15. How should sensor trust be represented without implying that attestation makes sensor readings true? 16. Does [SOKOLOV-AEP] already cover enough action/platform composition that only the pre-effectuation boundary remains? Das Expires 20 March 2027 [Page 64] Internet-Draft Actuation-Bound Finality September 2026 17. Is post-actuation action evidence useful as an audit complement even though it is not prevention? 18. How should fail-safe or de-energize behavior interact with cyber execution authority? 19. What is the correct fail behavior when cyber authority is valid but required safety state is UNKNOWN? 20. What is the correct fail behavior when safety permits motion but cyber authority is missing? 21. Should AI agents ever hold direct actuator authority, or should agent authority always terminate in an industrial controller profile? 22. What performance bounds are acceptable for high-rate motion and control loops? 23. Which checks belong on the real-time path versus a supervisory/ cold path? 24. Which existing Siemens, Rockwell, Schneider, ABB, OPC UA Safety, or other deployments already guarantee this exact invariant? 25. What counterexample would falsify or materially narrow the proposed architecture? 26. Is ACE, CoRE, RATS, DISPATCH, SAAG, or an external industrial standards body the appropriate venue for further discussion? 35. Potential IETF Discussion Venues and External Standards Boundaries 35.1. ACE ACE is directly relevant for constrained-device authorization and has active work in 2026. A central review question is whether an ACE Resource Server that is itself the actuator already provides the required protocol boundary. 35.2. CoRE CoRE is relevant where actuators expose CoAP resources or participate in constrained messaging. This document does not presume CoRE owns functional-safety semantics. Das Expires 20 March 2027 [Page 65] Internet-Draft Actuation-Bound Finality September 2026 35.3. RATS RATS is relevant for controller/device trust evidence and action/ platform evidence composition. The preferred question is whether actuation trust should be an application-layer Relying Party decision rather than a new RATS evidence format. 35.4. DISPATCH DISPATCH can be useful for routing if no current WG owns the cross- cutting composition problem. 35.5. SAAG SAAG is useful for broad Security Area architectural review. It is not a Working Group that adopts documents. 35.6. IEC, OPC Foundation, and Industrial Safety Communities IEC TC 65, IEC 61508/61511/62443 stakeholders, the OPC Foundation, safety assessors, industrial vendors, and functional-safety engineers are essential adjacent communities. IETF is not the owner of functional-safety certification. 35.7. No Presumed Home This document does not claim that any named IETF group or external standards body should adopt the work. Overlap analysis and industrial safety review should precede any standardization proposal. 36. Relationship to Other Execution-Finality Internet-Drafts This document isolates the cyber-command-to-physical-effect boundary. * The protocol-layer draft defines the broad Candidate Act, Non- Effective State, protected validation, and Finality Sink architecture. * The agentic draft applies execution finality to high-risk AI tool dispatch. * The hardware-enforced draft focuses on protected execution- finality boundaries for agentic and industrial systems. * The RATS/attestation-bound draft connects trusted workload state to consequential authority. Das Expires 20 March 2027 [Page 66] Internet-Draft Actuation-Bound Finality September 2026 * The state/policy-continuity draft asks whether earlier authorization remains applicable. * The finality-bound-revocation draft asks whether withdrawn authority survives to commit. * The consequence-path-completeness draft asks whether the consequence can bypass enforcement. * The third-party-decision-binding draft asks whether a required external authority actually issued the applicable decision. * The jurisdiction-bound draft asks whether effectuation occurs under the current permitted sovereign/governance context. * This document asks whether the exact cyber-originated act is still authorized under the current physical/process/safety context at the first physical effect. State continuity: Is earlier authorization still applicable? Revocation finality: Has authority been withdrawn? Path completeness: Can the consequence avoid enforcement? Third-party decision binding: Did the required authority actually approve? Jurisdiction finality: Is effectuation occurring in the permitted sovereign context? Actuation finality: Is the exact cyber-originated act still authorized under CURRENT physical/process/safety context at the first physical effect? Related documents include [DAS-PROTOCOL], [DAS-AGENTIC], [DAS-HARDWARE], [DAS-RATS], [DAS-STATE], [DAS-REVOCATION], [DAS-PATH], [DAS-THIRD-PARTY], and [DAS-JURISDICTION]. Das Expires 20 March 2027 [Page 67] Internet-Draft Actuation-Bound Finality September 2026 37. Public Implementations and Companion Engineering Material Public execution-finality repositories provide background implementations of exact-effect binding, current policy/epoch/ revocation checks, challenge binding, replay resistance, and protected finality [GH-ARCH] [GH-HARDENED]. Those repositories are not represented here as certified industrial- safety implementations or as complete AFB implementations. A production industrial profile would require real controller/actuator integration, safety-engineering review, timing analysis, path inventory, and test evidence. 38. Security Considerations Security depends on exact command binding, current authority, trusted current actuation context, preservation of existing safety authority, output-path non-bypassability, and protected check-to-output ordering. 38.1. Command Parameter Substitution Every parameter whose change affects physical consequence or authority must be covered by exact-act binding. 38.2. Target-Actuator Substitution The target actuator or output endpoint must be bound where redirection changes authority or safety meaning. 38.3. Command Replay Non-idempotent physical commands require explicit replay/consume- once/sequence semantics. 38.4. Duplicate Actuation Retries and crash recovery must not cause duplicate physical effects unless the application explicitly defines idempotent behavior. 38.5. Stale Authority Authentic earlier authority can become inapplicable after policy, operator, ownership, or authorization-state change. Das Expires 20 March 2027 [Page 68] Internet-Draft Actuation-Bound Finality September 2026 38.6. Stale Safety State A safety result sampled before a load-bearing state change must not be reused beyond the profile's allowed freshness semantics. 38.7. Stale Process State Process variables can change faster than supervisory authorization. Required state must be sampled or latched consistently with the real- time profile. 38.8. Interlock Race A guard/interlock change between verification and output can defeat upstream checks. The AFB must use the safety system's protected timing/ordering semantics. 38.9. Machine-Mode Confusion Commands valid in AUTO, TEACH, MANUAL, MAINTENANCE, or another mode are not automatically interchangeable. 38.10. Maintenance-Mode Abuse Maintenance mode can expose powerful actuation paths. It must be explicitly included, isolated, or excluded from the prevention claim. 38.11. Local or Manual Override Local/manual controls can be legitimate higher-priority mechanisms. Their relationship to the cyber prevention claim must be explicit rather than silently omitted. 38.12. Engineering Workstation Bypass An engineering tool or programming interface can become an alternate effectuation path and must be governed by the deployment's path model. 38.13. Direct Fieldbus Write A direct fieldbus command that can energize or actuate a device can bypass an application gateway and must cross equivalent enforcement. 38.14. Direct I/O Path Direct I/O writes or output forcing can defeat higher-layer finality unless physically or logically constrained. Das Expires 20 March 2027 [Page 69] Internet-Draft Actuation-Bound Finality September 2026 38.15. Recovery and Disaster-Recovery Control Paths Recovery interfaces can bypass normal control logic and must be explicitly included or placed in a separate assurance mode. 38.16. Firmware-Level Actuation Device firmware capable of directly controlling outputs is part of the trusted computing base or an alternate path under the relevant threat model. 38.17. Compromised Non-Safety PLC Where the ordinary PLC task is untrusted, the safety/AFB boundary must prevent it from directly completing the protected effect. 38.18. Compromised Gateway An upstream gateway may fabricate approval or modify commands. The AFB independently verifies the exact act and current authority. 38.19. Compromised Host OS Host-resident state and policy are insufficient for high-assurance profiles when the host OS is inside the adversary model. 38.20. Safety-Controller Compromise The base model does not claim to survive full compromise of the authoritative safety controller/AFB. Higher assurance may use architectural separation and certified mechanisms. 38.21. Sensor Spoofing Execution finality can only rely on the sensing assurance provided by the deployment. It does not make an untrusted sensor trustworthy. 38.22. Sensor Authenticity Is Not Physical Truth A signed or attested sensor value can prove provenance/integrity without proving that the sensor accurately represents physical reality. 38.23. Actuator Feedback Spoofing If feedback is used to establish current state or successful completion, its trust model must be explicit. Das Expires 20 March 2027 [Page 70] Internet-Draft Actuation-Bound Finality September 2026 38.24. Sequence and Reordering Attacks Commands that are safe only in an intended sequence require sequence binding and rejection of unauthorized reorderings. 38.25. TOCTOU Between Check and Output The final safety/authority check must be coupled to the output using atomicity, safety-controller cycle semantics, generation locking, or an equivalent protected ordering rule. 38.26. Crash Consistency Crash recovery must not repeat an irreversible/non-idempotent physical effect or re-enable an already consumed Candidate Act. 38.27. Fail-Open Behavior Failure to obtain required cyber authority or required safety/process state MUST NOT silently become ALLOW in a strict prevention profile. 38.28. Loss of Safety-State Source When a required safety-state source is unavailable, existing safety policy determines the safe response. Execution finality must not invent a positive state. 38.29. Denial of Service Attackers can make policy, sequence, or context state unavailable and force fail-safe behavior. Availability engineering must not weaken safety dominance. 38.30. Emergency Stop Precedence Emergency stop and other required safety functions dominate cyber authorization and execution-finality approval. 38.31. Fail-Safe Output State The safe state is deployment/safety-design specific. Execution finality does not define or certify the safe state. 38.32. Output Latching Latched outputs can remain physically effective after authority changes. Profiles must distinguish authority to initiate an effect from authority to continue or release it. Das Expires 20 March 2027 [Page 71] Internet-Draft Actuation-Bound Finality September 2026 38.33. Authority Consumption State Consume-once state must itself be protected against rollback or reset where replay is in the threat model. 38.34. Actuation Path Completeness All paths capable of producing the protected physical consequence must cross the AFB or an equivalent finality/safety invariant. 38.35. RATS Attestation Overclaim Attestation must not be interpreted as proof of unmeasured physical facts or as functional-safety certification. 38.36. Action Evidence Confused with Prevention Evidence that software reports an action does not prove that the action was physically prevented until the required pre-actuation conditions held. 38.37. Audit Is Not Prevention Logging the physical effect after it occurred is useful for accountability but is not the prevention invariant. 38.38. Real-Time Latency and Jitter Adding verification to a real-time path can itself create unsafe timing behavior. Profiles require timing analysis appropriate to the industrial control loop. 38.39. Functional-Safety Certification Boundary Implementing this document does not confer SIL, PL, safety certification, regulatory approval, or a claim of functional-safety compliance. The safety function, lifecycle, hazard analysis, validation, and certification remain governed by applicable industrial safety standards and competent assessors. 38.40. Physical Tampering Direct rewiring, mechanical bypass, or physical modification outside the declared threat model is outside the base prevention claim. Das Expires 20 March 2027 [Page 72] Internet-Draft Actuation-Bound Finality September 2026 39. Privacy Considerations Actuation evidence and context can reveal machine state, human presence, maintenance mode, production sequence, facility topology, device identity, operator activity, or sensitive industrial process information. Profiles SHOULD minimize disclosed context and keep detailed physical-state evidence local where possible. Human-presence or worker-location information can be especially sensitive and should be represented only where the safety function actually requires it. 40. Criticism, Corrections, and Review Invited This document is intentionally presented for adversarial review. Reviewers are invited to identify existing safety/controller architectures that already guarantee the full property, incorrect descriptions of industrial safety standards, unnecessary terminology, unrealistic real-time assumptions, unmodeled actuation paths, unsafe interactions with certified safety functions, sensor-trust mistakes, prior art, or reasons that the work should be narrowed, merged, moved to an industrial standards body, or stopped. Particularly useful feedback is a concrete system in which a certified safety controller, OPC UA Safety application, ACE Resource Server, RATS-based controller, or another existing architecture already makes exact cyber authority and current required physical/ safety context a non-bypassable precondition of the physical effect. Such evidence should narrow the proposal rather than be treated as opposition. 41. IANA Considerations This document has no IANA actions. 42. Conclusion Industrial functional safety, safety PLCs, secure industrial communication, constrained- device authorization, and remote attestation already solve essential parts of physical control security. This document isolates one narrower continuity question: when a cyber-originated command was valid earlier, what makes its exact physical effect remain conditional on current cyber authority, current process/safety applicability, and the actual non-bypassable actuation path? Das Expires 20 March 2027 [Page 73] Internet-Draft Actuation-Bound Finality September 2026 COMMAND ACCEPTED != ACTUATION AUTHORIZED For strict actuation finality: exact command + current cyber authority + current required safety/process state + correct actuator + authorized actuation path => eligible for protected output Any required safety DENY => NO protected physical effect. Existing systems that already enforce this relationship already satisfy the core invariant. The purpose of the draft is to make the cyber-authority-to-physical-effect relationship explicit, testable, composable with mature safety engineering, and open to correction by both IETF and industrial safety communities. A practical implementation should be able to explain not merely that actuation was denied, but whether the failure came from exact-command mismatch, actuator identity or remapping, cyber-authority currentness, revocation, safety/interlock state, process/envelope state, state source assurance, generation drift, replay/sequence semantics, continuing-effect authority, or an alternate physical path. That diagnostic separation is essential for engineering review without confusing cyber finality with functional-safety certification. 43. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, May 2017, . 44. Informative References Das Expires 20 March 2027 [Page 74] Internet-Draft Actuation-Bound Finality September 2026 [ABB-AC500S] ABB, "AC500-S Safety PLC", 2026, . [ABB-SAFETY-FUNCTION] ABB, "AC500-S Safety Function and Fault Reaction", 2026, . [DAS-AGENTIC] Das, S., "Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch in High-Risk AI Systems", Work in Progress, Internet-Draft, draft-das-agentic-execution- finality-02, September 2026, . [DAS-HARDWARE] Das, S., "Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI, MCP Tool Calls, and Industrial Agents", Work in Progress, Internet-Draft, draft-das-hardware-enforced-execution-finality-02, September 2026, . [DAS-JURISDICTION] Das, S., "Authorized Here, Not Authorized There: Jurisdiction-Bound Execution Finality for Cross-Border and Sovereign Systems", Work in Progress, Internet-Draft, draft-das-jurisdiction-bound-execution-finality-00, September 2026, . [DAS-PATH] Das, S., "When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality", Work in Progress, Internet-Draft, draft-das-consequence-path-completeness- 00, September 2026, . [DAS-PROTOCOL] Das, S., "The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority", Work in Progress, Internet-Draft, draft-das-execution-finality-protocol- layer-01, September 2026, . Das Expires 20 March 2027 [Page 75] Internet-Draft Actuation-Bound Finality September 2026 [DAS-RATS] Das, S., "Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU, SmartNIC, and Confidential-Computing Infrastructure", Work in Progress, Internet-Draft, draft- das-rats-attestation-bnd-execution-finality-04, September 2026, . [DAS-REVOCATION] Das, S., "Revoked but Still Executable: Closing the Authorization-to-Effect Gap with Finality-Bound Revocation", Work in Progress, Internet-Draft, draft-das- finality-bound-revocation-00, September 2026, . [DAS-STATE] Das, S., "When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary", Work in Progress, Internet-Draft, draft-das-state-policy- continuity-finality-00, September 2026, . [DAS-THIRD-PARTY] Das, S., "When I Checked Is Not Proof: Verifiable Third- Party Decision Binding at the Execution-Finality Boundary", Work in Progress, Internet-Draft, draft-das- third-party-decision-binding-00, September 2026, . [GH-ARCH] Das, S., "Execution-Finality Architecture for Machine- Generated Acts", 2026, . [GH-HARDENED] Das, S., "Hardened Challenge-Bound Execution Finality for AI Interoperability", 2026, . [IEC61508] International Electrotechnical Commission, "IEC 61508 — Functional safety of electrical/electronic/programmable electronic safety-related systems", 2010, . Das Expires 20 March 2027 [Page 76] Internet-Draft Actuation-Bound Finality September 2026 [IEC61511] International Electrotechnical Commission, "IEC 61511-1:2016 — Functional safety — Safety instrumented systems for the process industry sector", 2016, . [IEC62443] International Electrotechnical Commission, "IEC 62443-4-2:2019 — Security for industrial automation and control systems — Technical security requirements for IACS components", 2019, . [OPCUA-SAFETY] OPC Foundation, "OPC Unified Architecture — Part 15: Safety", 2026, . [OPCUA-SAFETY-POLICY] OPC Foundation, "OPC UA Safety — Safety Policy", 2026, . [RFC7252] IETF, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, . [RFC9200] IETF, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, August 2022, . [RFC9334] IETF, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . [ROCKWELL-GUARDLOGIX] Rockwell Automation, "CompactLogix 5380 and Compact GuardLogix 5380 Controllers User Manual", March 2025, . [SCHNEIDER-M580] Schneider Electric, "Modicon M580 Safety, System Guide", July 2026, . [SIEMENS-SAFETY] Siemens, "SIMATIC Safety Integrated — Fail-Safe S7 Controller Application Example", 2025, Das Expires 20 March 2027 [Page 77] Internet-Draft Actuation-Bound Finality September 2026 . [SOKOLOV-AEP] Sokolov, A., "Composing Application-Layer Action Evidence with Remote Attestation Procedures", Work in Progress, Internet-Draft, draft-sokolov-rats-aep-composition-05, August 2026, . Author's Address Sangam Das Independent Balasore Odisha India Phone: +91-9861363532 Email: info@sangamdas.com Das Expires 20 March 2027 [Page 78]