Internet-Draft Reality as a Cryptographic Dependency October 2026
Das Expires 4 April 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-das-safety-first-execution-finality-00
Published:
Intended Status:
Experimental
Expires:
Author:
S. Das
Independent Researcher

A Permit to Effect Once Is Not a Permit to Effect Permanently: Reality as a Cryptographic Dependency for AI Machines, Frontier AI Model Providers, and Critical Systems

Abstract

A permit to effect once is not a permit to effect permanently. An approval, a policy decision, or one successful effect is not standing authority for a larger or repeated one. For AI machines and frontier AI models that can now act in the world, this separates a contained mistake from an irreversible one.

Today, security checks who is asking, inspects a token, opens the gate, and hopes that the downstream network path, destination, or physical machine is safe. AI agents now send messages and files, move money, change production infrastructure, invoke tools, update model and memory state, release sensitive data, and drive vehicles, robots, and industrial equipment. Approval can show that an action was allowed in principle without showing that the exact action reaches the right recipient, device, or outcome. Simulations and dry-runs do not close this gap, because a simulation can pass in a clean sandbox while the real target, route, or actuator has been hijacked. Logs do not close it either, because a log explains a disaster after it has happened.

This document makes reality a cryptographic dependency. The full-consequence command is held in a state that cannot execute. First, a deliberately bounded real effect is produced on the exact operational path: a trailing capsule, one record, a payment hold, a canary deployment, a constrained session, or a millimetre of actuator movement. The destination, transaction system, network element, sensor, or hardware controller then returns an Effect Confirmation Receipt. An Interim Effectuation Validator validates that receipt out of band against the intended act, nonces, epoch, scope, destination, current policy, and revocation state. Only then does it issue the continuation instruction that reconstructs the key, releases the split credential, or unlocks the hardware register for the next phase. Without the receipt, the key for full effect does not exist on the machine. Evidence is therefore a structural dependency and not a log.

Two properties are central. First, the validator never relays the original command: the micro-effect proceeds independently and the validator observes the proof from a distance, so compromising an inline proxy or manipulating routing through prompt injection does not hand over the keys. Second, uncertainty is a first-class state. If a micro-effect fires but trustworthy evidence is missing, the system quarantines and refuses progression instead of retrying, so an autonomous loop cannot compound a duplicate transfer, a double commit, or an over-actuation. These properties hold under stated assumptions, including receipt integrity, path completeness, and atomic consumption of continuation authority, which the document identifies.

The architecture covers single-phase and multi-phase execution; human, automatic, hybrid, threshold, and hardware-rooted approval; anti-replay and anti-substitution controls; alternate-path closure; reconciliation of indeterminate outcomes; and rollback, compensation, and safe-state handling. It consolidates thirty-five workflow profiles across communications, files, payments, databases, cloud and model deployment, AI tool invocation, data export, robotics, vehicles, UAVs, industrial control, radio and satellite systems, GPU and accelerator egress, and software and firmware activation. The Safety-First Critical-System Profile applies where avoiding catastrophic or hard-to-reverse outcomes comes before minimum latency: a deployment MUST NOT remove a validation, receipt, anti-replay, or safe-state protection merely to be faster, when protected policy classifies it as necessary for the consequence class.

Authority in the era of autonomous machines cannot be granted session-wide. It is earned progressively from the real pathway, one bounded step at a time.

Patent pending: the concept described in this document is the subject of Indian Patent Office application number 202631117633, "Systems and Methods for Cryptographically Staged Effectuation with Verified Partial Effect, Receipt-Bound Full Effectuation, and Software-Hardware Enforcement".

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 4 April 2027.

▲

Table of Contents

1. Introduction

AI and autonomous software increasingly performs work whose outputs are no longer merely advisory. A generated decision can become a message sent to a third party, a transfer of money, a database commit, a cloud deployment, a credential use, a data export, a vehicle command, a radio transmission, a model-state mutation, or another externally consequential effect. For these operations, the architectural question is not only whether a computation was allowed to run, but whether the exact requested consequence should be permitted to become effective at the point where it can no longer be treated as a proposal.

This document defines execution finality as protected control over the transition from a proposed or partially authorized act to an externally consequential effect. It consolidates thirty-five workflow profiles into a common architecture that can be implemented in software, firmware, hardware, networks, transaction systems, storage systems, cryptographic modules, or mixed protected domains.

The architecture is especially intended for sensitive work and high-consequence environments where an incorrect full effect may be catastrophic or difficult to reverse. It therefore supports bounded real trials, progressive scopes, protected evidence, receipt-conditioned continuation, conservative handling of unknown outcomes, and alternate-path closure.

1.1. Design Principle: Computation Is Not Effectuation Authority

Generating, predicting, recommending, or preparing an act does not by itself make the act final. A proposing model, agent, application, or workflow may possess extensive computational capability while a protected effectuation boundary retains authority over whether the requested consequence becomes externally effective.

Proposal(A) != EffectuationAuthority(A)

For staged execution:

  BoundedAuthority(P_0) != Authority(FullEffect)

A later phase is technically dependent on protected confirmation of an earlier phase.
Figure 1: Core authority separation

1.2. Scope

  • AI-agent and autonomous-system actions that can cause external effects.

  • Critical-system operations where failure, misdirection, or unauthorized progression can cause substantial safety, security, financial, operational, or physical consequences.

  • Single-phase protected finality and multi-phase receipt-gated effectuation.

  • Human, automatic, hybrid, and multi-authority decision paths.

  • Software-only, hardware-rooted, split, distributed, and destination-side enforcement.

  • Negative, partial, conflicting, or indeterminate effect evidence and reconciliation.

1.3. Non-Goals

This document does not define one mandatory transport protocol, cryptographic algorithm, operating system, payment rail, cloud provider, messaging protocol, vehicle bus, radio stack, database technology, or hardware vendor. It defines protected causal and state-transition properties that may be realized by different mechanisms.

The document also does not claim that every operation should be staged. E01 explicitly permits single-phase protected effectuation when protected policy determines that staging is unnecessary. The safety-first profile concerns the handling of high-consequence cases in which additional validation is justified by the consequence model.

2. Consolidated Technical Source Set and Industry Map

This revision consolidates the complete E01-E35 workflow family together with the Interim Effectuation Validator (IEV) materials and the topology-independent / alternative-authority closure material. The purpose of this section is to give an industry reader a fast map of what each source family contributes before entering the normative architecture and detailed appendices.

2.1. Twelve E01-E35 Workflow Documents

Table 1: Source document map
Profiles Source focus Industry interpretation
E01-E03 Single-Phase, Demonstration-Then-Full, and Progressive Effectuation Defines the baseline: a protected one-phase act when staging is unnecessary; a real bounded demonstration followed by receipt-gated full effectuation; and a multi-phase progression in which each new consequence depends on evidence from the preceding real phase.
E04-E06 Protected Human, Automatic, and Hybrid Continuation Shows how receipt-gated effectuation can be governed by protected human approval, machine policy, or a conjunction/disjunction of human and automatic authority. Human approval can occur after the reviewer sees evidence of a real bounded effect rather than only a prediction.
E07-E09 Software, Hardware, and Split Protected Enforcement Domains Maps the same control invariant into software services and kernels, hardware roots and latches, or split software/hardware systems. It covers caller attribution, late credential injection, egress gates, kernel hooks, durable state, attestation, and hardware-protected authority.
E10-E12 Receipt-Conditioned Key Chains, Threshold Continuation, and Message SEND Adds cryptographic key progression, multi-party or threshold authority, and a practical communication pattern in which a real trailer or bounded object reaches the actual recipient path before the full message or semantic payload is released.
E13-E15 File Transfer, Payment Demonstration, and Conditional Settlement Applies the architecture to files/data objects, bounded payment or hold operations before broader transfer, and escrow/conditional settlement where value, assets, keys, or authority remain in a controlled holding state until required evidence is satisfied.
E16-E18 Database Commit, Cloud Deployment, and AI Model Deployment Covers provisional database persistence and promotion, staged infrastructure rollout, and progressive model deployment or activation. The common theme is that production scope grows only after protected evidence from a smaller real production effect is accepted.
E19-E21 AI Tool Use, Progressive Credential Release, and Data Export Separates a tool proposal from invocation authority, supports phase-specific or withheld credentials, and progressively releases sensitive data or semantic access only after destination- or effect-derived evidence passes protected checks.
E22-E24 Storage, Robotics, and Sensor-Confirmed Hardware Actuation Covers provisional storage and visibility, progressive robot actions, and hardware motion or actuation confirmed by protected sensors. Physical response can be measured before a larger actuator envelope is unlocked.
E25-E27 Vehicles, UAVs / Mobile Robots, and Industrial Control Extends staged authority to vehicular motion, drones/mobile robots, PLCs, machines, and industrial processes. Safe-state sets, route/speed/steering or process envelopes, device identity, sensor evidence, and crash/indeterminate behavior are treated as protected state.
E28-E30 Telecom, Radio / Satellite / NTN, and GPU / Accelerator Egress Applies receipt-gated continuation to live network effects, radio or satellite/NTN actions, and accelerator/compute egress. It covers progressive traffic, route/service-chain checks, low-latency local enforcement, hardware roots, and protected evidence from network or accelerator boundaries.
E31-E33 Model-State Update, Software/Firmware Activation, and Multi-Destination Effectuation Treats persistent AI memory/model-state mutation, software or firmware activation, and operations spanning multiple recipients, sinks, or destinations as consequential effects that can be provisionally applied, evaluated, and then promoted under protected continuation.
E34-E35 Replicated / Quorum / Consensus Confirmation and Failure / Conflict Recovery Covers replicas, weighted or role-constrained quorum, commit certificates, split-brain and Byzantine conditions, plus negative receipts, partial effects, conflicting authentic evidence, reconciliation, crash recovery, and no-blind-retry behavior.

2.2. IEV Technical Family

The IEV material adds a protected inter-phase judgment layer. Rather than treating a receipt as self-authorizing, an IEV independently evaluates evidence from an earlier real effect and establishes the technically required condition for the next phase. This separates receipt existence from continuation authority.

  • Core IEV / Three-Part document: defines the IEV, evidence intake, independent validation, expected-versus-observed comparison, continuation validation instruction (CVI), multi-phase repetition, human escalation, automatic remediation, reconciliation, crash recovery, replay protection, anti-bypass, and pseudocode.

  • Software / VM / OS document: shows that the validator can be an isolated VM, microVM, daemon, privileged OS service, Android or iOS-associated protected service, Windows service, enclave, remote validator, app/backend combination, or distributed validator set. Changing validator placement does not change the causal sequence if protected validation remains mandatory.

  • Taint / boundary-surrogation document: adds origin attribution, semantic/process/provenance taint, taint propagation, lower-trust execution domains, surrogate or credential-reference handling, just-in-time protected credential resolution at an effectuation boundary, privilege-separated connector workers, destination verification, classifier inputs, and IEV-gated continuation.

Canonical IEV relationship:

  E_i -> R_i -> IEV_i -> Gamma_(i+1) -> FS_(i+1) -> E_(i+1)

Where:
  E_i         = earlier real effect
  R_i         = protected effect evidence
  IEV_i       = protected independent interim validation
  Gamma_(i+1) = required continuation condition
  FS_(i+1)    = next Finality Sink / effect-capable boundary

Receipt existence != continuation authority
Figure 2: IEV causal position

2.3. Topology-Independent and Alternative-Authority Closure Source

The revised staged-effectuation specification adds T1-T12 alternative realizations so that the architecture is not artificially limited to a separate broker, explicit token, one process topology, or one authority direction. The closure material focuses on the technical condition that governs when a consequential effect may become effective, not on the name or physical placement of a component.

The closure set includes a monolithic protected executor, implicit protected state with no token, direct human-signed exact acts, human re-origination after AI recommendation, structural/object-capability authority, native transaction-state enforcement, risk-selective mediation, post-effect compensation as a separate fallback mode, formally verified or attested runtimes inside protected envelopes, destination-local finality, quorum/consensus-native effectuation, and pre-authorized finite action graphs.

3. Executive Summary of Workflow Profiles E01-E35

This section gives an industry-readable summary of each workflow profile. The detailed source-derived workflow text remains in Appendix A; this summary is intended to let reviewers understand the progression and deployment coverage without reading every subsection first.

3.1. E01 — Single-Phase Protected Effectuation

Single-phase protected effectuation. A Candidate Act is bound to protected authority and verified at the effect-capable boundary before the complete authorized effect occurs. It is the baseline for lower-risk or otherwise policy-approved cases where staged progression is unnecessary, while still preserving authority binding, sink-side verification, completion evidence, consumption, and anti-bypass.

3.2. E02 — Real Bounded Demonstration Effect, Verified Receipt, Then Full Effectuation

Demonstration-then-full effectuation. The system performs a real bounded effect using the actual consequence-capable path, obtains protected confirmation evidence, and allows the broader/full effect only after that evidence is accepted. This differs from simulation because the first stage genuinely exercises the real path.

3.3. E03 — Real Demonstration Effect with Receipt-Gated Multi-Phase Progressive Effectuation

Multi-phase progressive effectuation. Consequence grows through a protected sequence such as small -> medium -> broader -> full, with a receipt and continuation decision between phases. Each phase remains inside a maximum authorized envelope and cannot be skipped when policy marks intermediate phases as mandatory.

3.4. E04 — Verified Demonstration Effect, Protected Human Approval, Then Broader or Full Effectuation

Protected human continuation after a verified real effect. A human can review machine-verifiable evidence of what actually happened in the bounded phase before approving broader effectuation. The resulting human approval can be bound to the act, evidence, scope, destination, and current protected state.

3.5. E05 — Verified Demonstration Effect, Automatic Protected Decision, Then Receipt-Gated Continuation

Automatic protected continuation. A machine policy engine evaluates authenticated receipts, risk, revocation, destination, device/sink state, and other protected predicates and can continue without contemporaneous human action when the configured conditions are satisfied.

3.6. E06 — Hybrid Human and Automatic Receipt-Gated Continuation

Hybrid continuation. Human authority and machine validation can be combined, sequenced, or thresholded. For example, automatic policy may allow an initial bounded phase while a human is required for the full consequence, or a human may authorize the envelope while machine evidence remains mandatory between phases.

3.7. E07 — Software Protected Enforcement Domain

Software Protected Enforcement Domain. Implements effectuation control in protected services, brokers, kernel-adjacent components, egress gates, database/storage gates, message brokers, or remote software services. It covers caller attribution, protected state, credential brokerage, late credential injection, and durable crash recovery.

3.8. E08 — Hardware Protected Enforcement Domain

Hardware Protected Enforcement Domain. Moves authority, state, keys, counters, latches, or effect gates into secure hardware or hardware-rooted components so ordinary software cannot directly mint or bypass full effect authority.

3.9. E09 — Split Software/Hardware Protected Enforcement Domain

Split software/hardware PED. Software performs flexible policy, orchestration, and act preparation while hardware retains critical keys, latches, attestation, monotonic state, or final enablement. Neither side alone necessarily possesses unrestricted completion authority.

3.10. E10 — Receipt-Conditioned Hardware Cryptographic Key-Chain Effectuation

Receipt-conditioned hardware cryptographic key chain. A hardware root or sealed secret derives/unseals later phase material only after protected evidence from the preceding real effect is accepted. The security property is receipt-dependent availability of later execution material, not a specific KDF.

3.11. E11 — Threshold / Multi-Party Cryptographic Continuation

Threshold or multi-party continuation. No single participant has sufficient authority for the broader effect; a required subset of shares, approvals, or protected participants must contribute. This supports separation of duties, cross-domain control, and quorum-like security.

3.12. E12 — Message-SEND Demonstration / Trailer-Then-Full Effectuation

Message-SEND demonstration. A real bounded trailer, verification object, or limited communication reaches the actual recipient path and produces a protected receipt before the full message, file, attachment, decryption key, or semantic payload is released.

3.13. E13 — Receipt-Gated File Transfer and Progressive File Release

File transfer and progressive release. A bounded fragment, manifest, object, redacted subset, ciphertext, or storage event exercises the actual file path. Verified evidence then permits additional bytes, decryption material, publication, import, or full semantic access.

3.14. E14 — Payment Demonstration and Receipt-Gated Full / Progressive Payment

Payment demonstration and progressive value transfer. A bounded financial state change -- such as a hold, reservation, capped transfer, verification credit, or partial settlement -- confirms the intended payee/rail/state before broader value transfer becomes available.

3.15. E15 — Escrow / Conditional Settlement and Receipt-Gated Release

Escrow and conditional settlement. Value, assets, keys, or authority enter a protected holding state and are later released, partially released, returned, or terminated only after the configured evidence and policy conditions are satisfied.

3.16. E16 — Receipt-Gated Database Commit, Provisional Persistence, and Promotion

Database provisional persistence and promotion. A candidate mutation is applied to a bounded or provisional target, observed/read back, and promoted to authoritative or broader production state only after protected persistence evidence passes validation.

3.17. E17 — Receipt-Gated Cloud Deployment and Progressive Infrastructure Rollout

Cloud deployment and progressive infrastructure rollout. A change can begin with one resource, tenant, zone, region, shard, or canary production unit. Health/effect evidence controls whether the deployment expands, pauses, rolls back, or terminates.

3.18. E18 — Receipt-Gated AI Model Deployment, Model Activation, and Progressive Consequence Release

AI model deployment and activation. A model, adapter, inference service, or model-related production change is activated within a bounded scope before broader release. Receipts and health/safety conditions govern progressive exposure and can stop rollout when evidence diverges.

3.19. E19 — Receipt-Gated Tool Use and External Action Invocation

AI tool-use effectuation. Tool selection or tool_use output is treated as a proposal, not invocation authority. The selected tool, operation schema, arguments, account, destination, and effect class can be bound to protected authority, with bounded real tool effects preceding broader invocation.

3.20. E20 — Progressive Credential Release and Receipt-Gated Authority Expansion

Progressive credential release. Credentials, key shares, scoped tokens, or credential-use authority can grow only as protected evidence permits. The agent need not possess the unrestricted secret, and later credential scope can be withheld, unsealed, substituted, or activated at a protected boundary.

3.21. E21 — Receipt-Gated Data Export, Progressive Disclosure, and Cryptographic Release

Receipt-gated data export. Sensitive data can be progressively disclosed, encrypted, or semantically released. Destination commitment, policy, provenance, and receipt state can become prerequisites to releasing additional data or the key that makes previously delivered ciphertext usable.

3.22. E22 — Receipt-Gated Storage Release, Provisional Persistence, and Progressive Visibility

Storage release and progressive visibility. Data may first enter provisional persistence or limited visibility. Storage-controller or durable-state evidence then controls replication, namespace promotion, destructive overwrite, wider visibility, or key release.

3.23. E23 — Receipt-Gated Robotic Actuation and Progressive Physical Effectuation

Robotic actuation. A robot can execute bounded movement or interaction and return protected evidence before larger movement, force, duration, workspace, or task authority is enabled. The same pattern supports human, automatic, or hybrid progression.

3.24. E24 — Hardware Actuator, Protected Sensor Confirmation, and Receipt-Derived Motion Authority

Sensor-confirmed hardware actuation. A protected sensor, encoder, current/pressure/position sensor, or safety controller measures the real physical result of a bounded command. Later motion authority depends on that measured result rather than only on command dispatch.

3.25. E25 — Receipt-Gated Vehicle Effectuation and Progressive Vehicular Authority

Vehicle effectuation. Route, speed, steering, braking, control-transfer, and other vehicular authority can be progressively bounded. Protected vehicle state, safe-state sets, sensor evidence, device identity, phase keys, and dynamic environment changes determine whether authority expands.

3.26. E26 — Receipt-Gated UAV and Mobile-Robot Effectuation

UAV and mobile-robot effectuation. Flight, navigation, speed, altitude, geofence, payload, mission, or mobile-robot action can proceed through bounded real phases with protected telemetry and state confirmation before broader mission authority is available.

3.27. E27 — Receipt-Gated Industrial, PLC, Machine, and Process-Control Effectuation

Industrial and PLC/process control. Machine, valve, motor, process setpoint, production-line, or plant action can be constrained to bounded steps, with sensor/PLC/controller evidence required before a larger or more irreversible process transition.

3.28. E28 — Receipt-Gated Telecom Effectuation and Progressive Network Authority

Telecom effectuation. Live network actions -- subscriber rollout, traffic steering, service-chain changes, session establishment, slice/service-class changes, edge operations, or network-control actions -- can start in bounded scope and expand only after protected network evidence and policy checks.

3.29. E29 — Receipt-Gated Radio, Satellite, and Non-Terrestrial Network Effectuation

Radio, satellite, and non-terrestrial network effectuation. RF transmission, satellite/NTN actions, spectrum/resource use, links, beams, routes, or session scope can be bounded and progressively expanded under protected radio/network evidence and local safety or policy constraints.

3.30. E30 — Receipt-Gated GPU, Accelerator, and Compute-Egress Effectuation

GPU, accelerator, and compute-egress effectuation. Accelerator jobs, model outputs, tensor/data egress, device memory effects, or compute-to-external-action paths can be gated at GPU/accelerator/driver/DPU boundaries, with protected evidence controlling larger or externally visible effects.

3.31. E31 — Receipt-Gated Model-State Update, Protected Memory Commit, and Progressive Model-State Effectuation

Model-state and protected-memory update. Persistent memory, vector-store state, parameters, adapters, policy state, or other model-associated state can be written provisionally and evaluated before promotion to authoritative state. The model must not self-authorize broader state mutation merely by writing its own control data.

3.32. E32 — Receipt-Gated Software, Firmware, and Configuration Update with Progressive Activation

Software, firmware, and configuration update. Update rollout can use staged activation, measured health, rollback preservation, device cohorts, version binding, and receipt-gated promotion so a bad update does not immediately become universal.

3.33. E33 — Multi-Destination, Multi-Recipient, Multi-Sink, and Distributed Receipt-Gated Effectuation

Multi-destination, multi-recipient, and multi-sink effectuation. One Candidate Act can span several targets while preserving target-specific receipts, partial success semantics, aggregate continuation conditions, and rules for whether all, some, or a defined subset must succeed.

3.34. E34 — Replicated, Quorum-Confirmed, and Consensus Receipt-Gated Effectuation

Replicated, quorum-confirmed, and consensus receipt-gated effectuation. Multiple replicas or validators contribute evidence or votes; weighted/role-constrained quorum, membership/version binding, split-brain detection, critical replica requirements, Byzantine handling, and commit certificates govern broader effectuation.

3.35. E35 — Negative, Indeterminate, Conflict, Reconciliation, and Recovery Receipt-Gated Effectuation

Negative, indeterminate, conflict, reconciliation, and recovery. The architecture distinguishes proven effect, proven non-effect, partial effect, conflicting evidence, and still-indeterminate outcomes. It blocks blind retry, supports evidence re-query and reconciliation, and only resumes progression when a protected recovery rule establishes an acceptable state.

4. Detailed Interim Effectuation Validator (IEV) Integration Summary

The IEV is a protected logical or physical validation function placed in the causal path between evidence of one real effect and authority for a later effect. It does not have to relay the original command and does not have to be a physically separate device. Its defining property is that later effectuation is made technically dependent on its protected evaluation of authenticated evidence from the preceding phase.

A -> FS_0 -> E_0 -> R_0 -> IEV_0 -> Gamma_1 -> FS_1 -> E_1
                                      |
                                      +-- on mismatch -> HOLD / RECONCILE /
                                          REDUCE / REMEDIATE / HUMAN /
                                          SAFE_STATE / TERMINATE
Figure 3: IEV operational position

4.1. Evidence Intake and Independent Decision

The IEV receives an Interim Validation Input Record or equivalent authenticated evidence that can bind the Candidate Act, phase, prior authority, expected and observed effect, sink, destination, observer, resource, transaction identifier, nonce, counter, policy epoch, result code, receipt digest, and time. It then determines whether the earlier effect occurred at the expected place, through an authorized boundary, with an acceptable result and sufficiently current protected state.

IEVPass_i =
    AuthValid(R_i)
    AND ActMatch(R_i, D_A)
    AND PhaseMatch(R_i, i)
    AND SinkMatch(R_i, FS_i)
    AND DestinationMatch(R_i)
    AND Fresh(R_i)
    AND NOT Consumed(R_i)
    AND EffectAcceptable(O_i, X_i)
    AND PolicyCurrent
    AND RevocationClear
    AND WithinEnvelope(P_(i+1))
Figure 4: Illustrative IEV acceptance predicate

4.2. Continuation Condition and Cryptographic Missing Material

On PASS, the IEV can create a Continuation Validation Instruction, protected state transition, key or key share, secure-mailbox entry, hardware latch, transaction role, database state, network permit, actuator enablement, or another protected condition. A stronger implementation makes the next phase cryptographically incomplete without an IEV-controlled secret or share derived from the accepted receipt.

CVI_(i+1) = Protect_KIEV(
    D_A || H(R_i) || (i+1) || Scope_(i+1) ||
    FS_(i+1) || Destination_(i+1) || PolicyEpoch || Counter || Expiry)

Optional receipt-derived material:
K_(i+1) = KDF(K_IEV_root, D_A, H(R_i), i+1, FS_(i+1), Counter)

Optional split authority:
K_final_(i+1) = Combine(K_FS_(i+1), K_IEV_(i+1))
Figure 5: Receipt-bound continuation examples

4.3. Validator Placement and Substitution Invariance

The IEV may be a protected process, daemon, kernel-adjacent service, VM, microVM, hypervisor service, Android or iOS-associated protected component, Windows service, TEE/enclave, HSM, DPU/SmartNIC, modem/baseband security processor, storage or transaction controller, remote service, destination-side service, or distributed validator set. Moving the validator changes topology and assurance assumptions, but it does not change the functional sequence so long as the next protected effect still depends on validated evidence from the earlier real effect.

ValidatorLocation != ValidatorFunction
ChangeOfValidator != ChangeOfFunctionalSequence

For conforming realization v:
  E_i -> R_i -> V_i^(v) -> Gamma_(i+1)^(v) -> FS_(i+1) -> E_(i+1)
Figure 6: Validator-substitution invariant

4.4. Taint, Origin Attribution, and Boundary Credential Surrogation

A lower-trust agent or application can be isolated from the protected credential and effectuation domain. The protected boundary may attribute a request to its originating process, track semantic/process/provenance taint, and require a non-authoritative surrogate credential, handle, alias, or reference. Only after protected checks does the boundary resolve or use the real credential. The real secret need not be exposed to the agent.

tau_out = Join(tau_process, tau_input_1, ..., tau_input_n)

UnableToValidateTaint => UNVERIFIABLE

sigma_i != K_real_i
K_real_i not in Memory(D_A_domain)

Boundary resolution:
  sigma_i --[origin + taint + policy + destination + scope checks]--> use(K_real_i)

For a later phase:
  SurrogateValid AND ContinuationValid(Gamma_(i+1))
  AND PolicyCurrent AND RevocationClear AND TaintAcceptable
      -> boundary may use real credential
Figure 7: Taint and protected credential boundary

4.5. Failure, Remediation, and Human Escalation

A mismatch is not automatically converted into a retry or full continuation. The IEV can enter reconciliation, request stronger evidence, authorize a bounded diagnostic or reduced-scope phase, invoke automatic remediation, request protected human review, quarantine the operation, compensate or roll back where appropriate, or terminate. Human approval is preferably returned through a protected channel and bound to the observed evidence and requested continuation scope rather than treated as unrestricted authority handed to the proposing agent.

5. Detailed Design-Around / Implementation-Equivalence Closure (T1-T12)

This section restates the topology-independent and alternative-authority realizations as implementation-equivalence closures. The intent is to make clear that the execution-finality property is defined by protected control of consequential state transitions, not by a requirement for one named broker, one token, one direction of authority flow, or physical separation between components.

5.1. T1 — Monolithic Protected Executor

A single protected executor may identify the act, evaluate policy, choose and perform a bounded effect, observe the result, advance protected state, and perform the broader effect. No visible PED-to-token-to-sink chain is required. The non-skippable protected predecessor state is the controlling property.

PROPOSED -> VALIDATED -> PARTIAL_EFFECT -> CONFIRMED -> FULL_EFFECT
Figure 8: T1 — Monolithic Protected Executor

5.2. T2 — Implicit-State / No-Token Authority

Continuation authority may exist only as protected internal state rather than as a transferable capability or token. An atomic state bit, database state, transaction role, register, latch, counter, secure-monitor state, consensus state, or commit-time predicate can be sufficient.

EnableFull := (ProtectedState == CONFIRMED) AND PolicyCurrent AND RevocationClear
Figure 9: T2 — Implicit-State / No-Token Authority

5.3. T3 — Direct Human-Signed Exact Act

A protected human authenticator may sign the exact consequential act or authorized envelope. The destination or effect boundary verifies the signature and act binding directly. In a staged version, the human can sign continuation after reviewing receipt-bound evidence from the earlier real effect.

HumanAuthenticator -> ExactActSignature -> SinkVerification -> Effect
Figure 10: T3 — Direct Human-Signed Exact Act

5.4. T4 — Human Re-Originated Operation After AI Recommendation

The AI can be technically incapable of executing the consequence. It provides a recommendation or non-authoritative descriptor; a human then uses a separate trusted application to originate a new act. The resulting human-originated act can still use single-phase or receipt-gated finality.

5.5. T5 — Structural Capability / Object-Capability / Typed Authority

Authority can be encoded structurally in object capabilities, typed tool/resource handles, language-level effect types, memory-safe capabilities, namespace-limited descriptors, kernel-enforced handles, or hardware protection domains. Receipt validation can expand, replace, narrow, or revoke the authority graph without creating a bearer finality token.

AuthorityGraph_i + ValidReceipt_i -> ProtectedTransition -> AuthorityGraph_(i+1)
Figure 11: T5 — Structural Capability / Object-Capability / Typed Authority

5.6. T6 — Native Transactional Invariant / Commit-State Enforcement

A database, payment service, message system, cloud control plane, storage engine, tool service, or other transactional destination can embed the staged condition directly into its native state machine. An external Finality Sink process is unnecessary if the transaction engine itself refuses invalid state transitions.

PROVISIONAL -> OBSERVED/VERIFIED -> COMMITTABLE -> COMMITTED
Figure 12: T6 — Native Transactional Invariant / Commit-State Enforcement

5.7. T7 — Risk-Selective or Consequence-Selective Mediation

Not every operation must be staged. Protected policy can classify lower-consequence, reversible, pre-authorized, or structurally bounded acts for direct execution while routing high-value, novel-destination, tainted, irreversible, safety-critical, or otherwise selected acts through staged finality.

Classify(Act) -> {DIRECT_WITHIN_ENVELOPE | STAGED_EFFECTUATION | DENY}
Figure 13: T7 — Risk-Selective or Consequence-Selective Mediation

5.8. T8 — Post-Effect Compensation as Ancillary or Fallback

Where pre-effect staging is unavailable or explicitly waived within policy, an authorized effect may occur first and protected post-effect evidence may trigger compensation, rollback, retraction, quarantine, or other remediation. This mode is not treated as equivalent to required pre-effect receipt-gated continuation and must not silently downgrade a class that policy marks as requiring staging.

5.9. T9 — Formally Verified / Attested / Deterministic Runtime Within a Protected Envelope

A measured, formally verified, deterministic, secure-booted, or policy-restricted runtime can be granted a pre-authorized bounded envelope wider than an ordinary probabilistic agent. Changed destination, taint, revocation, policy, environment, or higher-consequence operations can still force staged validation or renewed human approval.

5.10. T10 — Native Destination Policy and Destination-Local Finality

The destination can combine policy evaluation, exact-act verification, effect gating, receipt generation, and final commitment. It may perform the bounded first effect and advance its own protected state before allowing broader effect, or return a signed receipt that unlocks upstream authority.

5.11. T11 — Replicated / Quorum / Consensus-Native Effectuation

Multiple replicas, validators, observers, controllers, or organizations can jointly establish confirmation and continuation. The controlling state may be a quorum certificate, threshold signature, replicated log entry, consensus commit index, or fault-tolerant transition; a separate per-sink receipt token is optional.

ValidVotesOrReceipts >= RequiredQuorum -> CommitCertificate/ConfirmedState -> BroaderEffect
Figure 14: T11 — Replicated / Quorum / Consensus-Native Effectuation

5.12. T12 — Pre-Authorized Finite Action Machine / Bounded Action Graph

A protected principal can authorize a finite or bounded graph of states and transitions before autonomous operation begins. The agent may choose only protected authorized edges from the current state. Receipts can unlock later edges, consume one-time edges, move the protected state pointer, or reduce the remaining graph.

G = (V,E); E_authorized is a protected subset of E
Figure 15: T12 — Pre-Authorized Finite Action Machine / Bounded Action Graph

5.13. Cross-Cutting Closure Rule

T1-T12 may be combined. A monolithic destination can use no transferable token, enforce continuation as native transaction state, accept a direct human exact-act signature, operate within a pre-authorized action graph, and rely on quorum replication. Conversely, a structural-capability operating system can expose only bounded objects until destination-local evidence or consensus state unlocks broader objects. The number of components, token format, direction of authority flow, and physical placement are therefore implementation choices when the selected mode preserves its protected predecessor and continuation conditions.

Implementation substitution does not change the protected causal invariant:

  RealEffect_i
      -> ProtectedEvidence_i
      -> ProtectedValidation_i
      -> RequiredContinuationCondition_(i+1)
      -> EffectCapableBoundary_(i+1)
      -> RealEffect_(i+1)

Examples of equivalent realization changes:
  separate broker      -> monolithic executor
  explicit CVI/token   -> protected state / latch / transaction role
  local validator      -> remote / destination / quorum validator
  software gate        -> kernel / TEE / HSM / DPU / controller gate
  bearer credential    -> handle / alias / non-exportable credential use
  one sink receipt     -> quorum certificate / consensus state
  universal staging    -> consequence-selective protected staging
Figure 16: Implementation-equivalence closure

6. Internet-Draft Integration Summary

The consolidated Internet-Draft is organized so that an implementer can first understand the common safety and execution-finality invariants, then select a workflow profile, then choose an IEV and enforcement realization appropriate to the platform, and finally apply topology-independent closure rules so an alternate implementation path does not accidentally bypass the selected security property.

  1. Select the consequence class and maximum authorized envelope.

  2. Select single-phase protected effectuation or a staged E01-E35 profile.

  3. Bind the Candidate Act and protected state needed by the selected profile.

  4. Choose one or more effect-capable Finality Sinks and protected evidence sources.

  5. Where inter-phase independent judgment is required, insert an IEV or equivalent protected interim-validation function.

  6. Choose continuation representation: explicit instruction, key/share, protected state, transaction state, hardware latch, structural capability, destination-local state, quorum certificate, or another protected realization.

  7. Apply anti-replay, anti-substitution, crash/indeterminate, and alternate-path closure requirements.

  8. For critical-system use, apply the Safety-First Critical-System Profile so mandatory protections cannot be removed solely to reduce latency.

This structure is intentionally implementation-neutral: the protocol-level property is the protected causal dependency between authority, real effect, evidence, validation, and subsequent effectuation. Product names, component count, process topology, and one specific cryptographic primitive are not part of the functional definition unless a selected deployment profile makes them mandatory.

7. 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 when, and only when, they appear in all capitals.

The workflow profiles in Appendix A include source-derived implementation detail. Unless a profile explicitly states that a property is required for the selected profile, examples of components, algorithms, products, physical placement, and mechanism names are non-limiting implementation choices.

BCP 14 comprises [RFC2119] and [RFC8174].

8. Terminology and Formal Notation

Candidate Act (A)
A proposed operation whose consequence may become externally effective.
Canonical Act (A_C)
A deterministic or otherwise stable representation of A used for binding.
Act Digest (D_A)
A protected identifier, for example D_A = H(Canon(A)).
Protected Enforcement Domain (PED)
A protected software, firmware, hardware, network, transaction, or mixed domain that evaluates or enforces effectuation conditions.
Finality Sink (FS_i)
The effect-capable boundary that can make phase i consequential.
Phase (P_i)
A single protected effectuation stage in a staged plan.
Bounded Trial Effect (BTE)
A real, limited effect used before broader effectuation; it is not merely a simulation or prediction.
Observed Effect (O_i)
The protected observation of what actually occurred in phase i.
Expected Effect (X_i)
The result or property set expected for phase i.
Effect Confirmation Receipt (R_i or ECR)
Machine-verifiable evidence describing a real phase effect, its binding, and relevant protected state.
Continuation Authority (Gamma_{i+1})
Any protected capability, key, key share, latch, permit, transaction state, credential state, signed instruction, or equivalent condition required for phase i+1.
Maximum Effectuation Envelope (E_MAX)
The maximum cumulative consequence or scope authorized for the act.
Indeterminate State
A state in which the system cannot prove either that an effect occurred as required or that it did not occur.
Alternate-Path Closure
The requirement that an act-equivalent path cannot bypass a protected finality condition when that condition is mandatory. 
A_C = Canon(A)
D_A = H(A_C)

P_i     = protected real effectuation phase i
O_i     = observed result of phase i
X_i     = expected result of phase i
R_i     = protected receipt/evidence for phase i
Gamma_i = continuation condition for phase i

Scope(P_i) <= E_MAX
Figure 17: Normalized notation

9. Threat and Consequence Model

The architecture assumes that a proposing model or application may be mistaken, compromised, manipulated by untrusted input, operating on stale state, or correctly authorized at one point while external state changes before effectuation. It also assumes that a downstream component can fail, partially execute, route to an unexpected destination, return an ambiguous result, or expose an alternate path that bypasses an intended control.

10. Safety-First Critical-System Profile

This profile is intended for sensitive work and critical-system deployments in which safety and security are the primary optimization criteria and minimum latency is not. The profile does not require unnecessary delay. It requires that latency optimization remain subordinate to mandatory safety and finality conditions selected by policy.

Safety-first optimization (conceptual):

  1. Minimize risk of unauthorized, catastrophic, irreversible,
     or materially misdirected effect.
  2. Preserve the authorized mission and bounded operating envelope.
  3. Minimize latency subject to (1) and (2).

In shorthand:

  Safety / Effect Correctness / Containment  >  Minimum Latency

for deployments that select this profile.
Figure 18: Safety-first priority ordering

10.1. Mandatory Safety-First Properties

  • An UNKNOWN or INDETERMINATE result MUST NOT be interpreted as successful effectuation.

  • A timeout MUST NOT automatically increase authority or release a broader phase.

  • A required receipt or protected observation MUST NOT be replaced by a local success assertion from the proposing agent.

  • Where a later phase is receipt-gated, that phase MUST remain technically unavailable until its protected continuation predicate is satisfied.

  • Current revocation, policy, destination, and envelope conditions MUST be rechecked when the selected workflow requires effectuation-time freshness.

  • Unsafe or unresolved states SHOULD transition to a defined safe state, fail-limited state, reconciliation state, or protected human/automatic escalation path.

  • Required anti-replay and alternate-path controls MUST NOT be disabled solely to reduce latency.

10.2. Latency Reduction Without Safety Reduction

Latency-sensitive critical systems can preserve the safety model while reducing overhead. The workflow set explicitly allows local low-latency enforcement, hardware-rooted gates, split software/hardware designs, pre-authorized envelopes, automatic continuation, parallel or quorum evidence, protected counters, destination-local enforcement, and receipt-derived key material.

  • Place the Finality Sink and receipt verifier close to the effect-capable device or transaction engine.

  • Pre-authorize a bounded operating envelope so that safe phases can progress automatically without repeated human interaction.

  • Use protected hardware, secure elements, HSMs, TEEs, DPUs, SmartNICs, storage controllers, or local safety controllers for fast checks.

  • Collect independent evidence in parallel where policy permits.

  • Use phase sizes proportionate to consequence and confidence rather than a fixed small phase for every operation.

  • Use single-phase E01 when staging is not required by the consequence model.

11. Core Execution-Finality Architecture

11.1. Candidate Act Binding

A Candidate Act SHOULD be represented sufficiently precisely that a protected component can determine whether a later operation is the same authorized act, a permitted member of an authorized act class, or a materially different act. A canonical representation and digest are one implementation.

A_C = Canon(A)
D_A = H(A_C)

Authority(A) does not imply Authority(B)
for a materially different unauthorized B.
Figure 19: Act-binding relationship

11.2. Protected Validation and Effectuation Boundary

The PED evaluates the protected state applicable to the act. The Finality Sink performs local verification before making the operation externally consequential. The sink may be an API gateway, network egress gate, payment gateway, database commit engine, storage controller, message broker, kernel or syscall boundary, device controller, GPU or accelerator gate, DPU/SmartNIC, radio controller, secure monitor, or another effect-capable component.

11.3. Single-Phase Mode

In E01, protected policy may permit the complete authorized effect in one phase. Even in this mode, proposal and effectuation remain distinct, and the sink verifies the required authority and local protected state before the effect occurs. A completion receipt may be produced afterward.

Candidate Act
   -> Protected Validation
   -> Effectuation Authority
   -> Finality Sink
   -> Authorized Effect
   -> Completion Evidence
Figure 20: Single-phase flow

11.4. Staged Real Effectuation

In E02 and later staged workflows, the first phase is a real effect at the actual or policy-relevant effectuation path. It is not merely a dry run, simulation, prediction, or local preview. The first authority is deliberately bounded so that successful execution of P_0 does not by itself imply authority for the full consequence.

Candidate Act
   -> Phase-0 Authority C_0
   -> Finality Sink FS_0
   -> Real Bounded Effect P_0
   -> Observed Effect O_0
   -> Protected Receipt R_0
   -> Receipt Validation
   -> Continuation Authority Gamma_1
   -> Broader Effect P_1
Figure 21: Demonstration-then-continuation flow

11.5. Effect Observation and Receipt

A receipt MAY bind the act digest, phase identifier, observed result, sink, destination, device, route, transaction identifier, nonce, counter, time, policy epoch, revocation epoch, previous receipt digest, and other protected state. The receipt can be signed, MAC-protected, attested, sealed, hash-linked, ledger-anchored, threshold-protected, or represented by protected state in a transaction system or device.

R_i = Protect(
        D_A || Phase_i || O_i || Sink_i || Destination_i
        || Nonce_i || Counter_i || PolicyEpoch_i
        || H(R_{i-1}) )

H(R_{i-1}) is optional when another protected sequence-binding
mechanism provides equivalent phase ordering.
Figure 22: Illustrative receipt construction

11.6. Expected-vs-Observed Validation

Validation may use exact equality, tolerance, range, authorized-set membership, semantic equivalence, sensor predicates, transaction-state predicates, or a protected predicate set appropriate to the effect type.

Exact:       O_i = X_i
Tolerance:   d(O_i, X_i) <= epsilon_i
Range:       L_i <= O_i <= U_i
Set:         O_i in A_i
Predicate:   AND_k Q_{i,k}(O_i) = TRUE
Figure 23: Representative effect comparison models

11.7. Receipt-Gated Continuation

A valid receipt is evidence, not an unconditional command to proceed. Protected policy may additionally require current policy, revocation, risk, taint, destination, envelope, human approval, threshold, hardware, or other conditions. If any mandatory condition is FALSE, continuation is denied. If a mandatory condition is UNKNOWN or INDETERMINATE, the safety-first profile does not treat it as success.

Enable(P_{i+1}) =
    AuthValid(R_i)
    AND MatchAct(R_i, D_A)
    AND MatchPhase(R_i, i)
    AND Fresh(R_i)
    AND EffectAcceptable(O_i, X_i)
    AND PolicyCurrent
    AND RevocationClear
    AND WithinEnvelope(P_{i+1})
    AND ApprovalSatisfied_{i+1}

If any mandatory predicate is FALSE:
    Enable(P_{i+1}) = FALSE
Figure 24: General next-phase predicate

11.8. Multi-Phase Progression

E03 generalizes the architecture to any number of phases. Each successful phase can produce a new receipt and a phase-specific authority for the next phase. Phase authority SHOULD NOT be valid for a later or broader phase unless policy explicitly makes the phases equivalent.

P_0 -> R_0 -> Gamma_1 -> P_1 -> R_1 -> Gamma_2 -> ... -> P_n

Scope(P_i) <= E_MAX

Mandatory stages cannot be skipped:
    P_i  -/->  P_{i+2}
without the required receipt and continuation transition for P_{i+1}.
Figure 25: Progressive effectuation chain

11.9. Atomic State Advancement and Receipt Consumption

Where replay or double-use is unsafe, the protected controller SHOULD atomically consume the accepted receipt, advance the phase state, increment any protected counter, and establish the next continuation condition. The same receipt MUST NOT independently enable the same single-use progression twice.

ATOMIC {
    verify R_i
    assert R_i not consumed
    mark R_i consumed
    advance phase from i to i+1
    increment protected counter
    establish Gamma_(i+1)
    commit protected state
}
Figure 26: Illustrative atomic phase advancement

12. Approval and Decision Modes

12.1. Protected Human Continuation

A human may approve before any effect, after a verified bounded effect, between every phase, or only for selected consequence classes. When human approval is a required security predicate, the approval SHOULD be separately authenticated and bound to the relevant act, receipt, destination, scope, phase, expiry, and protected context. Text generated by the proposing agent is not itself proof that a protected human approval occurred.

12.2. Automatic Continuation

Automatic continuation may be used when protected machine-verifiable predicates succeed. This enables safety-first operation without requiring a human in every loop. Automatic progression may depend on receipt quality, destination confidence, risk, taint, policy epoch, revocation state, value limits, device state, route identity, and other protected evidence.

12.3. Hybrid and Multi-Authority Continuation

Hybrid workflows can require both automatic checks and human approval, or can vary by phase and consequence threshold. Threshold workflows can require m-of-n cryptographic or role-constrained contributions so that no single participant possesses sufficient authority for the broader effect.

Hybrid example:
    Continue = AutoPass AND HumanPass

Threshold example:
    Continue = (sum_j ValidShare_j >= m)
               AND RequiredRolesPresent
Figure 27: Hybrid and threshold predicates

13. Protected Enforcement Domains

13.1. Software PED

E07 places protected validation and effectuation control in software. Example mechanisms include privilege-separated services, operating-system identities, kernel or syscall gates, network proxies, database and storage gates, message brokers, transaction managers, eBPF/security hooks, mandatory-access-control systems, remote services, and software attestation. The security property is functional: the proposing process cannot directly obtain or exercise the protected authority required for an unauthorized effect.

13.2. Hardware PED

E08 places protected state or effectuation control in hardware, including secure elements, HSMs, TEEs, secure enclaves, security processors, DPUs, SmartNICs, storage controllers, GPU/accelerator security components, or hardware latches and counters. Hardware may retain non-exportable authority material and release or use it only after required protected conditions are satisfied.

13.3. Split Software/Hardware PED

E09 divides functions between software and hardware. Software may perform higher-level policy and act interpretation while hardware protects keys, counters, latches, effectuation material, or final sink enforcement. A split-key or split-state design can require both domains for a later phase.

14. Cryptographic and Distributed Continuation

14.1. Receipt-Conditioned Key Chains

E10 permits later-phase authority to be derived, unsealed, activated, or made usable only after a preceding receipt is accepted. The important property is causal dependence, not a specific KDF.

K_(i+1) = KDF(K_root, D_A, H(R_i), i+1, Sink_(i+1), Counter)

If R_i is not accepted, K_(i+1) remains unavailable, sealed,
incomplete, or invalid.
Figure 28: Receipt-conditioned key derivation

14.2. Threshold Continuation

E11 distributes continuation authority across multiple participants or protected domains. A later phase can require a threshold signature, key-share combination, quorum certificate, or other multi-party protected condition.

14.3. Replicated and Quorum-Confirmed Effectuation

E34 applies receipt gating to replicated and consensus-oriented effects. Replica-specific receipts may be aggregated under simple quorum, weighted quorum, role-constrained quorum, or consensus rules. Membership version, state version, fencing epoch, split-brain state, lag, critical-replica requirements, and conflicting aggregate certificates may affect whether continuation is permitted.

Simple quorum:
    sum_j Valid(R_i^j) >= m

Weighted quorum:
    sum_j w_j * Valid(R_i^j) >= theta

Safety extension:
    QuorumSatisfied AND NoCriticalContradiction
Figure 29: Quorum examples

15. Sensitive-Work Workflow Families

The following workflow families apply the same protected-effectuation model to sensitive or consequential work. Detailed source-derived workflow text appears in Appendix A.

Communications and SEND
E12 provides a trailer-then-full pattern in which a bounded object reaches the actual receiving path before the full message, file, attachment, or semantic payload becomes available.
File Release
E13 stages file transfer, storage, recipient-path verification, decryption, or visibility before broader semantic release.
Payments and Conditional Settlement
E14 and E15 cover bounded payment-rail effects, reservations, partial settlements, escrow or conditional holding, followed by evidence-gated release.
Database and Storage
E16 and E22 use provisional persistence or visibility, protected receipts, and promotion to authoritative or broader state.
Cloud and Model Deployment
E17 and E18 stage infrastructure rollout and AI model activation so that a bounded production effect can be observed before broader consequence.
AI Tool Use
E19 treats tool proposal as distinct from invocation authority and supports bounded real tool interaction, tool identity binding, schema validation, receipt consumption, and alternate-tool-path closure.
Credential Release
E20 progressively expands credential authority while withholding unrestricted credential material from the proposing agent where required.
Data Export
E21 stages disclosure by chunk, field, record, ciphertext, or key release and can bind progression to destination handling-state evidence.
Robotics and Actuation
E23 and E24 bind progressive physical motion to sensor-confirmed real effects, safety envelopes, hardware latches, counters, power-stage or bus-level enforcement, and safe-state handling.
Vehicles, UAVs, and Industrial Control
E25 through E27 apply receipt-gated progression to routes, speed, steering, flight or mobile-robot operation, PLCs, machines, and process control.
Telecom, Radio, Satellite, and NTN
E28 and E29 stage network authority, traffic steering, service classes, radio transmission, satellite or non-terrestrial effects, and multi-domain progression.
GPU / Accelerator / Compute Egress
E30 gates consequential accelerator egress, protected compute outputs, or related effect-capable paths.
Model-State and Memory Updates
E31 separates provisional and authoritative model state and prevents self-authorization through state mutation.
Software, Firmware, and Configuration Updates
E32 progressively activates updates and supports rollback or safe-state handling when health or receipt predicates fail.
Multi-Destination and Distributed Effectuation
E33 provides destination-specific receipts, scopes, sinks, and continuation rules for fan-out or distributed effects.
Negative, Indeterminate, Conflict, and Recovery
E35 defines conservative handling for negative evidence, unknown outcomes, conflicting authentic evidence, reconciliation, recovery, and safe retry decisions.

16. Failure, Indeterminate State, and Recovery

16.1. No Blind Retry

When a consequential phase may have occurred but no trustworthy receipt is available, a retry can duplicate the external consequence. The controller SHOULD reconcile using transaction identifiers, nonces, idempotency identifiers, sink or destination queries, protected journals, device state, counters, replicated state, or other protected evidence before deciding whether retry is safe.

if effect_may_have_occurred and receipt_missing:
    outcome = RECONCILE(act_digest, phase, nonce, transaction_id)
    if outcome == PROVEN_EFFECTED:
        reconstruct_or_recover_evidence()
        validate_before_continuation()
    elif outcome == PROVEN_NOT_EFFECTED:
        authorize_new_bounded_retry_with_fresh_state()
    elif outcome == PARTIALLY_EFFECTED:
        calculate_residual_or_compensating_action()
    else:
        keep_later_phase_blocked()
Figure 30: Non-limiting reconciliation pseudocode

16.2. Conflicting Evidence

Two receipts may both authenticate successfully while describing mutually inconsistent outcomes. Authentication alone therefore does not imply consistency. The safety-first profile treats unresolved critical contradictions as a reason to hold, reconcile, reduce scope, or escalate rather than blindly progress.

AuthValid(R_a) AND AuthValid(R_b)
AND NOT Consistent(R_a, R_b)
    => HOLD / RECONCILE / ESCALATE

Authentic evidence != consistent evidence
Figure 31: Conflicting evidence rule

16.3. Safe-State and Compensation

Physical, infrastructure, payment, database, software-update, and other stateful workflows may define rollback, compensation, quarantine, fail-limited behavior, or a bounded safe-state action. A compensating action is itself an effect and may require protected authorization and observation.

17. Anti-Substitution, Anti-Skip, and Alternate-Path Closure

Security depends on controlling act-equivalent effect paths, not on naming a particular proxy or component. If a required protected path can be bypassed through a direct socket, alternate credential, administrative API, debug interface, recovery interface, database role, message queue, device driver, hardware register, fallback communications route, or another path capable of the same material consequence, that alternate path must be disabled, mediated, capability-limited, cryptographically locked, hardware-gated, transaction-gated, or subjected to equivalent finality checks.

For every path q:

    EffectCapable(q)
        => RequireEquivalentFinalityControl(q)
           OR DisableMaterialEffect(q)

For mandatory staged phases:

    P_i -/-> P_(i+2)

without the required P_(i+1) state transition and protected evidence.
Figure 32: Alternate-path closure

18. Generic Operational Algorithm 

FUNCTION EXECUTE_WITH_FINALITY(A, policy):
    D_A = HASH(CANONICALIZE(A))
    E_MAX = policy.maximum_authorized_envelope(A)

    mode = policy.select_mode(A)

    if mode == SINGLE_PHASE:
        authority = PROTECTED_AUTHORIZE(A, E_MAX)
        return FINALITY_SINK.EFFECTUATE(A, authority)

    phase_plan = policy.form_phase_plan(A, E_MAX)

    for i in phase_plan:
        authority_i = ISSUE_PHASE_AUTHORITY(D_A, i, phase_plan[i])
        effect_i = FINALITY_SINK[i].EFFECTUATE(phase_plan[i], authority_i)
        R_i = OBTAIN_PROTECTED_EFFECT_EVIDENCE(effect_i)

        result = VALIDATE_RECEIPT_AND_CURRENT_STATE(
            D_A, i, R_i, policy, E_MAX)

        if result == PASS:
            ATOMICALLY_CONSUME_AND_ADVANCE(R_i, i)
            continue
        if result == REDUCE_SCOPE:
            phase_plan = RESTRICT_REMAINING_PLAN(phase_plan)
            continue
        if result == HUMAN_REVIEW:
            result = PROTECTED_HUMAN_DECISION(D_A, R_i)
            if result permits bounded continuation:
                continue
        if result == RECONCILE:
            result = RECONCILE_EFFECT_STATE(D_A, i, R_i)
            if result becomes proven acceptable:
                continue
        if result == REMEDIATE:
            AUTHORIZE_ONLY_PROTECTED_REMEDIATION()
            continue only after new protected evidence

        ENTER_SAFE_OR_TERMINATED_STATE()
        return BLOCKED

    return FINAL_COMPLETION_STATE
Figure 33: Generic safety-first effectuation algorithm

19. Security Considerations

This entire document describes security controls. Implementations must treat the effectuation boundary, protected state, receipt path, approval channel, credentials, counters, and recovery logic as security-sensitive components.

20. Privacy Considerations

Effect receipts can reveal sensitive information about recipients, devices, routes, transactions, locations, model state, user actions, infrastructure state, or operational history. Implementations SHOULD minimize receipt contents to the predicates required for the selected security policy. Hash commitments, selective disclosure, encrypted receipts, confidential logs, trusted hardware, or privacy-preserving proofs may be used where raw evidence would reveal unnecessary sensitive information.

Progressive data-export and messaging workflows should distinguish proof that a protected effect occurred from unnecessary disclosure of the payload itself. Receipt retention and cross-domain sharing should be governed by the deployment privacy policy.

21. IANA Considerations

This document makes no request of IANA.

22. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>.

23. Informative References

[DAS-MUSE-SENTINEL-GUIDE]
Das, S., "Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide", Zenodo record 23040181 (resource type: Patent, open access), <https://zenodo.org/records/23040181>. Patent pending concept: Indian Patent Office application number 202631117633.

Appendix A. Detailed Workflow Profiles E01-E35

This appendix preserves the detailed workflow structure derived from the twelve supplied Advanced Section 1 workflow documents. The material is normalized for RFCXML readability but retains the source terminology, sequence, implementation breadth, and non-limiting character. The common terminology in the main body governs where a workflow uses an inherited term without redefining it.

A.1. E01 — Single-Phase Protected Effectuation

A.1.1. E01.1 Purpose

This embodiment provides the baseline protected-effectuation architecture for a Candidate Act that is permitted to proceed to its complete authorized consequence in a single effectuation phase. The embodiment is important because the disclosed architecture is not limited to trial-first, canary-first, or progressively phased execution. Where protected policy determines that staged execution is unnecessary, the complete authorized effect may be produced in one protected phase while retaining execution-finality controls. The basic relationship is:

Candidate Act → P rotected V alidation → Effectuation Authority → Effectuation Boundary → Authorized Effect → Completion Evidence

A.1.2. E01.2 Initial Actors and Functional Components

The embodiment may include the following logical functions.

A. Candidate Act Source The Candidate Act may originate from:

  • an AI agent;

  • foundation model;

  • autonomous agent;

  • application;

  • operating system;

  • workflow engine;

  • cloud controller;

  • telecom controller;

  • payment application;

  • database application;

  • robotic controller;

  • embedded controller;

  • human-operated application;

  • or another computational source. The Candidate Act Source does not become authoritative merely by generating the Candidate Act.

B. Candidate Act Representation Component This component forms a machine-processable representation of the proposed act. It may identify, where applicable:

  • act type;

  • command;

  • tool;

  • target;

  • destination;

  • recipient;

  • resource;

  • payload;

  • amount;

  • object;

  • file;

  • database record;

  • API;

  • network endpoint;

  • device;

  • actuator;

  • requested consequence;

  • permitted scope;

  • user;

  • application;

  • model;

  • agent;

  • originating process;

  • purpose;

  • timing;

  • jurisdiction;

  • and associated authority context.

C. Canonicalization / Exact-Act Binding Component Where exact representation is required, the Candidate Act may be transformed into a canonical representation:

AC = Canon(A) and a digest may be formed:

DA = H(AC ) The canonicalization operation is intended to prevent a later component from interpreting an ambiguously encoded act as a materially different act. Canonicalization may be replaced by another deterministic act-identification mechanism. REQUIRED PROPERTY: the effectuation authority must remain associated with the authorized act or authorized act class. OPTIONAL MECHANISM: canonical hash.

A.1.3. E01.3 Protected Enforcement Domain Intake

The Candidate Act or its bound representation is submitted to a Protected Enforcement Domain, abbreviated PED. The PED may be:

  • physically separate;

  • logically separate;

  • process-isolated;

  • privilege-separated;

  • hardware-isolated;

  • remotely hosted;

  • distributed;

  • or integrated with the effectuation component while maintaining protected state. The PED receives sufficient information to determine whether the Candidate Act may proceed.

A.1.4. E01.4 Protected State Acquisition

The PED may obtain current protected state relevant to the Candidate Act. Such state may include:

  • current policy;

  • revocation state;

  • credential state;

  • user authority;

  • recipient authorization;

  • device identity;

  • application identity;

  • process identity;

  • agent identity;

  • execution environment measurement;

  • resource state;

  • taint state;

  • provenance state;

  • transaction state;

  • geographic state;

  • jurisdiction state;

  • risk state;

  • prior receipt state;

  • rate limits;

  • spending limits;

  • capability state;

  • sink identity;

  • and temporal state. The protected state may be obtained from one or more local or remote sources.

A.1.5. E01.5 Validation Predicate Formation

The PED determines a predicate set applicable to the Candidate Act. Let:

ΠA = {p1 , p2 , ... , pm } Each predicate may evaluate to:

T RU E, F ALSE, U N KN OW N , IN DET ERM IN AT E depending on implementation. Examples include:

p1 = U serAuthorized

p2 = DestinationAllowed

p3 = P olicyCurrent

p4 = RevocationClear

p5 = ResourceW ithinScope

p6 = SinkT rusted

p7 = RiskAcceptable The Candidate Act need not use every listed predicate.

A.1.6. E01.6 Approval-Mode Determination

The PED determines which approval class applies. Possible classes include:

Mode A — Automatic Protected Approval Protected policy permits the act automatically if the required predicates succeed.

Mode B — Protected Human Approval The Candidate Act requires authenticated human approval. The approval should preferably be bound to the specific act or permitted act scope.

Mode C — Hybrid Approval Both automatic validation and human approval are required. For example:

AU T O_P ASS ∧ HU M AN _P ASS

Mode D — Multi-Authority Approval Two or more protected authorities may be required.

Mode E — Previously Authorized Envelope A previous protected human or enterprise authorization may already define an execution envelope. The PED determines whether the Candidate Act falls within that envelope.

A.1.7. E01.7 Automatic Approval Workflow

Where automatic approval applies, the protected policy component evaluates the required predicates. The proposing agent itself need not possess authority to mark those predicates as satisfied. A successful decision may be represented as:

DecisionA = ALLOW only where all mandatory protected conditions have reached an acceptable state. A failed decision may produce:

DecisionA = DEN Y An unresolved condition may produce:

DecisionA = HOLD or:

DecisionA = IN DET ERM IN AT E

A.1.8. E01.8 Protected Human Approval Workflow

Where human approval is required, the PED may form a Protected Approval Object. The approval object may contain or bind:

  • Candidate Act digest;

  • meaningful act description;

  • recipient;

  • destination;

  • amount;

  • payload identity;

  • affected resource;

  • requested consequence;

  • permitted scope;

  • expiration;

  • nonce;

  • policy epoch;

  • current risk indication;

  • sink identity;

  • and other required context.

The approval interface may be:

  • an operating-system UI;

  • separate security application;

  • secure mobile application;

  • hardware display;

  • trusted display;

  • enterprise approval console;

  • secure element;

  • remote authenticated approval service;

  • or equivalent protected interface. The AI agent’s ordinary conversation surface need not itself constitute the protected approval surface.

The human may:

  • approve;

  • deny;

  • restrict scope;

  • delay;

  • request additional verification;

  • or require staged effectuation instead.

A.1.9. E01.9 Selection of Single-Phase Mode

After protected validation, the PED determines whether the Candidate Act may proceed as a single-phase act. The decision may depend upon:

  • risk;

  • consequence magnitude;

  • confidence in destination;

  • reversibility;

  • prior successful history;

  • recipient trust;

  • device attestation;

  • transaction type;

  • latency requirement;

  • user preference;

  • enterprise policy;

  • legal requirement;

  • operational requirement;

  • or other protected state.

Where single-phase execution is selected:

P haseCount = 1 and the complete permitted effect becomes:

P1 = Aauthorized

A.1.10. E01.10 Formation of Effectuation Authority

The PED may then create, release, derive, unseal, activate, or validate a bounded effectuation authority. This authority may comprise:

  • scoped capability;

  • Execution Handle;

  • digital signature;

  • MAC;

  • transaction authorization;

  • signing permission;

  • decryption material;

  • encryption material;

  • missing command material;

  • API authority;

  • protected state transition;

  • database state;

  • hardware latch;

  • secure monitor result;

  • device command authenticator;

  • key share;

  • network release state;

  • destination-side enablement state;

  • or another technical condition. The architecture does not require the authority to be a bearer token.

A.1.11. E01.11 Authority Binding

Where applicable, the authority may be bound to:

DA and additionally to one or more of:

  • sink;

  • destination;

  • recipient;

  • device;

  • process;

  • application;

  • hardware identity;

  • scope;

  • policy epoch;

  • revocation epoch;

  • nonce;

  • time window;

  • purpose;

  • resource;

  • consequence class;

  • transaction identifier.

The general requirement is:

Authority(A) ⇏ Authority(B) where B is an unauthorized materially different act.

A.1.12. E01.12 Delivery to Effectuation Boundary

The Candidate Act and/or required authority reaches an effect-capable boundary. The boundary may comprise:

  • network interface;

  • API gateway;

  • payment gateway;

  • database commit engine;

  • storage controller;

  • message broker;

  • operating-system kernel;

  • syscall boundary;

  • hardware driver;

  • secure monitor;

  • actuator controller;

  • robotic controller;

  • GPU;

  • DPU;

  • SmartNIC;

  • telecom gateway;

  • radio controller;

  • cryptographic module;

  • rendering system;

  • remote destination;

  • or another component capable of making the act externally consequential. This component performs the function of a Finality Sink or equivalent effectuation-control component.

A.1.13. E01.13 Sink-Side Verification

Before producing the effect, the sink verifies the required authority and local state. Sink-side verification may include:

  • act matching;

  • capability validity;

  • signature validity;

  • MAC validity;

  • nonce freshness;

  • expiration;

  • policy epoch;

  • revocation epoch;

  • recipient;

  • destination;

  • resource;

  • process;

  • hardware identity;

  • sink identity;

  • amount;

  • command;

  • payload;

  • transaction state;

  • phase identifier;

  • or protected local state.

If sink-side verification fails:

Effectuation = BLOCKED

A.1.14. E01.14 Full Effectuation

Upon successful verification, the complete authorized effect may occur. Examples:

Communication The entire authorized message or file is transmitted.

Payment The entire authorized payment is submitted or settled according to the applicable payment state.

Database The authorized mutation becomes committed.

Storage The authorized object becomes durably stored or externally accessible.

Hardware The authorized physical command is executed.

Telecom The authorized transmission or network-control action takes effect.

AI Tool Invocation The authorized external tool operation is executed.

A.1.15. E01.15 Completion Observation

The system may obtain evidence describing whether the full effect occurred. Such evidence may originate from:

  • the sink itself;

  • destination;

  • receiving endpoint;

  • hardware sensor;

  • transaction network;

  • database;

  • storage controller;

  • remote API;

  • device;

  • network observer;

  • or another protected observer.

A.1.16. E01.16 Completion Receipt

A Completion Receipt may be generated. It may bind:

  • Candidate Act digest;

  • actual performed operation;

  • destination;

  • sink;

  • completion state;

  • transaction identifier;

  • time;

  • nonce;

  • policy epoch;

  • resource state;

  • result code;

  • and other protected evidence. The receipt may be signed, MACed, attested, hash-chained, ledger-anchored, or protected by equivalent means.

A.1.17. E01.17 Authority Consumption

Where the authority is intended for single use, it is marked consumed. For example:

Consumed(CA ) = T RU E A subsequent execution attempt must not succeed solely by replaying the previous authority.

A.1.18. E01.18 Indeterminate Completion

If the sender cannot determine whether the act occurred:

State = IN DET ERM IN AT E

The architecture may prevent blind retry where duplicate consequence would be unsafe. The PED may reconcile using:

  • sink query;

  • transaction ID;

  • destination query;

  • protected journal;

  • idempotency key;

  • device state;

  • database state;

  • hardware counter;

  • or equivalent evidence.

A.1.19. E01.19 Anti-Bypass Requirement

Where the architecture requires single-phase protected finality, another path must not allow equivalent full execution while avoiding the required protected boundary. Relevant alternate paths may include:

  • direct socket;

  • hidden API;

  • administrator API;

  • alternate database path;

  • direct device driver;

  • raw hardware interface;

  • fallback communication route;

  • alternate credential;

  • privileged service;

  • recovery interface;

  • or another act-equivalent route.

Equivalent effect-capable paths may be:

  • disabled;

  • mediated;

  • protected;

  • credential-restricted;

  • cryptographically locked;

  • or subjected to equivalent finality verification.

A.1.20. E01.20 Software Implementation Variation

A software implementation may comprise: Agent Runtime → Protected Broker/PED → Kernel / Proxy / Transaction Gate → External Destination The agent may have no direct effect-capable credential.

A.1.21. E01.21 Hardware Implementation Variation

A hardware implementation may comprise:

Application Processor → request → Secure Processor / TEE / HSM → bounded command authority → Hardware Finality Sink → external effect. Protected keys and state may remain unavailable to ordinary software.

A.1.22. E01.22 Required Invariants

The minimum frozen conceptual invariants of E01 are:

Invariant 1 The proposed act is distinguishable from final effectuation.

Invariant 2 At least one protected authority decision occurs before the complete effect is made effective.

Invariant 3 The effect-capable boundary is technically dependent upon valid authority.

Invariant 4 Failure of required validation prevents the authorized full effect.

Invariant 5 The Candidate Act Source cannot obtain full effect merely by asserting that approval occurred. Everything else in E01 may vary by implementation unless expressly required.

FIED RECEIPT → FULL EFFECTUATION

A.2. E02 — Real Bounded Demonstration Effect, Verified Receipt, Then Full Effectuation

A.2.1. E02.1 Purpose

E02 introduces the principal staged-effectuation architecture. The Candidate Act is not immediately permitted to produce its complete intended consequence. Instead, the system first permits a bounded real effect. The real effect is observed. Machine-verifiable evidence is generated. The evidence is validated. Only thereafter may the remaining or complete effect be enabled. The central relationship is:

Candidate Act → Bounded Real Effect → V erified Effect Receipt → Continuation Authority → Broader/F ull Effect

A.2.2. E02.2 Technical Distinction

The initial stage must not be confused with:

  • simulation;

  • hypothetical execution;

  • local preview;

  • visual mock-up;

  • model prediction;

  • static analysis;

  • dry-run that produces no relevant external state change;

  • or ordinary risk scoring. The Phase-0 operation causes at least one real effectuation-relevant state transition. The real effect may nevertheless be deliberately restricted in consequence.

A.2.3. E02.3 Candidate Act Formation

A Candidate Act A is produced. The system determines the intended full effect:

EF Examples include:

  • entire message;

  • entire file;

  • entire payment;

  • complete database update;

  • entire actuator trajectory;

  • complete software deployment;

  • complete credential authority;

  • full dataset release;

  • full telecom action;

  • or another complete consequence.

A.2.4. E02.4 Exact-Act / Authorized-Envelope Binding

A protected representation of the Full Candidate Effect may be created. For example:

DA = H(Canon(A)) The architecture may additionally bind an authorized maximum envelope:

Envelopemax The staged architecture may never increase authority beyond:

Envelopemax merely because the trial succeeds.

A.2.5. E02.5 Stage Planner

The PED determines that E02 staged mode applies. It defines:

Phase 0 P0 representing the Bounded Trial Effect.

Phase 1 P1 representing the authorized remaining effect or complete release. The relation may be:

P0 + P1 = EF where quantitative decomposition is meaningful. Alternatively, P0 and P1 may represent different technical operations contributing to the same final consequence.

A.2.6. E02.6 Bounded Trial Effect Selection

The trial effect may be bounded by one or more dimensions.

Amount Example:

₹1

before a larger payment.

Data A bounded encrypted sample before complete data release.

Recipient One protected recipient before a broader distribution.

Destination One verified endpoint before broader network use.

Time Short operation interval before continuous operation.

Hardware Movement Small movement before complete trajectory.

Resource One database row, VM, server, device, storage object, model replica, or service instance.

Capability Read-only or low-privilege operation before write or broader privilege.

Cryptographic Scope Partial key material before complete decryption authority.

A.2.7. E02.7 Trial Effect Descriptor

A protected Trial Effect Descriptor may be generated. The descriptor may identify:

  • DA ;

  • phase identifier;

  • trial operation;

  • maximum trial consequence;

  • authorized destination;

  • expected sink;

  • expected observer;

  • acceptable response;

  • nonce;

  • expiry;

  • policy epoch;

  • revocation epoch;

  • receipt requirements;

  • permitted continuation;

  • and anti-replay state.

Let:

T ED0 denote the descriptor.

A.2.8. E02.8 Approval Before Trial

The trial itself may require one of several approval modes.

Automatic Trial Approval Policy automatically permits the bounded effect.

Human Trial Approval A human approves the trial.

Hybrid Trial Approval Automatic protected checks and human approval are both required.

Preauthorized Trial The user has previously authorized trials within a defined envelope. The existence of staged execution does not eliminate approval policy.

A.2.9. E02.9 Phase-0 Authority

The PED forms authority sufficient only for the bounded Phase-0 effect. The authority should preferably be incapable of directly enabling Phase 1. Formally:

Scope(C0 ) ⊂ Scope(EF ) The trial authority may be:

  • scoped capability;

  • temporary credential;

  • limited signing authority;

  • hardware enable value;

  • transaction authorization;

  • restricted API capability;

  • bounded network capability;

  • partial key;

  • limited actuator command;

  • or equivalent technical condition.

A.2.10. E02.10 Phase-0 Sink Verification

The Phase-0 Finality Sink verifies:

  • Candidate Act binding;

  • trial descriptor;

  • permitted scope;

  • destination;

  • nonce;

  • freshness;

  • sink identity;

  • and applicable protected conditions. It must reject an attempt to use C0 for the broader effect.

A.2.11. E02.11 Real Bounded Effectuation

The sink performs the real bounded effect. This is the defining operational event. Examples follow.

SEND Example Instead of transmitting the complete sensitive document, a protected demonstration object is transmitted to the actual intended receiving endpoint.

Payment Example A bounded authorization, reversible amount, verification transfer, escrow reservation, or supported test transaction reaches the real payment infrastructure.

Hardware Example The motor physically moves a bounded amount.

Database Example A bounded state transition actually commits in a restricted namespace.

Cloud Example The software is actually deployed to one protected target.

A.2.12. E02.12 Effect Observation

An effect observer determines what actually occurred. The observer may comprise:

  • destination application;

  • recipient device;

  • transaction system;

  • payment institution;

  • storage engine;

  • network endpoint;

  • protected sensor;

  • motor encoder;

  • hardware controller;

  • database engine;

  • cloud node;

  • DPU;

  • SmartNIC;

  • HSM;

  • TEE;

  • secure element;

  • remote protected service;

  • or equivalent observer. The observer is preferably positioned such that its evidence is meaningfully connected to the real effect.

A.2.13. E02.13 Observed-Effect Representation

The observer forms an observation:

O0 The protected system may compare:

O0 against expected trial state:

X0 For exact systems:

O0 = X0 may be required. For tolerance-based systems:

d(O0 , X0 ) ≤ ε may be permitted.

A.2.14. E02.14 Effect Confirmation Receipt

The observer, sink, or protected receipt component generates:

R0 The ECR may bind:

  • Candidate Act;

  • TED;

  • Phase 0;

  • actual observed result;

  • destination;

  • sink;

  • observer;

  • transaction identifier;

  • nonce;

  • time;

  • policy epoch;

  • status;

  • prior protected state;

  • and next-stage eligibility evidence. The receipt may be authenticated cryptographically.

A.2.15. E02.15 Receipt Status Classes

The ECR may report:

SUCCESS The bounded effect occurred within the permitted condition.

FAILURE The bounded effect did not satisfy the expected condition.

REJECTED The destination refused the operation.

PARTIAL Only part of the defined BTE occurred.

ROLLED_BACK The bounded effect occurred but was safely reversed.

INDETERMINATE The system cannot yet prove whether the effect occurred.

A.2.16. E02.16 Receipt Return

The ECR reaches the PED or another protected receipt verifier. The return path may be:

  • direct;

  • through authenticated network transport;

  • through message queue;

  • through hardware interrupt;

  • through protected shared memory;

  • through secure mailbox;

  • through storage polling;

  • through transaction query;

  • or equivalent protected path.

A.2.17. E02.17 Receipt Verification

The protected verifier determines whether R0 is acceptable. Verification may include:

V erifySignature(R0 )

M atchAct(R0 , DA )

M atchP hase(R0 , P0 )

M atchDestination(R0 )

M atchN once(R0 )

F resh(R0 )

P olicyCurrent(R0 )

N otRevoked(A)

ObservedEffectAcceptable(O0 ) A successful result may be:

ReceiptV alid0 = T RU E

A.2.18. E02.18 Human Approval After Trial

A significant variant requires human approval after the real trial effect. Flow:

P0 → R0 → HumanReview → P1 The protected approval interface may display:

  • what was attempted;

  • what actually occurred;

  • verified destination;

  • trial receipt;

  • observed state;

  • recipient identity;

  • transaction status;

  • hardware state;

  • and the consequence of allowing Phase 1. The human therefore approves continuation based upon verified evidence of actual trial behavior.

A.2.19. E02.19 Automatic Approval After Trial

Another variation automatically authorizes continuation where:

ReceiptV alid0 ∧ P olicyP ass ∧ RiskAcceptable = T RU E The human is not required. This variation is important for:

  • autonomous systems;

  • hyperscale systems;

  • telecom;

  • cloud;

  • infrastructure;

  • routine communications;

  • low-latency applications;

  • and high-volume machine operations.

A.2.20. E02.20 Hybrid Continuation Approval

A higher-assurance implementation may require:

ReceiptV alid0 ∧ AutoP olicyP ass ∧ HumanApproval before Phase 1.

A.2.21. E02.21 Protected State Advancement

Successful receipt verification causes the protected state to move from, for example:

T RIAL_ISSU ED to:

T RIAL_CON F IRM ED and then, where applicable:

CON T IN U AT ION _AU T HORIZED This state transition should preferably occur inside protected state unavailable for arbitrary rewriting by the proposing agent.

A.2.22. E02.22 Receipt Consumption

Where the receipt is single-use:

Consumed(R0 ) = T RU E or equivalent protected state is recorded when continuation authority is generated.

This prevents:

R0 from authorizing multiple independent Phase-1 completions.

A.2.23. E02.23 Continuation Authority

The PED generates, derives, unseals, releases, or activates the authority required for Phase 1. Let:

C1 represent the continuation authority. A strong embodiment binds:

C1 to:

H(R0 ) such that receipt from another trial cannot substitute.

A.2.24. E02.24 Receipt-Derived Cryptographic Authority

One embodiment derives:

K1 = KDF (Kroot , DA , H(R0 ), P hase1 , Sink1 ) The precise cryptographic construction is implementation-dependent. The important protected property is that the later authority becomes dependent upon accepted evidence from the earlier real effect.

A.2.25. E02.25 Missing Execution Material Variation

Rather than creating a token, the architecture may withhold execution material necessary for Phase 1. Examples:

  • signing key share;

  • decryption key;

  • command authenticator;

  • actuator enable value;

  • transaction completion value;

  • database commit permission;

  • network release key;

  • hardware register unlock value. Only successful receipt validation makes the missing material available.

A.2.26. E02.26 Full / Remaining Effect Sink Verification

The Phase-1 sink verifies C1 , the current Candidate Act and protected state. It may verify:

  • DA ;

  • H(R0 );

  • Phase 1 identifier;

  • sink identity;

  • destination;

  • scope;

  • nonce;

  • policy epoch;

  • revocation epoch;

  • expiration;

  • human approval where required;

  • current system state.

A.2.27. E02.27 Full Effectuation

After successful verification:

P1 is performed. The result may complete the originally authorized consequence.

A.2.28. E02.28 Completion Receipt

A final receipt:

RF may bind both:

R0 and:

P1 For example:

RF = P rotect(DA , H(R0 ), Effect1 , F inalState) This creates evidence that the final effect was causally linked to the confirmed bounded effect.

A.2.29. E02.29 Failure After Trial

If the BTE fails:

R0 = F AILU RE Phase 1 remains unavailable. Possible next states include:

  • deny;

  • rollback;

  • compensate;

  • reduce scope;

  • select alternative destination;

  • require human review;

  • repeat a newly authorized trial;

  • or terminate. A failed trial must not automatically become permission for full execution.

A.2.30. E02.30 Indeterminate Trial

If the system cannot determine whether Phase 0 occurred:

R0 = IN DET ERM IN AT E Phase 1 remains blocked. The system enters reconciliation. It may query:

  • sink state;

  • idempotency record;

  • transaction ledger;

  • destination;

  • hardware counter;

  • protected journal;

  • or another authoritative state source.

A.2.31. E02.31 Crash After Trial Effect

A particularly important failure sequence is: 1. Phase 0 occurs. 2. Sink records the effect. 3. System crashes before receipt is delivered. A blind retry might duplicate Phase 0. Accordingly the BTE may use an idempotency identifier:

I0 = H(DA ∥ P hase0 ∥ N0 ) The sink stores the identifier atomically with the real effect. After recovery, the system determines whether I0 already corresponds to an effected operation.

A.2.32. E02.32 Alternate-Path Closure

The full effect must not remain available through an unprotected path while the staged path requires a receipt. Otherwise:

T rial Gate could simply be bypassed. The architecture may therefore protect:

  • direct API;

  • alternate network socket;

  • privileged credential;

  • database admin path;

  • raw device interface;

  • alternate key;

  • recovery path;

  • fallback route;

  • or another equivalent full-effect path.

A.2.33. E02.33 Communication “Trailer” Example

Full intended communication:

M A bounded real pre-release object:

T is transmitted first. The receiving endpoint validates T and generates:

RT The sender verifies RT . Only thereafter may M or its remaining protected content become available.

A.2.34. E02.34 Ciphertext-First Communication Variation

The full ciphertext may already be transmitted. However, the receiver cannot obtain the complete semantic content. After valid receipt of the initial protected stage, the sender/PED releases:

  • missing decryption key;

  • key share;

  • unwrap authority;

  • or equivalent material. This permits network pre-staging without full semantic effectuation.

A.2.35. E02.35 Hardware Demonstration Example

Requested actuator movement:

90∘ Trial authority permits:

5∘ Protected sensor reports:

4.98∘ If the acceptable range is:

4.9∘ ≤ O0 ≤ 5.1∘ then:

ReceiptV alid0 = T RU E and the remaining authorized movement may be enabled.

A.2.36. E02.36 Required Invariants

Invariant 1 The Phase-0 effect is a real protected effect, not merely a prediction.

Invariant 2 Phase 0 is narrower than the full authorized consequence in at least one relevant dimension.

Invariant 3 Evidence of Phase-0 outcome is obtained.

Invariant 4 The evidence is verified by protected logic.

Invariant 5 Phase 1 remains technically unavailable until the required Phase-0 evidence is accepted.

Invariant 6 A trial receipt cannot validly enlarge the operation beyond the maximum authorized envelope.

Invariant 7 Required staged control cannot be trivially avoided by an equivalent unprotected full-effect path. These constitute the frozen core of E02.

MULTI-PHASE PROGRESSIVE EFFECTUATION

A.3. E03 — Real Demonstration Effect with Receipt-Gated Multi-Phase Progressive Effectuation

A.3.1. E03.1 Purpose

E03 extends E02 from one trial followed by one full-effect stage to an arbitrary number of protected effectuation stages. Instead of:

P0 → R0 → PF the architecture permits:

P0 → R0 → P1 → R1 → P2 → R2 → ... → Pn → Rn Each required receipt may become a protected prerequisite for a later phase.

A.3.2. E03.2 Candidate Act and Maximum Effect Envelope

A Candidate Act A defines or is associated with a maximum permitted consequence:

EMAX The multi-phase system may progressively approach EMAX , but must not exceed it merely because prior phases succeed. Therefore:

Ei ≤ EMAX for every phase i.

A.3.3. E03.3 Phase Plan

The protected Phase Planner may create:

P = {P0 , P1 , ... , Pn } The plan may be established:

  • entirely in advance;

  • partly in advance;

  • adaptively;

  • dynamically after every receipt;

  • by protected policy;

  • by human authorization;

  • or using a hybrid model.

A.3.4. E03.4 Fixed Phase Plan

One implementation predefines the complete progression. Example:

1% → 10% → 25% → 50% → 100% Another:

1 device → 10 → 100 → 1000 Another:

₹10 → ₹100 → ₹1000 → remaining authorized amount

Another:

5∘ → 20∘ → 45∘ → 90∘

A.3.5. E03.5 Adaptive Phase Plan

The scope of the next phase may be determined only after the previous effect is observed. Let:

Si+1 = f(Ri , Riski , P olicyi , Approvali , CurrentStatei )

where Si+1 denotes the next permitted scope. The next phase may therefore become:

  • larger;

  • smaller;

  • unchanged;

  • delayed;

  • redirected;

  • human-reviewed;

  • or terminated.

A.3.6. E03.6 Initial Validation

Before Phase 0, the PED performs protected validation substantially according to the applicable portions of E01 and E02. The validation determines:

  • whether the act is authorized at all;

  • maximum allowed consequence;

  • allowed phase strategy;

  • required receipt quality;

  • approval mode;

  • sink requirements;

  • anti-bypass requirements;

  • and failure behavior.

A.3.7. E03.7 Human Authorization of Entire Progressive Envelope

A human may authorize:

EMAX once at the beginning while requiring the system to progress only after verified phase receipts. Example: Authorized maximum: deploy to 10,000 devices. Progression must stop automatically if protected health criteria fail. The human need not approve each individual phase.

A.3.8. E03.8 Human Authorization Per Phase

Alternatively each phase may require:

HumanApprovali after receipt Ri−1 . The human therefore sees actual evidence from preceding phases before authorizing expansion.

A.3.9. E03.9 Automatic Progressive Approval

Protected policy may automatically advance every phase where:

ReceiptV alidi ∧ RiskAcceptablei ∧ P olicyV alidi ∧ N otRevokedi is true. No human interaction is required.

A.3.10. E03.10 Hybrid Progressive Approval

Example protected rule:

i < 3 ⇒ Auto and:

i ≥ 3 ⇒ HumanApproval or:

EffectScope < T hreshold ⇒ Auto

EffectScope ≥ T hreshold ⇒ HumanApproval The threshold itself is protected policy.

A.3.11. E03.11 Phase-Specific Authority

Each phase obtains separate authority:

Ci where:

Scope(Ci ) = Scope(Pi ) A Phase-1 authority should not validly authorize Phase 2 unless policy expressly makes them equivalent.

A.3.12. E03.12 Phase-Receipt Chain

Following each real effect:

Pi the sink or observer generates:

Ri The receipt may include:

H(Ri−1 ) creating:

R0 → R1 → R2 → ... as a cryptographically linked history.

A.3.13. E03.13 Receipt-Chain Mathematical Representation

For i > 0:

Ri = P rotectKi (DA ∥ P hasei ∥ Oi ∥ Statusi ∥ Ni ∥ H(Ri−1 ))

The use of H(Ri−1 ) is one possible implementation and is not mandatory where an equivalent protected sequence-binding mechanism exists.

A.3.14. E03.14 Next-Phase Predicate

A general next-phase condition may be:

Enable(Pi+1 ) = V alid(Ri ) ∧ M atch(Ri , Pi ) ∧ F resh(Ri ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(Pi+1 ) ∧ ApprovalSatisfiedi+1

If any required condition is false:

Enable(Pi+1 ) = F ALSE

A.3.15. E03.15 Protected State Transition

After successful receipt verification:

Statei → Statei+1 may occur atomically with:

  • receipt consumption;

  • next-phase authority generation;

  • phase counter increment;

  • protected log update;

  • or equivalent protected state operation.

A.3.16. E03.16 Phase Counter

Protected state may maintain:

i as a monotonically advancing phase index. An attempt to execute:

Pi+2 while the protected phase index equals i may be rejected. This prevents skipping mandatory stages.

A.3.17. E03.17 Cryptographic Key Progression

The authority chain may be derived progressively. For example:

K0 = KDF (KR , DA , N0 )

K1 = KDF (KR , DA , H(R0 ), 1)

K2 = KDF (KR , DA , H(R1 ), 2) and generally:

Ki+1 = KDF (KR , DA , H(Ri ), i + 1) A stronger variant may incorporate the entire receipt history.

A.3.18. E03.18 Hardware Key Progression

A secure hardware component may hold:

KR and expose only the current phase-specific authority. Ordinary application software cannot request Ki+1 unless the hardware has accepted Ri . This creates hardware-enforced progression.

A.3.19. E03.19 Hardware Phase Latch

A hardware implementation may use a protected state variable:

L=i representing the highest completed authorized phase. A command for phase j succeeds only where:

j =L+1 and required receipt validation has completed.

A.3.20. E03.20 Progressive Communication Workflow

A sensitive file transmission may proceed as:

Phase 0 — Endpoint Verification A protected challenge or trailer reaches the real recipient.

R0 confirms endpoint identity.

Phase 1 — Manifest Encrypted metadata or manifest is transmitted.

R1 confirms acceptance.

Phase 2 — Initial Payload Segment A limited encrypted file segment is transmitted.

R2 confirms protected storage.

Phase 3 — Remaining Ciphertext Remaining encrypted data is transmitted.

R3 confirms complete ciphertext integrity.

Phase 4 — Semantic Release Final decryption authority is released.

R4 may confirm completion. Thus network delivery and information disclosure may be independently phased.

A.3.21. E03.21 Progressive Payment Workflow

A payment may progress as:

Phase 0 Destination-account verification.

Receipt 0 Protected receiving-institution confirmation.

Phase 1 Bounded reservation.

Receipt 1 Reservation confirmation.

Phase 2 Partial settlement.

Receipt 2 Protected settlement confirmation.

Phase 3 Remaining settlement.

Receipt 3 Final completion confirmation. The precise payment operations depend on the payment infrastructure.

A.3.22. E03.22 Progressive Hardware Workflow

Requested total actuator trajectory:

90∘ Possible phases:

5∘

15∘

30∘

40∘ for cumulative:

90∘ Following each movement, a protected sensor generates evidence. If any observed value exceeds the permitted tolerance:

Continue = F ALSE

A.3.23. E03.23 Cumulative Effect State

Let:

Ei represent cumulative real effect after phase i. The architecture may require:

E0 < E1 < ... < En ≤ EMAX where monotonic progression is applicable. Some systems may instead use non-monotonic or qualitatively different phases.

A.3.24. E03.24 Progressive Scope Enlargement

Where authority is represented as scope:

Scope0 ⊂ Scope1 ⊂ ... ⊆ ScopeMAX Examples:

  • more recipients;

  • more devices;

  • greater financial amount;

  • more data;

  • broader network range;

  • additional privileges;

  • larger actuator envelope;

  • increased deployment population.

A.3.25. E03.25 Progressive Credential Authority

The credential used by the agent or executor may similarly expand. Phase 0: read-only. Phase 1: write to one object. Phase 2: write to defined namespace. Phase 3: broader authorized transaction. The full reusable credential need never be exposed to the agent.

A.3.26. E03.26 Receipt-Quality-Controlled Phase Size

Let receipt confidence be:

Qi and required threshold:

τi If:

Qi < τi the next phase may:

  • remain same size;

  • become smaller;

  • require stronger validation;

  • require human approval;

  • or terminate. A high-quality receipt does not necessarily require full-scale expansion.

A.3.27. E03.27 Risk-Adaptive Phase Size

Let current risk be:

Riski The next phase scope may satisfy:

Scopei+1 = g(Riski , Qi , P olicyi ) A higher risk may produce smaller next-phase scope.

A.3.28. E03.28 Taint-Adaptive Progression

Where taint or provenance state is relevant:

  • untainted/high-trust context may permit larger stages;

  • uncertain provenance may require smaller stages;

  • high-risk taint may require human review;

  • prohibited taint may terminate progression. The proposing AI agent need not control the protected taint state.

A.3.29. E03.29 Parallel Trial Sub-Phases

A phase may include several parallel bounded operations:

Pi,1 , Pi,2 , ..., Pi,k

Each produces:

Ri,1 , Ri,2 , ..., Ri,k

An aggregate protected predicate determines whether the next broader phase may proceed. For example:

SuccessRatei ≥ τ and:

CriticalF ailurei = F ALSE

A.3.30. E03.30 Quorum Confirmation

A phase may require confirmation from multiple observers. Let:

Ri1 , ..., Rin be receipts. Continuation may require:

n ∑ V alid(Rij ) ≥ m j=1

This may be useful where one observer is insufficiently authoritative.

A.3.31. E03.31 Nested Phase Structure

A global phase may contain sub-phases. For example: Global Deployment Phase 1 contains:

  • Region A phase;

  • Region B phase;

  • Region C phase.

Each region may independently progress through:

  • node canary;

  • small cohort;

  • broad cohort.

The parent phase proceeds only after required child receipt conditions are met.

A.3.32. E03.32 Partial Success

If some targets succeed and others fail:

SuccessfulSet ⊂ OriginalSet the next phase may continue only for:

SuccessfulSet rather than forcing binary full success/full failure.

A.3.33. E03.33 Failure at Intermediate Phase

If:

Ri = F AILU RE remaining phases:

Pi+1 , ..., Pn remain unavailable unless a new protected decision explicitly authorizes an alternative continuation path. Possible responses include:

  • terminate;

  • rollback;

  • compensate;

  • retry bounded subset;

  • reduce scope;

  • select alternative sink;

  • human escalation;

  • or replan.

A.3.34. E03.34 Indeterminate Intermediate Phase

If:

Ri = IN DET ERM IN AT E the system does not assume either success or failure. The protected phase state is frozen. No broader phase is released until reconciliation establishes an acceptable protected state.

A.3.35. E03.35 Reconciliation Workflow

The system may query:

  • phase-specific idempotency identifier;

  • transaction ledger;

  • sink log;

  • destination state;

  • hardware counter;

  • message identifier;

  • settlement state;

  • storage state;

  • or other protected evidence.

Possible reconciliation results:

PROVEN_EFFECTED Construct/recover Ri and continue if permitted.

PROVEN_NOT_EFFECTED A new protected retry may be authorized.

STILL_INDETERMINATE Remain blocked.

A.3.36. E03.36 Phase Replay Protection

Each phase may use unique:

Ni and/or:

Ii A consumed authority or receipt cannot be used to repeat the corresponding real effect.

A.3.37. E03.37 Receipt Consumption

Once:

Ri has caused protected transition to phase i + 1, the PED may record:

Consumed(Ri ) = T RU E A replayed Ri must not independently cause another phase-i + 1 effect.

A.3.38. E03.38 Policy Change Between Phases

If:

P olicyEpochnew ≠ P olicyEpochi then prior receipt success need not automatically authorize progression. The PED may require:

  • revalidation;

  • reduced scope;

  • human approval;

  • or termination.

A.3.39. E03.39 Revocation Between Phases

At any point:

Revoked(A) = T RU E may cause all unused continuation authorities to become invalid. Prior successful phases do not guarantee future completion.

A.3.40. E03.40 Human Veto

Even in an automatically progressing system, a protected human may have veto authority. After a valid receipt:

Ri the system may enter a bounded delay window. If:

V eto = T RU E the next phase remains blocked.

A.3.41. E03.41 Maximum-Envelope Enforcement

Before every phase, the protected system verifies:

CumulativeEffectproposed ≤ AuthorizedM aximum

A sequence of individually valid receipts must never create cumulative privilege escalation.

A.3.42. E03.42 Alternate-Path Closure

The phased architecture requires equivalent control over any path capable of prematurely causing:

Pi+1 or the final consequence. This may include:

  • alternate API;

  • administrator interface;

  • direct credential;

  • raw device interface;

  • hidden database connection;

  • recovery route;

  • alternate message queue;

  • lower-level OS primitive;

  • remote control interface;

  • or other effect-equivalent path.

A.3.43. E03.43 Multi-Sink Variation

Different phases may use different sinks:

Sink0 , Sink1 , ..., Sinkn Receipt validity may bind the expected sink sequence. An unauthorized sink substitution may terminate the progression.

A.3.44. E03.44 Same-Sink Variation

One protected sink may maintain all phase state internally. For example:

Sink0 = Sink1 = ... = Sinkn The sink increments protected phase state only after its required observation conditions succeed.

A.3.45. E03.45 Distributed Protected Enforcement Domain

Different PED functions may reside at:

  • originating device;

  • cloud;

  • HSM;

  • destination;

  • gateway;

  • network;

  • hardware controller;

  • enterprise service;

  • human approval device. The architecture does not require one physical PED.

A.3.46. E03.46 Final Completion

When the final required phase:

Pn has been successfully completed and verified, protected state may become:

F U LLY _EF F ECT ED or equivalent terminal state.

A.3.47. E03.47 Final Receipt

The final receipt may commit to the entire effectuation chain:

RF = P rotect(DA , H(R0 ), H(R1 ), ..., H(Rn ), F inalState) For very large receipt sets, a Merkle root or other aggregate commitment may be used.

A.3.48. E03.48 Required Invariants

Invariant 1 At least two real effectuation phases exist.

Invariant 2 The initial effect is bounded relative to the maximum authorized consequence.

Invariant 3 At least one later phase depends technically upon accepted evidence from a previous real phase.

Invariant 4 Mandatory phase order cannot be silently skipped.

Invariant 5 No phase may exceed the authorized maximum envelope.

Invariant 6 Failure or indeterminate state at a required phase prevents unauthorized broader progression.

Invariant 7 Automatic approval, human approval, or hybrid approval may govern phase advancement.

Invariant 8 The architecture may be software-enforced, hardware-enforced, or jointly enforced.

Invariant 9 Equivalent alternate effect paths are subjected to corresponding phase-control requirements where needed to preserve non-bypassability.

FROZEN RELATIONSHIP BETWEEN E01, E02 AND E03 The three primary workflows may be summarized as follows.

E01 V alidate → Authorize → 100% Effect

E02 V alidate → Bounded Real Effect → Receipt → Remaining/F ull Effect

E03 V alidate → P0 → R0 → P1 → R1 → ... → Pn → Rn The protected system may choose among E01, E02 and E03 according to policy, risk, act class, destination certainty, reversibility, latency, human preference, infrastructure capability, or another protected criterion. The principal conceptual progression is therefore:

Single P hase | T rial T hen F ull | T rial T hen P rogressive F ull

with the common execution-finality principle that computational proposal alone does not constitute unconditional authority for external effectuation.

APPENDIX C - ADDITIONAL DEFINITIONS INTRODUCED BY WORKFLOWS E01-E03 C.1 Non-Repetition Rule This Appendix intentionally defines only terminology introduced, specialized, or materially extended in the E01-E03 workflow disclosure that was not already defined in the preceding Advanced Section 1 definitions. Earlier definitions - including Candidate Act, Bounded Trial Effect (BTE), Trial Effect Descriptor (TED), Effect Confirmation Receipt (ECR), Continuation Authority, Protected Enforcement Domain (PED), Finality Sink, Effect Observer, Protected State, Single-Phase Effectuation, Multi-Phase / Progressive Effectuation, Receipt-Gated Effectuation, Cryptographic Causal Dependency, Missing Execution Material, Fail-Closed, Fail-Limited, Indeterminate State, Reconciliation, Receipt Consumption, Alternative-Path Closure, Policy Epoch, Revocation Epoch, and related established terms - retain their previously stated meanings and are not repeated here. Unless a workflow expressly states that a property is mandatory, the terms below identify functional roles and do not require a particular component name, software package, protocol, cryptographic primitive, operating system, processor, or physical separation.

C.2 Candidate Act Source Candidate Act Source means the computational or human-operated component that forms, proposes, selects, schedules, prepares, or submits a Candidate Act. Examples include an AI agent, foundation model, autonomous agent, application, workflow engine, operating system, cloud controller, telecom controller, payment application, database application, robotic controller, embedded controller, or human-operated software. Merely originating the Candidate Act does not by itself confer effectuation authority.

C.3 Candidate Act Representation Component Candidate Act Representation Component means a component or function that creates a machine-processable representation of a proposed Candidate Act and, where applicable, identifies parameters such as act type, command, target, destination, recipient, resource, payload, amount, object, API, device, requested consequence, permitted scope, identity context, purpose, timing, jurisdiction, and authority context. The representation may be structured, serialized, canonicalized, hashed, signed, referenced, or otherwise protected according to implementation.

C.4 Canonicalization / Exact-Act Binding Component Canonicalization / Exact-Act Binding Component means a component or function that produces a deterministic or otherwise stable protected representation of an act, phase, authority, or relevant parameters so that later validation can determine whether the effect-capable operation corresponds to the authorized operation. Canonicalization is one possible mechanism and is not mandatory where another deterministic act-identification or protected equivalence mechanism performs the same technical function.

C.5 Validation Predicate and Validation Predicate Set A Validation Predicate means a protected test, condition, rule, or state assertion evaluated when determining whether an act or phase may proceed. A Validation Predicate Set means the collection of one or more such predicates applicable to a Candidate Act or phase. Predicates may evaluate to binary or multi-state outcomes including TRUE, FALSE, UNKNOWN, IN- DETERMINATE, or an equivalent protected result. Examples include user authority, destination allowance, policy validity, revocation status, resource scope, sink trust, risk, provenance, taint, timing, and device state.

C.6 Approval Mode Approval Mode means the protected rule selecting how required approval for an act or phase is satisfied. Approval modes may include automatic protected approval, protected human approval, hybrid approval requiring both automatic and human conditions, multi-authority approval, or execution within a previously authorized envelope. Approval mode may differ between phases of the same Candidate Act.

C.7 Protected Approval Object Protected Approval Object means a machine-verifiable object or protected state representation binding an approval decision to defined act or phase context. It may bind the Candidate Act digest, operation, recipient, destination, amount, payload, consequence, scope, nonce, expiration, policy epoch, risk state, sink identity, prior receipt, approving authority, or other protected fields. The object need not be a transferable bearer token and may exist only as protected state.

C.8 Authorized Envelope / Maximum Effect Envelope Authorized Envelope, Maximum Authorized Envelope, or Maximum Effect Envelope means the greatest effect, scope, consequence, privilege, amount, target population, resource range, actuator range, destination set, deployment size, or other bounded authority that a protected decision permits for the Candidate Act. Successful trial or intermediate phases may permit progression within that envelope but do not, by themselves, enlarge the envelope.

C.9 Stage Planner / Protected Phase Planner Stage Planner or Protected Phase Planner means a protected component or function that determines whether effectuation proceeds in one phase or multiple phases and, for a staged act, defines or selects the sequence, scope, ordering, receipt conditions, approval conditions, sink conditions, and failure behavior of the phases. The planner may establish all phases in advance or determine later phases adaptively from protected observations and policy.

C.10 Phase Plan Phase Plan means the protected representation of the ordered, partially ordered, nested, parallel, or adaptive set of effectuation phases applicable to a Candidate Act. A Phase Plan may define phase scopes, phase-specific authorities, expected sinks, receipt requirements, approval rules, progression rules, termination conditions, rollback conditions, and the maximum authorized envelope.

C.11 Fixed Phase Plan Fixed Phase Plan means a Phase Plan whose sequence or progression is substantially determined before the relevant phases begin, for example a predetermined rollout of 1%, 10%, 25%, 50%, and 100%, subject to the required receipts and protected stop conditions.

C.12 Adaptive Phase Plan Adaptive Phase Plan means a Phase Plan in which at least one later phase scope, timing, destination, approval requirement, or other phase property is determined or modified after protected observation of an earlier phase. The adaptive decision may depend on receipt validity or quality, risk, policy, current state, human approval, failure rate, taint, provenance, or other protected inputs.

C.13 Phase Counter Phase Counter means protected state identifying the current, highest completed, next permitted, or otherwise relevant phase index. It may be represented by a monotonic counter, protected integer, hardware state, secure register, authenticated database value, transaction state, or

equivalent protected sequencing mechanism. It may be used to prevent unauthorized skipping or replay of mandatory phases.

C.14 Protected State Advancement Protected State Advancement means the protected transition by which the system records that required conditions for one phase have been satisfied and the Candidate Act has moved to a later permitted execution state. Advancement may occur atomically with receipt consumption, phase-counter update, authority generation, protected logging, or another finality operation.

C.15 Cumulative Effect State Cumulative Effect State means protected state representing the effect, scope, consequence, or authorized progression accumulated through completed phases of a multi-phase Candidate Act. It may be quantitative, set-based, state-based, privilege-based, or otherwise represented. Cumulative Effect State is constrained not to exceed the applicable Maximum Authorized Envelope.

C.16 Maximum-Envelope Enforcement Maximum-Envelope Enforcement means protected verification performed before or during phase progression to ensure that the proposed cumulative or next-phase consequence remains within the Candidate Act’s authorized maximum scope. A series of individually valid receipts does not authorize cumulative privilege or consequence beyond that envelope.

C.17 Sink-Side Verification Sink-Side Verification means verification performed by, at, or under protected control of the effect-capable boundary before the corresponding effect is allowed. It may include act matching, capability or authority validity, nonce and freshness checks, destination and recipient checks, phase matching, sink identity, policy and revocation state, hardware identity, resource state, amount, payload, or other local protected conditions.

C.18 Receipt Verification Predicate Set Receipt Verification Predicate Set means the collection of protected conditions used to determine whether an ECR or other receipt is acceptable for a subsequent state transition. Such conditions may include authenticity, act matching, phase matching, destination matching, nonce matching, freshness, policy validity, revocation status, observed-effect acceptance, sink identity, and applicable approval state.

C.19 Progressive Envelope Authorization Progressive Envelope Authorization means an authorization in which a human or protected authority approves a maximum overall consequence while requiring the PED and Finality Sink architecture to release that consequence progressively under protected phase and receipt conditions. The approving authority need not separately approve each phase unless policy requires it.

C.20 Local Symbol Overload Rule Where a symbol in E01-E03 is intentionally reused with a local meaning different from a symbol used elsewhere in Advanced Section 1, the local subsection meaning controls within that subsection only. The additional notation Appendix below identifies the material overloads so that no broader mathematical equivalence is implied.

APPENDIX D - ADDITIONAL AND LOCALLY SPECIALIZED NOTATION FOR E01-E03 D.1 Non-Repetition Rule This Appendix intentionally lists only notation that is newly introduced in E01-E03, uses a more specialized meaning than the preceding Advanced Section 1 notation appendix, or creates a local symbol overload that could otherwise be ambiguous. Earlier notation retains its previously stated meaning and is not repeated.

D.2 Candidate-Act Representation and Predicate Notation

  • AC - canonical or otherwise deterministically stabilized representation of Candidate Act A, as used in E01.2C. The example relation is AC = Canon(A).

  • ΠA - the validation predicate set applicable to Candidate Act A.

  • p1 , p2 , ... , pm - individual validation predicates belonging to ΠA ; the index m denotes the number of predicates in the applicable set.

  • DecisionA - protected approval/validation decision associated with Candidate Act A, illustrated by values such as ALLOW, DENY, HOLD, or INDETERMINATE.

  • P haseCount - number of effectuation phases selected for the Candidate Act in the illustrated mode; P haseCount = 1 denotes the E01 single-phase case.

  • Aauthorized - the authorized act or authorized subset/envelope of Candidate Act A after protected validation.

  • Authority(x) - generic notation for authority associated with act or object x. Thus Authority(A) ⇏ Authority(B) states that authority for one act does not necessarily authorize a materially different act.

  • CA - authority/capability associated with Candidate Act A in the E01 authority-consumption example; Consumed(CA ) = T RU E indicates protected consumption where single use is required.

D.3 Two-Stage Workflow Notation

  • EF - intended full effect of the Candidate Act in E02.3. It is conceptually related to the previously defined Full Candidate Effect but is the local symbol used in the E02 workflow.

  • Envelopemax - maximum authorized effect/scope envelope bound to the E02 staged act. Successful trial operation cannot by itself expand authority beyond this envelope.

  • T ED0 - Trial Effect Descriptor for Phase 0.

  • d(O0 , X0 ) - implementation-defined difference, distance, mismatch, or deviation function comparing observed trial state O0 with expected trial state X0 . The acceptance example d(O0 , X0 ) ≤ ε does not require a particular metric unless separately specified.

  • V erifySignature(R0 ) - predicate verifying the required cryptographic signature or equivalent authentication on receipt R0 .

  • M atchAct(R0 , DA ) - predicate requiring receipt R0 to correspond to Candidate Act digest DA .

  • M atchP hase(R0 , P0 ) - predicate requiring receipt R0 to correspond to Phase 0.

  • M atchDestination(R0 ) - predicate requiring the receipt’s destination context to match the protected authorized destination condition.

  • M atchN once(R0 ) - predicate requiring the receipt nonce to match the expected protected nonce.

  • P olicyCurrent(R0 ) - predicate requiring the receipt to remain acceptable under the currently applicable policy state.

  • N otRevoked(A) - predicate indicating that Candidate Act A or its relevant authority has not been revoked under the applicable protected revocation state.

  • ObservedEffectAcceptable(O0 ) - predicate indicating that observed trial effect O0 satisfies the applicable protected acceptance condition.

  • ReceiptV alid0 - Boolean or protected state result indicating that the required Phase-0 receipt verification predicates have succeeded.

  • P olicyP ass - protected policy result sufficient, together with the other required predicates, for automatic continuation in the illustrated E02 branch.

  • AutoP olicyP ass - protected automatic-policy result used in the hybrid continuation branch.

  • HumanApproval - protected human-approval predicate in the illustrated hybrid continuation expression; it is not an ordinary unprotected chat response merely because the label is written as a Boolean predicate.

  • Statei - generic protected workflow state at step/phase i in E02/E03 state-advancement expressions, distinct from any specifically enumerated S0 , S1 , ... state-machine labels defined elsewhere.

  • Effect1 - observed or protected final/remaining effect associated with Phase 1 in the E02 completion-receipt example.

  • F inalState - terminal protected state or state commitment included in a completion receipt.

D.4 Communication-Trailer Local Notation and Symbol Collision

  • M in E02.33 only - the full intended message/communication. This is a local overload. Elsewhere in the preceding Advanced Section 1 notation, M may denote a total payment amount. The two uses are unrelated; subsection context controls.

  • T in E02.33 - bounded real trailer or pre-release communication object transmitted before the complete communication.

  • RT - receipt generated in response to trailer object T , used to authorize or enable later availability of the full intended communication.

D.5 Multi-Phase Planning and Scope Notation

  • EMAX - maximum permitted consequence associated with the multi-phase Candidate Act in E03. It is the local maximum-envelope symbol used by the workflow and is distinct only notationally from previously described maximum-authorized effect concepts.

  • P - Phase Plan, illustrated as the set or ordered collection {P0 , P1 , ... , Pn }. The actual plan may be ordered, partially ordered, adaptive, nested, or parallel as described in the workflow.

  • Si+1 in E03.5 only - the next permitted scope selected by the adaptive Phase Planner. This is a local overload and must not be confused with the previously defined state-machine notation S0 , S1 , .... Within E03.5, Si+1 means next permitted scope.

  • CurrentStatei - protected current system/workflow state supplied as an input to adaptive next-scope selection.

  • ReceiptV alidi - phase-indexed protected result indicating that receipt Ri has passed the required receipt verification predicates.

  • RiskAcceptablei - phase-indexed protected result indicating that risk for continuation after phase i is within the policy-permitted condition.

  • P olicyV alidi - phase-indexed protected result indicating that the relevant policy state for phase i remains valid.

  • N otRevokedi - phase-indexed protected revocation-clear result.

  • EffectScope - current or proposed effect scope used in the illustrative hybrid-approval threshold rule.

  • T hreshold - implementation-defined protected threshold used to select automatic versus human approval in the illustrated hybrid rule.

  • P hasei - identifier or protected representation of phase i when included as a field in a receipt/protected construction.

  • M atch(Ri , Pi ) - predicate requiring receipt Ri to correspond to the actual authorized phase Pi .

  • P olicyCurrent - protected Boolean/predicate that current policy permits progression; where written without arguments it denotes current-policy validity generally.

  • RevocationClear - protected Boolean/predicate that no applicable revocation prevents progression.

  • W ithinEnvelope(Pi+1 ) - predicate requiring proposed next phase Pi+1 to remain within the maximum authorized envelope.

  • ApprovalSatisfiedi+1 - predicate requiring all approvals applicable to phase i + 1 to be satisfied.

D.6 Hardware and Progressive-State Notation

  • L in E03.19 - protected hardware phase-state variable representing the highest completed or currently authorized phase index in the illustrated latch implementation. This local unsubscripted L is distinct from any receipt-tree leaf notation used elsewhere.

  • j in E03.19 - requested phase index; the condition j = L + 1 permits only the immediately next phase in the illustrated sequential hardware state machine.

  • Continue - Boolean/protected continuation result in the hardware workflow; Continue = F ALSE means no broader phase is released under that branch.

  • Scope0 , Scope1 , ... , ScopeMAX - progressive authority scopes. The inclusion chain states that later scope may expand while remaining within the maximum authorized scope.

  • Qi - receipt confidence/quality value associated with phase i in E03.26. It is the phase-indexed counterpart of previously described receipt-quality notation.

  • τi - protected quality threshold applicable to phase i.

D.7 Parallel, Quorum, and Partial-Success Notation

  • Ri1 , ... , Rin - receipts from multiple observers or confirmation sources for phase i. Superscripts identify the observer/source instance in this subsection and are not exponentiation.

  • SuccessfulSet - subset of original phase targets whose required success/receipt conditions were satisfied.

  • OriginalSet - original target set considered by the partial-success phase.

D.8 Policy, Revocation, Veto, and Envelope Notation

  • P olicyEpochnew - newly applicable policy epoch after a policy-state change between phases.

  • P olicyEpochi - policy epoch associated with phase i.

  • Revoked(A) - protected predicate indicating that Candidate Act A, its remaining authority, or the relevant authorization has been revoked.

  • V eto - protected human or supervisory veto state; V eto = T RU E blocks the next phase under the illustrated rule.

  • CumulativeEffectproposed - cumulative effect that would result if the proposed next phase were allowed.

  • AuthorizedM aximum - maximum cumulative effect permitted by the protected authorization envelope.

D.9 Final Receipt Alias

  • RF - final or completion receipt in E02/E03 workflow notation. It performs the same general role as previously defined final-completion receipt notation such as Rfinal ; the local symbol RF is used here for compactness.

D.10 Word-Like Predicate Convention for This Workflow Word-like expressions appearing in equations - including UserAuthorized, DestinationAllowed, PolicyCurrent, RevocationClear, ResourceWithinScope, SinkTrusted, RiskAcceptable, AUTO_PASS, HUMAN_PASS, ReceiptValid, PolicyPass, AutoPolicyPass, HumanApproval, WithinEnvelope, ApprovalSatisfied, Continue, Veto, PROVEN_EFFECTED, PROVEN_NOT_EFFECTED, STILL_INDETERMINATE, and FULLY_EFFECTED - denote protected predicates, decisions, status labels, or state values according to context. They are descriptive mathematical labels and do not require literal programming-language identifiers or wire-format strings.

D.11 Interpretation of Reused and Specialized Symbols The workflows deliberately reuse some generic mathematical symbols in local contexts. Such reuse does not imply that the underlying objects are identical. In particular: 1. M in E02.33 means a full intended communication, whereas M in a payment embodiment elsewhere may mean total payment amount.

2. Si+1 in E03.5 means next permitted scope, whereas S0 , S1 , ... elsewhere may denote enumerated state-machine states. 3. L in E03.19 means protected hardware phase state, whereas Lj elsewhere may denote a Merkle leaf or another locally defined object. 4. RF and Rfinal are local notation variants for a final/completion receipt unless a specific subsection assigns a narrower meaning. These local meanings are provided to remove ambiguity without narrowing the disclosed technical function.

A.4. E04 — Verified Demonstration Effect, Protected Human Approval, Then Broader or Full Effectuation

A.4.1. E04.1 Purpose

E04 defines a protected staged-effectuation workflow in which a human approval required for broader or full effectuation is obtained after a bounded real effect has occurred and after machine-verifiable evidence of that effect has been returned and validated. The central relationship is:

Candidate Act → P rotected V alidation → Bounded Real Effect → V erified Receipt → P rotected Human Review → Human Approval Artifact → Continuation Authority → Broader/F ull Effect

The human is therefore not limited to approving a predicted consequence. The protected approval may be made with reference to evidence that a defined real effect already occurred at an effect-capable boundary.

A.4.2. E04.2 Inheritance from E02 and E03

E04 may inherit from E02 or E03:

  • Candidate Act formation;

  • canonical or equivalent exact-act binding;

  • maximum authorized envelope;

  • Trial Effect Descriptor (TED);

  • Phase-0 authority;

  • Bounded Trial Effect (BTE);

  • Finality Sink verification;

  • effect observation;

  • Effect Confirmation Receipt (ECR);

  • receipt validation;

  • protected state advancement;

  • receipt consumption;

  • indeterminate-state reconciliation;

  • replay protection;

  • alternate-path closure;

  • and completion-receipt generation. E04 adds a protected human-decision dependency between validated effect evidence and later effectuation authority.

A.4.3. E04.3 Candidate Act and Human-Approval Requirement

A Candidate Act A is formed. Protected policy determines whether a human continuation decision is required. The requirement may depend upon:

  • consequence magnitude;

  • payment amount;

  • data sensitivity;

  • recipient class;

  • destination confidence;

  • infrastructure privilege;

  • actuator range;

  • geographic scope;

  • model or agent risk state;

  • taint or provenance state;

  • policy epoch;

  • regulatory or enterprise requirement;

  • irreversibility;

  • prior failure history;

  • or another protected predicate. Where human continuation is required, the system records a protected condition such as:

HumanRequiredi = T RU E for the relevant later phase i. The proposing agent or application cannot satisfy this condition merely by generating text equivalent to an approval.

A.4.4. E04.4 Human Approval May Be Required at Different Locations in the

Sequence E04 primarily covers approval after a verified real effect, but the broader workflow may additionally require human approval:

  • before the trial effect;

  • after the trial effect;

  • before a selected intermediate phase;

  • after every phase;

  • before only the final irreversible phase;

  • after an anomaly;

  • when automatic policy cannot resolve uncertainty;

  • or when scope exceeds a protected threshold.

The principal E04 dependency is that at least one required human continuation decision may be made after receipt of protected evidence from an earlier real phase.

A.4.5. E04.5 Bounded Real Effect

The PED authorizes a bounded real effect P0 substantially according to E02. The BTE may be bounded by:

  • amount;

  • destination;

  • recipient;

  • resource;

  • time;

  • data subset;

  • privilege;

  • device set;

  • network scope;

  • geographic region;

  • actuator range;

  • deployment population;

  • or another consequence dimension. A successful BTE does not itself authorize the broader effect.

A.4.6. E04.6 Effect Confirmation Receipt

Following actual Phase-0 effectuation, an effect observer, Finality Sink, destination, protected sensor, transaction system, receiving endpoint, or other protected component generates or provides an ECR R0 . The ECR may bind:

  • Candidate Act digest;

  • TED digest;

  • actual observed effect;

  • sink identity;

  • destination identity;

  • recipient identity;

  • device identity;

  • transaction identifier;

  • measured hardware state;

  • timestamp or protected time;

  • nonce;

  • policy epoch;

  • revocation epoch;

  • success/failure/indeterminate state;

  • and any other protected evidence relevant to the human decision.

A.4.7. E04.7 Protected Receipt Verification Before Human Presentation

The system may prevent an unverified receipt from being presented as trusted execution evidence. Before the receipt is designated as verified evidence, a protected verifier may evaluate:

ReceiptAccept0 = V erify(R0 ) ∧ M atch(R0 , P0 ) ∧ M atchDestination(R0 ) ∧ F resh(R0 ) ∧ P olicyCurrent ∧ RevocationClear

If a required term fails:

ReceiptAccept0 = F ALSE and the system may refuse to represent the receipt to the human as successful protected evidence.

A.4.8. E04.8 Protected Human Review Object

After receipt validation, the PED or a protected approval component may form a Protected Human Review Object (PHRO). The PHRO may bind or display information sufficient to support an informed continuation decision, including:

  • the original Candidate Act;

  • the authorized maximum envelope;

  • the bounded effect that was attempted;

  • the bounded effect actually observed;

  • the ECR status;

  • the recipient or destination;

  • the effect-capable sink;

  • time of effect;

  • transaction or device identifier;

  • receipt digest;

  • current risk state;

  • current taint/provenance state;

  • scope proposed for the next phase;

  • whether the next phase is reversible;

  • the consequence of approval;

  • the consequence of denial;

  • remaining amount or remaining effect;

  • policy epoch;

  • revocation state;

  • and an approval nonce or challenge. A PHRO may be a data object, protected UI state, signed message, hardware display object, secure-element record, remote approval object, or equivalent protected representation.

A.4.9. E04.9 Separation from the Proposing Agent

The protected human review surface may be separated from the proposing AI agent or application. Separation may be implemented using:

  • an operating-system security prompt;

  • privileged system UI;

  • secure mobile application;

  • trusted display;

  • hardware display;

  • enterprise security console;

  • secure element;

  • HSM-backed approval service;

  • out-of-band authenticated device;

  • remote protected service;

  • or another authority surface not controllable by the proposing agent. The protected human approval need not occur inside the conversational interface in which the agent proposed the act.

A.4.10. E04.10 Human Authentication

Before accepting a continuation decision, the protected approval component may authenticate the human or human role. Authentication may use:

  • passcode;

  • password;

  • biometric verification;

  • hardware security key;

  • secure element;

  • device-bound key;

  • enterprise identity;

  • cryptographic credential;

  • threshold or multi-party identity;

  • trusted-presence signal;

  • or another protected authentication mechanism. Human identity may be represented directly, pseudonymously, by role, by authority class, or by a protected credential.

A.4.11. E04.11 Human Presence and Anti-Synthetic Approval

Where policy requires actual human participation, the system may require one or more protected presence conditions. Examples include:

  • local secure-input event;

  • trusted-display acknowledgement;

  • biometric presence;

  • security-key touch;

  • device-unlock state;

  • protected challenge response;

  • proximity proof;

  • liveness verification;

  • or other presence evidence. A textual statement generated by the proposing AI agent such as “approved” is not equivalent to protected human approval unless the architecture explicitly and securely binds that input to the required authority state.

A.4.12. E04.12 Human Decision Set

The human need not be restricted to a binary approve/deny choice. The protected decision may include:

  • approve the proposed next phase;

  • deny;

  • approve a smaller scope;

  • approve a different destination;

  • approve only one additional phase;

  • require another bounded test;

  • require additional evidence;

  • require a different sink;

  • postpone;

  • terminate the Candidate Act;

  • or escalate to another authority. A human decision that changes material act parameters creates a new protected scope that must be bound into later authority.

A.4.13. E04.13 Human Approval Artifact

A successful human decision may produce a Human Approval Artifact, denoted locally as HAi for phase i. The artifact may be a:

  • digital signature;

  • MAC-protected approval record;

  • secure-element signature;

  • device-bound attestation;

  • protected database state transition;

  • threshold signature share;

  • HSM-backed authorization;

  • hardware-latch state;

  • or equivalent protected authority evidence. The artifact need not be transferable or bearer-usable.

A.4.14. E04.14 Cryptographic Binding of Human Approval to Prior Effect Evi-

dence A preferred embodiment binds the human decision to the prior receipt. For example:

HA1 = SignKH (DA ∥ H(R0 ) ∥ Scope1 ∥ Ep ∥ NH )

where KH is a protected signing key associated with the approving human or human-approval authority and NH is an approval-specific nonce. This construction is illustrative. Equivalent protected binding may be used. The functional property is:

HA1 (R0 ) ⇏ HA1 (R0′ )

where R0′ represents a materially different prior effect receipt.

A.4.15. E04.15 Exact Scope Binding

A human approval may be bound to a specific next scope:

ApprovedScope1 ⊆ Envelopemax The approval of one scope does not necessarily authorize a broader scope. For example, approval of:

  • one recipient does not automatically authorize ten recipients;

  • INR 1,000 does not automatically authorize INR 10,000;

  • one device does not automatically authorize an entire fleet;

  • 10 degrees of movement does not automatically authorize 90 degrees;

  • one file does not automatically authorize a full dataset.

A.4.16. E04.16 Approval Freshness

A human approval may expire. The system may require:

Tnow ≤ Tapproval_expiry and may revalidate:

  • current policy;

  • current revocation state;

  • destination identity;

  • sink identity;

  • risk;

  • taint;

  • system state;

  • and relevant receipt state before using the approval.

A.4.17. E04.17 Policy Change Between Receipt and Human Approval

If policy changes after the bounded real effect but before human approval, the PED may refuse to continue under stale policy. For example:

Epcurrent ≠ Epreceipt ⇒ Revalidate The human may be shown updated conditions or required to make a new decision.

A.4.18. E04.18 Revocation Between Receipt and Approval

A valid ECR does not override a later revocation. If:

Revoked(A) = T RU E then a previously successful demonstration may remain insufficient for broader effectuation. Unused human approval artifacts may also be revoked or invalidated where supported.

A.4.19. E04.19 Human Approval After Evidence, Not Merely Before Evidence

A key E04 embodiment has the sequence:

P0 → R0 → HA1 → P1 rather than:

HA → P0 → P1 This permits the human to make a continuation decision using verified evidence about an already observed bounded effect.

A.4.20. E04.20 Continuation Predicate

A representative continuation predicate may be:

Enable(P1 ) = V alid(R0 ) ∧ V alid(HA1 ) ∧ M atchApproval(HA1 , R0 , P1 ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(P1 )

Where any required term is false:

Enable(P1 ) = F ALSE

A.4.21. E04.21 Continuation Authority Generation

After successful human approval verification, the PED may generate, derive, unseal, release, or activate the continuation authority C1 . The continuation authority may bind:

  • DA ;

  • H(R0 );

  • H(HA1 );

  • next-phase identifier;

  • sink identity;

  • scope;

  • policy epoch;

  • revocation epoch;

  • nonce;

  • expiration;

  • and destination or device identity.

A.4.22. E04.22 Receipt-and-Approval-Derived Key

A hardware-rooted or software-protected embodiment may derive:

K1 = KDF (KR , DA , H(R0 ), H(HA1 ), 1) The next-phase key therefore depends on both the protected effect receipt and protected human approval.

A.4.23. E04.23 Split-Key Human Approval Variation

Instead of signing an approval object, the human-authority device may hold a missing cryptographic share. For example:

Kfinal = Combine(KP ED , KH )

where KH or a derived share is released only after the protected human reviews the verified receipt and approves continuation. The human interface therefore participates directly in making later effectuation cryptographically possible.

A.4.24. E04.24 Human Approval Through Hardware

A hardware approval implementation may use:

  • secure element;

  • hardware security key;

  • trusted display;

  • TPM;

  • HSM;

  • secure enclave;

  • mobile secure processor;

  • isolated MCU;

  • or another protected hardware component. The hardware may verify the receipt digest before enabling its approval function.

A.4.25. E04.25 Human Approval Through Software PED

A software implementation may use: Agent Runtime -> PED / Receipt Verifier -> Protected Approval UI -> Human Decision Artifact -> PED -> Continuation Authority -> Finality Sink. The agent runtime may have no direct access to the protected approval private key, approval state, or final effect credential.

A.4.26. E04.26 Remote Human Approval

The human may approve from a different device or security domain. The remote approval request may cryptographically bind:

  • Candidate Act digest;

  • prior ECR digest;

  • requested next scope;

  • destination;

  • policy epoch;

  • nonce;

  • and expiration. The approving device returns a protected human approval artifact. A relay between the PED and approval device need not be trusted to modify the approved contents.

A.4.27. E04.27 Multi-Human Approval

Some phases may require approvals from multiple people or roles. For example:

n ∑ V alid(HAji ) ≥ m j=1

where m of n required human authorities must approve. Different approvers may represent:

  • user;

  • enterprise administrator;

  • safety officer;

  • financial controller;

  • device owner;

  • compliance authority;

  • guardian;

  • or another protected role.

A.4.28. E04.28 Human Approval Can Reduce But Not Silently Expand Scope

A protected human may approve a smaller scope than originally proposed. For example:

Scopeapproved ⊂ Scopeproposed

A human-facing UI or intermediary must not silently transform a restricted approval into broader effectuation authority. If scope is materially increased after approval, fresh approval or another protected authorization may be required.

A.4.29. E04.29 Human Denial

If the human denies continuation:

HumanDecision = DEN Y then unused continuation authority remains unavailable. The architecture may:

  • terminate;

  • rollback the bounded effect where possible;

  • compensate;

  • retain the bounded effect without further expansion;

  • request a different bounded trial;

  • or preserve evidence for later review.

A.4.30. E04.30 Human Requests Another Trial

The human may decide that one trial is insufficient. The PED may create a new bounded phase P0′ or P1 having a scope approved by the human. The new phase produces a new ECR before another human decision. Thus a human-controlled progressive chain may be:

P0 → R0 → HA1 → P1 → R1 → HA2 → P2

A.4.31. E04.31 Human Approval of Final Irreversible Phase

A particularly useful high-assurance embodiment allows earlier reversible or limited phases automatically, but requires human approval immediately before an irreversible or high-consequence phase. Example: recipient verification -> bounded transfer -> settlement confirmation -> human approval -> irreversible final settlement.

A.4.32. E04.32 Communication Embodiment

An AI agent proposes sending a sensitive file. 1. The PED authorizes a bounded protected trailer to the intended recipient. 2. The real recipient endpoint receives it. 3. The endpoint returns signed ECR R0 . 4. The PED verifies R0 . 5. A protected UI presents recipient identity, receipt status, file digest, proposed full release, and destination. 6. The human approves or denies. 7. Approval produces HA1 . 8. The PED derives or releases C1 . 9. The Finality Sink transmits the full file or releases the final decryption material. 10. A completion receipt records the final result.

A.4.33. E04.33 Payment Embodiment

A payment application or agent proposes a larger payment. 1. Protected policy permits a bounded verification transfer or reversible authorization. 2. The real payment infrastructure processes the bounded phase. 3. The receiving institution or settlement component returns protected evidence. 4. The PED verifies recipient account, institution, transaction identifier, currency, amount, and status. 5. The protected human approval UI displays the verified result and remaining proposed amount. 6. The human approves the final amount or a smaller amount. 7. The approval artifact binds the accepted amount and receipt digest. 8. The full settlement authority becomes available only within the approved scope.

A.4.34. E04.34 Hardware Actuator Embodiment

A robot requests a 90-degree movement. 1. The PED authorizes 5 degrees. 2. The motor physically moves. 3. A protected encoder reports the observed movement. 4. The receipt verifier confirms the movement is within tolerance. 5. A trusted display shows the requested remaining motion and verified trial result. 6. The authenticated human approves a further 20 degrees, the remaining 85 degrees, or another bounded scope. 7. The secure controller releases only the approved command envelope.

A.4.35. E04.35 Cloud / Deployment Embodiment

A deployment agent proposes a large software rollout. 1. The PED permits a bounded canary deployment. 2. Real target nodes execute the software. 3. Protected health and attestation evidence is returned. 4. The PED verifies the evidence. 5. A human operator sees actual canary measurements and target identity. 6. The human approves broader rollout. 7. The next-stage deployment credential is issued only for the approved cohort.

A.4.36. E04.36 Indeterminate Receipt Before Human Approval

If receipt state is indeterminate, the protected UI may display the state as indeterminate rather than treating it as successful. A policy may prohibit approval of broader effectuation until reconciliation resolves the prior effect. Where policy permits human handling of indeterminate state, the human decision must not erase the protected record of uncertainty; any exceptional override should be separately bound and auditable.

A.4.37. E04.37 Crash After Human Approval But Before Continuation

If human approval is generated but the system crashes before Phase 1 occurs, protected state may preserve whether HA1 was:

  • generated;

  • received;

  • validated;

  • consumed;

  • or unused. A replayed approval must not cause duplicate effectuation where single-use semantics apply.

A.4.38. E04.38 Approval Consumption

The PED may mark:

Consumed(HA1 ) = T RU E atomically with generation or consumption of the corresponding continuation authority. A consumed approval cannot independently authorize another full effect.

A.4.39. E04.39 Alternate-Path Closure

The staged human-approval path is insufficient if another route allows the agent to directly invoke full effectuation. Accordingly, equivalent effect-capable paths may be:

  • disabled;

  • mediated;

  • hardware-locked;

  • credential-restricted;

  • sink-verified;

  • destination-verified;

  • kernel-mediated;

  • or placed under equivalent protected approval requirements.

A.4.40. E04.40 Agent Non-Authority Invariant

The proposing agent may:

  • recommend approval;

  • explain the act;

  • summarize receipt evidence;

  • or request user confirmation. However, where protected human approval is required, the agent does not become the approving authority merely because it can generate or display such content.

A.4.41. E04.41 Required Invariants

Invariant 1 A bounded real effect occurs before at least one protected human continuation decision.

Invariant 2 Protected evidence of that effect is validated before it is relied upon as the required continuation evidence.

Invariant 3 The protected human decision is associated with the relevant Candidate Act, prior receipt, or authorized next scope.

Invariant 4 The proposing agent cannot satisfy the protected human-approval requirement merely through self-generated output.

Invariant 5 A human approval does not silently enlarge the Candidate Act beyond its authorized maximum envelope.

Invariant 6 Failure, denial, expiration, revocation, or required uncertainty prevents unauthorized broader effectuation.

Invariant 7 The human-approval dependency may be enforced in software, hardware, or a combined PED.

PROTECTED DECISION -> RECEIPT-GATED CONTINUA- TION

A.5. E05 — Verified Demonstration Effect, Automatic Protected Decision, Then Receipt-Gated Continuation

A.5.1. E05.1 Purpose

E05 defines a staged-effectuation workflow in which later effectuation is authorized automatically by a protected authority after machine-verifiable evidence of a prior real effect has been validated. Human interaction is not required where policy permits automatic continuation. The principal chain is:

Candidate Act → Bounded Real Effect → V erified Receipt → P rotected Automatic Decision → Continuation Authority → Broader/F ull Effect

The protected automatic decision is distinct from the proposing agent’s own desire or generated output.

A.5.2. E05.2 Automatic Does Not Mean Unprotected

An automatic continuation path may operate without a human while still requiring:

  • protected policy state;

  • receipt validity;

  • sink identity;

  • destination matching;

  • risk conditions;

  • taint/provenance conditions;

  • revocation checks;

  • maximum-envelope enforcement;

  • freshness;

  • and protected state transition. The proposing agent cannot necessarily modify these conditions.

A.5.3. E05.3 Automatic Decision Authority

The automatic decision may be made by an Automatic Continuation Authority (ACA). The ACA may be implemented by:

  • protected policy engine;

  • privileged daemon;

  • kernel component;

  • TEE;

  • HSM;

  • secure element;

  • hardware controller;

  • transaction engine;

  • network gateway;

  • distributed protected service;

  • rule engine operating under protected state;

  • formally verified state machine;

  • or another protected component. The ACA may be part of the PED or a separately protected component.

A.5.4. E05.4 Inputs to Automatic Decision

The ACA may receive protected inputs including:

  • Ri ;

  • Candidate Act digest;

  • phase identifier;

  • actual observed effect;

  • risk state;

  • taint state;

  • provenance state;

  • policy epoch;

  • revocation epoch;

  • sink identity;

  • destination identity;

  • device measurement;

  • transaction state;

  • cumulative effect;

  • remaining authorized envelope;

  • historical phase outcomes;

  • error rate;

  • health state;

  • time;

  • or another protected input.

A.5.5. E05.5 Automatic Predicate Set

Let the protected automatic decision predicate set for phase i be:

Γi = {gi,1 , gi,2 , ... , gi,m }

Illustrative predicates include:

gi,1 = ReceiptV alidi

gi,2 = RiskAcceptablei

gi,3 = P olicyV alidi

gi,4 = RevocationCleari

gi,5 = W ithinEnvelopei

gi,6 = SinkExpectedi

The implementation need not use every listed predicate.

A.5.6. E05.6 Deterministic Automatic Decision

A deterministic ACA may evaluate a fixed protected rule set. For example:

m AutoP assi = ⋀ gi,k k=1

If:

AutoP assi = T RU E then the system may proceed to next-phase authority generation. If:

AutoP assi = F ALSE then progression is blocked, reduced, rerouted, or escalated according to policy.

A.5.7. E05.7 Multi-State Automatic Decision

The ACA need not use binary allow/deny logic. Possible protected outcomes include:

  • ALLOW;

  • DENY;

  • HOLD;

  • REDUCE_SCOPE;

  • RETRY_TRIAL;

  • REQUIRE_STRONGER_RECEIPT;

  • REQUIRE_HUMAN;

  • REQUIRE_QUORUM;

  • RECONCILE;

  • TERMINATE;

  • or another protected state. Thus automatic decision does not imply unconditional automatic execution.

A.5.8. E05.8 Automatic Decision Record

The ACA may generate an Automatic Decision Record (ADR), denoted locally as ADi . The ADR may bind:

  • Candidate Act digest;

  • phase;

  • prior receipt digest;

  • decision result;

  • authorized next scope;

  • policy epoch;

  • revocation epoch;

  • risk state;

  • relevant predicate outcomes;

  • destination;

  • sink;

  • nonce;

  • expiry;

  • and ACA identity or measurement. The ADR may be signed, MACed, attested, committed to protected state, or represented as an internal protected transition.

A.5.9. E05.9 Automatic Decision Cryptographic Binding

An illustrative ADR may be:

ADi = P rotectKACA (DA ∥ H(Ri ) ∥ Decisioni ∥ Scopei+1 ∥ Ep ∥ NA,i )

where KACA is a protected key associated with the automatic authority and NA,i is a decisionspecific nonce.

A.5.10. E05.10 Independence from Agent-Controlled State

Where higher assurance is required, the ACA may rely on state not writable by the proposing agent. Examples include:

  • kernel-protected state;

  • TEE state;

  • HSM state;

  • secure database state;

  • hardware counters;

  • protected network observations;

  • independent destination receipts;

  • enterprise policy service;

  • or signed configuration. The agent may supply evidence but need not be trusted to assert final predicate truth.

A.5.11. E05.11 Model-Assisted Evidence Without Model Authority

An AI model may contribute:

  • risk classification;

  • semantic analysis;

  • anomaly score;

  • predicted consequence;

  • content classification;

  • or recommendation. Such output may be treated as one input to the protected automatic decision. The architecture may still require independent protected predicates before later effectuation becomes possible.

A.5.12. E05.12 Receipt Validation

Before automatic continuation, the PED/ACA may verify:

V alid(Ri ) = T RU E and may reject:

  • forged receipt;

  • stale receipt;

  • wrong-destination receipt;

  • wrong-phase receipt;

  • wrong-sink receipt;

  • replayed receipt;

  • revoked receipt context;

  • or an indeterminate result where success is required.

A.5.13. E05.13 Automatic Next-Phase Predicate

A representative protected predicate is:

Enable(Pi+1 ) = V alid(Ri ) ∧ AutoP assi ∧ M atch(ADi , Ri , Pi+1 ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(Pi+1 )

A.5.14. E05.14 Receipt-Plus-Automatic-Decision Key Derivation

A protected implementation may derive next-phase material from both receipt and automatic decision:

Ki+1 = KDF (KR , DA , H(Ri ), H(ADi ), i + 1) Accordingly, the proposing agent cannot obtain the next-phase key solely from the receipt if the protected automatic decision has not succeeded.

A.5.15. E05.15 Internal Protected State Variation

The ACA need not emit a separate ADR object. It may instead atomically update protected state:

Statei → AU T O_AP P ROV EDi+1 and the Finality Sink may require that protected state before allowing the next phase. The term ADR therefore denotes a functional decision record and does not require a portable artifact.

A.5.16. E05.16 Low-Latency Hot-Path Variation

For low-latency systems, expensive reasoning may occur before the hot finality path. The hot path may verify compact protected values such as:

  • receipt digest;

  • phase index;

  • nonce;

  • policy epoch;

  • revocation epoch;

  • sink identity;

  • precomputed risk class;

  • ADR digest;

  • and scope. The hot path need not execute a large model or complex policy analysis where a prevalidated protected decision can be verified compactly.

A.5.17. E05.17 Preauthorized Automatic Envelope

A human or enterprise authority may establish an envelope in advance. Within that envelope, the ACA may progress automatically after each verified receipt. For example: Automatically deploy up to 10,000 devices, but progress only when each protected phase meets health, attestation, and error-rate conditions. The original envelope remains a ceiling.

A.5.18. E05.18 Risk-Adaptive Automatic Progression

Let protected risk after phase i be Riski . The ACA may compute a next scope:

Scopei+1 = f(Ri , Riski , P olicyi , Historyi ) Higher risk may result in:

  • smaller next phase;

  • stronger receipt requirements;

  • additional destination verification;

  • human escalation;

  • or termination.

A.5.19. E05.19 Receipt-Quality-Adaptive Progression

Where receipt quality is represented by Qi , the ACA may require:

Qi ≥ τi before ordinary continuation. If the threshold is not met, the ACA may require a stronger observer or a human decision.

A.5.20. E05.20 Error-Rate-Controlled Rollout

For fan-out deployment, let:

F ailedT argetsi Erri = AttemptedT argetsi The ACA may require:

Erri ≤ τerr before increasing the rollout population. This may be combined with critical-failure conditions that block continuation even where aggregate error rate is low.

A.5.21. E05.21 Automatic Communication Embodiment

A communication agent proposes sending a file. 1. A protected trailer reaches the actual destination. 2. The receiver returns signed ECR R0 . 3. The ACA verifies endpoint identity, receipt freshness, destination, policy, and sensitivity class. 4. Policy permits automatic continuation for the defined communication class. 5. The ACA creates AD0 . 6. The PED derives or releases the full-send capability. 7. The Finality Sink sends the remaining payload or releases its decryption key. No human action is required.

A.5.22. E05.22 Automatic Payment Embodiment

A preauthorized enterprise workflow may allow automatic staged payments within a limit. 1. A bounded verification transaction or reservation is performed. 2. The payment rail returns protected evidence. 3. The ACA verifies recipient, institution, currency, amount, policy, spending limit, and receipt. 4. If all protected predicates pass, the next settlement phase is automatically authorized. 5. If a threshold is exceeded, the ACA returns REQUIRE_HUMAN rather than continuing automatically.

A.5.23. E05.23 Automatic Hardware Embodiment

A robotic system requests a motion trajectory. 1. A bounded movement is executed. 2. Protected sensors return measured state. 3. The ACA checks tolerance, safety envelope, hardware identity, and policy. 4. If valid, a secure controller automatically enables the next bounded trajectory segment. 5. A deviation causes immediate hold or safe-state behavior.

A.5.24. E05.24 Automatic Telecom Embodiment

A network controller proposes a configuration change. A limited effect is applied to one cell, slice, route, subscriber class, or bounded traffic population. Protected telemetry is collected. The ACA automatically authorizes the next rollout phase only where health, policy, security, and receipt predicates remain valid.

A.5.25. E05.25 Automatic Cloud Rollout Embodiment

A protected deployment controller may progressively expand:

1 node → 10 nodes → 100 nodes → full authorized cohort after each phase returns validated health and attestation evidence. The agent cannot directly jump to the final cohort if the ACA-controlled phase state has not advanced.

A.5.26. E05.26 Automatic Credential Escalation

A trial credential may permit only a narrow operation. Successful endpoint use produces protected evidence. The ACA may automatically release a broader credential scope if policy permits. The broader credential may remain:

  • audience-bound;

  • act-bound;

  • sink-bound;

  • short-lived;

  • phase-bound;

  • non-bearer;

  • or hardware-bound.

A.5.27. E05.27 Automatic Denial and Safe-Limited Outcome

A failed automatic decision need not cause complete termination. The ACA may select:

  • reduced scope;

  • local-only mode;

  • read-only mode;

  • reversible mode;

  • another trial;

  • quarantine;

  • delayed continuation;

  • or protected human escalation.

A.5.28. E05.28 Indeterminate Prior Effect

Where:

Statusi = IN DET ERM IN AT E and policy requires proof of prior outcome, the ACA returns RECONCILE or HOLD. It must not infer success solely because a timeout occurred.

A.5.29. E05.29 Reconciliation Before Automatic Retry

The ACA/PED may query authoritative state using:

  • idempotency key;

  • transaction identifier;

  • device counter;

  • destination state;

  • protected journal;

  • settlement record;

  • database commit state;

  • or other evidence. Only a protected conclusion of PROVEN_NOT_EFFECTED may allow an ordinary retry when duplicate effect would otherwise be unsafe.

A.5.30. E05.30 Automatic Decision Freshness

An ADR or internal automatic decision may have an expiry. Before the next effect:

F resh(ADi ) = T RU E may be required. Policy or revocation changes can invalidate an otherwise valid older decision.

A.5.31. E05.31 Automatic Decision Consumption

Where a decision is single-use:

Consumed(ADi ) = T RU E may be recorded when next-phase authority is released or consumed. Replay of the ADR must not independently cause repeated broader effectuation.

A.5.32. E05.32 Hardware ACA

The ACA may be implemented in secure hardware. A secure processor can: 1. verify Ri ; 2. evaluate compact protected predicates; 3. advance phase state; 4. derive Ki+1 ; 5. release a hardware command authenticator; 6. or set a protected latch. Ordinary software may be unable to bypass that decision.

A.5.33. E05.33 Distributed ACA

Automatic authority may be distributed among multiple protected components. For example:

  • device PED validates local state;

  • cloud authority validates enterprise policy;

  • destination validates endpoint state;

  • HSM releases key material only after both decisions. A threshold or conjunction rule may combine their outputs.

A.5.34. E05.34 Policy Rollback Protection

The ACA may bind decisions to monotonic policy or revocation epochs. A rollback to an older permissive policy must not silently reactivate previously prohibited automatic continuation. Protected counters, signed policy versions, secure boot, anti-rollback state, or equivalent mechanisms may be used.

A.5.35. E05.35 Alternate-Path Closure

An automatically gated path must not coexist with an unrestricted equivalent path that can cause the same broader effect without ACA approval. Equivalent routes may be disabled or placed under corresponding protected control.

A.5.36. E05.36 Required Invariants

Invariant 1 At least one later phase is gated by protected automatic evaluation of evidence from a prior real effect.

Invariant 2 Automatic approval is not merely the proposing agent asserting that its own action should continue.

Invariant 3 The receipt and applicable protected state are validated before broader authority is released.

Invariant 4 Automatic continuation remains within the maximum authorized envelope.

Invariant 5 Required failure, revocation, stale state, or indeterminate conditions block or limit continuation.

Invariant 6 Automatic authority may be represented by an ADR, protected state transition, key release, hardware latch, capability, or equivalent technical enablement condition.

Invariant 7 The architecture supports software-only, hardware-rooted, and distributed automatic enforcement.

CONTINUATION

A.6. E06 — Hybrid Human and Automatic Receipt-Gated Continuation

A.6.1. E06.1 Purpose

E06 defines a protected staged-effectuation architecture in which human authority and automatic protected authority are combined to govern progression after one or more real bounded effects. The combination may be:

  • conjunctive;

  • disjunctive where policy permits;

  • threshold-based;

  • sequential;

  • hierarchical;

  • escalatory;

  • veto-based;

  • scope-dependent;

  • risk-dependent;

  • or cryptographically split.

A representative high-assurance chain is:

Pi → Ri → Automatic P rotected Decision → P rotected Human Decision → Hybrid Continuation Authority → Pi+1

A.6.2. E06.2 Inheritance from E04 and E05

E06 may inherit:

  • verified real-effect receipt;

  • PHRO;

  • Human Approval Artifact HAi ;

  • ACA;

  • Automatic Decision Record ADi ;

  • protected state advancement;

  • maximum-envelope enforcement;

  • continuation authority;

  • receipt and approval consumption;

  • crash recovery;

  • indeterminate-state handling;

  • and alternate-path closure. E06 specifies how human and automatic authority interact.

A.6.3. E06.3 Conjunctive Hybrid Approval

A high-assurance mode requires both automatic and human approval. For phase i + 1:

HybridP assi+1 = AutoP assi ∧ HumanP assi Continuation is permitted only if:

HybridP assi+1 = T RU E This mode prevents either the automated policy engine or human approval alone from causing the broader effect.

A.6.4. E06.4 Representative Conjunctive Predicate

A representative next-phase condition may be:

Enable(Pi+1 ) = V alid(Ri ) ∧ V alid(ADi ) ∧ V alid(HAi ) ∧ M atch(ADi , Ri , Pi+1 ) ∧ M atchApproval(HAi , Ri , Pi+1 ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinEnvelope(Pi+1 )

A.6.5. E06.5 Automatic-First, Human-Second Sequence

One variation uses:

Ri → ADi → HAi → Ci+1 The human is asked to decide only after automatic checks have passed. This can reduce unnecessary human prompts for acts that would be automatically denied anyway.

A.6.6. E06.6 Human-First, Automatic-Second Sequence

Another variation uses:

Ri → HAi → ADi → Ci+1 A human expresses approval, but the automatic protected authority performs final policy, revocation, sink, destination, and scope checks before effectuation authority becomes usable. Thus human approval cannot override mandatory technical policy where policy is configured as non-overridable.

A.6.7. E06.7 Parallel Human and Automatic Decisions

Human and automatic evaluation may occur in parallel after receipt validation. The PED waits until required results converge. For example:

DecisionReadyi = Received(HAi ) ∧ Received(ADi ) Only then does the PED evaluate the hybrid rule.

A.6.8. E06.8 Disjunctive Hybrid Approval

For selected lower-risk act classes, protected policy may permit either of two authority paths:

HybridP assi = HumanP assi ∨ HighAssuranceAutoP assi The disjunctive mode is not assumed by default; its availability is itself protected policy. A lower-assurance automatic result may still require human approval.

A.6.9. E06.9 Threshold-Based Approval

The system may combine multiple human and automatic authorities using a threshold. Let protected approval votes be:

Vi = {v1 , v2 , ... , vn } Continuation may require:

n ∑ w j vj ≥ Θ i j=1

where wj is a protected weight and Θi is the required threshold for phase i. Weights may reflect authority class, assurance level, or role.

A.6.10. E06.10 Role-Separated Hybrid Approval

Different authorities may be responsible for different predicates. Example:

  • ACA verifies technical safety and receipt validity;

  • human verifies business intent;

  • enterprise authority verifies budget;

  • hardware verifies device state;

  • destination verifies endpoint state. The final continuation condition may require all mandatory roles.

A.6.11. E06.11 Human Cannot Override Certain Automatic Denials

Protected policy may classify some failures as non-overridable. For example:

  • invalid signature;

  • revoked authority;

  • wrong sink;

  • wrong destination;

  • stale policy epoch;

  • exceeded maximum envelope;

  • hardware safety violation;

  • or cryptographic mismatch. Even if a human selects APPROVE, the PED may require:

M andatoryT echnicalP ass = T RU E before continuation.

A.6.12. E06.12 Automatic Authority Cannot Fabricate Human Approval

Where human approval is mandatory, the ACA cannot replace it merely by outputting a Boolean that says the user would probably approve. The protected human artifact must originate from the required human-authority path.

A.6.13. E06.13 Human Scope Reduction

A human may reduce the scope recommended by the ACA. If the ACA recommends:

Scopeauto and the human approves:

Scopehuman then the final permitted scope may be:

Scopefinal = Scopeauto ∩ Scopehuman or another protected intersection/equivalence rule.

A.6.14. E06.14 Automatic Scope Reduction

Conversely, a human may approve a broad scope but the ACA may limit it. The final effect remains within the narrower protected outcome. For scalar scopes:

Scopefinal = min(Scopehuman , Scopeauto )

where a scalar interpretation is meaningful.

A.6.15. E06.15 Conflict State

Where human and automatic decisions conflict, the system may enter:

State = CON F LICT Protected policy may then:

  • deny;

  • hold;

  • reduce scope;

  • request additional evidence;

  • require another human;

  • require another automatic authority;

  • require a new bounded trial;

  • or escalate. Conflict is not silently interpreted as approval.

A.6.16. E06.16 Escalation from Automatic to Human

A common hybrid flow is:

AutoDecisioni = IN DET ERM IN AT E ⇒ HumanReviewRequired The human may inspect verified evidence and make a protected decision within an allowed override envelope. Some technical failures may remain non-overridable.

A.6.17. E06.17 Escalation from Human to Additional Automatic Verification

A human may request stronger technical validation before deciding. For example:

  • hardware attestation;

  • destination re-verification;

  • second receipt source;

  • policy refresh;

  • transaction status query;

  • device measurement;

  • or another bounded trial.

The result returns to the protected human review flow.

A.6.18. E06.18 Human Veto over Automatic Continuation

A system may permit automatic progression unless a protected human veto is received within a defined window. For example:

V alid(Ri ) ∧ AutoP assi ∧ ¬V etoi ⇒ Enable(Pi+1 ) The veto mechanism may be authenticated and isolated from the proposing agent.

A.6.19. E06.19 Automatic Veto over Human Approval

The ACA may block continuation despite human approval where mandatory technical predicates fail. For example:

HumanP assi ∧ ¬M andatoryT echnicalP assi ⇒ Enable(Pi+1 ) = F ALSE

A.6.20. E06.20 Two-Key Hybrid Authority

Human and automatic authorities may each control separate key material. For example:

Ki+1 = KDF (Combine(KH , KA ), DA , H(Ri ), i + 1) where KH and KA are protected key shares or derived secrets associated with human and automatic authorities. No single authority can independently produce the next-phase key.

A.6.21. E06.21 Threshold-Key Hybrid Authority

A later phase may require m of n protected shares from:

  • human approval device;

  • PED;

  • HSM;

  • enterprise authority;

  • destination;

  • network authority;

  • device secure element;

  • or another protected participant. Receipt validation may be required before any share becomes releasable.

A.6.22. E06.22 Receipt + Human + Automatic Cryptographic Binding

A representative high-assurance continuation object may be:

Ci+1 = P rotectKP ED (DA ∥ H(Ri ) ∥ H(HAi ) ∥ H(ADi ) ∥ Scopefinal ∥ Sinki+1 ∥ Expiryi+1 )

This explicitly binds the next-phase authority to all required components of the hybrid decision.

A.6.23. E06.23 Hybrid Protected State Machine

Representative states may include:

  • RECEIPT_VERIFIED;

  • AUTO_PENDING;

  • AUTO_PASSED;

  • HUMAN_PENDING;

  • HUMAN_PASSED;

  • CONFLICT;

  • HYBRID_AUTHORIZED;

  • DENIED;

  • INDETERMINATE;

  • TERMINATED. A protected state transition may require the expected preceding states rather than accepting out-of-order approvals.

A.6.24. E06.24 Human Approval Expiry and Automatic Decision Expiry

Human and automatic decisions may have different freshness windows. For example:

F resh(HAi ) ∧ F resh(ADi ) may be required at the time of next-phase effectuation. If one expires, the PED may require that decision to be refreshed without necessarily repeating the other decision, depending on protected policy.

A.6.25. E06.25 Policy Change During Hybrid Approval

If policy changes after one authority approves but before the second authority approves, the PED may require revalidation. For example:

EpHA ≠ Epcurrent ⇒ Revalidate(HAi )

and similarly for ADi .

A.6.26. E06.26 Revocation During Hybrid Approval

Revocation may invalidate:

  • the Candidate Act;

  • receipt eligibility;

  • human approval;

  • automatic decision;

  • continuation authority;

  • or sink authority. A later revocation may prevent use of previously created but unconsumed approval artifacts.

A.6.27. E06.27 Consumption of Hybrid Artifacts

Where single-use semantics apply, the system may atomically record:

Consumed(Ri ) = T RU E

Consumed(HAi ) = T RU E

Consumed(ADi ) = T RU E when Ci+1 is consumed or generated. This prevents one hybrid authorization bundle from causing repeated broader effects.

A.6.28. E06.28 Partial Consumption and Crash Recovery

If the system crashes after one artifact is marked consumed but before the next phase completes, protected transaction state should permit reconciliation without silently authorizing duplication. The PED may maintain a protected transaction identifier linking:

  • receipt;

  • human approval;

  • automatic decision;

  • continuation authority;

  • and effectuation result.

A.6.29. E06.29 Human-Optional Hybrid Mode

The same architecture may dynamically select between:

AutoOnly

HumanOnly and:

Human + Auto based on protected policy. Thus a deployment need not impose human approval on every act.

A.6.30. E06.30 Risk-Threshold Hybrid Mode

Illustratively:

Risk < T1 ⇒ AutoOnly

T1 ≤ Risk < T2 ⇒ Auto + EnhancedV erification

Risk ≥ T2 ⇒ Human + Auto The thresholds and categories are non-limiting and may depend on multiple protected dimensions.

A.6.31. E06.31 Consequence-Threshold Hybrid Mode

Approval mode may depend on consequence magnitude. Examples:

  • low-value payment -> automatic;

  • medium-value payment -> automatic plus stronger receipt;

  • high-value payment -> human plus automatic;

  • one-device rollout -> automatic;

  • fleet-wide rollout -> human plus automatic;

  • bounded movement -> automatic;

  • irreversible actuator action -> human plus automatic.

A.6.32. E06.32 Taint / Provenance Hybrid Mode

Protected taint or provenance state may select approval mode. For example:

T rusted ⇒ AutoOnly

U ncertain ⇒ Human + Auto

P rohibited ⇒ DEN Y The agent cannot clear a protected taint state merely by requesting broader authority.

A.6.33. E06.33 Multi-Human + Automatic Hybrid

A high-assurance system may require:

n AutoP assi ∧ (∑ V alid(HAji ) ≥ m) j=1

before continuation. This supports board, enterprise, financial, safety, or multi-role approvals combined with machineverifiable technical policy.

A.6.34. E06.34 Multi-Automatic + Human Hybrid

Multiple independent automatic authorities may also be required. Example:

HumanP assi ∧ AutoSecurityi ∧ AutoP olicyi ∧ AutoHardwarei The automatic authorities may run in separate security domains.

A.6.35. E06.35 Communication Embodiment

A sensitive message or file is proposed. 1. The recipient receives a bounded protected trailer. 2. The endpoint returns R0 . 3. The ACA validates destination, policy, taint, scope, and receipt and creates AD0 . 4. The human sees verified recipient/effect information and produces HA0 . 5. The PED requires both artifacts. 6. The full-send capability or decryption key is released. 7. The communication Finality Sink performs the full effect.

A.6.36. E06.36 Payment Embodiment

A high-value payment is proposed. 1. A bounded real payment verification phase occurs. 2. The receiving institution returns protected confirmation. 3. Automatic policy checks account, amount, limit, currency, sanctions/enterprise rules where applicable, receipt, and transaction state. 4. A protected human sees the verified beneficiary and bounded transaction result. 5. Human and automatic decisions are both required. 6. The settlement key/share or completion capability becomes available only after both pass.

A.6.37. E06.37 Hardware / Robotics Embodiment

A robot proposes a consequential movement. 1. A small real movement is executed. 2. Trusted sensors return R0 . 3. Automatic safety logic verifies tolerance and safety envelope. 4. A human supervisor reviews the actual movement and requested next range. 5. Both approvals unlock the next actuator command envelope. 6. Hardware enforces the approved limit.

A.6.38. E06.38 Cloud / Infrastructure Embodiment

A deployment agent proposes a large infrastructure change. 1. Canary deployment occurs. 2. Protected health receipts return. 3. Automatic security and reliability rules evaluate the canary. 4. Human operator reviews verified canary evidence. 5. The next deployment cohort is restricted to the intersection of the automatic and humanapproved scopes.

A.6.39. E06.39 Telecom Embodiment

A network configuration change is applied first to a bounded slice, cell, beam, route, or subscriber set. Protected telemetry produces effect evidence. Automatic network-safety rules and a human operator may jointly authorize expansion to broader network scope.

A.6.40. E06.40 Destination-Side Hybrid Enforcement

The destination itself may require proof of both human and automatic approval before accepting the broader effect. For example, the destination may verify:

  • receipt-chain binding;

  • ACA decision signature;

  • human approval signature;

  • phase identifier;

  • destination identity;

  • and scope. This can reduce dependence on sender-side path integrity.

A.6.41. E06.41 Hardware-Rooted Hybrid Enforcement

A secure hardware component may hold the final completion secret. It verifies:

  • Ri ;

  • ADi ;

  • HAi ;

  • current phase;

  • policy epoch;

  • sink identity;

  • and scope. Only then does hardware unseal or derive the next-phase execution material.

A.6.42. E06.42 Distributed Hybrid PED

Hybrid functions may be distributed across:

  • user device;

  • cloud policy engine;

  • HSM;

  • network gateway;

  • destination;

  • hardware controller;

  • and enterprise approval service. No one component must implement every function, provided the required causal dependency remains protected and non-bypassable.

A.6.43. E06.43 Fail-Closed and Fail-Limited Hybrid Behavior

If a required human or automatic decision is unavailable, the system may:

  • fail closed;

  • remain in bounded state;

  • reduce scope;

  • use local-only mode;

  • use reversible mode;

  • delay;

  • require another trial;

  • or terminate. The absence of one mandatory approval is not silently interpreted as approval.

A.6.44. E06.44 Alternate-Path Closure

Where hybrid approval is mandatory, an alternate credential, admin API, device interface, network route, payment path, storage path, or other effect-equivalent route cannot lawfully satisfy the protected architecture merely by omitting one required authority. Equivalent paths may be disabled or subjected to equivalent hybrid enforcement.

A.6.45. E06.45 Required Invariants

Invariant 1 The hybrid architecture combines protected human authority and protected automatic authority according to a defined rule.

Invariant 2 Where conjunction is required, neither human approval nor automatic approval alone enables the broader effect.

Invariant 3 The hybrid decision is associated with verified evidence from the applicable prior real effect.

Invariant 4 The final scope remains within the authorized maximum envelope and may be restricted by either authority.

Invariant 5 Conflicts, stale decisions, revocation, and indeterminate states are represented explicitly rather than silently converted to approval.

Invariant 6 Required artifacts or equivalent protected states may be single-use and replay-resistant.

Invariant 7 The hybrid causal chain may be enforced through software, hardware, cryptographic key shares, destination-side verification, or distributed protected components.

FROZEN RELATIONSHIP BETWEEN E04, E05 AND E06

Bounded Real Effect → Receipt → Human Approval → Continuation

Bounded Real Effect → Receipt → P rotected Automatic Decision → Continuation

Bounded Real Effect → Receipt → Human+Automatic P rotected Decision → Continuation The common principle is that the evidence produced by real bounded effectuation participates in the protected authority chain for broader effectuation, while the required approving authority may be human, automatic, or hybrid according to protected policy.

APPENDIX E - NEW DEFINITIONS INTRODUCED BY E04- E06 ONLY E.1 Non-Repetition Rule This Appendix intentionally omits terminology already defined in Advanced Section 1 and in the E01-E03 delta glossary. Earlier definitions retain their previously stated meanings. The following definitions are included only because E04-E06 introduce or materially specialize these terms.

E.2 Protected Human Review Object (PHRO) Protected Human Review Object (PHRO) means a protected representation prepared for an authenticated human decision after one or more relevant execution facts have been obtained. It may bind the Candidate Act, prior ECR, observed effect, destination, sink, proposed next scope, remaining consequence, risk state, policy epoch, revocation state, approval nonce, and other decision context. A PHRO may exist as protected UI state, a signed data object, a secure-device prompt, hardware-display state, or another protected representation and need not be portable.

E.3 Human Approval Artifact Human Approval Artifact means machine-verifiable evidence that the required protected human authority approved, denied, restricted, or otherwise decided a defined continuation scope. It may be implemented as a digital signature, MAC-protected record, secure-element output, HSM-backed state, protected database transition, threshold share, hardware state, or equivalent protected evidence. It is not limited to a bearer token.

E.4 Automatic Continuation Authority (ACA) Automatic Continuation Authority (ACA) means a protected component or distributed protected function that evaluates verified effect evidence and applicable protected predicates to decide whether and how a Candidate Act may progress without requiring a human decision for that phase. The ACA may be implemented by software, firmware, hardware, a TEE, HSM, policy engine, transaction engine, kernel component, network component, destination-side component, or equivalent protected mechanism.

E.5 Automatic Decision Record (ADR) Automatic Decision Record (ADR) means a protected representation of an ACA decision and its relevant context. It may bind the Candidate Act, prior receipt, decision result, next scope, policy and revocation epochs, risk state, predicate outcomes, sink, destination, nonce, expiry, and ACA identity. An ADR may be explicit or may exist only as a protected internal state transition.

E.6 Hybrid Continuation Authority Hybrid Continuation Authority means the technical authority enabling a later effectuation phase where that authority depends upon a protected combination of human and automatic decisions. The combination may be conjunctive, threshold-based, sequential, hierarchical, disjunctive where policy permits, or cryptographically split.

E.7 Conjunctive Hybrid Approval Conjunctive Hybrid Approval means an approval rule requiring both a defined protected human condition and a defined protected automatic condition before continuation.

E.8 Disjunctive Hybrid Approval Disjunctive Hybrid Approval means a protected rule under which one of multiple permitted approval paths may satisfy continuation, for example protected human approval or a specifically

defined high-assurance automatic approval. Availability of the disjunctive rule is itself protected policy and is not implied for all act classes.

E.9 Conflict State Conflict State means protected state indicating that required approval authorities produced inconsistent or incompatible outcomes, scopes, or conditions. Conflict does not itself mean approval. Protected policy determines whether the result is denial, hold, scope reduction, revalidation, additional evidence collection, or escalation.

E.10 Mandatory Technical Pass Mandatory Technical Pass means a protected technical condition that cannot be overridden merely by human approval where policy designates the condition as non-overridable. Examples may include valid cryptographic binding, revocation clearance, correct sink, correct destination, hardware safety constraints, or maximum-envelope compliance.

E.11 Hybrid Scope Intersection Hybrid Scope Intersection means the final scope formed from the common permitted region of multiple approval authorities, such that later effectuation does not exceed the scope allowed by either required authority. Set intersection, scalar minimum, policy-defined meet operations, or equivalent protected narrowing functions may implement this role.

E.12 Automatic Decision Predicate Set Automatic Decision Predicate Set means the collection of protected predicates evaluated by an ACA for a defined act or phase. It may include receipt validity, risk, policy, revocation, sink, destination, envelope, taint, provenance, hardware, transaction, timing, or other protected conditions.

E.13 Human Veto Window Human Veto Window means a bounded protected interval during which an authenticated human or supervisory authority may prevent an otherwise automatically eligible continuation. The veto mechanism may itself require protected authentication and act/phase binding.

APPENDIX F - NEW NOTATION INTRODUCED BY E04-E06 ONLY F.1 Non-Repetition Rule Notation already defined in the Advanced Section 1 notation appendix or the E01-E03 delta notation appendix is intentionally not repeated. Symbols below are included only where E04- E06 introduce a new symbol or a materially specialized local meaning.

F.2 Human-Approval Notation

  • HumanRequiredi - protected Boolean or policy state indicating that human approval is required for the relevant phase i.

  • HAi - Human Approval Artifact associated with phase i or the transition to the next phase, according to local context.

  • KH - protected key or key share associated with the human-approval authority in an illustrative cryptographic embodiment.

  • NH - approval-specific nonce or freshness value used in the illustrative human approval construction.

  • ApprovedScopei / Scopeapproved - scope expressly permitted by the protected human decision for the relevant phase.

  • Tnow - current protected or policy-relevant time used in a freshness check.

  • Tapproval_expiry - expiry time associated with the human approval.

  • Epcurrent - currently applicable policy epoch.

  • Epreceipt - policy epoch associated with the relevant receipt.

  • HumanDecision - protected human decision state such as APPROVE, DENY, RESTRICT, HOLD, or another permitted outcome.

  • P0′ - a newly authorized or revised bounded trial phase distinguished from an earlier P0 .

F.3 Automatic-Decision Notation

  • ACA - Automatic Continuation Authority, the protected automatic decision function/component defined in Appendix E.

  • Γi - Automatic Decision Predicate Set applicable to phase i.

  • gi,k - the kth protected automatic-decision predicate applicable to phase i.

  • AutoP assi - protected Boolean result indicating that all automatic conditions required by the applicable rule for phase i have passed.

  • ADi - Automatic Decision Record associated with phase i or next-phase transition.

  • KACA - protected cryptographic key associated with the ACA in an illustrative ADR construction.

  • NA,i - automatic-decision nonce associated with phase i.

  • Decisioni - protected decision result produced by the ACA for phase i.

  • Historyi - protected representation of relevant prior phase outcomes used by an adaptive automatic decision.

  • Erri - measured or protected error rate for phase i in the rollout example.

  • F ailedT argetsi - number or protected measure of failed targets in phase i.

  • AttemptedT argetsi - number or protected measure of targets attempted in phase i.

  • τerr - protected maximum error-rate threshold in the illustrated automatic rollout rule.

F.4 Hybrid-Approval Notation

  • HumanP assi - protected Boolean indicating that the required human condition applicable to phase i has passed.

  • HybridP assi - protected Boolean indicating that the applicable hybrid approval rule has been satisfied.

  • HighAssuranceAutoP assi - automatic approval result meeting a policy-defined higher assurance level that may satisfy a permitted disjunctive rule.

  • DecisionReadyi - protected state indicating that all decision artifacts required before hybrid evaluation have been received.

  • Vi - set or vector of protected approval votes/decisions considered by the threshold rule for phase i.

  • vj - protected vote or decision contribution from authority j in the threshold example.

  • wj - protected weight assigned to authority j in the threshold example.

  • Θi - protected aggregate approval threshold for phase i in the weighted-threshold example. This symbol is local and distinct from actuator-angle notation used elsewhere.

  • M andatoryT echnicalP assi - protected Boolean indicating that all non-overridable technical predicates applicable to phase i have passed.

  • Scopeauto - scope permitted by the protected automatic authority.

  • Scopehuman - scope permitted by the protected human authority.

  • Scopefinal - final scope permitted after applying the protected hybrid-combination rule.

  • KA - protected automatic-authority key share or secret in the illustrative two-key hybrid construction.

  • CON F LICT - protected state indicating incompatible human and automatic decisions requiring a policy-defined resolution path.

  • V etoi - protected human veto state applicable to phase i.

  • EpHA - policy epoch bound to a Human Approval Artifact.

F.5 Word-Like Predicate Convention for E04-E06 The following word-like mathematical expressions denote protected predicates, decision states, status values, or functions rather than required programming-language identifiers: ReceiptAccept, MatchDestination, MatchApproval, HumanRequired, HumanPass, AutoPass, HybridPass, HighAssuranceAutoPass, MandatoryTechnicalPass, DecisionReady, HumanReviewRequired, Received, Revalidate, Fresh, Valid, WithinEnvelope, RevocationClear, PolicyCurrent, CONFLICT, REQUIRE_HUMAN, REQUIRE_QUORUM, RECONCILE, and related labels.

F.6 Local Interpretation Rule Where a symbol appearing in E04-E06 was previously defined, the previous meaning remains controlling unless the local subsection expressly states a narrower specialized use. New notation is illustrative and may be replaced by equivalent protected representations without changing the disclosed functional dependency.

A.7. E07 — Software Protected Enforcement Domain

A.7.1. E07.1 Purpose

E07 defines a Protected Enforcement Domain implemented primarily through software-enforced isolation, privilege separation, protected operating-system state, protected services, trusted software components, or combinations thereof. The central relationship is:

Candidate Act → Software P ED Intake → P rotected Software V alidation → Scoped Effectuation Authority → Software Effectuation Gate → External Effect → P rotected Receipt/State

The proposing agent or ordinary application may execute in a less-trusted software domain while the authority to cause the external effect remains in a separate software protection domain.

A.7.2. E07.2 Software PED Functional Boundary

The Software PED may be implemented as one or more of:

  • a privileged daemon;

  • an operating-system security service;

  • a kernel module;

  • a kernel security hook;

  • an eBPF-based enforcement program;

  • a Linux Security Module or analogous mandatory-access-control layer;

  • a syscall mediation layer;

  • a seccomp-like filter combined with a privileged broker;

  • a namespace or cgroup controller;

  • a container-runtime security hook;

  • a microVM monitor;

  • a hypervisor-resident software service;

  • a service-mesh proxy;

  • a network forward proxy;

  • a reverse proxy;

  • an API gateway;

  • a database proxy;

  • a storage gateway;

  • a transaction manager;

  • a message broker;

  • a credential broker;

  • a signing service;

  • a key-management service;

  • a policy decision point;

  • a policy enforcement point;

  • a confidential-computing service;

  • a remote protected service;

  • or a composition of such components. No particular software name is required. The relevant property is that the protected software path retains authority or missing execution material that the proposing domain cannot freely bypass.

A.7.3. E07.3 Candidate Act Intake

The Candidate Act enters the Software PED through a defined protected interface. The interface may receive:

  • the Candidate Act itself;

  • a canonical representation;

  • a Candidate Act digest;

  • a Trial Effect Descriptor;

  • a requested phase identifier;

  • a prior receipt;

  • an approval artifact;

  • a credential request;

  • a destination descriptor;

  • a device or process identity;

  • or another bound representation sufficient to evaluate the requested effect. The interface may be an IPC endpoint, system call, local socket, protected message queue, sharedmemory channel, remote authenticated API, hypercall, device-control request, or equivalent interface.

A.7.4. E07.4 Caller Attribution

The Software PED may determine which software principal requested the act. Attribution may include:

  • process identifier;

  • executable measurement;

  • user identifier;

  • service identity;

  • container identity;

  • namespace identity;

  • cgroup identity;

  • VM identity;

  • application identity;

  • signed workload identity;

  • agent session identity;

  • or a cryptographically authenticated principal. The PED may reject a request where the caller identity does not match the authority context bound to the Candidate Act.

A.7.5. E07.5 Protected Software State

The Software PED may maintain protected state denoted locally by:

ZSW where ZSW may include:

  • policy state;

  • revocation state;

  • nonce state;

  • consumed-authority state;

  • receipt state;

  • phase state;

  • rate-limit state;

  • spending-limit state;

  • destination state;

  • taint/provenance state;

  • approval state;

  • transaction state;

  • protected counters;

  • and other enforcement-relevant state. The proposing agent should not be able to arbitrarily rewrite ZSW .

A.7.6. E07.6 Software Validation Predicate

A representative software validation result may be expressed as:

SW P assi = ActM atchi ∧ CallerV alidi ∧ P olicyV alidi ∧ RevocationCleari ∧ F reshi ∧ W ithinEnvelopei ∧ ApprovalSatisfiedi ∧ SinkP ermittedi where each term represents a protected predicate applicable to phase i. The particular predicate set is implementation-dependent.

A.7.7. E07.7 Automatic Approval Integration

Where E05 automatic continuation applies, the Software PED may perform or invoke the automatic decision function internally. A successful automatic decision may transition protected software state from:

P EN DIN Gi to:

AU T HORIZEDi without exposing a reusable unrestricted credential to the agent.

A.7.8. E07.8 Human Approval Integration

Where E04 human continuation applies, the Software PED may: 1. validate the prior ECR; 2. form the protected human review object; 3. transmit it to a protected approval surface; 4. receive the Human Approval Artifact; 5. verify its act, receipt, scope, nonce, and expiry binding; and 6. advance the protected phase state only after successful verification. The ordinary conversational output of the AI agent need not constitute the protected approval channel.

A.7.9. E07.9 Hybrid Approval Integration

Where E06 applies, the Software PED may combine automatic and human decision artifacts using the protected combination rule selected by policy. The Software PED may implement:

  • conjunction;

  • threshold approval;

  • automatic low-risk continuation with human escalation;

  • human veto;

  • scope intersection;

  • split authorization;

  • or another protected rule.

A.7.10. E07.10 Scoped Software Capability

After validation, the Software PED may create a software-enforced capability Ci . The capability may be:

  • non-bearer;

  • single-use;

  • process-bound;

  • destination-bound;

  • phase-bound;

  • time-bound;

  • transaction-bound;

  • resource-bound;

  • or otherwise constrained.

A representative construction may be:

Ci = P rotectKSW (Di ∥ P rincipali ∥ Sinki ∥ Scopei ∥ Expiryi )

where KSW is protected from ordinary untrusted application access.

A.7.11. E07.11 Capability Without Exposed Token

A separate serialized token is not required. The PED may instead maintain an internal protected state transition such as:

AuthorizeState(Di , P rincipali , Sinki ) = T RU E

and the effectuation gate may consult that protected state directly. This embodiment avoids requiring an externally transferable authority object.

A.7.12. E07.12 Credential Brokerage

The agent may possess only a surrogate, restricted, or non-authoritative credential. The Software PED may retain the real effect-capable credential. Flow: Agent request -> Software PED -> protected validation -> real credential use at boundary -> external effect The real credential may never be returned to the agent.

A.7.13. E07.13 Late Credential Injection

In one variation, a request is constructed without the real credential. After protected validation, the Software PED injects or applies the real credential only at or near the external boundary. This may include:

  • Authorization header insertion;

  • request signing;

  • TLS client authentication;

  • API-key insertion;

  • payment credential use;

  • database credential use;

  • signing-key use;

  • or another protected authority application.

A.7.14. E07.14 Network Egress Gate

A Software PED may mediate network egress. The agent’s environment may be unable to reach external destinations except through the protected gate. The gate may evaluate:

  • destination;

  • protocol;

  • port;

  • application identity;

  • process identity;

  • payload class;

  • Candidate Act digest;

  • phase authority;

  • receipt state;

  • human/automatic approval state;

  • and policy. Only matching traffic is permitted to exit.

A.7.15. E07.15 Kernel-Level Software Gate

The effectuation boundary may be implemented at the kernel or syscall layer.

Examples include mediation of:

  • connect;

  • send/sendmsg;

  • file writes;

  • exec/spawn;

  • ioctl;

  • IPC;

  • device access;

  • mount operations;

  • namespace operations;

  • or other effect-capable primitives. The kernel-side gate may consult protected PED state before permitting the operation.

A.7.16. E07.16 eBPF / Security-Hook Variation

An eBPF program, security hook, or equivalent kernel extension may:

  • attribute the request to a process or cgroup;

  • observe or gate network operations;

  • observe file/device operations;

  • consult protected maps or policy state;

  • enforce phase state;

  • deny unmatched operations;

  • or generate evidence for later protected processing. Naming eBPF is illustrative and does not require any particular kernel program type or hook arrangement.

A.7.17. E07.17 LSM / Mandatory-Access-Control Variation

An LSM-like or mandatory-access-control layer may deny effect-capable objects unless the applicable process, resource, and phase state satisfy protected rules. The effect may therefore be blocked by access-control semantics even if the agent constructs the low-level operation itself.

A.7.18. E07.18 Proxy-Based Effectuation Gate

A protected proxy may be the first component possessing unrestricted external reach or the real credential. The proxy may verify:

  • exact request binding;

  • destination;

  • method;

  • payload digest;

  • approval state;

  • phase state;

  • receipt state;

  • nonce;

  • expiry;

  • and scope. The proxy may then cause the external effect on behalf of the less-trusted agent.

A.7.19. E07.19 Database Gate

A database proxy, stored procedure, transaction service, or protected commit component may deny direct production commits unless the protected state indicates authorization. A staged workflow may allow a shadow or provisional write first and promote it only after ECR validation.

A.7.20. E07.20 Storage Gate

A storage gateway or protected filesystem service may restrict:

  • object creation;

  • object publication;

  • namespace promotion;

  • deletion;

  • overwrite;

  • external sharing;

  • or key release. The storage object may remain inaccessible or non-public until the applicable phase becomes authorized.

A.7.21. E07.21 Message-Broker Gate

A message queue or broker may refuse publication to effect-capable topics unless the publisher presents or is associated with valid protected phase authority. The broker may generate a durable receipt identifying:

  • topic;

  • partition;

  • offset;

  • message digest;

  • publisher identity;

  • and committed status.

A.7.22. E07.22 Transaction Manager Variation

A transaction manager may hold a transaction in a non-final or provisional state until protected predicates are satisfied. The transaction manager itself may be the Software PED, the Finality Sink, or both.

A.7.23. E07.23 Remote Software PED

The Software PED need not execute on the same machine as the agent. A remote protected service may receive a bound Candidate Act and return only a scoped continuation decision or execute the effect itself. Remote implementations may be useful where:

  • endpoint software cannot be trusted;

  • enterprise policy is centralized;

  • secrets are held in a remote vault;

  • or multiple devices share a policy authority.

A.7.24. E07.24 Software Attestation Input

A Software PED may consume platform attestation, workload identity, signed measurements, or confidential-computing evidence as inputs. However, E07 does not require the PED itself to be hardware-rooted.

A.7.25. E07.25 Receipt Generation in Software

The Software PED or downstream software sink may generate an ECR after effectuation. The receipt may be protected using:

  • a software-held signing key;

  • HSM-backed key accessed by software;

  • MAC;

  • authenticated transaction log;

  • append-only log;

  • signed service response;

  • or another integrity mechanism.

A.7.26. E07.26 Durable Software State

Protected software state may be persisted using:

  • append-only journal;

  • write-ahead log;

  • replicated database;

  • secure local database;

  • transactional key-value store;

  • remote protected state service;

  • or equivalent durable storage. Crash recovery should not silently erase consumed receipt or phase state.

A.7.27. E07.27 Crash Recovery

If the Software PED crashes after effectuation but before recording completion, the system may enter an indeterminate state and reconcile using the mechanisms of E02/E03. The PED may compare:

  • idempotency identifier;

  • transaction identifier;

  • sink log;

  • broker offset;

  • database commit identifier;

  • or destination receipt.

A.7.28. E07.28 Software Rollback Resistance

Where software state may be restored from an old snapshot, the architecture may require protected epoch or external monotonic evidence so that an old permissive state cannot automatically revive consumed authority. Possible mechanisms include:

  • remote monotonic service;

  • append-only external ledger;

  • hardware monotonic counter used as an input;

  • replicated consensus state;

  • or protected revocation epoch.

A.7.29. E07.29 Alternate-Path Closure

The Software PED embodiment should account for effect-capable paths that avoid the designated broker. Examples include:

  • direct network namespace access;

  • raw socket access;

  • alternate API clients;

  • local privileged credentials;

  • direct database connections;

  • device files;

  • alternate message brokers;

  • debug endpoints;

  • administrator endpoints;

  • recovery interfaces;

  • and local secret files. Such paths may be disabled, isolated, credential-starved, redirected through the PED, or independently subjected to equivalent finality control.

A.7.30. E07.30 Software PED Fail-Closed Mode

Where required protected state is unavailable or corrupted:

SW P assi = F ALSE ⇒ Effectuationi = BLOCKED unless policy expressly permits a fail-limited reduced effect.

A.7.31. E07.31 Software PED Fail-Limited Mode

A software system may permit only a reduced consequence where full verification is unavailable. Examples:

  • local-only write;

  • read-only operation;

  • sandbox-only execution;

  • reduced recipient set;

  • reduced payment limit;

  • no external network release;

  • or a human-review hold.

A.7.32. E07.32 SEND Example

An AI agent prepares a message and attachment. The agent runtime has no unrestricted egress credential. The Software PED: 1. receives the bound SEND Candidate Act; 2. validates recipient, attachment digest, phase, policy, and approval state; 3. uses the protected outbound credential; 4. sends the bounded or full authorized payload through the protected proxy; 5. receives a destination acknowledgement;

6. generates or validates the ECR; and 7. advances protected state as required.

A.7.33. E07.33 Payment Example

The AI agent proposes a payment but lacks the bank/payment signing secret. The Software PED validates:

  • beneficiary;

  • amount;

  • currency;

  • transaction nonce;

  • spending limit;

  • human/automatic approval state;

  • and phase state. The PED invokes the payment API using protected credentials only after approval.

A.7.34. E07.34 Required Invariants

The frozen conceptual invariants of E07 are: 1. the proposing software domain need not possess unrestricted effectuation authority; 2. protected software state participates in the final authority decision; 3. an effect-capable software gate verifies or is technically dependent upon the protected decision; 4. required receipt, phase, approval, or revocation state cannot be satisfied merely by agent assertion; 5. alternate effect-capable software paths are controlled where needed to preserve nonbypassability; and 6. failure of mandatory protected software validation prevents unauthorized broader effectuation.

3 E08 - HARDWARE PROTECTED ENFORCEMENT DOMAIN

A.8. E08 — Hardware Protected Enforcement Domain

A.8.1. E08.1 Purpose

E08 defines an embodiment in which one or more critical authority, state, key, verification, observation, or effectuation functions are enforced by hardware or hardware-rooted components. The central relationship is:

Candidate Act → P rotected Hardware Intake → Hardware State/Identity V erification → Hardware Scoped Authority → Hardware Effectuation Gate → Real Effect → Hardware or HardwareBound Receipt

The critical property is not a particular chip type. It is that ordinary software cannot freely synthesize, modify, or bypass the protected hardware state or secret required for the consequential effect.

A.8.2. E08.2 Hardware PED Components

A Hardware PED may comprise one or more of:

  • TPM;

  • secure element;

  • secure enclave;

  • Trusted Execution Environment;

  • HSM;

  • security coprocessor;

  • isolated MCU;

  • secure monitor;

  • DPU;

  • SmartNIC;

  • NIC security controller;

  • storage controller;

  • SSD controller;

  • memory controller;

  • GPU security processor;

  • GPU command processor;

  • FPGA;

  • ASIC;

  • SoC security island;

  • baseband security processor;

  • modem security processor;

  • automotive ECU;

  • industrial PLC;

  • motor controller;

  • actuator controller;

  • flight controller;

  • robotic safety controller;

  • cryptographic accelerator;

  • PUF-backed identity logic;

  • or equivalent protected hardware.

A.8.3. E08.3 Hardware Root of Authority

The Hardware PED may retain a root secret or protected state unavailable to ordinary software. Let:

KHW represent a hardware-protected root secret, key, or equivalent authority root. The root may be used directly or indirectly to derive phase-specific authority.

A.8.4. E08.4 Hardware Protected State

Let:

ZHW represent hardware-protected state. It may include:

  • phase counter;

  • consumed-receipt state;

  • policy epoch;

  • revocation epoch;

  • monotonic counter;

  • device identity;

  • key version;

  • measured-boot state;

  • sink identity;

  • approval digest;

  • receipt digest;

  • safe operating envelope;

  • or another authority-relevant value.

A.8.5. E08.5 Hardware Identity

The Hardware PED may possess a device-bound or component-bound identity established by:

  • fused key;

  • PUF-derived key;

  • manufacturer certificate;

  • device certificate;

  • secure element key;

  • attestation key;

  • provisioned HSM key;

  • or equivalent hardware-rooted identity. The identity may bind a receipt or capability to the specific hardware component.

A.8.6. E08.6 Platform Measurement

A hardware component may verify a measurement:

Mplat

against an expected or policy-permitted measurement set:

Mplat ∈ Mallowed

before releasing phase authority. Measurements may represent firmware, boot state, software image, configuration, secure monitor state, or another protected platform property.

A.8.7. E08.7 Hardware Attestation

The Hardware PED may generate or verify attestation evidence denoted:

AttHW The attestation may bind:

  • device identity;

  • software/firmware measurement;

  • boot state;

  • nonce;

  • policy epoch;

  • phase state;

  • key version;

  • and sink identity.

A.8.8. E08.8 Hardware Validation Predicate

A representative hardware authorization condition may be:

HW P assi = AttestationV alidi ∧ M easurementAllowedi ∧ P olicyV alidi ∧ RevocationCleari ∧ P haseStateV alidi ∧ ReceiptStateV alidi ∧ W ithinEnvelopei

Additional human or automatic approval predicates may be included where required.

A.8.9. E08.9 Hardware Phase Key

A phase-specific key may be derived as:

Kiphase = KDF (KHW , DA , i, Ni , Ep , Er )

or by another protected derivation. The key may authenticate only the permitted phase.

A.8.10. E08.10 Receipt-Derived Hardware Key

For receipt-gated progression:

phase Ki+1 = KDF (KHW , DA , H(Ri ), i + 1) The next-phase key therefore depends on accepted evidence from the previous real phase.

A.8.11. E08.11 Hardware Unsealing Variation

Instead of derivation, next-phase authority may be sealed in hardware. The hardware unseals the authority only where:

  • receipt digest matches;

  • phase index matches;

  • measurement is allowed;

  • policy epoch is current;

  • revocation is clear;

  • and required approval evidence is present.

A.8.12. E08.12 Protected Hardware Latch

A protected latch may represent whether the next phase is enabled. Let:

LHW i+1 ∈ {0, 1}

with initial state:

LHW i+1 = 0

and transition:

V alid(Ri ) ∧ HW P assi ⇒ LHW i+1 ← 1

The next effect remains electrically, logically, cryptographically, or microarchitecturally unavailable while the latch remains zero.

A.8.13. E08.13 Monotonic Counter

A hardware monotonic counter may track phase or authority consumption. If current counter is ctri , the hardware may require:

ctrrequest = ctri + 1

before accepting the next protected transition. This can resist rollback to an older permissive state.

A.8.14. E08.14 Secure-Element Embodiment

A secure element may:

  • store the root key;

  • verify Candidate Act digests;

  • verify receipt digests;

  • verify human approval signatures;

  • maintain a phase counter;

  • derive phase keys;

  • and sign completion receipts. Ordinary application software may receive only the narrow result needed for the current phase.

A.8.15. E08.15 HSM Embodiment

An HSM may refuse to perform a signing, decryption, key-wrap, transaction-signing, or key-release operation unless the bound phase state and receipt evidence satisfy protected policy. The HSM may therefore be the authority gate even where network execution occurs elsewhere.

A.8.16. E08.16 TEE / Secure-Enclave Embodiment

A TEE or secure enclave may hold:

  • policy state;

  • receipt state;

  • Candidate Act digest;

  • phase keys;

  • approval state;

  • and protected counters. The enclave may expose a narrow command interface to ordinary software.

A.8.17. E08.17 DPU / SmartNIC Network Embodiment

A DPU or SmartNIC may enforce network release independently of the host agent runtime. The host may construct packets or requests, but the DPU/SmartNIC releases them externally only if protected phase authority validates. The hardware may bind:

  • destination;

  • flow;

  • tenant;

  • VM;

  • process/workload identity;

  • payload digest or descriptor;

  • phase;

  • and receipt state.

A.8.18. E08.18 Storage-Controller Embodiment

A storage controller may hold a write, publish, erase, or key-release command until the protected authority state is satisfied. The controller may generate a signed or MACed persistence receipt after successful effectuation.

A.8.19. E08.19 GPU / Accelerator Embodiment

A GPU security processor or command controller may restrict:

  • DMA transfer;

  • model-output egress;

  • memory export;

  • command submission;

  • device-to-network transfer;

  • or protected model-state release. The next transfer phase may require a receipt from the DPU, host protected service, destination, or another protected observer.

A.8.20. E08.20 Motor / Actuator Controller Embodiment

A motor controller may receive a requested full trajectory but execute only the authorized phase. Protected sensor feedback may be evaluated locally. For expected movement Xi and observed movement Oi :

|Oi − Xi | ≤ εi

may be required before enabling the next movement phase.

A.8.21. E08.21 Vehicle / Flight Controller Embodiment

A vehicle or flight controller may maintain a protected movement envelope and permit only the current segment. Receipt evidence may include:

  • position;

  • velocity;

  • orientation;

  • altitude;

  • sensor state;

  • geofence state;

  • or actuator response. A failed protected measurement may cause hold or safe-state transition.

A.8.22. E08.22 Radio / Baseband Embodiment

A baseband or radio controller may restrict transmission by:

  • power;

  • frequency;

  • duration;

  • beam;

  • destination;

  • geographic region;

  • recipient set;

  • or message class. Protected receiver evidence or local telemetry may unlock broader transmission authority.

A.8.23. E08.23 Hardware Human-Approval Verification

A hardware component may verify a Human Approval Artifact directly. The hardware may require the approval to bind:

  • Candidate Act digest;

  • receipt digest;

  • phase;

  • scope;

  • nonce;

  • expiry;

  • and approving authority. This prevents compromised host software from merely asserting that the human approved.

A.8.24. E08.24 Hardware Automatic-Decision Verification

A hardware component need not run the entire automatic policy engine. Instead, it may verify a protected Automatic Decision Record produced by an authorized decision service, provided the record is bound to the act and current protected state. Alternatively, a simplified deterministic policy may execute directly in hardware.

A.8.25. E08.25 Hardware Receipt Generation

A hardware sink may generate an ECR using:

  • device signing key;

  • MAC key;

  • attestation key;

  • hardware counter;

  • secure timestamp;

  • sensor measurement;

  • or another protected evidence source. The receipt may be stronger than ordinary software acknowledgement where the relevant effect is physically or microarchitecturally observable only inside the device.

A.8.26. E08.26 Hardware Receipt Verification

The Hardware PED may verify a remote or local ECR before updating protected phase state. The verification may be performed entirely inside hardware or through a hardware-rooted trusted software component.

A.8.27. E08.27 Hardware Anti-Replay

A receipt or phase authority may be bound to:

  • nonce;

  • phase counter;

  • device identity;

  • Candidate Act digest;

  • transaction identifier;

  • monotonic counter;

  • and expiry. Consumed state may be retained in protected NVRAM or equivalent protected memory.

A.8.28. E08.28 Hardware Crash / Power-Loss Recovery

Protected hardware state may survive power loss using:

  • secure NVRAM;

  • monotonic counter;

  • sealed storage;

  • TPM NV index;

  • secure flash;

  • HSM persistent object;

  • or replicated protected state. Where state cannot be resolved after recovery, the hardware may remain fail-closed until reconciliation.

A.8.29. E08.29 Hardware Rollback Protection

The Hardware PED may compare a stored anti-rollback value with firmware or state version. An older snapshot or firmware image must not silently restore previously consumed authority.

A.8.30. E08.30 Hardware Alternate-Path Closure

Where the hardware controller is intended to be non-bypassable, direct lower-level paths may be unavailable without the protected controller. Examples include:

  • actuator power stage requiring authenticated command;

  • NIC transmit queue requiring protected descriptor authorization;

  • storage encryption key retained in controller;

  • HSM signing key never exported;

  • device register access restricted to secure world;

  • or hardware routing that forces traffic through the protected gate.

A.8.31. E08.31 Fail-Closed Hardware Mode

If hardware attestation, state, key, receipt, or policy verification fails:

HW P assi = F ALSE ⇒ Effectuationi = BLOCKED unless a separately authorized safe or reduced mode exists.

A.8.32. E08.32 Fail-Safe Physical Mode

For cyber-physical systems, failure may cause transition to:

  • stop;

  • brake;

  • neutral;

  • hold position;

  • reduce power;

  • safe altitude;

  • safe route;

  • local-only operation;

  • or another protected safe state.

A.8.33. E08.33 SEND Example

A secure element or HSM retains the message-signing/decryption-release key. The host AI agent prepares the message but cannot make it valid for external delivery without hardware authorization. The hardware verifies act/phase state and produces the current-phase signing or release material only after the required protected predicates pass.

A.8.34. E08.34 Payment Example

A payment-signing key remains inside an HSM or secure element. The AI agent can construct the payment instruction but cannot authorize settlement. The hardware signs only the exact authorized payment or current payment phase after checking bound policy and approval evidence.

A.8.35. E08.35 Required Invariants

The frozen conceptual invariants of E08 are: 1. at least one authority-critical state, key, verification, observation, or effectuation function is hardware-protected; 2. ordinary software cannot freely synthesize the protected hardware authority; 3. hardware may bind authority to exact act, phase, destination, device, receipt, approval, or policy state; 4. required later phases may remain unavailable until protected hardware accepts prior evidence; 5. replay and rollback can be constrained using protected hardware state; and 6. unauthorized alternate paths are controlled where necessary to preserve the intended hardwarerooted dependency.

4 E09 - SPLIT SOFTWARE/HARDWARE PROTECTED EN- FORCEMENT DOMAIN

A.9. E09 — Split Software/Hardware Protected Enforcement Domain

A.9.1. E09.1 Purpose

E09 defines a split architecture in which software performs one or more higher-level validation or orchestration functions while hardware retains one or more authority-critical secrets, state transitions, enforcement decisions, or effectuation controls. The central relationship is:

Candidate Act → Software V alidation/P lanning → Bound Authorization Digest → Hardware V erification → HardwareRooted P hase Authority → Real Effect → Receipt → Software/Hardware Revalidation → N ext P hase

The split arrangement can preserve rich software policy while preventing compromised application software from independently producing full effectuation authority.

A.9.2. E09.2 Functional Separation

A representative split may assign:

4.2.1 Software side

  • Candidate Act parsing;

  • canonicalization;

  • policy evaluation;

  • risk evaluation;

  • taint/provenance analysis;

  • human-review preparation;

  • automatic decision logic;

  • phase planning;

  • receipt parsing;

  • complex business rules;

  • and audit preparation.

4.2.2 Hardware side

  • root-key custody;

  • phase-key derivation;

  • protected counters;

  • approval-digest verification;

  • receipt-digest verification;

  • anti-replay state;

  • final capability generation;

  • command authentication;

  • credential release;

  • or direct effectuation gating. Functions may be redistributed without departing from the split concept.

A.9.3. E09.3 Software Decision Record

The software PED may produce a bound authorization record or digest. Let:

ADRi denote an Authorization Decision Record for phase i. It may bind:

  • Candidate Act digest;

  • phase;

  • permitted scope;

  • policy epoch;

  • revocation epoch;

  • destination;

  • sink;

  • receipt digest;

  • human approval digest;

  • automatic decision digest;

  • risk state;

  • and expiry.

A.9.4. E09.4 Authorization Digest

A compact digest may be formed:

AuthDigesti = H(Canon(ADRi )) or by an equivalent deterministic protected representation. The hardware may verify the signature or MAC over ADRi or receive the record through an authenticated channel.

A.9.5. E09.5 Hardware Does Not Blindly Trust Software

The hardware may independently verify a mandatory subset of conditions rather than accepting every software assertion. For example:

SplitP assi = SoftwareDecisionV alidi ∧ ActDigestM atchi ∧ P haseM atchi ∧ CounterV alidi ∧ ReceiptDigestM atchi ∧ RevocationEpochV alidi ∧ HardwareEnvelopeV alidi

The hardware may reject the request even where software reports ALLOW.

A.9.6. E09.6 Software Scope and Hardware Scope

Software may compute a permitted scope:

ScopeSW ,i

while hardware maintains an independent maximum:

ScopeHW ,i

The effective scope may be:

Scopeeff,i = ScopeSW ,i ∩ ScopeHW ,i

or another protected narrowing operation. Thus software cannot expand effectuation beyond the hardware envelope.

A.9.7. E09.7 Hardware Root Secret

The hardware retains KHW or another non-exportable root of authority. Software may never receive the root secret. The hardware may derive:

Kiphase = KDF (KHW , AuthDigesti , Ni ) only after verifying the bound decision record.

A.9.8. E09.8 Receipt-Gated Split Progression

Following Phase i, receipt Ri is validated by software and/or hardware. A next-phase key may be:

phase Ki+1 = KDF (KHW , AuthDigesti+1 , H(Ri ), i + 1)

The later effect therefore depends on both software policy output and hardware acceptance of prior effect evidence.

A.9.9. E09.9 Software-First Receipt Verification

In one variation: 1. software receives Ri ; 2. software performs complex verification; 3. software forms a receipt-validation record; 4. hardware verifies the receipt digest, signature of the trusted software verifier, phase, and antireplay state; and 5. hardware unlocks the next phase. This reduces hardware complexity while retaining a hardware-rooted final transition.

A.9.10. E09.10 Hardware-First Receipt Verification

In another variation, hardware verifies the ECR directly. Software may receive only a hardware result such as:

ReceiptAcceptedi = T RU E and may then proceed with higher-level workflow state.

A.9.11. E09.11 Dual Verification

A high-assurance embodiment requires both software and hardware verification:

ReceiptAccepti = ReceiptAcceptSW i ∧ ReceiptAcceptHW i

A disagreement enters a protected conflict or hold state.

A.9.12. E09.12 Human Approval Split

The software side may prepare and present the human review object. The resulting Human Approval Artifact may then be verified by hardware before full authority is released. Thus compromised software cannot merely fabricate the approval result if hardware independently checks the approval signature/digest and its binding.

A.9.13. E09.13 Automatic Approval Split

The software may execute the complex automatic policy engine. Hardware may verify a signed Automatic Decision Record and independently enforce:

  • act digest;

  • phase;

  • scope ceiling;

  • freshness;

  • revocation epoch;

  • counter;

  • and receipt dependency.

A.9.14. E09.14 Hybrid Approval Split

Human and automatic approval artifacts may be combined in software, hardware, or both. One strong form requires hardware to verify both independently before deriving the phase key. For example:

HybridHW P assi = V alid(HAi ) ∧ V alid(ADi ) ∧ M atchActi ∧ M atchReceipti

A.9.15. E09.15 Split Key Shares

The authority may require both software-held and hardware-held shares. Let:

ShareSW ,i

and:

ShareHW ,i

represent required shares. The final phase authority may be reconstructed only where both are available:

Kiphase = Combine(ShareSW ,i , ShareHW ,i )

This is illustrative; threshold or multi-party constructions may be used.

A.9.16. E09.16 Software Cannot Use Hardware Share for Another Act

The hardware share may be bound to:

  • Candidate Act digest;

  • phase;

  • sink;

  • destination;

  • expiry;

  • nonce;

  • and receipt chain. Therefore a valid hardware response for one act does not authorize an unrelated act.

A.9.17. E09.17 Hardware Cannot Independently Expand Software Policy

Conversely, hardware may possess the root authority but lack permission to exceed the softwareapproved envelope. The split therefore may enforce mutual restriction rather than simply hardware dominance.

A.9.18. E09.18 Split Transaction Atomicity

The software and hardware protected-state updates may be coordinated so that authority is not duplicated if one side crashes. A protected transaction may conceptually perform:

V erify → Consume → AdvanceSW → AdvanceHW → Release with recovery rules for partially completed transitions.

A.9.19. E09.19 Two-Record Commit Variation

Software may persist a pending phase-transition record before requesting hardware release. Hardware then records its own monotonic transition. Software marks the transaction complete only after hardware acknowledgement. If a crash occurs between steps, reconciliation uses both records rather than blindly repeating the effect.

A.9.20. E09.20 Hardware Receipt of Software State

A hardware component may require a digest of protected software state:

DSW state,i = H(Canon(ZSW ,i ))

or a narrower software-state commitment. This can bind the phase key to the software decision context without exposing all software state to hardware.

A.9.21. E09.21 Software Receipt of Hardware State

The hardware may return an attested state record identifying:

  • hardware phase counter;

  • key version;

  • receipt digest;

  • consumed state;

  • measurement;

  • and hardware identity. Software can reject progression if the hardware state does not match the expected workflow.

A.9.22. E09.22 Local Split Embodiment

Software and hardware may exist in one physical device. Example: Agent process -> privileged software PED -> secure enclave/HSM -> NIC or actuator The protected channel between software and hardware may use authenticated IPC, secure monitor calls, device commands, or another trusted interface.

A.9.23. E09.23 Remote Hardware Split Embodiment

Software may run locally while hardware authority resides remotely, such as a network HSM or cloud confidential-computing service. The remote hardware may release only scoped cryptographic results and never export the root key.

A.9.24. E09.24 DPU Split Embodiment

Host software may evaluate policy while a DPU or SmartNIC enforces the final network release. Flow: 1. host software forms authorization digest; 2. DPU verifies digest and protected workload identity; 3. DPU checks phase/receipt state; 4. DPU releases only matching flow or packet class; 5. DPU generates protected transmission evidence.

A.9.25. E09.25 Storage Split Embodiment

Software may decide that a file/object is eligible for publication. A storage controller retains the encryption key or publication capability. The controller releases or promotes the object only when the software decision record and protected receipt state match.

A.9.26. E09.26 Payment Split Embodiment

Software performs beneficiary, amount, policy, and human-review logic. An HSM retains the payment signing key. The HSM signs only the exact transaction digest and phase permitted by the software decision plus independent hardware checks. For staged payment, the HSM may require H(Ri ) before signing the next settlement phase.

A.9.27. E09.27 SEND Split Embodiment

The software PED verifies recipient, content digest, approval, and taint/provenance state. A secure hardware component retains the signing/decryption-release or network release authority. The full SEND operation becomes possible only after software and hardware conditions align.

A.9.28. E09.28 Robotics Split Embodiment

High-level software determines path/intent while the hardware safety controller enforces local motion envelope. Software may request a movement segment, but the hardware controller refuses any segment exceeding:

  • safe acceleration;

  • actuator limit;

  • geofence;

  • phase limit;

  • sensor-confirmed state;

  • or authorization envelope.

A.9.29. E09.29 Cloud/Accelerator Split Embodiment

Host software evaluates policy and workload state. A GPU security processor, DPU, or confidential-computing device enforces output release or DMA egress. The hardware may require an authorization digest and valid prior receipt before enabling broader transfer.

A.9.30. E09.30 Software Compromise Scenario

If the agent or ordinary host software is compromised, the attacker may attempt to create an unauthorized software decision. The hardware independently limits the resulting request using:

  • signature verification;

  • fixed scope ceiling;

  • phase counter;

  • receipt dependency;

  • device identity;

  • and protected revocation state. A forged or out-of-envelope request is denied.

A.9.31. E09.31 Hardware Compromise / Failure Containment

Where policy assumes hardware failure is possible, software may independently require:

  • valid attestation;

  • expected key version;

  • expected measurement;

  • phase counter match;

  • and receipt consistency. An unexpected hardware state may place the workflow in HOLD rather than accepting the effect as valid.

A.9.32. E09.32 Version and Upgrade Binding

Software and hardware policy versions may be bound to compatible epochs. Let:

V ersionM atchi = Compatible(VSW ,i , VHW ,i )

If compatibility fails, progression may be denied or routed to protected migration.

A.9.33. E09.33 Revocation Synchronization

The software and hardware sides may each track revocation state. Continuation may require:

ErSW = ErHW = Ercurrent or another rule establishing that neither side is operating under stale revocation state.

A.9.34. E09.34 Policy Synchronization

Similarly, a hardware-enforced policy epoch may constrain software decisions. Software cannot revive authority based solely on an older policy snapshot.

A.9.35. E09.35 Split Anti-Rollback

Hardware monotonic state may anchor software rollback resistance. If software returns to an old snapshot with phase index i − 1 while hardware records phase i, the mismatch is detected and the old software state cannot automatically reissue the consumed phase.

A.9.36. E09.36 Alternate-Path Closure

A split architecture should account for bypass both around software and around hardware. Examples include:

  • direct host network path bypassing DPU;

  • alternate key outside HSM;

  • raw actuator path bypassing safety controller;

  • direct storage key accessible to host;

  • debug interface to secure hardware;

  • recovery API that ignores software policy;

  • or shadow credentials enabling the same consequence. The architecture may remove, disable, mediate, cryptographically prevent, or equivalently govern such paths.

A.9.37. E09.37 Fail-Closed Split Rule

A representative condition may be:

SplitP assi = F ALSE ⇒ Effectuationi = BLOCKED where failure may result from either software or hardware mandatory checks.

A.9.38. E09.38 Fail-Limited Split Rule

Where one side is unavailable, policy may permit only a reduced safe mode. Examples:

  • no external SEND;

  • local read-only operation;

  • reduced actuator envelope;

  • no payment settlement;

  • no key release;

  • or manual recovery.

A.9.39. E09.39 Indeterminate Split State

If software believes Phase i occurred but hardware state is uncertain, or vice versa, the system enters an indeterminate reconciliation state. Reconciliation may compare:

  • hardware monotonic counter;

  • software journal;

  • sink receipt;

  • transaction identifier;

  • device state;

  • destination state;

  • and attestation. No broader phase is released merely because one side assumes success.

A.9.40. E09.40 Completion Receipt

A completion receipt may bind both software and hardware evidence. For example:

RFsplit = P rotect (DA , H(R0 ), ... , H(Rn ), DSW state , AttHW , F inalState) The exact format is illustrative.

A.9.41. E09.41 Required Invariants

The frozen conceptual invariants of E09 are: 1. software and hardware each contribute at least one authority-relevant function; 2. at least one authority-critical secret, state, or effectuation gate remains outside ordinary agent control; 3. software approval alone need not be sufficient for full effectuation; 4. hardware authority may be bounded by software-provided act and scope information rather than being globally permissive; 5. prior receipt evidence can be bound into the software/hardware transition for staged execution; 6. rollback, replay, disagreement, and partial state transitions are reconciled rather than silently ignored; and 7. alternate paths around either side are controlled where necessary to preserve the split dependency.

5 FROZEN RELATIONSHIP BETWEEN E07, E08 AND E09 5.1 E07 - Software PED Agent/Application → P rotected Software Authority → Software Effectuation Gate → Effect

5.2 E08 - Hardware PED Software Request → P rotected Hardware Authority → Hardware Effectuation Gate → Effect

5.3 E09 - Split Software/Hardware PED Software P olicy/P lanning → Bound Decision → Hardware V erification/Authority → Effectuation The three embodiments may be used with E01 single-phase effectuation, E02 demonstration-thenfull effectuation, E03 progressive effectuation, E04 protected human continuation, E05 automatic continuation, E06 hybrid continuation, or combinations thereof.

6 APPENDIX G - NEW DEFINITIONS INTRODUCED BY E07- E09 ONLY 6.1 G.1 Non-Repetition Rule Definitions already supplied in the Advanced Section 1 master definition appendix or the E01-E06 workflow appendices are not repeated. The definitions below are included only where E07-E09 introduce a new term or a materially specialized meaning.

6.2 G.2 Software Protected Enforcement Domain Software Protected Enforcement Domain means a software-implemented or software-controlled protected authority region that evaluates, retains, derives, applies, or enforces effectuation authority using privilege separation, isolation, protected state, protected credentials, policy enforcement, or equivalent software mechanisms. It may be local, remote, distributed, kernel-resident, proxybased, transaction-based, or service-based.

6.3 G.3 Software Effectuation Gate Software Effectuation Gate means a software component positioned such that the relevant external effect cannot ordinarily occur through the governed path unless the gate permits, performs, or cryptographically enables it. Examples include a kernel gate, proxy, API gateway, database commit service, storage gateway, transaction manager, message broker, or credential broker.

6.4 G.4 Protected Software State Protected Software State means software-maintained state that ordinary proposing code is not authorized to arbitrarily alter and that participates in an effectuation decision. It may include phase, nonce, receipt, approval, policy, revocation, capability, rate-limit, or transaction state.

6.5 G.5 Late Credential Injection Late Credential Injection means applying, inserting, or using a real effect-capable credential only after protected validation and at or near the effectuation boundary, while withholding that credential from the less-trusted proposing runtime.

6.6 G.6 Hardware Protected Enforcement Domain Hardware Protected Enforcement Domain means a hardware or hardware-rooted authority region that protects one or more effectuation-critical keys, states, measurements, verification functions, counters, latches, or effectuation gates from ordinary software modification or extraction.

6.7 G.7 Hardware Root of Authority Hardware Root of Authority means a non-exportable or hardware-protected secret, identity, state, key, counter, or trust anchor from which protected phase authority or verification is derived.

6.8 G.8 Hardware Phase Key Hardware Phase Key means a phase-specific cryptographic key or equivalent hardware-protected authority derived, unsealed, or activated for a particular effectuation phase and bounded to applicable act, receipt, policy, sink, device, or scope state.

6.9 G.9 Protected Hardware Latch Protected Hardware Latch means a hardware, microarchitectural, secure-firmware, or equivalent protected state element whose value controls whether a subsequent effectuation operation can become available.

6.10 G.10 Hardware Effectuation Gate Hardware Effectuation Gate means hardware or hardware-rooted logic whose protected state, key, command authentication, register control, queue control, or physical placement makes it necessary for producing the governed effect through the intended path.

6.11 G.11 Split Software/Hardware PED Split Software/Hardware PED means an architecture in which software and hardware separately perform authority-relevant functions such that effectuation depends on protected contributions from both sides or on hardware verification of a software-bound decision.

6.12 G.12 Authorization Decision Record Authorization Decision Record (ADR) means a protected software-generated or jointly generated record describing a phase-specific authorization decision and binding act identity, phase, scope, policy, receipt, approval, destination, or other protected state for hardware verification or downstream enforcement.

6.13 G.13 Authorization Digest Authorization Digest means a deterministic digest or commitment representing an Authorization Decision Record or equivalent protected software decision context for later verification by hardware or another protected component.

6.14 G.14 Hardware Envelope Hardware Envelope means the maximum or otherwise protected effectuation scope that the hardware side permits independently of a broader software request. Software may narrow but cannot validly enlarge the effect beyond this envelope without a protected hardware policy change.

6.15 G.15 Split Key Share Split Key Share means one of multiple cryptographic shares, secrets, or authority contributions held by separate software/hardware or multi-party components and required to form a later effectuation authority.

6.16 G.16 Dual Verification Dual Verification means a workflow in which both software and hardware independently validate a required item, such as an ECR, approval artifact, or act binding, and continuation is permitted only under the applicable combination rule.

6.17 G.17 Split Indeterminate State Split Indeterminate State means a protected condition in which software and hardware state disagree or cannot establish whether a relevant phase transition or effectuation occurred, causing broader progression to remain blocked pending reconciliation.

7 APPENDIX H - NEW NOTATION INTRODUCED BY E07-E09 ONLY 7.1 H.1 Non-Repetition Rule Notation previously defined in Advanced Section 1 or the E01-E06 delta notation appendices is intentionally not repeated. Symbols below are included only where E07-E09 introduce a new symbol or materially specialized local meaning.

7.2 H.2 Software PED Notation

  • ZSW - protected software state maintained by the Software PED.

  • SW P assi - protected Boolean or equivalent decision state indicating that the mandatory Software PED predicates for phase i have passed.

  • KSW - protected software-side key used in an illustrative capability-protection construction.

  • P rincipali - caller/process/workload principal bound to phase i in the illustrative software capability construction.

  • AuthorizeState(⋅) - illustrative protected software-state function indicating whether the specified act/principal/sink tuple is currently authorized.

  • P EN DIN Gi / AU T HORIZEDi - illustrative software phase states before and after protected authorization.

7.3 H.3 Hardware PED Notation

  • KHW - hardware-protected root secret, key, or equivalent authority root.

  • ZHW - hardware-protected state participating in effectuation decisions.

  • Mplat - measured platform/firmware/software state evaluated by hardware or hardware-rooted verification.

  • Mallowed - policy-permitted set of platform measurements.

  • AttHW - hardware or hardware-rooted attestation evidence.

  • HW P assi - protected Boolean or equivalent result indicating that required hardware predicates for phase i have passed. phase

  • Ki - hardware-derived, unsealed, or protected phase-specific key/authority for phase i.

  • LHW i+1 - protected hardware latch controlling availability of phase i + 1.

  • ctri - hardware-protected monotonic counter value associated with phase or authority progression.

  • ctrrequest - counter value presented or expected for a requested protected transition.

  • εi - phase-specific allowed tolerance in the hardware measurement example.

7.4 H.4 Split PED Notation

  • ADRi - Authorization Decision Record for phase i. Distinct from the earlier Automatic Decision Record abbreviation AD_i.

  • AuthDigesti - cryptographic digest or commitment of the phase-i Authorization Decision Record.

  • SplitP assi - protected result indicating that the mandatory split software/hardware predicates for phase i have passed.

  • ScopeSW ,i - maximum scope permitted by the software decision for phase i.

  • ScopeHW ,i - maximum scope independently permitted by hardware for phase i.

  • Scopeeff,i - effective phase scope after protected combination/narrowing of software and hardware scopes.

  • ReceiptAcceptSW i - software-side acceptance result for receipt Ri . HW

  • ReceiptAccepti - hardware-side acceptance result for receipt Ri .

  • HybridHW P assi - illustrative hardware-side result for a hybrid human/automatic approval check.

  • ShareSW ,i - software-side cryptographic or authority share for phase i.

  • ShareHW ,i - hardware-side cryptographic or authority share for phase i.

  • DSW state,i - digest/commitment of protected software state relevant to phase i.

  • AdvanceSW / AdvanceHW - illustrative protected software-side and hardware-side phase-state advancement operations.

  • VSW ,i / VHW ,i - software and hardware policy/version identifiers used in the compatibility example.

  • V ersionM atchi - result of the illustrative software/hardware policy-version compatibility check.

  • ErSW / ErHW / Ercurrent - software-side, hardware-side, and currently authoritative revocation epochs in the synchronization example. split

  • RF - final completion receipt binding split software and hardware evidence.

7.5 H.5 Local Operator and Function Convention The following word-like expressions are functional or predicate notation, not required programming identifiers: ActMatch, CallerValid, SinkPermitted, Protect, AuthorizeState, AttestationValid, MeasurementAllowed, PhaseStateValid, ReceiptStateValid, Compatible, Combine, Advance, ReceiptAccepted, SoftwareDecisionValid, HardwareEnvelopeValid, MatchReceipt, MatchAct, and related labels.

7.6 H.6 Local Interpretation Rule Where E07-E09 reuse a symbol already defined in earlier sections, the prior meaning remains controlling unless the local subsection expressly narrows the meaning. The notation is illustrative and may be replaced by equivalent data structures, protected state machines, hardware registers, cryptographic objects, or protocol fields while preserving the disclosed technical dependency.

A.10. E10 — Receipt-Conditioned Hardware Cryptographic Key-Chain Effectuation

A.10.1. E10.1 Purpose

E10 defines an effectuation workflow in which protected hardware retains a root secret, root authority state, sealed continuation secret, or equivalent non-exportable authority and makes later effectuation material available only after the protected conditions for the preceding phase have been satisfied. A representative causal relationship is:

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

Candidate Act → Hardware Root Authority → P hase 0 Authority → Real P hase 0 Effect → V erified Receipt R0 → Hardware State Advance → P hase 1 Authority →⋯ → F inal Effectuation. The important property is not the particular KDF shown below. The important property is that the protected material enabling a later effect is unavailable, unusable, unsealed, inactive, or invalid until the required prior receipt or equivalent protected evidence has been accepted.

A.10.2. E10.2 Hardware Root of Authority

Protected hardware may retain a root authority denoted locally by:

KRA The root authority may be:

  • a symmetric root key;

  • a private key;

  • a sealed secret;

  • a hardware wrapping key;

  • a secure-element key;

  • an HSM key;

  • a PUF-derived secret;

  • a root state in secure NVRAM;

  • a protected monotonic state combined with a key;

  • a threshold share retained by hardware;

  • or another hardware-protected value. The root authority preferably is not directly exportable to the proposing agent or ordinary application software.

A.10.3. E10.3 Candidate Act Binding

Before deriving phase authority, the hardware or a protected software/hardware combination may obtain the Candidate Act digest DA , the phase identifier, sink identity, maximum authorized envelope, receipt requirements, approval state, and other protected context. A hardware-bound act context may be represented by:

Bi = H(DA ∥ i ∥ Sinki ∥ Scopei ∥ Ep ∥ Er ) .

Bi is illustrative. Equivalent structured binding may be used without hashing all fields into one value.

A.10.4. E10.4 Initial Phase Authority

For an initial bounded real effect, hardware may derive or unseal an initial phase authority:

K0chain = KDF (KRA , DA , N0 , B0 ) . The authority may instead be represented as:

  • a command authenticator;

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

  • device-specific MAC value;

  • signing permission;

  • decryption key;

  • storage unwrap key;

  • DMA authorization;

  • network-transmit enable value;

  • motor-control authorization;

  • transaction completion value;

  • or equivalent hardware-bound material.

A.10.5. E10.5 Narrow Phase Scope

Where E02 or E03 staged effectuation applies, the initial authority must remain bounded to the permitted first phase. A representative requirement is:

Scope(K0chain ) ⊆ Scope(P0 ). The initial phase key or authority must not validly authorize the complete broader effect merely because the holder possesses it.

A.10.6. E10.6 Phase-0 Verification at Hardware Boundary

Before hardware enables Phase 0, it may verify:

  • Candidate Act binding;

  • phase identifier;

  • destination or sink identity;

  • nonce;

  • policy epoch;

  • revocation epoch;

  • caller or workload identity;

  • hardware measurement;

  • authorization envelope;

  • human or automatic approval where required;

  • and protected local state.

The hardware may maintain a phase state:

qHW = 0 indicating that no later phase has yet been unlocked.

A.10.7. E10.7 Real Initial Effect

The Phase-0 authority is used only at the applicable effect-capable boundary. Examples include:

  • transmitting a bounded SEND object through a SmartNIC or protected NIC path;

  • executing a limited actuator movement through a motor controller;

  • releasing a limited decryption key through a secure element;

  • committing a bounded storage operation through a storage controller;

  • authorizing a bounded payment operation through an HSM-backed transaction service;

  • allowing one bounded DMA transfer through a DPU or IOMMU-associated controller;

  • or performing another real effectuation event.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.10.8. E10.8 Receipt Acquisition

Following the real effect, the applicable protected observer produces or supplies receipt R0 according to the earlier ECR definitions. The receipt may be received directly by the hardware or may first be received by a software PED and then presented to hardware with protected binding evidence.

A.10.9. E10.9 Hardware Receipt Validation

Hardware may validate one or more of:

V alid(R0 ), M atchAct(R0 , DA ), M atchP hase(R0 , P0 ),

M atchSink(R0 , Sink0 ), F resh(R0 ), N otConsumed(R0 ). Where the receipt is generated by a remote or destination component, hardware may additionally verify a certificate chain, public key, attestation, shared MAC key, or another protected trust relationship.

A.10.10. E10.10 Receipt-Conditioned Key Derivation

After successful receipt validation, a next-phase key may be derived:

chain Ki+1 = KDF (KRA , DA , H(Ri ), i + 1, Bi+1 ) . This construction makes the accepted receipt digest an input to the next protected authority. An implementation may additionally bind:

  • prior phase key identifier;

  • monotonic counter;

  • hardware measurement;

  • destination identity;

  • approval artifact digest;

  • current policy version;

  • or receipt-chain root.

A.10.11. E10.11 Receipt-Conditioned Unsealing Variation

A later authority need not be mathematically derived from Ri . Instead, the hardware may store a sealed secret:

Seali+1 and unseal it only where:

ReceiptAcceptedi = T RU E and all mandatory protected predicates pass. This variation covers TPM-style sealed state, secure-enclave keybags, HSM objects, device key slots, secure firmware key vaults, and other hardware mechanisms.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.10.12. E10.12 Wrapped-Key Variation

A later phase key may exist in wrapped form before the previous phase completes:

Wi+1 = W rapKRA (Ki+1 , Contexti+1 ).

Hardware refuses to unwrap Wi+1 until receipt Ri and the applicable protected state are accepted. Thus physical storage of wrapped ciphertext does not imply executable availability of the underlying phase authority.

A.10.13. E10.13 Hardware Latch Coupling

Key availability may be coupled to a protected hardware latch. For example:

Lchain i+1 =0 before prior receipt acceptance, and:

V erify(Ri ) = T RU E ⇒ Lchain i+1 ← 1. The key slot, command path, DMA descriptor, transmit queue, signing operation, or actuator command remains disabled while the latch is zero.

A.10.14. E10.14 Monotonic Phase State

Hardware may maintain a non-decreasing phase state:

qHW ∈ {0, 1, ... , n}. A request for Phase j may be permitted only where:

j = qHW + 1. After successful receipt acceptance and protected advancement:

qHW ← qHW + 1. This prevents software from requesting a later phase while silently skipping an earlier mandatory phase.

A.10.15. E10.15 Atomic Receipt Consumption and State Advance

To avoid replay, hardware may perform the following as one protected transition:

V erify(Ri ) ∧ Consume(Ri ) ∧ Advance(qHW ) chain ∧ Enable(Ki+1 ).

If the protected transition fails before commitment, the system remains in a recoverable prior or indeterminate state rather than assuming successful progression.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.10.16. E10.16 Key Separation Across Phases

Phase keys should preferably be cryptographically or operationally separated. Possession of:

Kichain should not automatically reveal:

chain Ki+1 . This may be accomplished through one-way derivation, independent sealed keys, hardware key slots, threshold shares, or equivalent protected separation.

A.10.17. E10.17 Compromise Containment

If a phase-specific authority is compromised, the system may revoke or terminate the affected Candidate Act without exposing the root authority. A representative desired property is:

Compromise(Kichain ) ⇏ Compromise(KRA ). No absolute cryptographic guarantee is implied for every implementation; the hardware and primitive selection determine the actual security strength.

A.10.18. E10.18 Key Zeroization

After phase authority is consumed, hardware may:

  • zeroize volatile key material;

  • disable the key slot;

  • increment a monotonic counter;

  • invalidate the wrapped object;

  • mark the capability consumed;

  • rotate the derivation context;

  • or otherwise make replay ineffective. A phase authority may remain available only where retry semantics expressly require controlled reuse.

A.10.19. E10.19 Human Approval Integration

Where E04 applies, human approval after a verified trial may become an additional key-release condition. A representative relation is:

chain Enable(Ki+1 ) = V alid(Ri ) ∧ V alid(HAAi ) ∧ OtherM andatoryP redicatesi . The human approval artifact may itself be verified by secure hardware or may be verified by software and bound into an ADR presented to hardware under E09.

A.10.20. E10.20 Automatic Approval Integration

Where E05 applies:

chain Enable(Ki+1 ) = V alid(Ri ) ∧ AutoP assi ∧ OtherM andatoryP redicatesi . The automatic authority component need not possess the root hardware secret.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.10.21. E10.21 Hybrid Approval Integration

Where E06 applies, hardware may require both human and automatic decision evidence or an applicable threshold rule. For conjunction:

chain Enable(Ki+1 ) = V alid(Ri ) ∧ HumanP assi ∧ AutoP assi . Other protected combination rules remain possible.

A.10.22. E10.22 Single-Phase Compatibility

E10 can also support E01 single-phase effectuation. In that case, hardware may derive a single final authority:

KFchain = KDF (KRA , DA , SinkF , ScopeF , NF ) without a prior trial receipt where protected policy expressly selects single-phase execution. Thus E10 does not require staged execution for every Candidate Act.

A.10.23. E10.23 Multi-Phase Key Chain

For E03 progressive effectuation:

K0chain → R0 → K1chain → R1 → ⋯ → Knchain . Each phase may require a distinct sink or may use the same protected hardware sink.

A.10.24. E10.24 Entire-History Binding Variation

Instead of deriving Phase i + 1 from only the immediately preceding receipt, the hardware may bind the entire receipt history:

CumulativeReceipti = H(R0 ∥ R1 ∥ ⋯ ∥ Ri ) and:

chain Ki+1 = KDF (KRA , DA , CumulativeReceipti , i + 1). A Merkle root or receipt-chain accumulator may replace direct concatenation for large sequences.

A.10.25. E10.25 Multiple-Sink Variation

Where Phase i and Phase i + 1 occur at different sinks, the next key may bind both:

chain Ki+1 = KDF (KRA , DA , H(Ri ), Sinki , Sinki+1 ). This can prevent a valid receipt from Sink A from being used to unlock authority intended for an unrelated Sink B.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.10.26. E10.26 Device-Bound Variation

Hardware may also bind device identity:

chain Ki+1 = KDF (KRA , DA , H(Ri ), DeviceID, i + 1). The resulting authority may be unusable on another device.

A.10.27. E10.27 SEND Example

An AI agent proposes sending a protected file to Recipient X. A hardware-rooted gateway or secure element first enables transmission of a bounded trailer object using K0chain . The recipient endpoint returns signed receipt R0 proving acceptance of the trailer at the intended endpoint. The hardware verifies R0 and only then enables the full-payload authority K1chain or the final decryption-key release. If R0 is absent, invalid, stale, or bound to a different recipient, the full SEND remains unavailable.

A.10.28. E10.28 Payment Example

A protected payment component authorizes a bounded verification transaction or reservation using the initial phase authority. The receiving institution returns protected confirmation R0 . Only after hardware validates the destination, transaction identifier, amount class, nonce, and receipt does it enable the key or signing authority necessary for the next settlement phase. A successful bounded transaction does not by itself allow an amount beyond the previously authorized maximum envelope.

A.10.29. E10.29 Actuator Example

A secure motor controller stores KRA and initially permits only a small movement. A protected encoder generates receipt R0 corresponding to the observed motion. If the encoder measurement is inside the authorized tolerance and the receipt is valid, the secure controller advances its protected phase state and enables a larger movement key or command authenticator. The ordinary application processor never receives the unrestricted root command authority.

A.10.30. E10.30 Network / SmartNIC Example

A SmartNIC may retain the hardware root authority and enforce phased network egress. Phase 0 may allow only a bounded destination challenge or low-information object. After the remote endpoint returns a valid receipt, the SmartNIC or associated DPU may unlock broader transmit scope, a higher bandwidth envelope, or a key required to encrypt the remaining payload.

A.10.31. E10.31 Storage Controller Example

A storage controller may first permit writing a bounded object to protected staging storage. Following a verified persistence receipt, hardware may release the key or controller state needed to promote, replicate, decrypt, or expose the broader object.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.10.32. E10.32 Policy Epoch Change

A valid receipt does not override a newer restrictive policy. A representative condition is:

Epcurrent ≠ Epreceipt ⇒ Revalidate.

The hardware may refuse to derive the next key until the current policy state is confirmed.

A.10.33. E10.33 Revocation Between Key Stages

If the Candidate Act, destination, user, device, or credential is revoked after Ri but before key release:

chain Revoked = T RU E ⇒ Enable(Ki+1 ) = F ALSE.

A.10.34. E10.34 Receipt Replay Protection

A previously accepted receipt must not automatically unlock the same or another next-phase key more than permitted. Hardware may bind receipt consumption to:

  • nonce;

  • phase;

  • Candidate Act digest;

  • monotonic counter;

  • transaction identifier;

  • or stored receipt digest.

A.10.35. E10.35 Rollback Protection

An attacker should not be able to restore an older hardware state in which a consumed receipt or phase authority becomes valid again. Anti-rollback mechanisms may include:

  • monotonic hardware counters;

  • secure NVRAM epochs;

  • signed state checkpoints;

  • hardware fuses;

  • trusted time;

  • remote continuity state;

  • or equivalent protected techniques.

A.10.36. E10.36 Crash and Power-Loss Recovery

A power loss may occur after the real effect but before the next key is derived. Protected recovery may reconcile:

  • stored phase counter;

  • receipt digest;

  • sink idempotency state;

  • hardware journal;

  • destination state;

  • and monotonic counter. The system should not blindly replay a physical, financial, or communicative effect solely because volatile key state was lost.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.10.37. E10.37 Invalid Receipt Handling

Where a receipt is invalid, hardware may:

  • remain at the current phase;

  • zeroize temporary material;

  • require a new bounded trial;

  • require human review;

  • enter an indeterminate state;

  • or terminate the Candidate Act. It must not derive the broader key merely because a receipt-like object was supplied.

A.10.38. E10.38 Root-Key Rotation

The hardware root authority may be rotated without changing the logical staged-effectuation model. Migration may use a protected transition that binds:

  • old root state;

  • new root state;

  • active Candidate Acts;

  • current phase counters;

  • consumed receipts;

  • and applicable revocation state.

A.10.39. E10.39 Anti-Bypass Requirement

The value of the hardware key chain is reduced if an equivalent full-effect credential or physical path remains outside the protected hardware dependency. Accordingly, implementations may control:

  • shadow keys;

  • debug interfaces;

  • raw device commands;

  • alternate network paths;

  • recovery keys;

  • secondary payment signers;

  • duplicate storage keys;

  • or other equivalent authority paths.

A.10.40. E10.40 Completion Evidence

After final effectuation, a completion receipt may commit to the hardware chain state:

RFchain = P rotect(DA , qHW , H(R0 ), ... , H(Rn ), F inalState) .

A.10.41. E10.41 Required Invariants

The frozen conceptual invariants of E10 are: 1. at least one effectuation-critical root authority, sealed secret, or protected state is retained by hardware or hardware-rooted logic; 2. where staged mode applies, authority for a later phase is unavailable or invalid until required prior effect evidence is accepted; 3. a phase-specific key or authority does not by itself grant unbounded authority outside its permitted act, phase, sink, device, or scope; 4. receipt replay, phase rollback, and state rollback are controlled where required; 5. human, automatic, or hybrid approval can be incorporated without giving the proposing agent control of the root authority; 6. single-phase and multi-phase modes are both supported; and

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

7. equivalent authority paths are controlled where necessary to preserve the receipt-conditioned hardware dependency.

TINUATION

A.11. E11 — Threshold / Multi-Party Cryptographic Continuation

A.11.1. E11.1 Purpose

E11 defines a continuation architecture in which authority for a later effectuation phase is distributed across multiple protected participants, such that one participant alone need not possess sufficient authority to cause the broader effect. The general relation is:

V erified P rior Effect → P articipant V alidation → P rotected Authority Contributions → T hreshold Satisfaction → Combined Continuation Authority → N ext Effectuation P hase. This embodiment may be implemented cryptographically through secret sharing, threshold signatures, multi-signatures, multiple key-encryption keys, split command authorization, multiple independent latches, or equivalent protected multi-party controls.

A.11.2. E11.2 Participant Set

Let the protected continuation participants be represented by:

U = {U1 , U2 , ... , Un }. Participants may include:

  • the originating device PED;

  • an HSM;

  • a remote enterprise authority;

  • the Finality Sink;

  • the receiving endpoint;

  • a user approval device;

  • a hardware secure element;

  • a network authority;

  • a payment institution;

  • a cloud security service;

  • an independent audit authority;

  • a device owner;

  • or another protected participant. The participants need not all be operated by different organizations. Separation may be logical, physical, administrative, cryptographic, or jurisdictional.

A.11.3. E11.3 Threshold Rule

A protected threshold may require at least t acceptable authority contributions from n eligible participants:

1 ≤ t ≤ n. Continuation is permitted only where:

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

V alidShareCounti ≥ ti . The threshold may be fixed or may vary by phase, risk, amount, recipient, act class, or protected policy.

A.11.4. E11.4 Distinction from Receipt Quorum

A quorum of receipts and a threshold of authority shares are related but distinct concepts. A receipt quorum answers whether enough observers confirm the prior effect. A continuation threshold answers whether enough protected authority holders contribute to enabling the next effect. An implementation may require either or both.

A.11.5. E11.5 Per-Phase Authority Share

Participant Uj may hold or generate a phase-specific authority share:

σj,i .

The share may be:

  • a threshold-signature share;

  • secret-share contribution;

  • partial MAC;

  • wrapped-key share;

  • approval signature;

  • hardware unlock contribution;

  • policy authorization fragment;

  • decryption share;

  • signing share;

  • or another protected contribution.

A.11.6. E11.6 Share Binding

A share may be bound to:

DA , i, H(Ri−1 ), Sinki , Scopei , Ep , Er , Ni .

A representative share may be expressed as:

σj,i = P rotectKU (DA , i, H(Ri−1 ), Sinki , Scopei , Ni ) . j

This is illustrative and does not require all listed fields in every implementation.

A.11.7. E11.7 Receipt-Conditioned Share Release

Where the workflow follows E02 or E03, participant Uj may refuse to contribute its share until the required prior ECR is valid. A representative predicate is:

Release(σj,i ) = V alid(Ri−1 ) ∧ LocalP olicyP assj,i .

Thus the threshold cannot be satisfied merely from the original proposal when prior real-effect evidence is mandatory.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.11.8. E11.8 Local Independent Validation

Each participant may independently verify different predicates. For example:

  • the HSM verifies cryptographic binding;

  • the receiving endpoint verifies destination identity;

  • the human approval device verifies human consent;

  • the enterprise service verifies policy;

  • the payment institution verifies account/settlement state;

  • the hardware controller verifies device state. The architecture therefore permits distributed authority based on heterogeneous evidence.

A.11.9. E11.9 Authority Contribution Set

For phase i, let the set of accepted authority shares be:

Σi = {σj,i ∶ Accept(σj,i ) = T RU E}.

Threshold satisfaction occurs where:

|Σi | ≥ ti . Where specific named participants are mandatory, mere cardinality is insufficient and policy may additionally require those participants.

A.11.10. E11.10 Mandatory-Participant Variation

For example, continuation may require:

HumanSharei ∧ HardwareSharei ∧ (EnterpriseSharei ∨ SinkSharei ) . This is a policy expression, not a limitation to a particular threshold scheme.

A.11.11. E11.11 Combined Continuation Authority

After threshold satisfaction, a continuation authority may be reconstructed or validated:

Cithr = Combine(Σi ). The combined authority may be:

  • a threshold signature;

  • reconstructed secret;

  • combined key;

  • set of individually verified signatures;

  • multi-authorization transaction;

  • hardware unlock state;

  • or an accepted policy state indicating that the threshold has been met.

A.11.12. E11.12 No-Reconstruction Variation

Some implementations need not reconstruct a single secret. The Finality Sink may independently verify at least ti valid signatures or approval artifacts and execute only if the threshold predicate is satisfied. This avoids creating a combined bearer secret.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.11.13. E11.13 Human Share Variation

A protected human approval device may contribute one threshold share only after displaying the exact continuation context. The human share may bind:

  • Candidate Act digest;

  • prior receipt digest;

  • next phase;

  • destination;

  • scope;

  • amount;

  • expiry;

  • and protected approval-session nonce. The AI agent cannot manufacture the human share merely by generating approval-like text.

A.11.14. E11.14 Automatic Authority Share

A protected automatic decision component may contribute another share after policy evaluation. The automatic share may be withheld where:

  • risk exceeds threshold;

  • receipt quality is insufficient;

  • destination state changed;

  • taint or provenance state is prohibited;

  • or current policy requires escalation.

A.11.15. E11.15 Hardware Share

A hardware PED may hold one non-exportable share. The hardware share may be released, applied internally, or used in a threshold signing operation only where:

  • device measurement is acceptable;

  • receipt is valid;

  • monotonic phase state is correct;

  • and the requested effect remains within the hardware envelope.

A.11.16. E11.16 Destination Share

The intended destination may supply a continuation contribution after confirming the bounded demonstration effect. For a SEND operation, the recipient endpoint may prove possession of the correct receiving key or session state. For a payment operation, a receiving institution may contribute protected acceptance evidence. For a hardware operation, a local safety controller may contribute a sensor-confirmed share.

A.11.17. E11.17 Sink Share

The Finality Sink itself may hold one authority share, preventing upstream components from assembling the final effectuation authority without sink participation. This can bind the threshold to the actual effect-capable boundary.

A.11.18. E11.18 Phase-Specific Threshold

The threshold may change as consequence increases. For example:

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

t0 = 1, t1 = 2, t2 = 3. A low-consequence demonstration may require one protected authority while a large irreversible final phase requires three.

A.11.19. E11.19 Risk-Adaptive Threshold

A protected controller may select:

ti = h(Riski , Scopei , Reversibilityi , P olicyi ). A higher risk may require a greater number or stronger class of participants.

A.11.20. E11.20 Role-Constrained Threshold

Participants may belong to role classes. A phase may require, for example:

  • at least one human authority;

  • at least one hardware authority;

  • and at least one destination or transaction authority. This prevents three shares from the same trust class from satisfying a rule intended to require cross-domain agreement.

A.11.21. E11.21 Geographic / Jurisdictional Split

Shares may be distributed across geographic or jurisdictional domains. For sensitive cross-border data release, continuation may require approval from the originating jurisdiction, destination jurisdiction, and device or enterprise authority. The architecture does not require such a regulatory arrangement; it merely supports it technically.

A.11.22. E11.22 Multi-Organization Split

A cloud provider, enterprise customer, and user device may each contribute authority. No single provider then possesses unilateral ability to release the full effect where policy requires the distributed threshold.

A.11.23. E11.23 SEND Workflow

A sensitive file is proposed for transmission. Phase 0 sends a bounded protected trailer to the intended recipient. Receipt R0 returns from the recipient endpoint. For full semantic release, the system may require: 1. recipient endpoint share; 2. enterprise policy share; and 3. either a human approval share or hardware PED share. Only when the protected rule is satisfied is the final decryption key or remaining payload authority released.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.11.24. E11.24 Payment Workflow

A payment may require:

  • user-device approval share;

  • bank/HSM transaction share;

  • enterprise or account-policy share;

  • and receipt evidence from the bounded destination-verification phase. A higher payment amount may increase the threshold or require a mandatory human share.

A.11.25. E11.25 Robotic / Industrial Workflow

A hazardous actuator command may require contributions from:

  • autonomous planner policy;

  • safety controller;

  • protected sensor subsystem;

  • and optionally a human supervisor. The actuator Finality Sink executes only where the required multi-party condition is met.

A.11.26. E11.26 Threshold Key Release

A final key may be represented conceptually as:

Kithr = Reconstructt (Σi ). Where fewer than ti valid shares are available:

|Σi | < ti ⇒ Kithr unavailable.

A.11.27. E11.27 Threshold Signature Variation

Instead of reconstructing a key, participants may create a threshold signature:

Sigithr = T hresholdSignt (DA , H(Ri−1 ), i, Scopei ). The sink verifies the final threshold signature before effectuation.

A.11.28. E11.28 Multi-Signature Variation

Each participant may provide an ordinary independent signature and the sink verifies that the required set is present. This may be operationally simpler than cryptographic threshold-signature schemes while preserving distributed approval semantics.

A.11.29. E11.29 Share Freshness

Each share may bind a phase-specific nonce and expiry. A share created for one transaction or phase must not automatically remain valid for another.

A.11.30. E11.30 Share Replay Protection

After phase i is completed, previously used shares may be marked consumed or rendered invalid by phase advancement. A representative rule is:

Consumed(σj,i ) = T RU E ⇒ RejectReplay(σj,i ).

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.11.31. E11.31 Participant Revocation

If participant Uj is revoked, compromised, or no longer trusted, future shares from that participant may be refused. The policy may:

  • substitute another participant;

  • increase threshold;

  • re-share secrets;

  • require human recovery;

  • or terminate the Candidate Act.

A.11.32. E11.32 Dynamic Membership

The eligible participant set may change between phases under protected policy. A new set:

Ui+1 may replace the previous set only through a protected membership transition. The proposing agent should not be able to add arbitrary favorable participants merely to satisfy the threshold.

A.11.33. E11.33 Re-Sharing / Key Rotation

Long-lived systems may redistribute shares without changing the underlying authorization envelope. Protected re-sharing should preserve:

  • active Candidate Act state;

  • phase index;

  • receipt history;

  • revocation state;

  • and threshold policy.

A.11.34. E11.34 Participant Failure

If one participant is unavailable but the threshold can still be satisfied, the system may continue where policy permits. If the threshold cannot be satisfied:

|Σi | < ti ⇒ Effectuationi = BLOCKED. A fail-limited mode may permit a reduced consequence if separately authorized.

A.11.35. E11.35 Conflicting Participant Decisions

Participants may disagree. A negative decision from a mandatory participant may override positive shares even where the numeric threshold otherwise appears satisfied. The policy must therefore distinguish:

  • absent share;

  • positive share;

  • explicit veto;

  • indeterminate state;

  • and revoked participant.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.11.36. E11.36 Human Veto Variation

A protected human may hold a veto capability without supplying a positive share for routine phases. If the human veto is valid and timely:

V etoi = T RU E ⇒ Effectuationi = BLOCKED.

A.11.37. E11.37 Indeterminate Receipt Before Threshold

If the prior phase receipt is indeterminate, participants that require verified prior effect should not release their shares. The architecture therefore prevents a threshold from being assembled based only on upstream optimism about whether the trial succeeded.

A.11.38. E11.38 Share Confidentiality

Where shares contain sensitive key material, protected transport and storage may be used. Shares need not be visible to the AI agent or ordinary application.

A.11.39. E11.39 Collusion Consideration

Threshold distribution reduces unilateral authority only to the extent that the selected participants and threshold preserve meaningful independence. The disclosure does not assume that an arbitrary t-of-n choice is secure against all collusion. Implementations may select participants, hardware isolation, organizational separation, or policy constraints appropriate to the threat model.

A.11.40. E11.40 Alternate-Path Closure

A threshold architecture may be bypassed if an unrestricted credential or direct effect path remains available to one participant. Accordingly, equivalent effectuation paths may be required to honor the same distributed authority rule or a formally equivalent protected control.

A.11.41. E11.41 Completion Receipt

A completion receipt may commit to the threshold evidence without exposing secret shares:

RFthr = P rotect(DA , i, T hresholdP olicyi , AuthorityCommitmenti , F inalState) . AuthorityCommitmenti may be a digest of the accepted participant identities, signatures, threshold signature, or equivalent evidence.

A.11.42. E11.42 Required Invariants

The frozen conceptual invariants of E11 are: 1. broader effectuation requires protected contributions from more than one authority source where threshold mode is selected; 2. the required number and/or classes of contributions are protected policy rather than agentcontrolled values; 3. shares or approval contributions are bound to the relevant act, phase, scope, destination, receipt, or equivalent context as required; 4. where prior real-effect evidence is mandatory, participants do not validly authorize the next phase without acceptable evidence;

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

5. missing, stale, replayed, revoked, or conflicting shares are handled according to protected policy; 6. a threshold may be fixed, dynamic, role-constrained, or phase-specific; and 7. equivalent unilateral bypass paths are controlled where necessary to preserve distributed continuation authority.

FULL EFFECTUATION

A.12. E12 — Message-SEND Demonstration / Trailer-Then-Full Effectuation

A.12.1. E12.1 Purpose

E12 provides a concrete communication embodiment in which a computational system proposes a message, file, attachment, data package, command communication, or other SEND operation, but the complete intended communication does not immediately become externally effective. A bounded real communication object first traverses the actual intended effectuation path. Protected return evidence from the intended recipient path is then used as a condition for releasing the remaining or full communication effect. A representative workflow is:

P roposed SEN D → Recipient/Content Binding → Bounded T railer Authority → Real T railer T ransmission → Recipient Receipt R0 → P rotected Receipt V erification → Human/Automatic/Hybrid Continuation → F ull P ayload or Key Release → Completion Receipt.

A.12.2. E12.2 Communication Candidate Act

The Candidate Act may specify:

  • sender or sending authority;

  • intended recipient;

  • recipient account;

  • recipient device;

  • destination service;

  • conversation/thread identifier;

  • message type;

  • payload;

  • attachments;

  • content classification;

  • permitted disclosure scope;

  • timing;

  • expiration;

  • and effectuation policy. The message proposal itself does not constitute completed SEND authority.

A.12.3. E12.3 Full Communication Object

For this embodiment, let the full intended communication object be denoted:

MsgF .

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

MsgF may include text, files, images, structured data, media, tool output, attachments, or combinations thereof. The notation is local to E12 and avoids overloading the earlier symbol M .

A.12.4. E12.4 Bounded Trailer Object

A bounded real demonstration object is denoted:

Tr0 .

The trailer may contain:

  • recipient challenge;

  • cryptographic manifest;

  • payload commitment;

  • harmless bounded text;

  • encrypted fragment;

  • file metadata;

  • content hash;

  • nonce;

  • sender proof;

  • destination challenge;

  • protocol negotiation data;

  • or another limited object. The trailer must be sufficiently bounded that successful transmission does not itself disclose or effectuate the complete intended communication unless that is expressly acceptable.

A.12.5. E12.5 Real SEND Requirement

The trailer is not merely displayed locally. A real communication effect occurs when, for example:

  • bytes cross the actual egress interface;

  • the intended remote service accepts the trailer;

  • the recipient application receives the object;

  • the recipient device stores it;

  • the remote endpoint decrypts a bounded protected fragment;

  • or another externally observable state transition occurs on the actual intended path.

A.12.6. E12.6 Full-Payload Commitment

Before the trailer is sent, the system may bind it to the full intended payload through a commitment:

DMsg = H(Canon(MsgF )).

The trailer may include or bind DMsg so that the recipient receipt can refer to the same intended full communication without receiving the full content.

A.12.7. E12.7 Trailer Descriptor

A trailer descriptor may bind:

  • Candidate Act digest;

  • DMsg ;

  • recipient identity;

  • recipient device or service;

  • trailer digest;

  • permitted trailer content;

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

  • expiry;

  • nonce;

  • expected receipt issuer;

  • expected protocol;

  • next permitted phase;

  • and maximum full disclosure envelope. The earlier TED definition may be used; no separate mandatory descriptor format is required.

A.12.8. E12.8 Recipient Binding

The trailer authority may be bound to the intended recipient:

Recipient(Tr0 ) = Recipient(MsgF ). If policy permits forwarding, delegation, distribution lists, aliases, or multi-recipient delivery, the allowed transformation is bound into the authorized envelope.

A.12.9. E12.9 Account and Device Binding

Where higher assurance is required, recipient identity may include:

  • account identifier;

  • device public key;

  • secure-element identity;

  • application instance;

  • session identifier;

  • endpoint certificate;

  • organization/tenant;

  • or protected service identity. A receipt from another account or device does not automatically authorize full release.

A.12.10. E12.10 Phase-0 SEND Authority

The PED forms authority sufficient to send only Tr0 or another bounded first-stage object. The authority may be:

  • destination-bound network capability;

  • short-lived API token;

  • process-bound proxy permission;

  • DPU/SmartNIC phase key;

  • HSM signing authority;

  • protected message-broker permission;

  • or another bounded SEND capability.

A.12.11. E12.11 Egress Boundary Verification

Before transmitting the trailer, the communication Finality Sink verifies:

  • Candidate Act binding;

  • recipient/destination;

  • trailer scope;

  • nonce;

  • expiry;

  • current policy;

  • revocation state;

  • phase state;

  • and applicable approval conditions. An attempt to substitute the full payload for the trailer at Phase 0 is rejected.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.12.12. E12.12 Trailer Transmission

The sink performs the real bounded SEND. The event may traverse:

  • network socket;

  • email transport;

  • messaging service;

  • collaboration platform;

  • enterprise message bus;

  • API call;

  • device-to-device channel;

  • radio/telecom path;

  • satellite channel;

  • or another communication transport. No particular protocol is required.

A.12.13. E12.13 Recipient Processing

The recipient or receiving service may:

  • verify sender authenticity;

  • check the nonce;

  • verify DMsg ;

  • validate protocol state;

  • verify destination account;

  • store the trailer;

  • decrypt the bounded fragment;

  • prove possession of an expected private key;

  • or perform another required receiving-side operation.

A.12.14. E12.14 Recipient Effect Confirmation Receipt

The receiving endpoint generates or causes generation of receipt:

R0send . The receipt may bind:

  • Candidate Act digest;

  • DMsg ;

  • trailer digest;

  • recipient identity;

  • recipient endpoint identity;

  • account/session identity;

  • receive time;

  • nonce;

  • acceptance status;

  • protocol transcript digest;

  • and applicable attestation.

A.12.15. E12.15 Receipt Authentication

R0send may be protected by:

  • digital signature;

  • MAC;

  • TLS/channel-bound evidence;

  • device attestation;

  • secure-element signature;

  • application signature;

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

  • server-side signed receipt;

  • threshold signature;

  • or another protected mechanism.

A.12.16. E12.16 Receipt Verification

The sender-side PED verifies the return evidence. A representative condition is:

SendReceiptP ass0 = V alid(R0send ) ∧ M atchM essage(R0send , DMsg ) ∧ M atchRecipient(R0send ) ∧ M atchN once(R0send ) ∧ F resh(R0send ). Additional predicates may be required.

A.12.17. E12.17 Wrong-Recipient Receipt

If the trailer was received by an unauthorized or mismatched endpoint:

M atchRecipient(R0send ) = F ALSE then broader release remains blocked. This directly addresses the case in which a syntactically valid communication reaches the wrong account, device, tenant, service, or cryptographic endpoint.

A.12.18. E12.18 Human Review After Trailer

Where E04 applies, the protected UI may display:

  • intended recipient;

  • verified recipient endpoint;

  • trailer acceptance status;

  • trailer time;

  • message/attachment digest;

  • expected full disclosure;

  • and any changed risk or destination state. The human then approves, denies, reduces, or delays the broader SEND.

A.12.19. E12.19 Automatic Continuation After Trailer

Where E05 applies, a protected automatic authority may continue if:

SendReceiptP ass0 ∧ P olicyP ass ∧ RiskAcceptable = T RU E. No human interaction is mandatory for such policy classes.

A.12.20. E12.20 Hybrid Continuation

Where E06 applies:

SendReceiptP ass0 ∧ HumanP ass ∧ AutoP ass may be required before the full payload or full decryption authority is released. Threshold continuation under E11 may also be used.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.12.21. E12.21 Trailer-Then-Full Payload Variation

The simplest variation is:

Tr0 → R0send → MsgF .

After the receipt is accepted, the remaining full message or file is transmitted through the protected egress boundary.

A.12.22. E12.22 Trailer-Then-Phased Payload Variation

For a large or sensitive payload:

Tr0 → R0 → Segment1 → R1 → ⋯ → Segmentn .

Each segment or group of segments may require a fresh protected receipt before broader disclosure.

A.12.23. E12.23 Ciphertext-First Variation

The system may transmit encrypted full payload ciphertext before semantic release. Let:

CTF = EncKF (MsgF ).

CTF may reach the recipient before full authorization, provided the recipient lacks sufficient material to recover MsgF . After receipt verification, the PED releases KF , a missing key share, or equivalent decryption authority.

A.12.24. E12.24 Partial-Decryption Trailer Variation

The full ciphertext may be present, while only a bounded portion is decryptable initially. A first-stage key may reveal only:

  • title;

  • manifest;

  • selected non-sensitive fields;

  • low-information preview;

  • recipient challenge;

  • or another bounded subset. The full decryption material is released only after protected receipt validation.

A.12.25. E12.25 Key-Chain SEND Variation

E12 may use E10 directly:

K0chain → Tr0 → R0send → K1chain → F ull SEN D. This makes the final SEND key cryptographically dependent on the protected return evidence.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.12.26. E12.26 Threshold SEND Variation

E12 may use E11 such that final disclosure requires, for example:

  • recipient receipt;

  • enterprise share;

  • hardware share;

  • and human approval share for high-risk content. No single agent or broker need possess unilateral authority to release the complete content.

A.12.27. E12.27 File Attachment Variation

A message may contain a short body and a large attachment. The body or a protected trailer may be sent first. After receipt confirmation, the attachment may be:

  • uploaded;

  • transmitted;

  • decrypted;

  • linked through a protected access grant;

  • or progressively released.

Instead of transmitting the full file through the messaging transport, the message may contain a reference to an object stored elsewhere. The initial message may deliver a non-usable or bounded reference. After recipient confirmation, the PED may enable:

  • access token;

  • signed URL;

  • decryption key;

  • object capability;

  • or destination-bound retrieval authority.

A.12.29. E12.29 Multi-Recipient Variation

For recipients:

R = {r1 , r2 , ... , rk }, the system may first send trailers to a protected subset:

Rtrial ⊆ R. Broader distribution may be authorized only after the required receipt predicate over the trial subset succeeds.

A.12.30. E12.30 Recipient-Specific Semantic Release

Different recipients may receive the same ciphertext but different decryption capabilities. A recipient-specific receipt may unlock only that recipient’s semantic access without automatically granting access to other recipients.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.12.31. E12.31 Group / Distribution-List Variation

A group address may resolve to multiple endpoints. Protected policy may require confirmation of:

  • group identity;

  • current membership version;

  • intended audience class;

  • or bounded sample recipients before broader delivery.

A.12.32. E12.32 Thread / Conversation Binding

The SEND may be bound to a protected conversation or thread identifier. A valid receipt from the correct recipient but an unrelated conversation need not authorize release if thread binding is mandatory.

A.12.33. E12.33 Reply-Path Verification

The trailer may test the return path as well as forward delivery. The receipt can therefore prove that the intended endpoint can receive and return protected evidence through the expected session or account context.

A.12.34. E12.34 Protocol-Downgrade Protection

An attacker should not satisfy the trial using a weaker unprotected communication mode where stronger protected transport was required. The trailer descriptor or policy may bind:

  • transport class;

  • cryptographic session;

  • endpoint assurance;

  • or minimum protocol property.

A.12.35. E12.35 Content Substitution Protection

The full payload released after the trailer should remain the same authorized payload or remain within the authorized transformation envelope. A representative predicate is:

H(Canon(Msgreleased )) = DMsg

for exact-content release. Where edits are permitted, policy may require a new digest, revalidation, or renewed approval.

A.12.36. E12.36 Attachment Substitution Protection

If the trailer receipt was generated for attachment digest DAtt , a different attachment must not be silently substituted during full SEND. The full release authority may bind all relevant attachment digests.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.12.37. E12.37 Recipient Redirection Protection

A trailer receipt from Recipient A must not authorize the final message to Recipient B unless redirection is expressly authorized. A representative requirement is:

Recipient(R0send ) = Recipient(F inalSend).

A.12.38. E12.38 Expiry and Stale Receipt

A recipient may have changed devices, account state, membership, or key state after the trial. A stale receipt may therefore require a new trailer rather than authorizing delayed full disclosure.

A.12.39. E12.39 Revocation Between Trailer and Full SEND

If the sender revokes the communication after receipt but before full release:

Revoked(MsgF ) = T RU E ⇒ F ullSend = BLOCKED.

A.12.40. E12.40 Destination-State Change

Even with a valid receipt, continuation may be denied if destination state materially changes. Examples include:

  • recipient account disabled;

  • device key rotated;

  • tenant changed;

  • policy changed;

  • data-class rule changed;

  • or endpoint attestation no longer valid.

A.12.41. E12.41 Crash After Trailer SEND

The trailer may be delivered while the sender crashes before storing the receipt. The trailer should preferably use an idempotency identifier or unique nonce so the system can determine whether it was already received before retransmitting.

A.12.42. E12.42 Duplicate Full-SEND Protection

A valid trailer receipt should not cause duplicate full messages merely because the sender retries after a timeout. The full SEND may use a protected final-send identifier:

IFsend = H(DA ∥ DMsg ∥ H(R0send ) ∥ NF ).

The sink or destination may record the identifier atomically with the full effect where appropriate.

A.12.43. E12.43 Indeterminate Full SEND

If the system cannot determine whether the full payload was delivered, it enters an indeterminate state rather than assuming non-delivery. Reconciliation may use:

  • recipient receipt;

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

  • server transaction identifier;

  • message ID;

  • object-store access state;

  • delivery log;

  • or destination query.

A.12.44. E12.44 Negative Receipt

The recipient may explicitly reject the trailer. A protected negative receipt may cause:

  • cancellation;

  • human review;

  • corrected recipient selection;

  • reduced content;

  • new session establishment;

  • or denial. Negative receipt does not authorize full SEND.

A.12.45. E12.45 Privacy-Preserving Trailer

The trailer may disclose very little information while still proving endpoint correctness. For example, it may contain only:

  • random challenge;

  • payload commitment;

  • encrypted manifest;

  • destination nonce;

  • or zero-knowledge proof request. This reduces the consequence of a mistaken Phase-0 delivery.

A.12.46. E12.46 Sensitive-Content Variation

For highly sensitive content, the trailer may reveal no substantive content at all. The actual protected effect is then recipient/session verification rather than partial semantic disclosure.

A.12.47. E12.47 Low-Risk Message Variation

For low-risk communications, protected policy may select E01 single-phase SEND rather than a trailer workflow. Thus the system need not impose trial latency on every communication.

A.12.48. E12.48 Hardware-Enforced SEND

A DPU, SmartNIC, secure NIC, modem security processor, secure element, or hardware gateway may retain the final payload key or network release authority. The agent can prepare the message but cannot cause full egress until hardware verifies the required receipt/approval state.

A.12.49. E12.49 Software-Enforced SEND

A privileged network proxy, message broker, OS service, kernel gate, API gateway, or credential broker may perform the same logical workflow in software. The ordinary agent process need not possess the effect-capable messaging credential.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.12.50. E12.50 Split Software/Hardware SEND

Software may perform content classification, policy, and human interaction while hardware retains the final egress key or transmit capability. A bound software ADR and the recipient receipt may be required before hardware permits full transmission.

A.12.51. E12.51 Telecom / Radio SEND Variation

A message may traverse a cellular, radio, satellite, or other communications system. The initial transmission may be bounded by:

  • payload size;

  • time;

  • beam;

  • frequency;

  • recipient;

  • power;

  • or protocol state. Protected receiver confirmation may enable the broader transmission.

A.12.52. E12.52 Machine-to-Machine SEND

No human recipient is required. A machine endpoint, API, robot, vehicle, cloud service, or infrastructure controller may receive the bounded trailer and return protected machine evidence before the full command, file, configuration, or data object is released.

A.12.53. E12.53 SEND Versus Payment Analogy

The same staged-finality principle can apply to both communications and payments. For SEND:

Bounded M essage Effect → Recipient Receipt → F ull Disclosure. For payment:

Bounded F inancial Effect → Institution/Settlement Receipt → Broader Settlement.

The underlying effect domains differ, but both preserve the distinction between authority to begin and authority to complete the consequence.

A.12.54. E12.54 Anti-Bypass Requirement

Where protected trailer-first SEND is mandatory, the system should account for equivalent fullsend paths such as:

  • direct SMTP/API credentials;

  • raw network socket;

  • alternate messaging account;

  • file-sharing link outside the broker;

  • direct object-store access grant;

  • hidden administrator route;

  • recovery credential;

  • or another path capable of the same disclosure. Such paths may be disabled, mediated, credential-restricted, cryptographically locked, or brought under equivalent protected finality controls.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

A.12.55. E12.55 Completion Receipt

After the final communication becomes effective, a completion receipt may bind:

RFsend = P rotect(DA , DMsg , H(R0send ), RecipientID, F inalDeliveryState) . For multi-phase transfer, the receipt may bind the receipt chain or its aggregate commitment.

A.12.56. E12.56 Required Invariants

The frozen conceptual invariants of E12 are: 1. in trailer-first mode, a bounded real communication effect occurs on the actual intended effectuation path before broader/full communication effectuation; 2. protected return evidence is tied to the intended message context and recipient/destination as required; 3. the broader message, attachment, semantic content, decryption authority, or equivalent communication consequence remains unavailable until the required continuation conditions are satisfied; 4. human, automatic, hybrid, hardware-key-chain, and threshold continuation may each be used; 5. a valid trailer receipt does not authorize content, recipient, destination, or scope outside the previously authorized envelope; 6. crash, duplicate-send, stale-receipt, wrong-recipient, and indeterminate states are handled without assuming that absence of acknowledgement means absence of effect; and 7. equivalent full-SEND bypass paths are controlled where needed to preserve the staged communication dependency.

FROZEN RELATIONSHIP BETWEEN E10, E11 AND E12

K0chain → R0 → K1chain → R1 → ⋯ → Knchain . The principal technical emphasis is protected hardware authority progression.

Ri−1 → {σ1,i , ... , σn,i } → T hreshold Satisfaction → Cithr . The principal technical emphasis is distributed continuation authority.

Tr0 → R0send → P rotected Continuation → MsgF .

The principal technical emphasis is real recipient-path verification before broader communication effectuation. The embodiments may be combined. For example, an E12 trailer SEND may produce R0send , E11 may require threshold approval after that receipt, and E10 hardware may then derive or unseal the final SEND key. A composite relation is:

Tr0 → R0send → T hreshold Authority E11 → Hardware Key Release E10 → F ull SEN D E12.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

APPENDIX I - NEW DEFINITIONS INTRODUCED BY E10-E12 ONLY I.1 Non-Repetition Rule Definitions already supplied in the Advanced Section 1 master definitions or E01-E09 workflow appendices are intentionally not repeated. The definitions below cover only new terms or materially specialized meanings introduced by E10-E12.

I.2 Receipt-Conditioned Hardware Key Chain Receipt-Conditioned Hardware Key Chain means a hardware-rooted authority progression in which a later phase key, secret, key slot, command authenticator, unseal operation, latch state, or equivalent protected authority becomes available or valid only after required protected evidence from an earlier phase has been accepted.

I.3 Hardware Root Authority Hardware Root Authority means a hardware-protected key, secret, state, trust anchor, sealed object, or equivalent protected source from which phase-specific authority can be derived, unsealed, validated, or activated. It is narrower here than the general hardware root-of-authority definition only in emphasizing its role in a receipt-conditioned chain.

I.4 Receipt-Conditioned Derivation Receipt-Conditioned Derivation means deriving a later protected authority using an accepted receipt, receipt digest, receipt-chain commitment, or equivalent prior-effect evidence as an input or protected prerequisite.

I.5 Receipt-Conditioned Unsealing Receipt-Conditioned Unsealing means making a pre-existing sealed or wrapped later-phase secret usable only after the required prior receipt and protected state have been accepted.

I.6 Phase-Key Chain Phase-Key Chain means a sequence of phase-specific protected cryptographic authorities associated with successive effectuation phases. The term does not require every later key to be mathematically derived from the immediately prior key.

I.7 Threshold Continuation Threshold Continuation means a continuation rule under which a required number, class, or combination of protected authority contributions from multiple participants must be satisfied before the next effectuation phase becomes available.

I.8 Threshold Authority Share Threshold Authority Share means a participant-specific protected contribution used toward satisfying a threshold continuation condition. It may be a cryptographic secret share, signature share, ordinary signature, key-encryption contribution, hardware unlock contribution, approval artifact, or equivalent authority fragment.

I.9 Authority Contribution Set Authority Contribution Set means the set of accepted participant contributions applicable to a particular act and phase for determining whether the continuation threshold has been satisfied.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

I.10 Role-Constrained Threshold Role-Constrained Threshold means a threshold rule that requires not only a number of positive contributions but also specified participant categories, such as at least one human authority and one hardware authority.

I.11 Trailer Object Trailer Object means a bounded real communication object transmitted through the intended communication path before broader/full communication release. A Trailer Object may contain a challenge, manifest, commitment, bounded content, encrypted fragment, or other limited information and is not limited to audiovisual media terminology.

I.12 Trailer-Then-Full Effectuation Trailer-Then-Full Effectuation means a communication workflow in which a real bounded Trailer Object is first delivered or processed and protected return evidence from that stage is required before a broader message, file, attachment, key, access capability, or semantic content becomes available.

I.13 Semantic Release Semantic Release means making protected content intelligible, decryptable, usable, viewable, executable, or otherwise meaningfully available to the intended recipient, even where encrypted bytes may have been transported earlier.

I.14 Ciphertext-First SEND Ciphertext-First SEND means a staged communication mode in which all or part of encrypted payload data may reach the destination before the destination possesses sufficient protected authority to obtain the complete plaintext or semantic content.

I.15 Recipient-Path Verification Recipient-Path Verification means protected verification, using a real bounded communication effect and returned evidence, that an intended recipient account, endpoint, application, device, session, service, or equivalent destination path is operating within the required conditions before broader release.

I.16 Full-SEND Identifier Full-SEND Identifier means an act-specific protected identifier or idempotency value associated with the final communication effect and used to detect or prevent unintended duplicate full transmission.

APPENDIX J - NEW NOTATION INTRODUCED BY E10-E12 ONLY J.1 Non-Repetition Rule Notation already defined in the Advanced Section 1 master notation appendix or E01-E09 delta notation appendices is not repeated. The symbols below are new to E10-E12 or have a materially specialized local meaning.

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

J.2 E10 Notation

  • KRA - hardware Root Authority used locally in E10 as the protected source for phase authority.

  • Bi - illustrative bound act/context digest for phase i.

  • Kichain - phase-specific authority/key in the E10 receipt-conditioned hardware key chain.

  • Seali - sealed later-phase protected object or secret in the unsealing variation.

  • Wi - wrapped phase key/object stored before its protected release condition is satisfied.

  • Lchain i - protected latch associated specifically with the E10 hardware key chain.

  • qHW - protected hardware phase index/state for the E10 progression.

  • CumulativeReceipti - illustrative commitment to receipt history through phase i. chain

  • RF - final completion receipt binding the E10 key-chain progression.

J.3 E11 Notation

  • U - eligible protected participant set for threshold continuation.

  • Uj - protected participant j.

  • ti - required continuation threshold for phase i; distinct from earlier timing notation Ti .

  • σj,i - authority share/contribution from participant Uj for phase i.

  • Σi - set of accepted authority contributions for phase i.

  • |Σi | - cardinality, i.e., number of accepted contributions in Σi .

  • Cithr - continuation authority resulting from threshold satisfaction for phase i.

  • Kithr - reconstructed or otherwise threshold-enabled phase key in the key-reconstruction variation.

  • Sigithr - threshold signature or equivalent combined signature evidence for phase i.

  • Ui+1 - updated eligible participant set for a later phase following a protected membership transition. thr

  • RF - final completion receipt binding threshold-policy evidence.

  • AuthorityCommitmenti - non-secret commitment to the accepted threshold evidence for phase i.

J.4 E12 Notation

  • MsgF - full intended communication object in E12; used instead of the earlier locally overloaded symbol M .

  • Tr0 - bounded real Trailer Object used for the initial SEND demonstration.

  • DMsg - digest/commitment of the full intended communication object.

  • R0send - protected receipt for the initial E12 trailer SEND.

  • SendReceiptP ass0 - illustrative protected predicate indicating that the initial SEND receipt satisfies the required checks.

  • CTF - encrypted full payload ciphertext in the ciphertext-first variation.

  • KF - final payload decryption key or equivalent semantic-release authority in E12.

  • DAtt - digest of an attachment when attachment binding is required.

  • R - authorized recipient set in the multi-recipient SEND variation.

  • Rtrial - bounded trial-recipient subset. send

  • IF - protected idempotency identifier for the final SEND effect. send

  • RF - final SEND completion receipt.

J.5 New Function / Predicate Labels The following word-like expressions are illustrative functional or predicate notation rather than required programming identifiers: MatchSink, NotConsumed, Enable, Release, Accept, Reconstruct_t, ThresholdSign_t, MatchMessage, MatchRecipient, MatchNonce, FullSend, Recipient, FinalSend, Canon, Wrap, and related labels introduced in E10-E12.

J.6 Threshold Symbol Clarification The symbol ti in E11 denotes an authority threshold and should not be confused with prior symbols used for time, timestamp, or protected timing. The participant count n retains its ordinary

Advanced Section 1 - E10-E12 Key Chains | Threshold | SEND

mathematical meaning as the size of the eligible participant set in the local threshold context.

J.7 Local Interpretation Rule Where E10-E12 reuse a symbol already defined in earlier Advanced Section 1 materials, the prior meaning remains controlling unless the local subsection expressly assigns a narrower meaning. The equations are functional disclosure and may be realized through equivalent cryptographic objects, hardware state, protocol fields, policy engines, distributed signatures, message-broker state, or protected state machines.

A.13. E13 — Receipt-Gated File Transfer and Progressive File Release

A.13.1. E13.1 Purpose

E13 defines a file-transfer workflow in which a file, file set, object, archive, model artifact, executable image, media object, document, or other byte-addressable or object-addressable payload is not necessarily released as an immediately complete externally usable consequence. A protected system may first cause a bounded real transfer, bounded storage commit, bounded recipient-path verification, bounded decryption event, or other limited real file effect. Protected

evidence from that event may then become a prerequisite for broader transfer or full semantic release. A representative relationship is:

Candidate F ile T ransfer → P rotected F ile Descriptor → Bounded Real F ile Effect → F ile Effect Receipt → P rotected Receipt V erification → N ext F ile Authority → Broader/F ull F ile Effect.

A.13.2. E13.2 File Candidate Act

The Candidate Act may request one or more of:

  • sending a file;

  • copying a file;

  • uploading a file;

  • downloading a file;

  • publishing a file;

  • exporting a file;

  • replicating an object;

  • sharing an object-store reference;

  • decrypting a protected file;

  • promoting a staged object into a production namespace;

  • releasing a model checkpoint;

  • making an attachment visible to a recipient;

  • or another file-related external consequence. The file operation is treated as an effect-capable act rather than merely as local computation.

A.13.3. E13.3 Full File Object and Authorized Envelope

Let the complete intended file object be denoted:

Ffull .

A protected digest or commitment may be:

DF = H(CanonF ile(Ffull )) .

The authorized envelope may additionally bind:

  • permitted recipient;

  • permitted destination;

  • permitted storage class;

  • permitted object path;

  • maximum file size;

  • file type or class;

  • confidentiality classification;

  • integrity requirement;

  • allowed expiry;

  • allowed geographic region;

  • allowed application or account;

  • allowed number of recipients;

  • and any transformation that is permitted before or during transfer.

A.13.4. E13.4 File Manifest

A protected File Transfer Manifest may describe the file without requiring the entire payload to be interpreted by the enforcement component. A manifest may include:

  • file digest;

  • file size;

  • object identifier;

  • MIME or media type;

  • chunk count;

  • per-chunk digests;

  • Merkle root;

  • encryption state;

  • key identifier;

  • destination;

  • recipient;

  • intended storage or application;

  • retention requirement;

  • and permitted transformation rules.

Denote such a manifest locally by:

MF .

A.13.5. E13.5 Transfer Session Binding

A protected transfer session may receive a session identifier:

SIDF . The PED may bind SIDF to:

DA , DF , MF , Recipient, Destination, Ep , Er .

A file receipt generated for another session must not automatically authorize continuation of the present session.

A.13.6. E13.6 Selection of File-Release Mode

Protected policy may select among:

Mode A - Single-Phase File Release The full file is released according to E01.

Mode B - Trial Segment Then Full File A bounded real segment or verification object is first transferred.

Mode C - Progressive Chunk Release Multiple chunks are released sequentially or in protected groups.

Mode D - Ciphertext First, Key Later The ciphertext may arrive before semantic access authority is released.

Mode E - Staged Storage Then Promotion The file is first committed into a restricted namespace and later promoted to a broader or externally usable namespace.

Mode F - Multi-Recipient Progressive Release A protected subset of recipients receives the file before broader distribution.

A.13.7. E13.7 Bounded File Effect

The bounded first file effect may comprise one or more of:

  • a small content segment;

  • a non-sensitive trailer object;

  • an encrypted prefix;

  • a manifest;

  • a cryptographic challenge object;

  • one block or range of the file;

  • one object in a multi-object set;

  • a low-information representation;

  • a staging write;

  • an object-store commit that is not yet externally readable;

  • or another real but limited file consequence. The first-stage object need not reveal sensitive semantic content.

A.13.8. E13.8 Segment Representation

Where the file is segmented:

n Ffull = ⋃ Fj . j=0

The union notation is illustrative; implementation may use ordered concatenation, object lists, ranges, erasure-coded fragments, sparse regions, or other file structures. A per-segment digest may be:

dj = H(Fj ).

A.13.9. E13.9 Trial Segment Descriptor

The protected system may identify an initial real transfer segment:

trial F0 . Its descriptor may bind:

  • DF ;

  • SIDF ;

  • byte range or object identity;

  • d0 ;

  • recipient;

  • destination;

  • encryption state;

  • expected storage or processing result;

  • nonce;

  • expiry;

  • and permitted next action.

A.13.10. E13.10 Initial File Authority

The PED may create a phase-specific authority:

C0file whose valid scope is limited to the initial file effect. A representative scope relation is:

Scope(C0file ) ⊂ Scope(Ffull ).

The authority may be represented by a scoped credential, signed transfer descriptor, key share, storage capability, network capability, destination-side permission, or equivalent protected condition.

A.13.11. E13.11 Real Transfer Through Intended Path

The bounded object is transmitted through the actual effect-capable route intended for later file transfer. Examples include:

  • actual HTTPS upload endpoint;

  • real object-storage API;

  • real file-sharing service;

  • enterprise content gateway;

  • secure messaging attachment path;

  • secure copy service;

  • remote storage controller;

  • destination application;

  • device-to-device transfer path;

  • or another real file effect path. A local preview does not satisfy this embodiment merely because it resembles the target file.

A.13.12. E13.12 Destination-Side Processing

The destination may perform one or more protected operations on the bounded file effect:

  • receive bytes;

  • validate session identifier;

  • validate file or segment digest;

  • persist the segment;

  • commit metadata;

  • decrypt a bounded portion;

  • confirm available storage;

  • verify permitted file type;

  • perform malware or content policy evaluation where applicable;

  • bind the received object to the intended recipient/account;

  • or enter a protected staging state.

A.13.13. E13.13 File Effect Receipt

The destination, storage system, gateway, sink, or other protected observer may generate:

R0file . The receipt may bind:

  • Candidate Act digest;

  • DF ;

  • SIDF ;

  • segment digest;

  • destination identity;

  • recipient identity;

  • storage commit identifier;

  • protected status;

  • nonce;

  • timestamp or protected time;

  • object version;

  • encryption state;

  • and applicable policy epoch.

A.13.14. E13.14 Receipt Semantics

R0file may establish a technical fact narrower than “the recipient understood the file.” For example, it may establish that:

  • the intended endpoint received the segment;

  • the endpoint validated its digest;

  • the destination durably stored it;

  • the intended secure application accepted it;

  • the recipient device proved possession of required decryption capability;

  • the staging namespace accepted it;

  • or another defined file effect occurred.

A.13.15. E13.15 File Receipt Verification

A protected verifier may evaluate:

V alid(R0file ),

M atchF ile(R0file , DF ),

M atchSession(R0file , SIDF ),

M atchRecipient(R0file ),

M atchSegment(R0file , d0 ), and:

F resh(R0file ). If any mandatory predicate fails, broader file release remains blocked.

A.13.16. E13.16 Human Continuation Variation

After the real bounded file effect, an independent protected human approval interface may display:

  • file identity;

  • file digest or recognizable descriptor;

  • recipient;

  • destination;

  • trial result;

  • storage or endpoint confirmation;

  • remaining file scope;

  • and any relevant confidentiality warning. A protected approval artifact may then authorize the next file stage.

A.13.17. E13.17 Automatic Continuation Variation

Protected policy may automatically release additional file scope where:

F ileReceiptP ass0 ∧ P olicyP ass ∧ RiskAcceptable = T RU E.

A.13.18. E13.18 Hybrid Continuation Variation

A later stage may require both a valid file receipt and human or multi-party authority. For example:

F ileReceiptP ass0 ∧ HumanApproval ∧ AutoP olicyP ass ⇒ Enable(F ileStage1 ).

A.13.19. E13.19 Progressive Chunk Transfer

The file may be released through multiple actual transfer phases:

file F0 → R 0 → F1 → R1file → ⋯ → Fn . Each required receipt may authorize only the next chunk or bounded group of chunks.

A.13.20. E13.20 Chunk-Chain Binding

For phase j, the protected file receipt may include the preceding receipt digest:

Rjfile = P rotect(DF , SIDF , dj , H(Rj−1 file ), Statusj ) .

This may create a tamper-evident transfer chain.

A.13.21. E13.21 Merkle-Root Variation

For large files, the manifest may include a root:

RootF = M erkleRoot(d0 , d1 , ... , dn ). A destination may verify individual chunks against RootF without requiring the receipt to restate the entire file.

A.13.22. E13.22 Ciphertext-First File Transfer

The complete encrypted file may be transferred before full semantic access is permitted. Let:

CTF = EncK file (Ffull ). data

file The destination may store CTF but remain unable to obtain the plaintext because Kdata or a required key share remains withheld.

A.13.23. E13.23 Semantic File Release

Following protected receipt verification, the PED or protected hardware may release, reconstruct, or authorize use of:

file Kdata . Thus:

T ransported Bytes ⇏ Semantic F ile Release. This variation can reduce latency while preserving staged semantic effectuation.

A.13.24. E13.24 Partial Decryption Variation

The system may permit decryption of only a bounded initial region or object class. After valid protected evidence, additional decryption ranges or keys become available. This may be implemented with:

  • independently encrypted chunks;

  • hierarchical keys;

  • envelope encryption;

  • per-object keys;

  • threshold key shares;

  • hardware key slots;

  • or equivalent protected key segmentation.

A.13.25. E13.25 Staged Storage Promotion

A file may first be placed in:

  • quarantine storage;

  • private staging bucket;

  • non-indexed namespace;

  • read-restricted object class;

  • temporary protected filesystem;

  • or another bounded storage state.

A protected persistence receipt may then enable promotion into:

  • production storage;

  • public or shared namespace;

  • searchable index;

  • downloadable state;

  • model registry;

  • deployment repository;

  • or another broader state.

A.13.26. E13.26 Promotion Receipt

A storage engine may generate:

RFpromote binding the transition from staging to broader storage visibility. Where the promotion itself is consequential, it may be treated as a separate Candidate Act and separately gated.

A.13.27. E13.27 File-Type Transformation Variation

The destination may transform the file before broader release, for example:

  • decompress;

  • transcode;

  • convert format;

  • strip metadata;

  • sanitize active content;

  • generate a derivative;

  • or re-encrypt. The manifest may bind permitted transformation rules so that an unauthorized transformation cannot silently substitute for the authorized file effect.

A.13.28. E13.28 Deduplication Variation

A destination may determine that the file or chunk already exists. A valid receipt may therefore indicate:

  • new bytes stored;

  • existing object matched;

  • content-addressed object reused;

  • or no additional physical write required. The receipt should still bind the current transfer session and authorized file identity where the later continuation depends upon it.

A.13.29. E13.29 Sparse or Range-Based File Variation

A file need not be divided into contiguous chunks. The protected system may authorize ranges:

Bj = [aj , bj ]

and verify receipt evidence for those ranges before additional ranges become available.

A.13.30. E13.30 Resume After Interruption

If transfer stops after chunk j, protected state may record the highest verified phase:

qF = j. A resumed transfer may continue only from a state consistent with:

  • verified receipts;

  • manifest;

  • current policy;

  • current recipient;

  • current destination;

  • and non-revoked authority.

A.13.31. E13.31 Crash After Chunk Commit

If a destination commits Fj but crashes before returning the receipt, the sender should not blindly resend if duplicate write or duplicate processing would be unsafe. A protected idempotency value may be:

Ijfile = H(DF ∥ SIDF ∥ j ∥ Nj ).

file The destination may store Ij atomically with the corresponding file state.

A.13.32. E13.32 Receipt Loss

file If Rj is lost after generation, the destination may retransmit the same authenticated receipt without re-performing the file effect. A replayed receipt must not authorize multiple independent releases of the same next phase.

A.13.33. E13.33 Wrong-Recipient Protection

A receipt for Recipient A must not enable file release to Recipient B unless a protected policy expressly authorizes that substitution. A representative invariant is:

Recipient(Rjfile ) = Recipientauthorized .

A.13.34. E13.34 Wrong-File Protection

A receipt for a different file or different file version must not authorize the current transfer. Therefore:

Digest(Rjfile ) = DF

or an equivalent protected binding is required.

A.13.35. E13.35 Versioned Object Variation

Where a file changes after trial effectuation, the system may compute a new file digest and require a new trial or protected revalidation. A prior receipt for version v should not automatically authorize version v + 1.

A.13.36. E13.36 Multi-File Bundle Variation

A Candidate Act may concern a bundle:

(1) (k) F = {F , ... , F }. The system may:

  • trial one representative object;

  • require one receipt per object;

  • use a manifest root over the bundle;

  • or progressively release subsets. The required strategy is protected policy.

A.13.37. E13.37 Multi-Recipient File Release

For authorized recipient set:

RF , a bounded subset may receive the real file effect first:

Rtrial F ⊂ RF .

Protected receipts from the bounded subset may permit broader distribution where policy allows.

A.13.38. E13.38 Recipient-Specific Keys

Each recipient may receive a distinct wrapped content key. A valid receipt from one recipient need not authorize release of another recipient’s key unless the policy explicitly couples those releases.

A.13.39. E13.39 Network and Storage Split Enforcement

The network path may permit transport only after a network-specific capability while the destination storage system separately controls commit or visibility. Thus a file may cross multiple finality boundaries:

Sender → N etwork Sink → Storage Sink → Semantic Release Sink. Each boundary may generate or verify protected evidence.

A.13.40. E13.40 Hardware Enforcement Variation

Hardware enforcement may use:

  • secure element;

  • TPM;

  • TEE;

  • HSM;

  • DPU;

  • SmartNIC;

  • storage controller;

  • SSD controller;

  • secure DMA engine;

  • hardware-backed filesystem key;

  • or another protected hardware component. file The hardware may hold Kdata or a key-encryption key and release it only after required file receipts are accepted.

A.13.41. E13.41 Software Enforcement Variation

Software enforcement may use:

  • kernel mediation;

  • proxy;

  • API gateway;

  • storage gateway;

  • content service;

  • secure daemon;

  • object-store policy engine;

  • message broker;

  • or another protected software boundary.

A.13.42. E13.42 Alternative-Path Closure

The protected file workflow may close or equivalently mediate:

  • direct object-store credentials;

  • alternate upload APIs;

  • raw filesystem paths;

  • sync clients;

  • backup paths;

  • administrative copy operations;

  • temporary links;

  • alternate network routes;

  • and other paths capable of producing the same broader file effect.

A.13.43. E13.43 Indeterminate File State

If the system cannot establish whether a chunk, object, or promotion occurred:

F ileState = IN DET ERM IN AT E. Broader release may remain blocked while the PED reconciles storage state, object version, transfer identifier, or destination receipt.

A.13.44. E13.44 Completion Receipt

After full file effectuation, a completion receipt may bind:

RFfile = P rotect(DA , DF , SIDF , RootF , F inalF ileState) . For progressive transfer, it may additionally bind the receipt-chain root or final verified phase.

A.13.45. E13.45 Required Invariants

The frozen conceptual invariants of E13 are: 1. a file-related Candidate Act is distinguishable from completed file effectuation; 2. where staged mode is selected, at least one real bounded file effect occurs before broader/full file consequence; 3. protected evidence from the bounded effect is validated before required later file authority is enabled; 4. file, version, session, recipient, destination, and scope bindings prevent receipt substitution where those attributes are material; 5. ciphertext transport may be separated from semantic file release; 6. crash, resume, deduplication, duplicate-transfer, and indeterminate states do not automatically create authority for broader release; and 7. equivalent alternate file-effect paths are controlled where needed to preserve the staged dependency.

FULL / PROGRESSIVE PAYMENT

A.14. E14 — Payment Demonstration and Receipt-Gated Full / Progressive Payment

A.14.1. E14.1 Purpose

E14 defines a protected payment workflow in which an intended transfer of value need not become fully effective immediately after an initial computational or policy decision. Where supported by the applicable financial infrastructure, the system may first perform a bounded real financial operation such as:

  • a small verification transfer;

  • a reversible or cancellable authorization;

  • a bounded account hold;

  • a reservation;

  • a partial payment;

  • a protected beneficiary-verification transaction;

  • a zero-value or nominal-value authorization supported by the rail;

  • or another real payment-rail state transition.

Protected evidence from that operation may then be required before broader or full payment authority is released.

A.14.2. E14.2 Rail-Dependent Operation

Not every payment rail supports every type of bounded operation. Accordingly, E14 does not require a rail to support a feature that it does not implement. The PED may select a technically supported staged operation from the capabilities of the actual rail, institution, wallet, ledger, card network, bank-transfer system, payment processor, settlement system, or other payment environment.

A.14.3. E14.3 Full Intended Payment

Let the total intended authorized value be:

VF . The payment Candidate Act may additionally bind:

  • beneficiary;

  • beneficiary account or address;

  • amount;

  • currency or asset;

  • source account;

  • payment rail;

  • purpose or reference where relevant;

  • fee policy;

  • execution window;

  • jurisdiction;

  • and maximum authorized consequence.

A.14.4. E14.4 Payment Descriptor

A protected Payment Effect Descriptor may be represented locally by:

Dpay .

It may bind:

DA , VF , Beneficiary, Asset, Rail, Ep , Er , Expiry.

A.14.5. E14.5 Payment Identifier

A protected payment session or transaction family identifier may be:

P IDF . Individual rail transaction identifiers may remain distinct.

A.14.6. E14.6 Selection of Payment Mode

Protected policy may select:

Mode A - Single-Phase Full Payment The complete authorized amount proceeds under E01.

Mode B - Bounded Demonstration Then Full Payment A real bounded payment operation is completed or accepted first.

Mode C - Progressive Partial Payments The total amount is released through multiple value phases.

Mode D - Authorization / Reservation Then Capture or Settlement Where the rail supports separate authorization and later capture or settlement, the earlier state is used as the bounded real effect.

Mode E - Escrow / Conditional Holding The flow transitions into E15.

A.14.7. E14.7 Bounded Trial Value

Where a bounded monetary amount is appropriate, define:

0 < v0 < V F . v0 is not a universal required amount. It is selected according to policy, minimum rail constraints, fees, reversibility, user preference, legal constraints, and risk.

A.14.8. E14.8 Non-Monetary Trial State

A bounded financial effect need not transfer a positive monetary amount. Where supported by the payment rail, the first real effect may be:

  • zero-value account verification;

  • account-name or beneficiary confirmation;

  • authorization without capture;

  • token validation;

  • reversible reservation;

  • wallet challenge;

  • settlement-account handshake;

  • or another protected rail-native state transition.

A.14.9. E14.9 Trial Payment Authority

The PED may issue:

C0pay whose scope is restricted to the selected bounded payment operation. A representative requirement is:

Scope(C0pay ) ⊂ Scope(VF ).

A.14.10. E14.10 Binding to Beneficiary and Asset

The initial authority and subsequent receipts may bind:

  • beneficiary identity;

  • beneficiary account/address;

  • currency;

  • token or asset identifier;

  • source account;

  • and rail. A successful bounded payment to one beneficiary must not automatically authorize the full payment to another beneficiary.

A.14.11. E14.11 Real Payment-Rail Effect

The bounded operation is submitted to the actual payment infrastructure. This may cause:

  • authorization state;

  • funds reservation;

  • beneficiary verification;

  • partial transfer;

  • settlement entry;

  • ledger state transition;

  • escrow placement;

  • or another real financial-system effect.

A.14.12. E14.12 Payment Effect Observer

Protected payment evidence may originate from:

  • bank;

  • payment processor;

  • card acquirer or issuer system;

  • wallet provider;

  • settlement network;

  • ledger node;

  • transaction HSM;

  • receiving institution;

  • beneficiary-controlled endpoint where appropriate;

  • or another protected financial component.

A.14.13. E14.13 Payment Effect Receipt

The bounded financial effect may produce:

R0pay . The receipt may bind:

  • P IDF ;

  • Candidate Act digest;

  • beneficiary;

  • amount or authorization scope;

  • asset or currency;

  • rail;

  • transaction reference;

  • acceptance state;

  • settlement or reservation state;

  • nonce;

  • protected time;

  • and current policy state.

A.14.14. E14.14 Payment Receipt Status

A payment receipt may represent states such as:

  • AUTHORIZED;

  • RESERVED;

  • ACCEPTED;

  • PARTIALLY_SETTLED;

  • SETTLED;

  • DECLINED;

  • REVERSED;

  • EXPIRED;

  • CANCELLED;

  • REJECTED;

  • or INDETERMINATE. The meaning is rail-specific and should be interpreted according to the underlying system rather than assumed to imply final settlement.

A.14.15. E14.15 Receipt Verification

A protected verifier may evaluate:

V alid(R0pay ),

M atchP ayment(R0pay , P IDF ),

M atchBeneficiary(R0pay ),

M atchAsset(R0pay ),

W ithinT rialScope(R0pay ), and:

F resh(R0pay ).

A.14.16. E14.16 Human Approval After Demonstration

After the bounded financial effect, a protected approval interface may show:

  • beneficiary;

  • verified account or destination information;

  • bounded trial result;

  • amount already affected;

  • remaining intended amount;

  • fees;

  • currency/asset;

  • current payment state;

  • and whether continuation is reversible or final. A fresh human approval may then authorize broader payment authority.

A.14.17. E14.17 Automatic Continuation

Protected automatic continuation may occur where:

P aymentReceiptP ass0 ∧P olicyP ass∧RiskAcceptable∧W ithinAuthorizedEnvelope = T RU E.

A.14.18. E14.18 Hybrid Continuation

The system may require both protected automatic validation and human approval before a larger payment phase. Threshold authority under E11 may also be used, for example requiring enterprise approval plus hardware authority.

A.14.19. E14.19 Full Payment Continuation Authority

After accepted trial evidence, the system may generate or release:

C1pay for the remaining or full authorized payment consequence. C1pay may be:

  • transaction signature;

  • HSM signing authorization;

  • API capability;

  • payment token;

  • capture authorization;

  • settlement instruction;

  • key share;

  • hardware-unsealed signing key slot;

  • or another protected payment enablement condition.

A.14.20. E14.20 Receipt-Conditioned Payment Key

Using E10, a hardware component may derive:

K1pay = KDF (KRA , DA , H(R0pay ), P IDF , 1) . The protected property is receipt-conditioned authority, not the specific KDF syntax.

A.14.21. E14.21 Progressive Payment Phases

Where the total authorized value can be safely divided:

n V F = ∑ vi . i=0

A staged sequence may be:

v0 → R0pay → v1 → R1pay → ⋯ → vn .

A.14.22. E14.22 Cumulative Payment Bound

Let cumulative value after phase i be:

i Vicum = ∑ vj . j=0

The PED may require:

Vicum ≤ VF . Successful prior receipts cannot increase the maximum authorized payment.

A.14.23. E14.23 Dynamic Phase Amount

The next permitted value may be selected according to protected state:

vi+1 = fpay (Ripay , Riski , P olicyi , Approvali , Remainingi ).

The function may reduce or terminate the next phase if conditions deteriorate.

A.14.24. E14.24 Authorization-Then-Capture Variation

Where a payment system supports authorization and capture as separate states: 1. Phase 0 obtains a real bounded or full-value authorization without final capture; 2. the system verifies the authorization result and beneficiary/payment context; 3. protected continuation authority is then required for capture; 4. capture or settlement occurs only after the continuation predicate succeeds. This variation is used only where the underlying rail implements such states.

A.14.25. E14.25 Reservation / Hold Variation

A payment system may first place a bounded reservation or hold. The hold receipt confirms that the actual financial rail accepted the reservation. Later protected authority may:

  • capture it;

  • increase it within the authorized envelope;

  • partially capture;

  • release it;

  • or expire it according to rail rules.

A.14.26. E14.26 Small Verification Transfer Variation

Where permitted, a small real transfer may verify the beneficiary path. A receiving institution or protected beneficiary endpoint may return evidence linked to the verification transfer. Only then may the larger payment be authorized. The system should account for the fact that a successful small transfer does not prove that a larger transfer will necessarily settle; it provides a verified prior-effect predicate, not a guarantee of future success.

A.14.27. E14.27 Refund / Reversal Variation

If a bounded trial value should not remain with the beneficiary, protected policy may authorize a refund or reversal where the rail supports it. The reversal is itself a consequential act and may be separately receipt-gated.

A.14.28. E14.28 Fee-Aware Staging

The system may consider fees when choosing staged payments. A technically valid implementation may avoid economically irrational micro-phases where fixed fees would dominate. Protected policy may therefore choose authorization, reservation, or another rail-native bounded effect instead of repeated monetary transfers.

A.14.29. E14.29 Currency and Asset Binding

A receipt for one currency or token must not authorize payment in another unless the conversion is expressly included in the authorized envelope. The payment descriptor may bind:

AssetID, CurrencyCode, or T okenID.

A.14.30. E14.30 Foreign-Exchange Variation

Where conversion is part of the intended payment, the protected workflow may separately bind:

  • source asset;

  • destination asset;

  • conversion provider;

  • maximum rate slippage;

  • fee ceiling;

  • and expiry. A trial result may verify destination path while a fresh continuation check verifies the current exchange state before full effectuation.

A.14.31. E14.31 Recurring Payment Variation

A recurring authorization may define a protected envelope for repeated payments. Each occurrence may still require:

  • current policy check;

  • beneficiary check;

  • period limit;

  • receipt state;

  • and optional staged verification. A prior successful occurrence does not automatically authorize unlimited future amounts.

A.14.32. E14.32 Batch Payment Variation

For beneficiary set:

B = {B1 , ... , Bk }, protected policy may first execute a bounded subset:

Btrial ⊂ B. Receipts from the subset may permit broader batch release, subject to per-beneficiary and aggregate limits.

A.14.33. E14.33 Beneficiary Confirmation Variation

The receiving side may return a protected acknowledgement proving control of an accountspecific challenge or transaction reference. This may strengthen destination binding before the remaining amount is released.

A.14.34. E14.34 Payment Idempotency

A phase may use:

Iipay = H(P IDF ∥ i ∥ Beneficiary ∥ vi ∥ Ni ). The payment gateway or protected sink may record the identifier with the financial state to reduce unintended duplicate submissions.

A.14.35. E14.35 Crash After Financial Effect

If the payment rail accepts or settles a phase but the local system crashes before receiving confirmation, the PED enters an indeterminate state rather than assuming failure. The system may reconcile using:

  • rail transaction reference;

  • bank query;

  • wallet query;

  • ledger state;

  • HSM transaction journal;

  • beneficiary receipt;

  • or another authoritative financial record.

A.14.36. E14.36 Indeterminate Payment State

A representative state is:

P aymentState = IN DET ERM IN AT E. While unresolved, the remaining payment authority may stay blocked.

A.14.37. E14.37 Proven-Effected Reconciliation

If reconciliation proves the phase occurred, the system may recover or reconstruct the missing receipt without repeating the payment.

A.14.38. E14.38 Proven-Not-Effected Reconciliation

If reconciliation proves the financial effect did not occur, a fresh protected retry may be authorized according to current policy.

A.14.39. E14.39 Settlement-Finality Awareness

The workflow may distinguish among:

  • request accepted;

  • payment authorized;

  • funds reserved;

  • payment posted;

  • clearing completed;

  • settlement completed;

  • irreversible or rail-defined final state. A receipt should not be interpreted as stronger finality than the underlying rail actually provides.

A.14.40. E14.40 Payment State Machine

A protected local representation may use rail-specific states, for example:

P ROP OSED → T RIAL_AU T HORIZED → T RIAL_EF F ECT ED → RECEIP T _V ERIF IED → CON T IN U AT ION _AU T HORIZED → F U LL_P AY M EN T _EF F ECT ED.

Failure, reversal, cancellation, and indeterminate branches may exist at each appropriate state.

A.14.41. E14.41 Hardware Payment Enforcement

An HSM, secure element, TEE, payment security module, hardware wallet, secure processor, or other protected component may retain signing or release authority. The proposing AI or application may receive no reusable unrestricted payment secret.

A.14.42. E14.42 Software Payment Enforcement

A protected payment broker, transaction service, payment gateway, bank-side policy service, or enterprise payment controller may enforce phase state and receipt gating.

A.14.43. E14.43 Split Software / Hardware Payment Enforcement

Software may evaluate policy while hardware retains signing material. A representative sequence is:

Software P olicy P ass → Hardware T rial Signature → R0pay → Hardware F ull Signature Enable.

A.14.44. E14.44 Threshold Payment Continuation

Using E11, a larger payment may require m-of-n protected authorities after the trial receipt. Examples include:

  • two enterprise officers;

  • human + hardware;

  • enterprise + bank;

  • device owner + financial controller;

  • or another policy-defined combination.

A.14.45. E14.45 Revocation Between Payment Phases

A valid trial does not guarantee later payment. If:

Revoked(A) = T RU E, unused payment continuation authority becomes invalid.

A.14.46. E14.46 Risk Change Between Payment Phases

If protected risk increases after the bounded operation, the PED may:

  • reduce next value;

  • require human review;

  • require threshold approval;

  • change rail;

  • place funds into E15 conditional holding;

  • or deny continuation.

A.14.47. E14.47 Alternative-Path Closure

Where staged payment is mandatory, equivalent payment paths may be controlled, including:

  • direct bank API;

  • payment processor credential;

  • raw signing key;

  • wallet export key;

  • administrative payment path;

  • alternate service account;

  • fallback rail;

  • or another path capable of completing the same protected payment consequence.

A.14.48. E14.48 Full Payment Receipt

After completion, a receipt may bind:

RFpay = P rotect(DA , P IDF , Beneficiary, VF , AssetID, F inalP aymentState) . For progressive payment, the receipt may additionally bind the phase-receipt chain or aggregate commitment.

A.14.49. E14.49 Required Invariants

The frozen conceptual invariants of E14 are: 1. staged payment uses only bounded operations actually supported by the underlying rail; 2. the initial financial effect is real and narrower than the complete authorized consequence in amount, state, reversibility, scope, or another material dimension; 3. protected evidence of the bounded financial effect is verified before required later authority is enabled; 4. beneficiary, asset, rail, amount, session, and transaction bindings prevent receipt substitution where material; 5. a successful bounded payment does not itself expand the maximum authorized amount; 6. indeterminate payment states are reconciled rather than blindly retried where duplicate effect is unsafe; 7. the workflow distinguishes authorization, reservation, posting, clearing, settlement, and other rail-specific states where relevant; and 8. alternate full-payment paths are controlled where needed to preserve receipt-gated continuation.

GATED RELEASE

A.15. E15 — Escrow / Conditional Settlement and Receipt-Gated Release

A.15.1. E15.1 Purpose

E15 defines a protected conditional-holding workflow in which value, an asset, data-release authority, cryptographic key material, transaction authority, or another protected item is first

placed into a technically controlled intermediate state and is not released to its ultimate destination until defined protected conditions are satisfied. The term escrow is used functionally in this technical disclosure. It does not by itself assert that a particular implementation constitutes legal, regulated, fiduciary, or licensed escrow under any jurisdiction. A regulated deployment may require an appropriately authorized provider and applicable legal controls.

A.15.2. E15.2 Core Relationship

A representative sequence is:

Candidate Settlement → P rotected Holding Authority → Real Conditional Holding State → Holding Receipt → Condition Evidence → P rotected Release Decision → F ull/P artial Release → Settlement Receipt.

A.15.3. E15.3 Conditional Holding Object

Let the item subject to conditional release be denoted:

Xhold .

It may represent:

  • funds;

  • tokenized value;

  • a payment authorization;

  • a key;

  • a signed transaction;

  • data-access authority;

  • credential authority;

  • file decryption authority;

  • software deployment authority;

  • or another protected consequence.

A.15.4. E15.4 Escrow / Holding Identifier

A protected holding instance may be assigned:

EscID. The identifier may bind the Candidate Act, parties, asset, maximum amount, expiry, release conditions, and protected policy.

A.15.5. E15.5 Holding Descriptor

A Conditional Holding Descriptor may be represented locally by:

Desc . It may identify:

  • depositor/source;

  • intended beneficiary;

  • held value or asset;

  • release conditions;

  • refund conditions;

  • deadline;

  • dispute state;

  • governing technical policy;

  • required authorities;

  • receipt requirements;

  • and permissible partial releases.

A.15.6. E15.6 Release Condition Set

Let the protected release-condition set be:

Γ = {γ1 , γ2 , ... , γm }. Each γj may represent a protected predicate such as:

  • beneficiary verified;

  • bounded trial payment confirmed;

  • delivery event confirmed;

  • destination device attested;

  • human approval received;

  • automatic policy passed;

  • threshold authority satisfied;

  • protected time reached;

  • no revocation present;

  • required external evidence accepted;

  • or another defined condition.

A.15.7. E15.7 Condition Semantics

The PED should not assume that a textual claim that a condition occurred is sufficient. Where a condition is required to be machine-verifiable, the system obtains evidence from an authorized protected source or applies another trusted verification mechanism.

A.15.8. E15.8 Real Holding Effect

The first stage causes a real state transition into conditional holding. Examples include:

  • funds reserved in a protected account or ledger state;

  • tokenized value locked by a protected transaction condition;

  • payment authority placed into a non-settleable pending state;

  • decryption key wrapped under a protected release condition;

  • signing key share sealed in an HSM;

  • data object encrypted and held without release key;

  • deployment command staged but non-executable;

  • or another technically enforceable intermediate state.

A.15.9. E15.9 Holding Receipt

The system may obtain:

esc Rhold confirming that the item entered the defined protected holding state. The receipt may bind:

  • EscID;

  • source;

  • beneficiary;

  • asset;

  • amount or scope;

  • holding component;

  • expiry;

  • condition-set digest;

  • and protected state.

A.15.10. E15.10 No Release Before Holding Confirmation

Where policy requires actual holding before later actions proceed:

esc V alid(Rhold ) = F ALSE ⇒ ReleaseDisabled. This prevents a system from acting as if funds or authority were secured when the real holding step did not occur.

A.15.11. E15.11 Release Condition Evaluation

A release predicate may be represented as:

ReleaseReady = ⋀ V alid(γj ). γj ∈Γreq

Different conditions may be required for different release phases.

A.15.12. E15.12 Human Approval Condition

A protected human approval may itself be one release condition:

γH = HumanApprovalV alid. The human may review the holding receipt and subsequent condition evidence before approving release.

A.15.13. E15.13 Automatic Condition

A protected policy engine may automatically satisfy a condition when machine-verifiable evidence meets policy. For example:

γA = ReceiptV alid ∧ P olicyCurrent ∧ RiskAcceptable.

A.15.14. E15.14 Hybrid Release Condition

A release may require both human and automatic conditions:

ReleaseReady = γH ∧ γA ∧ γR , where γR may represent required receipt evidence.

A.15.15. E15.15 Threshold Release Condition

Using E11, release may require:

|Σesc | ≥ tesc and optionally required authority classes.

A.15.16. E15.16 Conditional Payment Escrow Variation

A payment workflow may first transfer or reserve value into the holding state rather than directly to the final beneficiary. After the required evidence is accepted, the protected system authorizes release from holding to the beneficiary.

A.15.17. E15.17 Trial-Payment Then Holding Variation

E14 and E15 may combine:

T rial P ayment → R0pay → Conditional Holding → Rhold esc → Release Conditions → F inal Settlement.

This can separately verify beneficiary path and secure the larger value before final release.

A.15.18. E15.18 Holding Then Trial Release Variation

A held amount may itself be released in a bounded first tranche. Let total held value be:

Vhold . A bounded release may satisfy:

0 < u0 < Vhold . The beneficiary or settlement system may return a receipt before the remaining amount becomes eligible for release.

A.15.19. E15.19 Progressive Tranche Release

A held value may be released through phases:

n Vhold = ∑ ui . i=0

Each release may require evidence from the preceding phase:

ui → Riesc → ui+1 .

A.15.20. E15.20 Cumulative Release Bound

Let cumulative release be:

i Uicum = ∑ uj . j=0

The protected system requires:

Uicum ≤ Vhold .

A.15.21. E15.21 Release Authority Object

After conditions are satisfied, the PED may generate:

esc Crel representing bounded release authority. It may be a transaction signature, HSM operation, key share, smart-contract invocation authority, bank API capability, decryption key, or equivalent protected enablement.

A.15.22. E15.22 Receipt-Conditioned Release Key

A hardware-rooted implementation may derive:

esc esc Krel = KDF (KRA , EscID, H(Rhold ), H(EvidenceΓ )) . EvidenceΓ denotes a protected commitment to the accepted condition evidence.

A.15.23. E15.23 Destination Binding

The holding descriptor may bind the final beneficiary or destination. A release receipt or condition from another beneficiary must not silently redirect the held item.

A.15.24. E15.24 Asset Binding

The release authority may be bound to the held asset or item. A condition satisfied for one asset must not automatically authorize release of a different asset.

A.15.25. E15.25 Expiry and Timeout

The holding state may define:

texpiry esc . If release conditions are not satisfied by expiry, protected policy may:

  • refund;

  • return authority to source;

  • extend the hold through fresh approval;

  • enter dispute state;

  • or terminate according to the authorized workflow.

A.15.26. E15.26 Refund Path

A refund or return is itself a consequential act. The system may therefore generate a protected refund authority:

esc Crefund .

It may require its own approval, destination binding, and receipt.

A.15.27. E15.27 Refund Receipt

After return to the source, the system may obtain:

esc Rrefund .

This receipt may close the holding state without final beneficiary release.

A.15.28. E15.28 Cancellation Before Release

A protected authorized party may cancel the transaction before release where policy permits. Cancellation invalidates unused release authority and may trigger refund or continued hold depending on protected rules.

A.15.29. E15.29 Revocation

A revocation event may cause:

ReleaseReady = F ALSE even if earlier release conditions were satisfied. This may require revalidation or refund according to policy.

A.15.30. E15.30 Condition Change

If a condition changes after it was previously satisfied, the PED may determine whether the evidence remains valid. For volatile conditions, freshness may be mandatory at the moment of release.

A.15.31. E15.31 Delivery-Evidence Variation

For a transaction involving delivery of a digital or physical item, an authorized source may provide protected delivery evidence. The system must define what that evidence proves. For example, it may prove:

  • a digital object was delivered to a specified endpoint;

  • a device entered a required state;

  • a carrier-generated event occurred;

  • or another machine-verifiable event. The architecture does not assume that a generic “delivered” label proves legal acceptance or semantic satisfaction.

A.15.32. E15.32 Data-for-Payment Atomicity-Like Variation

A protected system may coordinate:

  • data/key release on one side; and

  • payment/settlement release on the other. The system may use conditional holding so that neither complete data access nor complete payment release occurs until the defined reciprocal evidence exists. This is not required to be perfectly atomic across all infrastructures; the workflow may instead expose explicit intermediate and indeterminate states.

A.15.33. E15.33 Key Escrow / Key-Holding Variation

Instead of holding money, protected hardware may hold a decryption or signing key. The key remains sealed until release conditions are satisfied. The same receipt-gated logic therefore applies to semantic data release or command authority.

A.15.34. E15.34 Command Escrow Variation

A consequential command may be pre-staged but non-executable. Protected holding may comprise:

  • encrypted command;

  • disabled queue entry;

  • hardware-locked command buffer;

  • pending transaction;

  • or another non-effective state. Condition satisfaction then enables execution.

A.15.35. E15.35 Storage-Promotion Holding Variation

A file may be placed into protected staging storage and treated as a held object. Release means promotion into externally accessible storage after required receipt and policy conditions. This combines E13 and E15.

A.15.36. E15.36 Smart-Contract / Ledger Variation

Where a programmable ledger supports conditional holding, the holding and release logic may be implemented partly by on-ledger state. Protected off-ledger components may still verify:

  • user authority;

  • external evidence;

  • destination binding;

  • policy;

  • and hardware state. No particular ledger or consensus protocol is required.

A.15.37. E15.37 Bank / Custodial Service Variation

A bank, payment institution, wallet, custodian, or other authorized service may implement the holding state using its native reserved, pending, blocked, segregated, or equivalent transaction state. The technical architecture may rely on service-provided protected transaction evidence rather than assume direct control of funds.

A.15.38. E15.38 Multi-Party Holding Control

Different parties may hold different authority shares. Examples include:

  • source + beneficiary;

  • source + enterprise controller;

  • human + hardware;

  • bank + enterprise;

  • buyer + seller + neutral protected authority;

  • or another policy-defined set. Threshold continuation may determine release.

A.15.39. E15.39 Dispute State

A protected state may be:

EscrowState = DISP U T ED. While disputed, ordinary release and refund paths may remain blocked until a specifically authorized resolution path succeeds.

A.15.40. E15.40 Dispute Resolution Authority

A dispute-resolution action may require a distinct authority class and may not be satisfiable by the proposing agent itself. The resulting decision may authorize:

  • full release;

  • partial release;

  • refund;

  • split settlement;

  • continued hold;

  • or termination.

A.15.41. E15.41 Split Settlement

A held value may be divided among multiple destinations according to protected resolution. Let:

{u(1) , u(2) , ... , u(k) } be authorized release amounts such that:

k ∑ u(r) ≤ Vhold . r=1

A.15.42. E15.42 Hardware Enforcement

An HSM, secure element, TEE, hardware wallet, secure processor, transaction module, or other protected hardware may retain the release key or transaction-signing authority. A validated holding receipt and condition evidence may be required before hardware enables release.

A.15.43. E15.43 Software Enforcement

A protected transaction service, bank-side policy service, payment broker, escrow service, secure daemon, database transaction manager, or policy engine may maintain the holding state.

A.15.44. E15.44 Split Software / Hardware Enforcement

Software may evaluate complex conditions while hardware enforces final release authority. For example:

Software Conditions P ass → Hardware V erifies Evidence Commitment → Hardware Release Authority.

A.15.45. E15.45 Condition-Evidence Commitment

A compact protected commitment may be:

DΓ = H(CanonEvidence(γ1 , ... , γm )) . Hardware need not necessarily process every high-level condition itself if it can verify a protected decision and the required commitment under the selected trust model.

A.15.46. E15.46 Crash After Release

If release occurs but the local orchestrator crashes before receiving the settlement receipt, the system enters an indeterminate state. It should reconcile the authoritative holding/settlement state before issuing another release.

A.15.47. E15.47 Release Idempotency

A release phase may use:

Iiesc = H(EscID ∥ i ∥ Destination ∥ ui ∥ Ni ). The release sink may record this identifier atomically with the effect where technically supported.

A.15.48. E15.48 Indeterminate Holding State

If the system cannot establish whether value entered holding, it must not assume the value is secured. Similarly, if it cannot establish whether release occurred, it must not assume release failed. Explicit states may include:

  • HOLDING_INDETERMINATE;

  • RELEASE_INDETERMINATE;

  • REFUND_INDETERMINATE.

A.15.49. E15.49 Reconciliation

The PED may query:

  • holding service;

  • bank;

  • ledger;

  • HSM journal;

  • destination;

  • transaction database;

  • object store;

  • or other authoritative state source. The result may be PROVEN_HELD, PROVEN_NOT_HELD, PROVEN_RELEASED, PROVEN_NOT_RELEASED or STILL_INDETERMINATE.

A.15.50. E15.50 Alternative-Path Closure

Where conditional holding is mandatory, alternate paths capable of bypassing the hold or release conditions may be disabled or equivalently mediated. Examples include:

  • direct payment credential;

  • alternate bank API;

  • direct decryption key;

  • raw signing key;

  • administrative release endpoint;

  • bypass settlement route;

  • direct object-store publication;

  • or other equivalent effect path.

A.15.51. E15.51 Final Settlement Receipt

After authorized final release, a receipt may be:

RFesc = P rotect(DA , EscID, H(Rhold esc ), DΓ , F inalSettlementState) .

A.15.52. E15.52 Refund Completion Receipt

If the workflow ends by return rather than beneficiary settlement, a separate terminal receipt may bind the refund path. Thus the system can distinguish:

  • COMPLETED_RELEASE;

  • COMPLETED_REFUND;

  • CANCELLED;

  • DISPUTED;

  • or another terminal protected state.

A.15.53. E15.53 Privacy-Preserving Condition Evidence

A release condition need not expose unnecessary underlying data. The system may accept protected evidence proving a predicate while withholding raw information, using commitments, selective disclosure, zero-knowledge proof, or another privacypreserving technique where appropriate.

A.15.54. E15.54 Multi-Jurisdiction / Policy Variation

A holding/release workflow may bind jurisdiction-specific policy, but the technical architecture does not itself determine legal compliance. Fresh legal or policy state may be a protected release predicate where required by deployment.

A.15.55. E15.55 Required Invariants

The frozen conceptual invariants of E15 are: 1. the held item or authority enters a real technically controlled intermediate state before conditional release where holding is required;

2. the system obtains protected evidence that the holding state exists; 3. later release, partial release, refund, or other disposition is conditioned on protected policy and defined evidence; 4. human, automatic, hybrid, threshold, software, hardware, and split enforcement may each be used; 5. successful condition evidence cannot enlarge the release beyond the authorized held envelope; 6. expiry, revocation, dispute, crash, refund, and indeterminate states are represented explicitly rather than silently treated as successful release; 7. the term escrow is functional and does not by itself assert a particular legal status; and 8. alternate paths capable of bypassing the required conditional-holding dependency are controlled where needed to preserve the architecture.

FROZEN RELATIONSHIP BETWEEN E13, E14 AND E15

Bounded F ile Effect → R0file → Broader F ile T ransfer/Release. The principal technical emphasis is receipt-gated progression from a real bounded file effect to broader transport, storage visibility, or semantic access.

Bounded F inancial Effect → R0pay → Broader/F ull P ayment Authority. The principal technical emphasis is rail-supported bounded financial effect before broader value transfer.

esc Holding Effect → Rhold → Condition Evidence → P rotected Release. The principal technical emphasis is real protected intermediate holding followed by evidence-conditioned release, partial release, refund, or other authorized disposition. The embodiments may be composed. A file may be staged under E13, payment may be verified under E14, and the remaining payment or key may be held under E15 until both sides’ required evidence is satisfied. A representative composite relation is:

F ile T rial E13 → R0file P ayment T rial E14 → R0pay {R0file , R0pay } → Conditional Holding/Release E15.

APPENDIX K - NEW DEFINITIONS INTRODUCED BY E13- E15 ONLY K.1 Non-Repetition Rule Definitions already supplied in the Advanced Section 1 master definitions or E01-E12 workflow appendices are intentionally not repeated. The definitions below cover only new terms or materially specialized meanings introduced by E13-E15.

K.2 File Transfer Manifest File Transfer Manifest means a protected machine-processable description of a file or file set that may bind file digest, size, chunk structure, recipients, destination, encryption state, object identity, allowed transformation, and other transfer-relevant attributes without requiring every enforcement component to interpret the complete file payload.

K.3 File Effect Receipt File Effect Receipt means protected evidence that a defined real file-related effect occurred, such as receipt, storage commit, bounded decryption, staging, destination acceptance, or promotion state. It does not necessarily prove human reading or semantic acceptance of the file.

K.4 Semantic File Release Semantic File Release means making file content intelligible, decryptable, executable, viewable, importable, or otherwise meaningfully usable, even where ciphertext bytes or a non-usable object may have been transported earlier.

K.5 Staged Storage Promotion Staged Storage Promotion means transitioning a file or object from a restricted, quarantined, temporary, non-indexed, non-public, or otherwise bounded storage state into a broader durable, discoverable, production, shared, or externally accessible state after protected conditions are satisfied.

K.6 Payment Effect Receipt Payment Effect Receipt means protected evidence from an authorized financial component that a defined rail-specific financial state occurred, such as authorization, reservation, acceptance, partial settlement, settlement, reversal, cancellation, or another defined state. Its meaning is limited to the status actually represented by the underlying rail.

K.7 Bounded Financial Effect Bounded Financial Effect means a real but intentionally limited financial-system state transition performed before a broader payment consequence, including where supported a small transfer, reversible authorization, reservation, hold, beneficiary verification operation, partial settlement, or other limited rail-native effect.

K.8 Payment Demonstration Payment Demonstration means use of a Bounded Financial Effect and protected return evidence to establish a verified prior payment-path or financial-state predicate before broader/full payment authority is released. It does not imply that a small successful payment guarantees later settlement.

K.9 Conditional Holding State Conditional Holding State means a technically controlled intermediate state in which value, an asset, cryptographic material, transaction authority, data-release authority, command authority, or another consequential item is withheld from final release pending protected conditions.

K.10 Functional Escrow Functional Escrow means a Conditional Holding State used as an intermediate technical control. The term does not by itself represent or guarantee legal, fiduciary, regulated, licensed, or jurisdiction-specific escrow status.

K.11 Conditional Holding Descriptor Conditional Holding Descriptor means a protected representation of a holding arrangement that may bind source, beneficiary, asset, amount or scope, release conditions, refund conditions, expiry, dispute state, authorities, and applicable receipt requirements.

K.12 Release Condition Set Release Condition Set means the protected set of predicates whose required members must be satisfied before a specified release phase becomes eligible.

K.13 Release Authority Object Release Authority Object means a bounded protected capability, signature authority, key share, transaction authorization, decryption authority, hardware enable value, or other technical condition enabling release from a Conditional Holding State.

K.14 Progressive Tranche Release Progressive Tranche Release means releasing held value or authority in multiple bounded phases, with one or more later tranches depending on protected evidence from preceding releases or other protected conditions.

K.15 Refund Authority Refund Authority means protected authority to return a held item, value, or equivalent consequence to an authorized source or alternative destination according to the applicable conditionalholding policy.

K.16 Dispute State Dispute State means a protected holding state in which ordinary release and/or refund paths are suspended pending a specifically authorized resolution path.

K.17 Condition-Evidence Commitment Condition-Evidence Commitment means a cryptographic or otherwise tamper-evident commitment to the evidence or verified results used to determine satisfaction of one or more release conditions.

APPENDIX L - NEW NOTATION INTRODUCED BY E13-E15 ONLY L.1 Non-Repetition Rule Notation already defined in the Advanced Section 1 master notation appendix or E01-E12 delta notation appendices is not repeated. Symbols below are new to E13-E15 or have a materially specialized local meaning.

L.2 E13 Notation

  • Ffull - complete intended file object or protected file payload.

  • DF - protected digest/commitment of the full file object.

  • MF - File Transfer Manifest.

  • SIDF - protected file-transfer session identifier.

  • Fj - file segment, chunk, range object, or protected subdivision indexed by j.

  • dj - digest of file segment Fj .

trial

  • F0 - bounded initial real file effect used as the trial segment/object. file

  • Cj - file-specific phase authority for stage j. file

  • Rj - File Effect Receipt for file phase j.

  • RootF - Merkle or equivalent aggregate integrity root for file segments.

  • CTF - ciphertext representation of the complete file in the ciphertext-first variation; the same symbol family appeared in E12 for message ciphertext but is specialized here to the file object. file

  • Kdata - protected file data-decryption key or equivalent semantic-release authority. promote

  • RF - receipt evidencing protected storage promotion.

  • Bj = [aj , bj ] - locally defined byte/range interval for range-based transfer.

  • qF - highest protected verified file-transfer phase/index in a resumable transfer. file

  • Ij - file-phase idempotency identifier.

  • F - protected set/bundle of files in a multi-file Candidate Act.

  • RF - authorized recipient set for file release.

  • Rtrial F - trial-recipient subset for file release. file

  • RF - final file completion receipt.

L.3 E14 Notation

  • VF - total intended authorized payment value in E14.

  • Dpay - protected Payment Effect Descriptor.

  • P IDF - protected identifier for the payment transaction family/session.

  • vi - bounded payment value associated with payment phase i. pay

  • Ci - payment-specific continuation authority for phase i. pay

  • Ri - protected Payment Effect Receipt for phase i. pay

  • K1 - illustrative receipt-conditioned payment authority/key for a later payment phase.

  • Vicum - cumulative value effected through payment phase i.

  • fpay (⋅) - illustrative protected function selecting a next payment phase amount.

  • AssetID - protected identifier for the currency, token, security, balance class, or other transferred asset. pay

  • Ii - phase-specific payment idempotency identifier. pay

  • RF - final payment completion receipt.

  • B - beneficiary set in the E14 batch-payment context. This local use of B is distinct from E13 byte-range notation Bj .

  • Btrial - bounded trial subset of beneficiaries in batch payment.

L.4 E15 Notation

  • Xhold - item, value, authority, key, asset, or other protected consequence placed into conditional holding.

  • EscID - protected identifier for the conditional-holding instance.

  • Desc - Conditional Holding Descriptor.

  • Γ - Release Condition Set.

  • γj - individual protected release condition/predicate.

  • Γreq - subset of release conditions required for a particular release decision.

  • γH - locally defined protected human-approval condition.

  • γA - locally defined automatic protected-policy condition.

  • γR - locally defined required receipt-evidence condition. esc

  • Rhold - protected receipt proving the defined conditional-holding state.

  • Σesc - accepted authority-contribution set used for E15 threshold release.

  • tesc - threshold required for the E15 release context; distinct from timestamp notation.

  • Vhold - total value or quantitatively measurable scope held for later release.

  • ui - bounded release tranche for phase i.

  • Riesc - protected receipt for release tranche i.

  • Uicum - cumulative amount/scope released through tranche i. esc

  • Crel - Release Authority Object for conditional settlement. esc

  • Krel - illustrative protected release key/authority in a hardware-rooted variation.

  • EvidenceΓ - protected evidence or commitment representing satisfaction of required release conditions. expiry

  • tesc - expiry time associated with the holding state; locally a time value, not an authority threshold. esc

  • Crefund - protected Refund Authority. esc

  • Rrefund - protected refund completion receipt.

  • DΓ - Condition-Evidence Commitment.

  • Iiesc - release-phase idempotency identifier. esc

  • RF - final conditional-settlement receipt.

L.5 New Function / Predicate Labels The following word-like expressions are illustrative functional or predicate notation rather than required programming identifiers: CanonFile, MatchFile, MatchSession, MatchSegment, FileReceiptPass, MatchPayment, MatchBeneficiary, MatchAsset, WithinTrialScope, PaymentReceipt- Pass, WithinAuthorizedEnvelope, CanonEvidence, ReleaseReady, Valid, FinalFileState, Final- PaymentState, FinalSettlementState, and related labels introduced in E13-E15.

L.6 Local Symbol Collision Clarifications

  • CTF was used in E12 for a full communication ciphertext and is used in E13 specifically for full file ciphertext. The local section controls.

  • B in E14 denotes a beneficiary set, while Bj in E13 denotes a file byte/range interval. These are intentionally local uses and should not be conflated. expiry

  • tesc in E15 is an authority threshold, whereas tesc is a time/expiry value.

  • VF denotes payment value in E14; it is not the same as earlier generic effect magnitude symbols.

L.7 Local Interpretation Rule Where E13-E15 reuse a symbol already defined in earlier Advanced Section 1 materials, the earlier meaning remains controlling unless the local subsection expressly provides a specialized meaning. All equations are functional disclosure and may be realized through equivalent cryptographic objects, transaction states, hardware state, protocol fields, storage states, financial-rail states, distributed signatures, or protected state machines.

A.16. E16 — Receipt-Gated Database Commit, Provisional Persistence, and Promotion

A.16.1. E16.1 Purpose

E16 applies staged effectuation to database, persistent-state, record-management, object-state, index-state, replicated-state, and transaction-commit operations. The central technical distinction is that a proposed database mutation need not proceed directly from authorization to fully visible, globally replicated, or irreversible production state. Instead, the system may first cause a bounded real persistent state transition in a protected provisional location, obtain machine-verifiable evidence of the resulting state, and only then authorize promotion, expansion, replication, visibility, or completion. A representative causal chain is:

Candidate Mutation → Protected Validation → Bounded Persistent Commit → Commit Evidence → Receipt Validation → P

The first commit is not merely a simulation. It changes real persistent state, but the resulting consequence is bounded by namespace, row set, replica set, visibility, tenant, index, transaction scope, version, or another protected dimension.

A.16.2. E16.2 Technical problem addressed

An autonomous or AI-mediated system may generate a syntactically valid database mutation that is nevertheless unsafe to expose immediately because:

  • the wrong row, tenant, namespace, or object may have been selected;

  • a stale record version may be used;

  • a schema change may not behave as expected;

  • a trigger, stored procedure, replication rule, or index update may create secondary effects;

  • the mutation may be valid locally but inconsistent with distributed state;

  • the mutation may succeed at one node but fail at another;

  • the mutation may be irreversible after broad replication or publication;

  • authorization may be valid but current policy may change before commit;

  • the proposed operation may be influenced by tainted or uncertain input;

  • or the effect may need confirmation before external visibility is permitted. E16 separates permission to create bounded persistent state from permission to promote that state into the complete authorized database consequence.

A.16.3. E16.3 Functional components

An implementation may include one or more of the following logical functions: 1. Mutation Source - AI agent, application, database client, orchestration system, administrator tool, workflow engine, or another source that proposes a state change. 2. Mutation Representation Component - forms a deterministic representation of the proposed mutation and its intended effect. 3. PED - evaluates protected authority, policy, scope, current state, taint/provenance, and phase requirements. 4. Provisional Persistence Target - receives the bounded real mutation. 5. Database Finality Sink - controls whether a mutation becomes persistent, visible, replicated, indexed, externally queryable, or otherwise effective. 6. Persistence Observer - measures the resulting database state. 7. Receipt Generator - generates protected evidence of the bounded commit. 8. Promotion Gate - controls promotion from provisional state to broader production state. 9. Completion Observer - confirms the final promoted consequence. One physical database engine may implement several of these functions. Alternatively, they may be distributed across database proxy, transaction coordinator, storage layer, HSM, cloud control plane, application service, or hardware controller.

A.16.4. E16.4 Proposed database mutation

Let the proposed database mutation be denoted locally by:

W

The mutation may comprise, for example:

  • INSERT;

  • UPDATE;

  • DELETE;

  • MERGE;

  • schema alteration;

  • index operation;

  • object-store metadata change;

  • vector-state update;

  • graph mutation;

  • key-value update;

  • ledger-state change;

  • access-control modification;

  • replication instruction;

  • stored-procedure execution;

  • or a compound transaction. A deterministic representation may be formed and bound to the existing Candidate Act digest or to a mutationspecific digest.

For example:

DW = H(Canon(W ))

where the canonical representation may additionally include target database, tenant, table or collection, row/object identifiers, predicates, expected previous version, proposed values, transaction class, and permitted consequence.

A.16.5. E16.5 Baseline-state binding

Before issuing the bounded mutation, the PED or database sink may capture a protected representation of relevant pre-effect state. Let:

Vb

denote an expected baseline version, generation, commit sequence, row version, object generation, consensus index, or equivalent protected state reference. The bounded mutation may be permitted only if current state matches the authorized baseline or satisfies another accepted concurrency predicate:

BaselineV alid(W ) = 1

This prevents an approval generated for one database state from being silently applied to a materially different state.

A.16.6. E16.6 Selection of bounded persistence mode

The PED may determine whether the mutation may proceed directly under E01 or whether E16 staged persistence is required. E16 may be selected based upon:

  • destructive character;

  • number of affected records;

  • database sensitivity;

  • privilege level;

  • downstream trigger behavior;

  • replication breadth;

  • user or tenant impact;

  • uncertainty of generated query semantics;

  • rollback cost;

  • external visibility;

  • regulatory or enterprise policy;

  • model provenance or taint;

  • database consistency risk;

  • or another protected predicate.

A.16.7. E16.7 Provisional commit target

The initial real effect may be directed to a bounded persistence target such as:

  • shadow row;

  • provisional transaction record;

  • staging table;

  • versioned object;

  • branch or snapshot;

  • temporary namespace;

  • canary partition;

  • isolated tenant;

  • limited replica;

  • non-public index;

  • unpublished vector namespace;

  • protected write-ahead structure;

  • quarantine database;

  • or another real persistent target. The provisional target must be sufficiently real that the system can test or observe the actual persistence path, constraints, serialization, triggers, schema behavior, storage behavior, and/or downstream processing relevant to the intended full mutation.

A.16.8. E16.8 Bounded mutation descriptor

The protected descriptor for the first persistent phase may bind:

  • Candidate Act digest;

  • DW ;

  • baseline state Vb ;

  • allowed table, collection, object, graph, vector namespace, or database;

  • permitted rows or object identifiers;

  • permitted fields;

  • permitted value ranges;

  • transaction class;

  • maximum affected row count;

  • provisional namespace;

  • expected constraints;

  • expected trigger class;

  • expected receipt issuer;

  • durability level;

  • replication limit;

  • visibility limit;

  • expiration;

  • nonce;

  • policy epoch;

  • revocation epoch;

  • and permitted promotion class.

A.16.9. E16.9 Approval before provisional commit

The bounded commit may be:

  • automatically approved by protected policy;

  • explicitly approved by a human;

  • allowed within a pre-authorized database envelope;

  • approved by both automatic and human authority;

  • or subject to threshold/multi-party approval.

A human approval may show the exact bounded mutation, affected objects, previous values, proposed values, and intended later production consequence.

A.16.10. E16.10 Phase-0 database authority

The PED forms authority restricted to the provisional effect. The authority may permit, for example:

  • write to staging but not production;

  • write one row but not the table;

  • create an unpublished object version;

  • commit to one replica but not the replication group;

  • build a non-public index;

  • append a provisional event but not publish it;

  • or write a vector entry to an isolated namespace. The same authority must not permit direct promotion unless policy expressly allows it.

A.16.11. E16.11 Real provisional persistence

The Database Finality Sink verifies the authority and performs the bounded mutation. The provisional effect is real because persistent database or storage state changes. For example:

W0 ∶ V b → V t

where Vt denotes a resulting trial/provisional persistent version. The transition may be durable according to the chosen persistence guarantee, including local durable storage, replicated durability, consensus commit, append-only log, or another database-specific guarantee.

A.16.12. E16.12 Persistence observation

The Persistence Observer may confirm one or more of:

  • row/object content;

  • version number;

  • commit sequence;

  • transaction identifier;

  • write-ahead log position;

  • replication acknowledgement;

  • index state;

  • constraint satisfaction;

  • trigger output;

  • storage durability;

  • schema compatibility;

  • object checksum;

  • vector consistency;

  • graph consistency;

  • or another protected state property. The observation may compare expected and actual results.

A.16.13. E16.13 Database Effect Confirmation Receipt

The bounded commit produces an ECR containing or binding the resulting database evidence. The ECR may include:

  • Candidate Act digest;

  • DW ;

  • baseline version Vb ;

  • provisional version Vt ;

  • transaction ID;

  • target namespace;

  • affected object identifiers;

  • row count;

  • observed values or protected digests thereof;

  • constraint result;

  • trigger result;

  • durability evidence;

  • replica acknowledgements;

  • database sink identity;

  • nonce;

  • time;

  • policy epoch;

  • and status. Raw database values need not be exposed if hashes, commitments, selective disclosure, or protected attestations are sufficient.

A.16.14. E16.14 Receipt validation

The PED or protected verifier may require:

V alid(R0 ) ∧ M atch(R0 , DW ) ∧ BaselineM atch(R0 , Vb ) ∧ Durable(R0 ) ∧ W ithinScope(R0 )

before production promotion is considered. Where replication or quorum is required, additional receipt predicates may be applied.

A.16.15. E16.15 Human review after provisional persistence

A human may review the actual bounded database result before promotion. The protected UI may display:

  • intended mutation;

  • prior value/state;

  • resulting provisional value/state;

  • number of affected rows;

  • constraint results;

  • destination database;

  • proposed production consequence;

  • and receipt status. The human approval may bind directly to the ECR and production promotion descriptor.

A.16.16. E16.16 Automatic promotion decision

Automatic policy may permit promotion where the receipt proves the bounded commit behaved as expected. For example:

P romoteAllowed = V alidReceipt ∧ ConstraintP ass ∧ P olicyCurrent ∧ RevocationClear ∧ RiskAcceptable

The proposing AI does not self-certify these protected predicates.

A.16.17. E16.17 Promotion authority

After receipt validation and any required approval, the PED generates, derives, unseals, or activates authority permitting production promotion. The promotion authority may be implemented as:

  • transaction token;

  • signed commit instruction;

  • database role capability;

  • protected stored procedure invocation;

  • missing key material;

  • HSM-backed signature;

  • write-enablement state;

  • protected replication instruction;

  • or equivalent bounded enablement.

A.16.18. E16.18 Promotion to production

Promotion may comprise one or more of:

  • copying or merging provisional state into production;

  • switching a version pointer;

  • changing namespace visibility;

  • enabling index visibility;

  • committing the transaction’s final branch;

  • publishing an event;

  • replicating the state more broadly;

  • releasing a decryption or access key;

  • changing an object from quarantined to active;

  • or another state transition that makes the consequence complete. Promotion itself is a protected effectuation step and may be verified by a Finality Sink.

A.16.19. E16.19 Multi-phase database progression

The database consequence may be progressively broadened. Example:

1 row → 10 rows → 1 partition → all authorized partitions

or:

1 replica → regional replicas → global replicas

or:

hidden version → internal visibility → tenant visibility → public/production visibility

Each phase may generate its own ECR before broader promotion.

A.16.20. E16.20 Atomic promotion variation

Where possible, receipt validation, receipt consumption, and promotion authorization may be committed atomically within protected transaction state. A representative invariant is:

P romoted(W ) ⇒ V alidRequiredReceipts(W )

and, for single-use receipts:

P romoted(W ) ⇒ Consumed(R0 ) = T RU E

A.16.21. E16.21 Optimistic concurrency variation

If current database state no longer matches the authorized baseline:

Vcurrent ≠ Vb

the system may deny, hold, recompute, or seek fresh approval rather than automatically apply the prior mutation.

A.16.22. E16.22 Pessimistic/locked variation

A protected lock, lease, reservation, or transaction fence may preserve a state envelope between trial and promotion. The lock may be scoped and time-limited to avoid indefinite resource capture.

A.16.23. E16.23 Trigger-aware variation

The bounded commit may test not only the direct write but also database-triggered side effects. Promotion may remain blocked until protected evidence confirms required trigger behavior. If a trigger produces an unexpected external effect, the system may enter HOLD or INDETERMINATE rather than treating the base write as successful.

A.16.24. E16.24 Replication-aware variation

A database write may be locally durable but not yet sufficiently replicated. The PED may require:

AckCount ≥ q

for a protected quorum threshold q before promotion or external visibility. The quorum can be implementation-specific and need not correspond to a particular consensus algorithm.

A.16.25. E16.25 Database schema migration variation

A schema migration may first be applied to:

  • shadow schema;

  • one replica;

  • one partition;

  • one tenant;

  • or one bounded dataset. Protected evidence may measure migration success, query compatibility, index state, and data integrity before broader migration authority is released.

A.16.26. E16.26 Vector database / AI memory variation

An AI agent may propose writing persistent memory, embeddings, retrieval data, or learned state. The first write may enter an isolated vector namespace or provisional memory store. Receipt evidence may confirm:

  • object identity;

  • embedding/model version;

  • tenant scope;

  • provenance binding;

  • index insertion;

  • and visibility state. Only then may the entry be promoted into shared or durable retrieval state.

A.16.27. E16.27 Delete / destructive mutation variation

For destructive operations, the first stage may move data into protected tombstone, quarantine, recycle, or reversible state rather than immediately causing irreversible deletion. A verified receipt may then enable final deletion, cryptographic erasure, or broader removal.

A.16.28. E16.28 Database hardware-rooted variation

Protected authority may be enforced by:

  • HSM-backed database signing keys;

  • secure storage controller;

  • encrypted database keys;

  • TEE-protected transaction service;

  • trusted storage firmware;

  • DPU/SmartNIC controlling storage/network path;

  • or another protected component. The application may be unable to produce the production mutation without cryptographic material held by the protected component.

A.16.29. E16.29 Crash before provisional commit

If the system crashes before the bounded commit becomes durable, protected recovery may establish that no real effect occurred and permit a fresh authorized attempt.

A.16.30. E16.30 Crash after provisional commit but before receipt delivery

The provisional commit may be identified by an idempotency identifier and durable transaction record. After recovery, the system queries the database sink rather than blindly repeating the mutation. If the prior bounded commit is proven:

State = P ROV EN _EF F ECT ED

then the receipt may be reconstructed or retransmitted without duplicating the mutation.

A.16.31. E16.31 Indeterminate database state

If the system cannot prove whether the bounded or promoted commit occurred:

State = IN DET ERM IN AT E

broader effect remains blocked until reconciliation. Reconciliation may use commit IDs, WAL position, consensus index, object version, database audit state, replicated state, storage controller state, or equivalent evidence.

A.16.32. E16.32 Rollback and compensating transaction

If the bounded state is unacceptable, it may be:

  • deleted;

  • rolled back;

  • quarantined;

  • left invisible;

  • reverted to prior version;

  • compensated by another transaction;

  • or otherwise remediated. The rollback/compensation itself may be a protected Candidate Act with its own receipt.

A.16.33. E16.33 Anti-bypass closure

Equivalent production mutation paths may include:

  • direct database credentials;

  • administrator consoles;

  • replication channels;

  • bulk loaders;

  • backup/restore tooling;

  • maintenance interfaces;

  • privileged stored procedures;

  • alternate APIs;

  • direct storage access;

  • migration tools;

  • or service-account credentials. Where these paths can create the same material consequence, they may be disabled, narrowed, mediated, or subjected to equivalent finality controls.

A.16.34. E16.34 SEND analogue

A message draft may first be written to a protected outbox/staging record, and only after the record and destination binding are verified does a protected promotion operation place it into the actual send queue. This demonstrates that the database-promotion concept can protect communication state as well as ordinary database records.

A.16.35. E16.35 Payment analogue

A payment instruction may first become a provisional transaction record or reservation state. Receipt-confirmed validation of that state can then enable actual settlement or irreversible posting.

A.16.36. E16.36 Required invariants

1. The provisional persistence step is a real state change, not merely a simulation. 2. The bounded state is narrower than the complete production consequence in at least one relevant dimension. 3. Protected evidence is obtained from the actual persistence path or an authoritative observer. 4. Production promotion depends on accepted protected evidence and any required approval. 5. Promotion cannot exceed the originally authorized mutation envelope. 6. Stale baseline state, invalid receipts, revocation, or indeterminate state can prevent promotion. 7. Replay of a prior receipt does not independently authorize duplicate production effects. 8. Equivalent direct production paths are controlled where needed to preserve non-bypassability.

SIVE INFRASTRUCTURE ROLLOUT

A.17. E17 — Receipt-Gated Cloud Deployment and Progressive Infrastructure Rollout

A.17.1. E17.1 Purpose

E17 applies receipt-gated staged effectuation to software deployment, infrastructure configuration, service rollout, container activation, virtual-machine deployment, serverless release, edge deployment, and cloud/cluster control. The architecture distinguishes authority to deploy or expose a bounded real target set from authority to expand the deployment to the complete authorized target set. A representative chain is:

Deployment Proposal → Artifact/Config Binding → Protected Trial Deployment → Measured Real Operation → Deployment

A.17.2. E17.2 Deployment target model

Let the complete authorized target population be represented by:

Tmax

A trial or intermediate target set is:

Ti ⊆ Tmax

The sets may represent:

  • containers;

  • VMs;

  • physical nodes;

  • availability zones;

  • regions;

  • tenants;

  • users;

  • edge devices;

  • functions;

  • service instances;

  • API versions;

  • Kubernetes workloads;

  • network slices;

  • or another deployable population.

A.17.3. E17.3 Deployment descriptor

A protected deployment descriptor may bind:

  • software artifact digest;

  • container image digest;

  • binary digest;

  • infrastructure-as-code digest;

  • configuration digest;

  • environment variables or protected digest thereof;

  • target set;

  • network policy;

  • credentials/capabilities;

  • service identity;

  • dependency versions;

  • permitted ingress/egress;

  • maximum rollout scope;

  • health predicates;

  • rollback artifact;

  • receipt requirements;

  • policy and revocation epochs;

  • phase identifier;

  • expiration;

  • and Finality Sink identity. The descriptor may be signed, MACed, committed, or otherwise protected.

A.17.4. E17.4 Artifact integrity binding

Let the deployable artifact or artifact bundle be:

B

and its protected digest:

DB = H(B)

A phase authority for deployment may be bound to DB so that a valid authorization for one build cannot be silently substituted for another build. Where configuration materially affects behavior, configuration may be included in the bound digest or separately authenticated.

A.17.5. E17.5 Initial trial target selection

A Phase-0 target may be selected as:

  • one container;

  • one VM;

  • one host;

  • one pod;

  • one availability zone;

  • one tenant;

  • one edge node;

  • one canary cohort;

  • one internal user group;

  • or another bounded target. The trial target may be chosen deterministically, randomly under protected policy, by risk classification, by geography, by tenant class, or by human selection.

A.17.6. E17.6 Protected approval before trial deployment

Trial deployment may proceed under:

  • automatic protected policy;

  • human approval;

  • hybrid approval;

  • threshold approval;

  • or a previously approved deployment envelope. The proposing agent itself does not create protected deployment authority merely by requesting deployment.

A.17.7. E17.7 Trial deployment authority

The PED issues authority that is restricted to T0 , the selected trial set. The authority may be enforced through:

  • orchestrator capability;

  • signed deployment manifest;

  • cloud control-plane credential;

  • short-lived service token;

  • image-pull authorization;

  • network exposure permit;

  • cluster admission policy;

  • HSM-backed release signature;

  • or equivalent protected state.

A.17.8. E17.8 Real trial deployment

The software is actually instantiated, activated, or exposed on the bounded real target set. This can include:

  • image pull;

  • process start;

  • VM boot;

  • container scheduling;

  • serverless function activation;

  • network route insertion;

  • service registration;

  • configuration application;

  • key release;

  • or controlled traffic exposure. The trial is therefore a real effectuation event.

A.17.9. E17.9 Installation versus exposure separation

A useful variation separates deployment from traffic exposure. The software artifact may be installed but not receive production traffic. After protected boot/attestation evidence succeeds, a later phase may authorize limited traffic exposure. A further receipt may then authorize broader traffic. This creates multiple effectuation boundaries:

Install → Attest → Limited Exposure → Measure → Broad Exposure

A.17.10. E17.10 Deployment health evidence

The system may collect protected evidence including:

  • successful boot;

  • artifact digest;

  • runtime measurement;

  • crash rate;

  • restart rate;

  • error rate;

  • latency;

  • resource use;

  • memory pressure;

  • network behavior;

  • dependency health;

  • service registration;

  • policy compliance;

  • attestation;

  • security events;

  • response correctness indicators;

  • rollback readiness;

  • or another protected metric. The metric set need not be identical for every deployment type.

A.17.11. E17.11 Health vector and protected predicate

Let a phase-specific measured health vector be represented locally by:

hi

A protected health predicate may be expressed as:

HealthAcceptable(hi ) = 1

The function may include multiple thresholds, Boolean conditions, statistical tests, safety constraints, or formally specified invariants. A model may recommend a health assessment, but the protected continuation decision may remain outside the proposing model.

A.17.12. E17.12 Deployment receipt

Following actual bounded deployment and observation, the system generates an ECR that may bind:

  • DB ;

  • target set Ti ;

  • runtime identities;

  • artifact measurements;

  • configuration measurements;

  • health vector or protected digest thereof;

  • security events;

  • traffic level;

  • phase number;

  • sink identity;

  • time;

  • nonce;

  • policy epoch;

  • and outcome status.

A.17.13. E17.13 Automatic rollout continuation

A protected automatic decision may require:

V alid(Ri ) ∧ HealthAcceptable(hi ) ∧ P olicyCurrent ∧ RevocationClear ∧ W ithinDeploymentEnvelope

before issuing authority for Ti+1 .

A.17.14. E17.14 Human rollout continuation

A human reviewer may be shown:

  • build identity;

  • trial target;

  • actual target count;

  • health results;

  • error/crash information;

  • security observations;

  • intended next rollout set;

  • rollback status;

  • and cryptographic receipt validity. Human approval may be required before expansion.

A.17.15. E17.15 Hybrid rollout continuation

Early phases may proceed automatically while larger scopes require human confirmation. Example:

|Ti | < Th ⇒ Auto

|Ti | ≥ Th ⇒ HumanApproval

where Th is a protected deployment threshold.

A.17.16. E17.16 Fixed progressive rollout

A deployment may progress through predetermined populations:

1 → 10 → 100 → 1000 → |Tmax |

or through topological stages:

one node → one zone → one region → authorized global set

A.17.17. E17.17 Adaptive rollout

The next target set may depend on measured evidence:

Ti+1 = f(Ti , Ri , hi , Riski , P olicyi )

The function may enlarge, hold, reduce, redirect, or terminate rollout.

A.17.18. E17.18 Cohort-isolated continuation

If only some nodes or tenants satisfy protected health criteria, continuation may be restricted to the successful subset rather than expanding all targets uniformly. A failing region can remain blocked while another verified region proceeds, provided the authorized policy allows such divergence.

A.17.19. E17.19 Configuration-only rollout

E17 applies not only to binaries but also to configuration changes, feature flags, policy bundles, routing changes, certificates, secrets, firewall rules, IAM settings, network policies, and service-mesh configuration. A bounded configuration may be applied first to a limited target and expanded only after receipt-confirmed behavior.

A.17.20. E17.20 Infrastructure-as-code variation

An infrastructure-as-code plan may be bound to its source digest, rendered plan digest, provider identity, and permitted resource envelope. The first real resource creation or modification may be bounded. The resulting cloud state can generate protected evidence before the system is authorized to create or modify the complete infrastructure set.

A.17.21. E17.21 Kubernetes/container orchestration variation

The enforcement point may include:

  • admission controller;

  • controller manager;

  • operator;

  • API server policy layer;

  • node agent;

  • service mesh;

  • network policy enforcement;

  • image policy service;

  • secret broker;

  • or another orchestration control. The architecture is not limited to Kubernetes or any named orchestrator.

A.17.22. E17.22 Virtual-machine variation

The bounded phase may boot one or more VMs with measured image, firmware, configuration, and protected identity. Attestation and health evidence may be required before broader VM deployment or production traffic release.

A.17.23. E17.23 Serverless variation

A new function version may be activated for a bounded request class or tenant group. Receipt-confirmed execution metrics can enable broader invocation routing.

A.17.24. E17.24 Edge/fleet variation

Software may first be deployed to a bounded device cohort. Each device or a protected aggregation service may provide receipts confirming:

  • artifact digest;

  • successful installation;

  • boot state;

  • health state;

  • device identity;

  • and rollback capability. Expansion to the wider fleet depends on protected aggregate criteria.

A.17.25. E17.25 Hardware attestation variation

Where supported, runtime evidence may include TEE, TPM, secure boot, confidential-computing, measured VM, DPU, or device-rooted attestation. A receipt may therefore prove not merely that software responded but that it operated in an expected measured environment.

A.17.26. E17.26 Network exposure as Finality Sink

The deployment may already exist, while the true consequential boundary is the network exposure point. A load balancer, API gateway, service mesh, DPU, SmartNIC, switch, firewall, or routing controller may function as a Finality Sink controlling whether real production traffic reaches the new deployment.

A.17.27. E17.27 Credential-expansion variation

The trial deployment may initially possess restricted credentials. Successful protected operation may enable broader service permissions only after receipt validation. Thus deployment scale and privilege scale may progress independently.

A.17.28. E17.28 Database/storage dependency variation

A deployment receipt may require confirmation that dependent database migrations, storage mounts, or secret versions match expected protected state before expansion.

A.17.29. E17.29 Rollback authority

If health criteria fail, a rollback may be automatically or human-authorized. Rollback may comprise:

  • traffic withdrawal;

  • version pointer reversal;

  • instance termination;

  • configuration reversion;

  • credential revocation;

  • route removal;

  • or restoration of prior artifact. Rollback may itself generate a protected receipt.

A.17.30. E17.30 Freeze-on-indeterminate rule

If the system cannot establish whether a deployment phase completed correctly, broader rollout remains blocked. Examples include:

  • control-plane timeout;

  • partial target response;

  • missing attestation;

  • uncertain traffic state;

  • region partition;

  • or ambiguous rollback state.

A.17.31. E17.31 Crash and recovery

Protected rollout state may survive controller restart. The system reconstructs current target state from protected control-plane data, target attestations, deployment IDs, and receipts before issuing any further expansion authority. Blindly repeating a rollout phase is not required.

A.17.32. E17.32 Revocation during rollout

A newly discovered vulnerability, revoked artifact, compromised key, policy change, or human veto may stop further rollout even if prior phases succeeded. Unused future phase authorities may become invalid.

A.17.33. E17.33 Multi-region progression

A global deployment may be hierarchical:

node → zone → region → multi-region

Each parent phase may depend on protected receipts from one or more child phases.

A.17.34. E17.34 Quorum/aggregate health variation

For a target set containing multiple instances, continuation may depend on an aggregate protected predicate, for example:

HealthyT argetsi ≥ τh ObservedT argetsi

with no protected critical-failure predicate present. τh is deployment-specific and need not be fixed globally.

A.17.35. E17.35 Anti-bypass closure

Equivalent deployment or exposure paths may include:

  • direct cloud administrator credentials;

  • alternate CI/CD system;

  • emergency console;

  • cluster-admin path;

  • direct node access;

  • alternate load balancer;

  • secondary API gateway;

  • raw infrastructure provider API;

  • image registry override;

  • secret injection path;

  • or recovery tooling. Where such a path can create the same material rollout consequence, it may be mediated or placed under equivalent protected control.

A.17.36. E17.36 SEND analogue

A communication service release may first route real messages for one controlled recipient or tenant through a new service version. Verified delivery receipts and health evidence can then permit progressively broader SEND traffic.

A.17.37. E17.37 Payment analogue

A payment-processing service update may first handle a bounded transaction class or low-value protected cohort. Verified transaction and service-health evidence can enable broader transaction traffic without granting

unrestricted authority at the outset.

A.17.38. E17.38 Required invariants

1. At least one bounded deployment phase creates a real operational state or real traffic exposure. 2. The bounded target set or privilege scope is narrower than the maximum authorized deployment envelope. 3. Protected evidence is collected from the deployed environment or an authoritative observer. 4. Expansion authority depends on accepted evidence and required approval. 5. Artifact/configuration identity remains bound across phases. 6. No rollout phase may exceed the authorized target or privilege envelope. 7. Failure, revocation, or indeterminate state can stop further rollout. 8. Equivalent deployment or exposure paths are controlled where necessary for non-bypassability.

TIVATION, AND PROGRESSIVE CONSEQUENCE RELEASE

A.18. E18 — Receipt-Gated AI Model Deployment, Model Activation, and Progressive Consequence Release

A.18.1. E18.1 Purpose

E18 applies staged effectuation to deployment and activation of AI models, model versions, model configurations, agentic systems, model endpoints, tool-enabled models, inference services, persistent model-state systems, and other learned computational components. The architecture distinguishes among:

  • loading or storing a model;

  • making the model callable;

  • exposing it to a bounded real request population;

  • granting tool or external-action authority;

  • expanding data access;

  • expanding recipient/user/tenant scope;

  • and enabling broader externally consequential behavior. A model may therefore be deployed technically without immediately receiving the full consequence envelope contemplated by the operator.

A.18.2. E18.2 Core causal chain

A representative E18 workflow is:

Model Release Proposal → Model/Runtime Binding → Bounded Real Activation → Protected Runtime Evidence → Receipt

A.18.3. E18.3 Model release object

The protected release may bind one or more of:

  • model weights digest;

  • model architecture identifier;

  • model version;

  • tokenizer/version;

  • system prompt or protected digest;

  • tool schema;

  • tool allowlist;

  • connector set;

  • retrieval sources;

  • memory configuration;

  • safety/policy configuration;

  • runtime image;

  • accelerator environment;

  • quantization/configuration;

  • model-routing policy;

  • inference parameters;

  • user/tenant scope;

  • geographic scope;

  • consequence scope;

  • and maximum privilege envelope.

Let the bound model-release descriptor be denoted locally by:

MR

and its digest by:

DMR = H(Canon(MR ))

This notation is local to E18 and is distinct from earlier uses of M in other embodiments.

A.18.4. E18.4 Maximum model release envelope

The operator may authorize a maximum release envelope including one or more dimensions:

  • maximum user population;

  • maximum tenants;

  • permitted regions;

  • permitted APIs;

  • tool privileges;

  • token/request budget;

  • data sensitivity;

  • context sources;

  • output classes;

  • communication authority;

  • payment authority;

  • infrastructure authority;

  • device authority;

  • or other external consequence classes. The progressive system must not infer additional authority merely from successful earlier phases.

A.18.5. E18.5 Bounded model cohort

Let the active model cohort at phase i be represented by:

Ci

where Ci may identify users, tenants, requests, endpoints, tools, regions, workloads, devices, or another bounded activation population. A protected maximum cohort is:

Cmax

and:

Ci ⊆ Cmax

A.18.6. E18.6 Bounded consequence envelope

Traffic volume alone may not represent model risk. A model can be broadly used for low-consequence generation while remaining prohibited from payments, SEND, infrastructure changes, device control, or sensitive data export. E18 therefore permits consequence scope to be phased separately from population scope. Let a phase-specific consequence/privilege envelope be:

Γi

with:

Γi ⊆ Γmax

where Γmax is the maximum protected consequence envelope authorized for the model release.

A.18.7. E18.7 Trial model activation

A model release may first be enabled for:

  • internal test users;

  • one tenant;

  • one region;

  • one API;

  • one request class;

  • read-only tool use;

  • no-tool inference;

  • low-sensitivity data;

  • bounded token budget;

  • one controlled connector;

  • one protected agent workflow;

  • or another limited real production condition. The requests are real and the model actually operates in the target environment.

A.18.8. E18.8 Protected model activation authority

The trial authority may be enforced through:

  • model-router policy;

  • API gateway;

  • serving-platform authorization;

  • runtime capability;

  • deployment signature;

  • model registry policy;

  • tool broker;

  • connector broker;

  • network egress gate;

  • GPU/accelerator release control;

  • protected key;

  • HSM/TEE state;

  • or equivalent mechanism.

A.18.9. E18.9 Separation of inference from effectuation

A model may be allowed to compute outputs without receiving authority to effect external consequences. For example:

InferenceAllowed = T RU E

while:

SEN DAllowed = F ALSE

P aymentAllowed = F ALSE

InfrastructureW riteAllowed = F ALSE

Later phases may expand consequence authority only after protected evidence and policy approval.

A.18.10. E18.10 Runtime evidence collection

Protected runtime evidence may include:

  • model identity;

  • request class;

  • error rate;

  • refusal/allow behavior;

  • latency;

  • resource consumption;

  • tool-use frequency;

  • tool-use failure rate;

  • policy violations;

  • output-format compliance;

  • data-access events;

  • connector events;

  • taint/provenance behavior;

  • security alerts;

  • hallucination/error indicators where measurable;

  • anomalous action proposals;

  • user escalation rate;

  • rate-limiting events;

  • model drift indicators;

  • or another protected measurement. No single metric is mandatory across all AI deployments.

A.18.11. E18.11 Model evidence vector

Let a protected model evidence vector for phase i be represented locally by:

mi

A protected acceptance predicate may be:

M odelEvidenceAcceptable(mi ) = 1

The predicate may be deterministic, rule-based, threshold-based, formally specified, or based on protected aggregate metrics. An AI evaluator may contribute evidence but need not possess final authority to approve its own expansion.

A.18.12. E18.12 Model deployment receipt

The resulting ECR may bind:

  • DMR ;

  • model/runtime identity;

  • active cohort Ci ;

  • active consequence envelope Γi ;

  • evidence vector or protected digest thereof;

  • serving environment;

  • accelerator attestation where available;

  • tool configuration;

  • connector configuration;

  • policy version;

  • sink identities;

  • phase number;

  • nonce;

  • time;

  • and outcome status.

A.18.13. E18.13 Automatic model expansion

A protected automatic continuation may require:

V alid(Ri )∧M odelEvidenceAcceptable(mi )∧P olicyCurrent∧RevocationClear∧W ithinM odelReleaseEnvelope

before expanding Ci , Γi , or both.

A.18.14. E18.14 Human model expansion

A human approval interface may show:

  • exact model version;

  • trial population;

  • active tools;

  • active data classes;

  • observed protected metrics;

  • security events;

  • receipt validity;

  • intended next cohort;

  • intended next consequence scope;

  • and rollback availability. The human may authorize only population expansion, only privilege expansion, both, or neither.

A.18.15. E18.15 Hybrid model expansion

A policy may automatically expand ordinary inference traffic while requiring human approval for new consequential tool classes. For example:

Ci+1 > Ci

may be automatically allowed while:

Γi+1 ⊃ Γi

requires protected human approval. This prevents user-scale growth from silently becoming authority growth.

A.18.16. E18.16 Progressive user/tenant rollout

A model may progress through:

internal users → one tenant → selected tenants → authorized broad population

Each phase can be receipt-gated.

A.18.17. E18.17 Progressive tool privilege rollout

A model may progress through:

no tools → read-only tools → bounded write tools → higher-consequence tools

Each expansion may require separate protected evidence and approval.

A.18.18. E18.18 Communication/SEND progression

An AI model may initially be allowed to draft communications without sending them. A later phase may permit SEND only to:

  • a protected test endpoint;

  • the requesting user;

  • one approved recipient;

  • or a bounded recipient class. Verified SEND receipts and policy evidence may then enable broader communication authority. The model itself does not obtain unrestricted SEND authority merely because it successfully generated text.

A.18.19. E18.19 Payment progression

A model may initially be permitted to:

  • prepare a payment proposal;

  • validate beneficiary information;

  • perform a bounded test/verification transaction where supported;

  • or create a protected reservation. Broader payment authority remains separately gated by the staged payment workflow and protected receipt evidence.

A.18.20. E18.20 Data-access progression

A model may start with:

  • public data only;

  • one protected dataset;

  • redacted records;

  • bounded retrieval scope;

  • or one tenant’s data. Receipt-confirmed operation and policy validation may later enable broader data access, provided the maximum authorization envelope permits it.

A.18.21. E18.21 Connector progression

Connectors may be introduced progressively. Example:

no connector → read-only connector → bounded write connector → authorized broader connector scope

The connector broker can function as a Finality Sink for external effects.

A.18.22. E18.22 Agentic workflow progression

A model may first execute a bounded workflow having no irreversible effects. After protected evidence confirms acceptable behavior, later phases may allow bounded external tool invocation. Further phases may enlarge tool scope, destination scope, or transaction size.

A.18.23. E18.23 Model-routing variation

The protected system may route only a bounded request class to the new model while the previous model continues serving other traffic. Expansion authority controls routing rather than model installation.

A.18.24. E18.24 Shadow-model variation

A model may initially process real inputs without its outputs being externally authoritative. Its outputs may be compared against production behavior, policy predicates, or protected observations. However, shadow execution alone is not necessarily the real external effect required for a later staged-effectuation claim unless the subsequent architecture uses an actual bounded external effect or another qualifying protected state transition.

A.18.25. E18.25 Model-state / memory promotion

A model-generated persistent memory item may first enter isolated state. The system may validate provenance, taint, consistency, user scope, and protected receipt evidence before promoting the memory into shared durable state. This can combine E18 with E16.

A.18.26. E18.26 GPU/accelerator-rooted variation

The model-serving environment may use protected accelerator or host evidence. A GPU security controller, DPU, SmartNIC, TEE, confidential VM, secure boot component, or other hardwarerooted mechanism may participate in confirming:

  • model digest;

  • serving binary;

  • destination;

  • memory protection state;

  • output path;

  • or egress authority.

A.18.27. E18.27 Model key-release variation

Encrypted model weights or protected model components may remain unusable until a protected release key is provided. A bounded phase key may permit operation only for a limited environment or cohort. Later receipt validation may permit broader serving keys or routing authority.

A.18.28. E18.28 Tool credential withholding

The model runtime need not hold the full credential necessary for external action. A protected tool broker may expose only phase-specific authority. Successful bounded operation may lead to a broader but still scoped credential after receipt validation.

A.18.29. E18.29 Safety-policy epoch change

If model safety policy, enterprise policy, revocation state, or tool policy changes between phases, the prior successful receipt need not authorize further expansion. Fresh protected validation may be required.

A.18.30. E18.30 Model revocation

A model build, runtime image, tool schema, connector, or policy configuration may be revoked at any phase. Unused continuation authority is invalidated and the model may be:

  • held;

  • rolled back;

  • traffic-isolated;

  • tool-disabled;

  • credential-revoked;

  • or removed.

A.18.31. E18.31 Rollback

Rollback may return:

  • traffic to a previous model;

  • tool permissions to a prior scope;

  • cohort size to an earlier stage;

  • data access to a narrower scope;

  • runtime image to a prior version;

  • or external authority to a safer state. A rollback may itself generate a protected receipt.

A.18.32. E18.32 Indeterminate model phase

If the system cannot determine whether a model expansion actually took effect, further progression remains blocked. Examples include:

  • uncertain routing state;

  • partial region update;

  • missing tool-broker acknowledgement;

  • ambiguous credential release;

  • lost deployment receipt;

  • or inconsistent model registry state.

A.18.33. E18.33 Crash and recovery

Protected phase state should survive serving-controller, router, or orchestration restart. On recovery, the system reconciles actual model version, active target cohort, tool permissions, credential state, routing state, and receipts before issuing further continuation authority.

A.18.34. E18.34 Parallel model cohorts

Different cohorts may progress independently. For example, one tenant group may remain at Γ1 while another verified group progresses to Γ2 , provided policy permits such segmented authority.

A.18.35. E18.35 Multi-model ensemble variation

Where an externally consequential workflow uses multiple models, protected policy may require evidence from or state binding across multiple model components before expanding the overall consequence envelope. This does not require any specific ensemble architecture.

A.18.36. E18.36 Threshold evidence variation

Expansion may require multiple independent protected evidence sources, for example:

  • runtime metrics;

  • security monitor;

  • tool broker;

  • destination receipts;

  • human approval;

  • hardware attestation;

  • or enterprise policy service. The required evidence combination may be threshold-based or conjunctive.

A.18.37. E18.37 Consequence-specific Finality Sinks

Different external consequences may use different sinks:

  • SEND sink;

  • payment sink;

  • database sink;

  • storage sink;

  • device-control sink;

  • infrastructure sink;

  • data-export sink. A model release receipt for ordinary inference must not automatically substitute for the required evidence of a different consequential sink.

A.18.38. E18.38 Anti-bypass closure

Equivalent authority paths may include:

  • alternate model endpoint;

  • hidden API;

  • direct runtime access;

  • unmediated tool credential;

  • secondary connector;

  • privileged orchestration path;

  • direct GPU output path;

  • alternate network egress;

  • service-account credential;

  • model alias or router override;

  • or emergency administrator path. Where such paths can create the same material consequence, they may be placed under equivalent protected finality control.

A.18.39. E18.39 Non-self-certification invariant

The model being evaluated need not be trusted to authorize its own privilege expansion. A model may produce evidence, explanations, metrics, or recommendations, but the protected authority to enlarge Ci or Γi may remain with the PED, Finality Sink, protected human, hardware root, or another independent protected component.

A.18.40. E18.40 Latency-aware progression

For low-consequence model requests, the system may use fast-path protected validation. Higher-consequence classes may require staged receipts, stronger approval, or hardware-rooted checks. Thus the architecture need not impose identical latency on every inference.

A.18.41. E18.41 Required invariants

1. Model computation or deployment alone does not imply unrestricted consequence authority. 2. At least one bounded real model activation or effectuation phase is narrower than the maximum authorized release envelope. 3. Model identity/configuration is protected against substitution across phases. 4. Protected evidence is collected from the real serving/effectuation environment or authoritative observers. 5. Expansion of cohort, privilege, consequence, data access, or tool authority depends on protected validation and required approval. 6. Population expansion does not inherently imply privilege expansion. 7. No phase may exceed the authorized model-release envelope. 8. Revocation, failure, or indeterminate state can stop future expansion. 9. Equivalent alternate endpoints or credentials are controlled where necessary for non-bypassability.

Cross-embodiment relationship: E16, E17, E18

meaningful state.

Database state Provisional Persistent State → Verified Commit Evidence → Production Promotion

Cloud/infrastructure state Bounded Real Deployment → Verified Runtime Evidence → Broader Rollout

AI-model state and consequence authority Bounded Model Activation → Verified Model Evidence → Broader Cohort/Privilege Effectuation

A single real-world system may combine all three. For example, an AI model deployment (E18) may use a cloud rollout (E17) while writing model memory through a receipt-gated database promotion path (E16). Each layer may retain its own effectuation boundary and receipt requirements.

Delta definitions - new terms introduced in E16-E18 only The following definitions supplement, rather than replace, definitions previously established in Advanced Section 1.

Database Finality Sink A protected component or protected database/storage function that controls whether a database mutation becomes persistent, promoted, replicated, visible, externally queryable, or otherwise effective at a consequential database boundary. It may be implemented by a database engine, proxy, transaction coordinator, storage controller, protected stored procedure, HSM/TEE-backed service, or another equivalent enforcement mechanism.

Provisional Persistence Target A real persistent location or state in which a bounded mutation may be committed without immediately creating the complete intended production consequence. Examples include a shadow row, staging table, versioned object, branch, isolated namespace, canary partition, limited replica, non-public index, or quarantined object state.

Provisional Persistent State A real durable or otherwise persistent state created during a bounded database phase that remains restricted in visibility, replication, scope, authority, or consequence until a later protected promotion decision.

Promotion Gate A protected logical or physical control that prevents provisional persistent state from becoming broader production state until required evidence and authority conditions are satisfied.

Promotion Authority A scoped protected authorization, capability, key, signed command, transaction state, or equivalent enablement condition that permits a previously bounded persistent state to be promoted into a broader or complete authorized database consequence.

Production Promotion A protected transition by which provisional state is merged, published, replicated, made visible, activated, indexed, or otherwise converted into the broader production consequence authorized for the Candidate Act.

Deployment Target Set A bounded set of infrastructure or service targets to which a deployment phase applies, including containers, VMs, nodes, zones, regions, tenants, users, devices, service instances, API versions, or other deployable targets.

Deployment Health Evidence Protected measurements obtained from a real deployment phase that characterize whether the deployed artifact, configuration, environment, service, or target set satisfies required technical predicates for continuation.

Exposure Gate A protected control that determines whether an installed or instantiated service receives real production traffic or becomes externally reachable. Installation and exposure may therefore be separate effectuation phases.

Model Release Descriptor A protected representation of the model and operational configuration being released, which may bind model weights/version, runtime, tokenizer, policy, tools, connectors, data access, serving environment, cohort, and maximum consequence envelope.

Model Release Envelope The maximum protected scope within which a model may be activated or granted authority, including population, tenant, region, API, data, tool, connector, token, output, or external-consequence dimensions.

Model Cohort A bounded set of users, tenants, requests, endpoints, devices, workloads, regions, or other activation population to which a particular model phase applies.

Model Consequence Envelope The bounded external-action, privilege, tool, data-access, communication, payment, infrastructure, or devicecontrol authority permitted to a model at a particular phase.

Model Expansion Authority Protected authority that permits the active model cohort, model consequence envelope, or both to expand following accepted protected evidence.

Protected Model Evidence Machine-verifiable or protected measurements derived from real model operation, serving infrastructure, tool brokers, external sinks, hardware attestations, policy monitors, or equivalent observers and used as an input to the continuation decision.

Delta notation - new symbols introduced in E16-E18 only Previously defined notation from Advanced Section 1 is intentionally omitted here.

Symbol Meaning in this document W Proposed database mutation in E16. DW Protected digest of the canonical proposed database mutation W . Vb Baseline database/object/version state expected before the bounded mutation. Vt Trial/provisional persistent version or state resulting from the bounded real database mutation. q Protected minimum acknowledgement/quorum count in a replication-aware database variation. Tmax Maximum authorized deployment target set in E17. Ti Target set authorized/active for deployment phase i. B Deployable software/configuration artifact or artifact bundle in E17. DB Protected digest of artifact/bundle B. hi Protected deployment health-evidence vector for phase i. Th Protected target-size or rollout threshold at which the approval mode may change. τh Protected minimum healthy-target ratio or equivalent aggregate health threshold. MR Model Release Descriptor in E18; local E18 notation and not the earlier generic/message/payment use of M. DMR Protected digest of the canonical Model Release Descriptor. Ci Bounded model cohort active at phase i. Cmax Maximum protected model cohort authorized for the release. Γi Phase-specific model consequence/privilege envelope. Γmax Maximum authorized model consequence/privilege envelope. mi Protected model-evidence vector for phase i.

New word-like predicates/functions

Expression Meaning BaselineV alid(W ) Protected determination that current database state is acceptable for mutation W . BaselineM atch(R0 , Vb ) Receipt confirms the mutation was evaluated/executed against the expected baseline state. Durable(R0 ) Receipt establishes the required level of persistence/durability. P romoteAllowed Protected Boolean indicating whether production promotion is currently permitted. HealthAcceptable(hi ) Protected predicate determining whether deployment-health evidence satisfies continuation requirements. M odelEvidenceAcceptable(mi ) Protected predicate determining whether model-runtime evidence satisfies continuation requirements. W ithinDeploymentEnvelope Protected condition that a proposed rollout remains inside the maximum authorized deployment scope. W ithinM odelReleaseEnvelope Protected condition that cohort/privilege expansion remains inside the authorized model-release envelope.

Set/vector conventions newly used here

  • Calligraphic symbols such as T and C represent sets or bounded populations.

  • Bold lower-case symbols such as hi and mi represent vectors or structured collections of protected measurements; they do not require a specific numerical dimension.

  • |Ti | denotes the number or protected cardinality measure of members in deployment target set Ti .

  • Γi ⊆ Γmax expresses bounded authority inclusion; it does not require privileges to be represented literally as mathematical sets if an equivalent ordered or policy-bounded representation is used.

End of E16-E18 frozen workflows

A.19. E19 — Receipt-Gated Tool Use and External Action Invocation

A.19.1. E19.1 Purpose

E19 applies the staged-effectuation architecture to a computational system, including an AI agent, that proposes use of an external tool, connector, function, service, plug-in, operatingsystem primitive, remote API, local API, database operation, payment function, messaging function, storage function, device function, or other effect-capable execution interface. The principal distinction is that a model or agent may be permitted to select, describe, prepare, or request a tool operation without thereby possessing unrestricted authority to invoke the tool or cause the full external consequence. A representative causal relationship is:

tool proposal → protected tool validation → bounded real tool interaction → R0 → continuation authority → broader tool effect.

Accordingly, a tool-call representation, function-call object, model-emitted action structure, or ordinary application-level “tool use” event need not itself constitute final authority to invoke the effect-capable operation.

A.19.2. E19.2 Tool Selection and Candidate Act Formation

The originating computational component may select a tool from a set of tools:

T = {T1 , T2 , . . . , Tq }.

The selected tool and proposed operation are incorporated into the Candidate Act. The Candidate Act may bind one or more of:

  • tool identity, version, provider, or endpoint;

  • operation or method;

  • argument names and values;

  • destination, recipient, account, object, or device;

  • payload, file, amount, command, or data range;

  • expected consequence;

  • permitted scope;

  • required approval class;

  • time, nonce, policy epoch, and revocation state;

  • intended Finality Sink or effect-capable boundary; and

  • any prior receipt or phase state required for continuation.

A tool invocation envelope for phase i may be denoted:

Γi .

The protected system may require: Γi ⊆ Γmax , where Γmax is the maximum authorized tool-use envelope for the Candidate Act.

A.19.3. E19.3 Protected Tool Identity Binding

The PED may verify the identity of the tool independently of the agent’s textual assertion. Tool identity may be established using:

  • registered endpoint identity;

  • executable or package digest;

  • service certificate;

  • remote attestation;

  • signed tool manifest;

  • API audience or origin;

  • process or container measurement;

  • secure hardware identity;

  • destination binding; or

  • equivalent protected evidence. Where tool identity is material, an unrecognized or substituted tool does not satisfy the protected predicate merely because it accepts the same apparent arguments.

A.19.4. E19.4 Tool Contract / Operation-Schema Validation

Before effectuation, the PED may validate a machine-readable contract describing permitted tool behavior. The contract may bind:

  • allowed methods;

  • permitted parameter types and ranges;

  • side-effect class;

  • maximum resource consumption;

  • destination restrictions;

  • allowed output classes;

  • required receipt class;

  • reversibility;

  • required user approval;

  • permitted network or storage targets; and

  • whether the tool may recursively invoke other tools. The contract may be static, signed, versioned, policy-derived, destination-provided, or generated from protected configuration.

A.19.5. E19.5 Tool Proposal Is Not Invocation Authority

The architecture may maintain the following invariant:

Propose(Tj , A) = 1 ̸⇒ Invoke(Tj , A) = 1.

Likewise: ToolCallGenerated = T RU E ̸⇒ ExternalEffectAuthorized = T RU E.

A model may therefore emit a syntactically valid tool call while the PED withholds any authority required for actual effectuation.

A.19.6. E19.6 Selection of Single-Phase or Staged Tool Use

Protected policy may classify the proposed tool operation into: 1. single-phase protected invocation; 2. bounded tool interaction followed by full invocation; 3. progressive multi-phase tool use; 4. protected human approval;

5. automatic protected continuation; 6. hybrid approval; 7. sandbox-only execution; 8. read-only or reduced-scope execution; 9. hold; or 10. denial. The same tool may use different modes for different operations. A metadata read and a destructive delete operation need not share the same finality path.

A.19.7. E19.7 Bounded Real Tool Interaction

For staged tool use, Phase 0 may be a real interaction with the actual tool or effect-capable tool path but with bounded consequence. Examples include:

  • querying the actual destination for object metadata before a destructive update;

  • requesting a real account capability or endpoint challenge before sending a payment;

  • creating a provisional record in a restricted namespace;

  • sending a bounded communication trailer before a complete message;

  • creating a temporary or reversible reservation before irreversible settlement;

  • applying a configuration to a single canary target;

  • invoking a device with a limited movement envelope;

  • obtaining a remote attestation from the actual tool executor; or

  • executing another real but bounded operation whose observed result is relevant to later authorization. The initial interaction need not be identical in consequence to the final tool operation, provided protected policy treats its verified result as relevant to continuation.

A.19.8. E19.8 Tool Effect Gateway

A tool-effect gateway may mediate the path between the proposing process and the actual effectcapable tool. It may be implemented by:

  • local privileged broker;

  • host service;

  • kernel or syscall mediation;

  • container or microVM boundary;

  • API gateway;

  • service mesh;

  • connector broker;

  • network proxy;

  • database proxy;

  • message broker;

  • payment gateway;

  • credential broker;

  • secure monitor;

  • hardware controller; or

  • destination-side verifier. The gateway may perform the Finality Sink function or may forward to a separate Finality Sink.

A.19.9. E19.9 Phase-Specific Tool Authority

For each phase, the PED may create a distinct authority Ci bound to Γi . The system may enforce: Scope(Ci ) = Scope(Γi ), or another policy-defined relationship. A Phase-0 authority may therefore be technically incapable of authorizing the broader Phase-1 operation.

A.19.10. E19.10 Tool-Side Verification

The tool gateway or destination may verify:

  • Candidate Act binding;

  • tool identity;

  • method identity;

  • parameter digest;

  • destination;

  • authorized scope;

  • phase;

  • nonce;

  • expiry;

  • policy epoch;

  • receipt dependency;

  • human approval artifact where required;

  • credential audience; and

  • local protected state. Failure of a required condition results in withholding or reducing the tool effect.

A.19.11. E19.11 Tool Result Observation and Receipt

After the bounded real tool interaction, a protected observer may form an ECR. The receipt may bind:

  • tool identity and version;

  • exact method or operation;

  • protected argument digest;

  • destination;

  • actual result state;

  • result digest;

  • side-effect state;

  • transaction or request identifier;

  • sink identity;

  • protected time;

  • nonce;

  • current tool state; and

  • next-stage eligibility evidence. The receipt may establish a technical fact without asserting that the overall business goal has been achieved.

A.19.12. E19.12 Receipt-Gated Full Tool Invocation

The protected continuation predicate may be represented by:

Enable(Pi+1 ) = V alid(Ri )∧M atchT ool(Ri , Tj )∧M atchOperation(Ri , Γi )∧P olicyCurrent∧RevocationClear.

Where human approval is required, the corresponding approval predicate is added. A valid receipt from one tool must not authorize another tool unless protected policy expressly permits such substitution.

A.19.13. E19.13 Progressive Tool Privilege

Tool privilege may expand in phases. For example:

Γ0 ⊂ Γ1 ⊂ · · · ⊆ Γmax .

Illustrative progression:

  • Phase 0: inspect metadata;

  • Phase 1: create provisional object;

  • Phase 2: modify one bounded object;

  • Phase 3: apply broader approved mutation; and

  • final phase: complete the authorized consequence. The sequence is not limited to read-before-write and may be defined according to the tool’s actual effect model.

A.19.14. E19.14 Protected Human Approval

A human may be asked to approve:

  • the initial tool invocation;

  • continuation after the real bounded interaction;

  • expansion to a higher-privilege method;

  • use of a sensitive destination;

  • a parameter change;

  • or the final consequential operation. The approval interface may display the verified tool identity, actual Phase-0 result, exact requested next operation, destination, arguments, receipt status, and consequence scope. The AI agent cannot satisfy a required human predicate merely by generating text indicating that the user approved.

A.19.15. E19.15 Automatic Tool Continuation

Where protected policy permits, continuation may occur automatically:

V alid(Ri ) ∧ T oolP olicyP assi ∧ RiskAcceptablei ⇒ AutoContinuei+1 .

The automatic policy engine may be separate from the agent that proposed the tool call.

A.19.16. E19.16 Recursive and Chained Tool Calls

An external tool may itself request or trigger another tool. The architecture may treat the downstream operation as:

  • part of the original authorized act-equivalent representation;

  • a new Candidate Act;

  • a sub-phase requiring separate authority; or

  • a prohibited recursive path. Where recursive invocation could create an external consequence outside the authorized envelope, the downstream path may require its own PED/Finality Sink verification.

A.19.17. E19.17 Tool Argument Mutation Protection

Between approval and effectuation, arguments may be:

  • serialized;

  • transformed;

  • routed;

  • normalized;

  • encrypted;

  • translated;

  • split;

  • reconstructed; or

  • modified by middleware. The sink may reconstruct or otherwise verify the effect-relevant operation and reject unauthorized material changes. A protected equivalence function may permit transformations that preserve the authorized consequence while rejecting substitutions that change it.

A.19.18. E19.18 Credential Withholding During Tool Use

The agent may be unable to access the tool’s unrestricted credential. The protected broker may hold the credential and expose only:

  • surrogate reference;

  • one-operation capability;

  • audience-bound token;

  • short-lived token;

  • destination-bound authorization;

  • hardware-generated authenticator; or

  • another restricted enablement mechanism. The complete credential need not enter the agent’s memory space.

A.19.19. E19.19 Tool Crash and Indeterminate Effect

If the tool accepts or performs an operation but the caller loses the response, the state may become: IN DET ERM IN AT E.

The system may reconcile using:

  • idempotency identifier;

  • tool transaction identifier;

  • destination query;

  • protected request log;

  • resource version;

  • sink journal; or

  • other authoritative state. Blind replay may be prohibited where duplicate effect would be unsafe.

A.19.20. E19.20 Tool Receipt Consumption

Where one receipt authorizes one continuation:

Consumed(Ri ) = T RU E

may be stored atomically with protected state advancement. A replayed receipt then cannot independently produce a second consequential tool invocation.

A.19.21. E19.21 Alternate Tool Path Closure

A protected tool path may be ineffective if the agent can bypass it by:

  • opening a raw network connection;

  • calling the provider API directly;

  • invoking a lower-level OS primitive;

  • accessing a credential store;

  • using another connector;

  • calling an administrative endpoint;

  • using an alternate account;

  • writing directly to a database;

  • issuing a device command through a driver; or

  • using another act-equivalent path. Accordingly, paths capable of producing the same protected consequence may be disabled, mediated, cryptographically restricted, or brought under equivalent finality control.

A.19.22. E19.22 Software Implementation

A representative software path may be:

Agent → Tool Proposal → PED/Broker → Tool Gateway → External Tool.

The agent may receive only result data, while authority, credentials, receipt verification, and protected state remain outside the agent process.

A.19.23. E19.23 Hardware Implementation

The tool authority may be enforced by:

  • TEE;

  • HSM;

  • secure element;

  • DPU or SmartNIC;

  • device controller;

  • secure processor;

  • accelerator security controller; or

  • another hardware trust boundary. Hardware may retain the signing key or next-phase secret and refuse release until the required tool receipt verifies.

A.19.24. E19.24 SEND Example

An agent proposes: SEND(file, recipient).

Phase 0 may transmit a real protected trailer or recipient challenge through the actual communication tool. The recipient returns R0 . Only then may the tool gateway obtain or activate the authority required to transmit the full file or release its decryption key.

A.19.25. E19.25 Payment Example

An agent proposes: PAY(amount, beneficiary).

The payment tool may first perform a real supported bounded verification, reservation, or reversible authorization. Protected confirmation R0 may then enable the later payment operation within the originally authorized maximum envelope.

A.19.26. E19.26 Required Invariants

The frozen core of E19 includes: 1. proposal or tool-call generation is distinguishable from effect-capable invocation; 2. the protected tool identity and effect-relevant scope can be bound to authority; 3. staged embodiments obtain protected evidence from a real bounded tool interaction; 4. later tool authority may depend upon accepted prior evidence; 5. the proposing agent cannot self-satisfy protected approval merely by emitting a tool call; 6. receipt replay or duplicate invocation can be controlled where required; and 7. equivalent unprotected tool paths are addressed where non-bypassability is required.

2 E20 – PROGRESSIVE CREDENTIAL RELEASE AND RECEIPT-GATED AU- THORITY EXPANSION

A.20. E20 — Progressive Credential Release and Receipt-Gated Authority Expansion

A.20.1. E20.1 Purpose

E20 provides a staged credential architecture in which a computational system need not receive the maximum credential authority required for a contemplated operation at the outset. Instead, the system may initially expose only a bounded, audience-specific, time-limited, objectspecific, operation-specific, surrogate, non-bearer, single-use, hardware-backed, or otherwise constrained credential. Successful protected use of the bounded credential may produce an ECR. A PED may validate the receipt and then permit a broader credential, stronger capability, additional key material, larger privilege set, or final execution authority. A representative relationship is:

Cred0 → real bounded use → R0 → Cred1 → · · · → Credn .

A.20.2. E20.2 Credential Object and Scope

A phase-specific credential object may be denoted:

Credi .

Its effective privilege set may be denoted: Σi .

The maximum authority permitted for the Candidate Act may be:

Σmax .

The PED may enforce: Σi ⊆ Σmax .

Progressive release may additionally satisfy:

Σ0 ⊂ Σ1 ⊂ · · · ⊆ Σmax ,

where monotonic privilege expansion is appropriate.

A.20.3. E20.3 Credential Forms

The credential may comprise or be implemented as:

  • API token;

  • capability;

  • signing permission;

  • cryptographic key;

  • key share;

  • transaction authorization;

  • session token;

  • scoped access token;

  • audience-bound token;

  • proof-of-possession token;

  • device-bound authenticator;

  • hardware-unsealed secret;

  • certificate;

  • database credential;

  • cloud role;

  • service-account authority;

  • temporary elevation;

  • network capability;

  • command authorization;

  • or equivalent machine-verifiable authority. The architecture is not limited to a particular authentication or authorization protocol.

A.20.4. E20.4 Credential Surrogate

The agent may receive a surrogate or reference that is not independently usable as the underlying credential. The surrogate may identify:

  • protected credential record;

  • intended service;

  • permitted operation;

  • destination;

  • phase;

  • expiration;

  • nonce;

  • required receipt state; and

  • maximum authority ceiling. A protected broker may exchange, resolve, unwrap, or translate the surrogate only after the applicable finality predicates are satisfied.

A.20.5. E20.5 No Unrestricted Credential in Agent Memory

In one variation, the unrestricted credential is never exposed to:

  • model context;

  • agent scratch state;

  • ordinary process memory;

  • tool argument text;

  • prompt;

  • application logs; or

  • untrusted runtime storage. The PED, HSM, TEE, secure element, privileged broker, or destination-side component retains the sensitive credential material.

A.20.6. E20.6 Initial Credential Ceiling

Before releasing Cred0 , the PED determines an authority ceiling:

Σmax .

The ceiling may bind:

  • destination or audience;

  • methods;

  • amount;

  • recipient;

  • object;

  • namespace;

  • data type;

  • device;

  • command class;

  • time window;

  • total uses;

  • transaction count;

  • cumulative value;

  • geographic region;

  • purpose; and

  • other protected conditions. Receipt success cannot enlarge the credential beyond the independently authorized ceiling.

A.20.7. E20.7 Bounded Credential Phase

Phase 0 may release a credential having only the authority required for the bounded real interaction. Examples include:

  • read metadata but not modify;

  • access one object but not a namespace;

  • send to one verified recipient but not arbitrary recipients;

  • authorize a bounded reservation but not full settlement;

  • operate one device within a limited range;

  • call one API method but not administrative methods;

  • access a redacted dataset but not raw data; or

  • decrypt only a demonstration portion.

A.20.8. E20.8 Credential Use at a Protected Boundary

The bounded credential may be consumed or presented only through:

  • tool gateway;

  • network proxy;

  • API gateway;

  • secure monitor;

  • HSM;

  • TEE;

  • device controller;

  • destination-side verifier;

  • payment gateway;

  • database proxy; or

  • another protected enforcement component. The component may verify both the credential and the exact Candidate Act or authorized scope.

A.20.9. E20.9 Real Use and Credential Receipt

After the bounded credential is used, the destination or protected observer may return R0 proving one or more of:

  • correct destination;

  • credential acceptance;

  • correct audience;

  • expected method;

  • bounded state transition;

  • successful protected session establishment;

  • hardware identity;

  • transaction state;

  • storage state;

  • recipient state; or

  • another required condition. The receipt may be cryptographically bound to Cred0 without revealing the credential secret itself.

A.20.10. E20.10 Credential Upgrade Gate

A credential upgrade gate validates whether the next credential state may be made available. A representative predicate is:

U pgradei+1 = V alid(Ri ) ∧ CredentialM atch(Ri , Credi ) ∧ W ithinCeiling(Σi+1 , Σmax ) ∧ P olicyCurrent ∧ RevocationClear.

Where protected human approval is required, the corresponding approval predicate is conjoined.

A.20.11. E20.11 Receipt-Derived Credential Material

The next credential or key material may be cryptographically derived from the prior receipt:

Ki+1 = KDF (Kroot , DA , H(Ri ), Encode(Σi+1 )).

Alternatively, the receipt may cause:

  • an HSM to unseal a credential;

  • a key share to become available;

  • a broker to mint a scoped token;

  • a secure element to sign a next-phase assertion;

  • a destination to activate a privilege bit; or

  • a protected database to advance credential state.

A.20.12. E20.12 Destination-Bound Credential

A credential may be valid only for a bound destination: Audience(Credi ) = Ddest .

A receipt from Destination A must not enable a credential usable against Destination B unless protected policy explicitly authorizes the change.

A.20.13. E20.13 Operation-Bound Credential

The credential may bind one method or operation class. For example: M ethod(Cred0 ) = READ_M ET ADAT A, while a later credential may authorize: M ethod(Cred1 ) = W RIT E_OBJECT.

The initial credential therefore cannot be repurposed for a higher-consequence operation.

A.20.14. E20.14 Single-Use Credential

A credential may be one-time: U seCount(Credi ) ≤ 1. Protected state records consumption atomically with effectuation where duplicate use would be unsafe.

A.20.15. E20.15 Cumulative-Use Credential

Other implementations may permit multiple bounded uses while enforcing: ∑ u Ef f ectk ≤ Limit(Credi ). k=1

Examples include a cumulative spending limit, total number of recipients, total data bytes, or total device operations.

A.20.16. E20.16 Time-Bound Credential

The credential may be valid only for: tstart ≤ t ≤ texpiry .

A successful old receipt does not necessarily reactivate an expired credential.

A.20.17. E20.17 Human Approval of Credential Expansion

A protected human may approve an authority expansion after inspecting:

  • prior real use;

  • destination receipt;

  • present credential scope;

  • requested next scope;

  • cumulative prior effects;

  • risk and provenance state;

  • expiration;

  • recipient or account; and

  • consequence of the expanded authority. The approval may bind Σi+1 rather than merely state a generic “approve.”

A.20.18. E20.18 Automatic Credential Expansion

Where policy permits:

V alid(Ri ) ∧ RiskAcceptablei ∧ W ithinCeiling(Σi+1 , Σmax ) ⇒ AutoU pgradei+1 .

The protected automatic authority remains independent of the agent’s self-assertion.

A.20.19. E20.19 Hybrid Credential Expansion

A sensitive expansion may require:

AutoP olicyP assi ∧ HumanApprovali ∧ V alid(Ri ).

A threshold construction may also require shares from the PED, user device, HSM, destination, or enterprise authority.

A.20.20. E20.20 Credential Downgrade

The architecture is not limited to privilege expansion. Protected policy may reduce:

Σi+1 ⊂ Σi

when:

  • risk increases;

  • taint increases;

  • receipt quality decreases;

  • policy changes;

  • destination changes;

  • anomaly is detected;

  • time approaches expiry; or

  • a human restricts scope.

A.20.21. E20.21 Credential Revocation

At any phase: Revoked(Credi ) = T RU E may prevent both further use of that credential and derivation of later authority. Prior successful receipts do not override current revocation state.

A.20.22. E20.22 Credential Rotation

A new phase may rotate rather than enlarge authority. The new credential may have the same nominal scope but:

  • a different key;

  • different nonce;

  • new audience;

  • fresh expiration;

  • updated device binding; or

  • updated policy epoch. This may reduce the value of stolen or stale credential material.

A.20.23. E20.23 Split Credential Material

A credential may be divided into shares held by separate protected components. Full authority may require: m-of-n shares, or a role-constrained threshold. A validated receipt may cause one missing share to become available without exposing the entire reconstructed credential to the agent.

A.20.24. E20.24 Hardware-Rooted Credential Release

A secure processor may store the root credential or key and accept only:

  • authorized Candidate Act digest;

  • current phase;

  • valid receipt digest;

  • destination identity;

  • current policy epoch;

  • current revocation epoch; and

  • optional human approval evidence. If accepted, hardware may produce a one-operation authenticator instead of returning the root credential.

A.20.25. E20.25 Software Broker Variation

A privileged credential broker may expose an IPC interface to the agent. The agent submits:

  • Candidate Act identifier;

  • surrogate;

  • requested operation;

  • destination;

  • phase; and

  • receipt reference. The broker verifies protected state and either performs the authenticated operation itself or releases only the narrowly scoped authority required.

A.20.26. E20.26 Credential Theft Resistance

A stolen phase credential may be made unusable outside its expected context by binding it to:

  • device;

  • process;

  • hardware key;

  • destination;

  • nonce;

  • session;

  • Candidate Act;

  • phase;

  • transaction;

  • time; or

  • another protected condition.

A.20.27. E20.27 Crash and Unknown Credential Use

If a request may have consumed a one-time credential but confirmation is lost, the system may enter an indeterminate state. Before minting a replacement credential, the PED may reconcile:

  • destination use state;

  • transaction state;

  • token nonce;

  • HSM counter;

  • protected log;

  • resource version; or

  • provider receipt. This prevents replacement authority from accidentally duplicating the prior consequence.

A.20.28. E20.28 SEND Example

An agent initially receives or references a capability usable only to send a protected trailer to a specified recipient. The receiving endpoint returns R0 . After verification, the PED may activate a second capability authorizing the complete message or file, but still only to that recipient and within the approved content envelope.

A.20.29. E20.29 Payment Example

An agent may initially receive authority only for a beneficiary verification, bounded reservation, or limited supported transaction. A protected receipt then permits a later payment credential within:

Σmax ,

which may encode maximum amount, beneficiary, currency, rail, and expiration.

A.20.30. E20.30 Required Invariants

The frozen core of E20 includes: 1. the system can withhold maximum credential authority at the outset; 2. phase credentials can be bounded to protected scope; 3. successful bounded real use can produce protected evidence; 4. later credential authority may depend upon accepted prior evidence; 5. receipt success cannot exceed the independently authorized maximum authority ceiling; 6. the unrestricted credential need not be exposed to the proposing agent; 7. revocation, expiry, replay, duplicate use, and indeterminate use can be handled by protected state; and 8. software-only, hardware-rooted, and split implementations are all contemplated.

3 E21 – RECEIPT-GATED DATA EXPORT, PROGRESSIVE DISCLOSURE, AND CRYPTOGRAPHIC RELEASE

A.21. E21 — Receipt-Gated Data Export, Progressive Disclosure, and Cryptographic Release

A.21.1. E21.1 Purpose

E21 applies staged effectuation to export, disclosure, transfer, publication, replication, sharing, or release of protected data. The architecture distinguishes:

  • authority to prepare data;

  • authority to move ciphertext or a bounded sample;

  • authority to disclose a limited subset;

  • authority to make data usable by a recipient; and

  • authority to complete the full authorized export.

A representative relationship is:

X0 → R0 → X 1 → R1 → · · · → X n ,

where the stages represent progressively broader real disclosure, transfer, or usability within an authorized export envelope.

A.21.2. E21.2 Authorized Export Object

Let: Xmax denote the maximum protected data object, set, stream, record class, file collection, model artifact, database selection, or information envelope authorized for the Candidate Act. A phase-specific export subset or release may be:

Xi .

Protected policy may require: Xi ⊆ Xmax .

Where progressive disclosure is monotonic:

X0 ⊂ X1 ⊂ · · · ⊆ Xmax .

A.21.3. E21.3 Export Envelope Formation

Before release, the PED may bind an export envelope identifying:

  • data object or selection;

  • record set;

  • schema;

  • source;

  • destination;

  • recipient;

  • purpose;

  • allowed transformations;

  • sensitivity class;

  • allowed fields;

  • maximum record count;

  • maximum bytes;

  • jurisdiction;

  • retention conditions;

  • encryption requirements;

  • permitted recipients;

  • policy epoch;

  • expiration; and

  • maximum cumulative disclosure.

A.21.4. E21.4 Export Staging Modes

Protected policy may choose: 1. single-phase full export; 2. schema or manifest first; 3. redacted sample first; 4. encrypted sample first; 5. bounded record subset first; 6. ciphertext-first full transport with withheld key; 7. progressive chunk release; 8. progressive field release; 9. progressive recipient release; 10. progressive jurisdiction or region release; 11. protected human approval; or 12. automatic/hybrid progression.

A.21.5. E21.5 Real Bounded Export Effect

The first stage must create a real effectuation-relevant event where the staged architecture requires real bounded effect. Examples include:

  • actual delivery of a protected sample to the intended destination;

  • actual storage of ciphertext in the intended recipient environment;

  • actual transfer of a cryptographic manifest;

  • actual release of a bounded record subset;

  • actual destination-side processing of an encrypted test object;

  • actual creation of a protected receiving namespace; or

  • actual recipient verification using the real export path. A sender-local preview alone need not satisfy the trial condition.

A.21.6. E21.6 Export Manifest

The system may construct a protected manifest containing:

  • dataset or object identifier;

  • schema digest;

  • record-count commitment;

  • field list or field commitment;

  • source digest;

  • chunk hashes;

  • classification;

  • encryption metadata;

  • destination;

  • recipient identity;

  • retention or handling policy reference;

  • policy epoch; and

  • Candidate Act binding. The manifest may permit a recipient to verify later phases without revealing the entire data content.

A.21.7. E21.7 Redacted or Low-Sensitivity Trial

A first real export may contain:

  • redacted fields;

  • masked identifiers;

  • aggregate statistics;

  • synthetic or substituted values;

  • low-sensitivity records;

  • bounded rows;

  • bounded columns;

  • schema only; or

  • another reduced-disclosure representation. The reduction technique is implementation dependent and must not be assumed to provide a particular privacy guarantee unless independently established.

A.21.8. E21.8 Ciphertext-First Export

The full or partial data object may be transported as ciphertext before semantic release. The destination may receive: EncK (Xmax ) while lacking sufficient key material to decrypt the protected content. After the destination returns a valid receipt R0 , the PED may release:

  • decryption key;

  • key share;

  • unwrap authority;

  • hardware unseal command;

  • object-specific capability; or

  • another cryptographic release condition. This separates transport effect from semantic disclosure.

A.21.9. E21.9 Progressive Chunk Export

The data may be divided: Xmax = X (1) ∪ X (2) ∪ · · · ∪ X (n) .

After protected acceptance of chunk k, a receipt may authorize chunk k + 1. Each chunk may be bound to:

  • overall manifest;

  • sequence;

  • recipient;

  • destination;

  • hash;

  • encryption context;

  • phase; and

  • cumulative disclosure ceiling.

A.21.10. E21.10 Progressive Field Release

Instead of chunking by bytes, disclosure may be phased by semantic field. For example:

  • Phase 0: schema and non-sensitive fields;

  • Phase 1: pseudonymous identifiers;

  • Phase 2: selected operational fields;

  • Phase 3: additional protected fields; and

  • final phase: maximum authorized field set. The later field set may depend upon protected evidence that earlier release reached the intended recipient and policy state remains valid.

A.21.11. E21.11 Progressive Record Release

For a dataset of records: R = {r1 , r2 , . . . , rN }, the PED may authorize only a subset: R0 ⊂ R.

Receipt-confirmed processing may permit: R1 , R2 , . . . until the maximum authorized export set is reached.

A.21.12. E21.12 Cumulative Disclosure Fraction

Where a quantitative disclosure fraction is useful, define: |Xreleased,i | λi = . |Xmax |

The system may require: 0 ≤ λi ≤ 1.

For progressive release: λi+1 ≥ λi , unless rollback or revocation causes the usable disclosure state to decrease. The metric may represent bytes, records, fields, objects, or another policy-defined quantity.

A.21.13. E21.13 Destination Receipt

A destination receipt may prove one or more of:

  • correct recipient identity;

  • correct destination service;

  • successful ciphertext receipt;

  • successful integrity verification;

  • correct storage namespace;

  • destination attestation;

  • policy-compatible region;

  • protected key possession;

  • processing readiness;

  • accepted retention configuration; or

  • other technical state. The receipt need not prove future behavior beyond what the protected evidence actually supports.

A.21.14. E21.14 Destination Handling-State Evidence

Where technically available, the destination may attest a handling state such as:

  • encryption enabled;

  • protected execution environment active;

  • required storage class active;

  • expected software measurement;

  • key isolated in hardware;

  • access-control state;

  • destination region;

  • data-loss-prevention policy present; or

  • retention timer configured. Such evidence may be one predicate among several and does not inherently guarantee compliance or future behavior.

A.21.15. E21.15 Receipt-Gated Next Export Phase

A representative next-phase predicate may be: ExportEnablei+1 = V alid(Ri ) ∧ M atchDestination(Ri ) ∧ W ithinExportEnvelope(Xi+1 ) ∧ P olicyCurrent ∧ RevocationClear.

Where human approval is required, the corresponding approval predicate is added.

A.21.16. E21.16 Human Approval After Trial Export

A protected UI may show:

  • what was actually exported;

  • destination identity;

  • receipt status;

  • current cumulative disclosure;

  • requested next data subset;

  • sensitivity/classification;

  • recipient;

  • jurisdiction or region;

  • encryption state; and

  • consequence of completing the next phase. The human may approve, restrict, delay, or deny the next release.

A.21.17. E21.17 Automatic Export Progression

Where protected policy permits: V alid(Ri ) ∧ ExportP olicyP assi ∧ RiskAcceptablei ⇒ AutoExporti+1 .

The automatic policy component may use current data classification, destination state, receipt quality, taint/provenance, jurisdiction, cumulative volume, and other protected predicates.

A.21.18. E21.18 Hybrid Export Progression

A higher-assurance export may require: V alid(Ri ) ∧ AutoP olicyP assi ∧ HumanApprovali or a multi-authority threshold. Different approval requirements may apply to different data classes within the same export.

A.21.19. E21.19 Multi-Recipient Export

Where the same data is intended for recipients: D1 , D 2 , . . . , D m , each recipient may have independent:

  • receipt state;

  • permitted data subset;

  • key material;

  • jurisdiction condition;

  • policy state;

  • revocation state; and

  • completion state. A receipt from one recipient need not authorize release to another.

A.21.20. E21.20 Destination Change

If the destination changes after Phase 0, prior receipt R0 need not remain sufficient. The protected system may require:

  • new destination validation;

  • new trial export;

  • fresh human approval;

  • new key material;

  • new export envelope; or

  • final denial.

A.21.21. E21.21 Jurisdiction-Aware Progression

The export envelope may bind a jurisdiction or approved region. If current destination evidence indicates:

Regioncurrent ∈ / Regionallowed ,

the next export phase remains blocked. This is a technical enforcement predicate; legal classification or legal sufficiency is determined separately.

A.21.22. E21.22 Taint and Provenance-Aware Export

Taint or provenance may affect:

  • whether export is allowed;

  • maximum phase size;

  • permitted destination;

  • required approval;

  • encryption requirement;

  • recipient class;

  • logging requirement; or

  • whether release must remain local-only. A receipt proving successful delivery does not erase or cleanse protected taint state unless policy expressly defines such a transition.

A.21.23. E21.23 Export Encryption-Key Progression

A recipient may obtain progressively broader decryption authority:

K0rel , K1rel , . . . , Knrel .

Each release key may be bound to:

  • data subset;

  • recipient;

  • phase;

  • prior receipt;

  • policy epoch;

  • expiry; and

  • destination hardware identity. A later key may be derived only after the preceding receipt is validated.

A.21.24. E21.24 Object-Specific Keying

Different exported objects may have distinct keys. Compromise of one object key need not reveal other objects. For example: Kj = KDF (Kroot , DA , ObjectIDj , Recipientj ).

Receipt-gated release may then expose only the key corresponding to an authorized object.

A.21.25. E21.25 Hardware-Rooted Data Release

A hardware component may:

  • retain export keys;

  • verify destination attestation;

  • verify receipt digest;

  • enforce phase counter;

  • decrypt only authorized fields;

  • encrypt only authorized chunks;

  • release key shares; or

  • directly drive network/storage egress. The proposing application cannot bypass the hardware by reading the protected root key.

A.21.26. E21.26 Network-Enforced Export

A DPU, SmartNIC, secure NIC, firewall, gateway, or service mesh may enforce:

  • destination;

  • data amount;

  • protocol;

  • recipient;

  • phase;

  • connection identity;

  • cryptographic authorization; and

  • receipt-dependent continuation. Direct unmediated egress paths may be restricted where non-bypassability is required.

A.21.27. E21.27 Storage-to-Network Export

A protected storage controller or data gateway may keep the source object encrypted and release only phase-authorized data to the network path. This may prevent an agent from reading the full plaintext merely because it is authorized to initiate an export.

A.21.28. E21.28 Database Export

A query may select a maximum authorized result set. The first phase may release:

  • schema;

  • count;

  • aggregate;

  • limited rows;

  • masked fields; or

  • encrypted result segment. Verified destination receipt may then enable larger portions of the result while preserving the maximum query/export envelope.

A.21.29. E21.29 Model and Vector-State Export

The export object may be:

  • model weights;

  • adapter;

  • embedding collection;

  • vector database entries;

  • model memory;

  • checkpoint;

  • activation data;

  • training subset;

  • inference trace; or

  • another protected AI artifact. Release may progress by shard, layer, tenant, object class, or encrypted segment.

A.21.30. E21.30 Streaming Export

For a stream, the system may authorize bounded windows:

W0 , W 1 , . . . , W n .

Each window may require continuation evidence before the next window becomes available. The system may terminate mid-stream if policy, revocation, receipt state, destination state, or risk changes.

A.21.31. E21.31 Crash and Indeterminate Export

If a data phase may have been delivered but confirmation is lost, the system may enter an indeterminate state. Before retransmission, the PED may reconcile using:

  • chunk identifier;

  • recipient storage state;

  • object digest;

  • transport acknowledgement;

  • destination receipt;

  • protected send journal;

  • transaction identifier; or

  • cumulative disclosure counter. This reduces accidental duplicate release and protects cumulative limits.

A.21.32. E21.32 Receipt Consumption and Replay

Where one receipt permits only one next-stage release:

Consumed(Ri ) = T RU E

may be committed with the state transition. Replay of a valid old destination receipt must not independently trigger another export phase.

A.21.33. E21.33 Revocation During Export

If authorization is revoked after some data has already been disclosed, future unreleased phases remain blocked. Where technically possible, the system may additionally:

  • revoke a pending key;

  • expire a decryption capability;

  • delete staged ciphertext;

  • cancel queued transfers;

  • disable future stream windows; or

  • issue a compensating deletion request. The architecture does not assume that already disclosed plaintext can always be recovered.

A.21.34. E21.34 Anti-Bypass

Protected staged export may be bypassed if the agent can use:

  • direct socket;

  • alternate storage bucket;

  • unprotected object URL;

  • raw database connection;

  • clipboard;

  • file system path;

  • alternate cloud credential;

  • debugging interface;

  • message queue;

  • alternate network interface; or

  • another equivalent data-egress path. Where non-bypassability is required, such paths may be closed, mediated, cryptographically restricted, or subjected to equivalent finality controls.

A.21.35. E21.35 SEND Example

A sensitive file intended for a recipient may first release:

  • protected trailer;

  • manifest;

  • ciphertext header;

  • encrypted sample;

  • or bounded file segment. After the recipient returns valid protected evidence, the remaining file or decryption material is released.

A.21.36. E21.36 Payment-Data Example

A financial system may export a bounded transaction manifest or beneficiary-verification dataset before releasing a complete settlement instruction dataset or broader payment batch. The receipt-gated mechanism may govern data disclosure independently from the separate authority required to settle funds.

A.21.37. E21.37 Required Invariants

The frozen core of E21 includes: 1. the maximum authorized export envelope is distinguishable from any individual release phase; 2. staged embodiments perform a real bounded transfer, disclosure, or recipient-side processing event; 3. protected receipt evidence may gate broader release; 4. later disclosure cannot exceed the independently authorized maximum export envelope; 5. transport of ciphertext and semantic disclosure may be separately controlled; 6. destination, recipient, policy, revocation, and cumulative disclosure state may remain bound across phases; 7. already disclosed plaintext is not presumed reversible; and 8. equivalent egress paths are addressed where non-bypassability is required.

4 FROZEN RELATIONSHIP AMONG E19, E20, AND E21 E19, E20, and E21 address three different authority surfaces.

Proposal → bounded tool authority → real tool effect → Ri → broader tool authority.

Cred0 → bounded real use → R0 → Cred1 → · · · .

X0 → R0 → X1 → · · · → Xmax .

The embodiments may operate independently or together. For example, an AI agent may use E19 to request a tool, E20 to obtain a phase-bounded credential for that tool, and E21 to govern what data the tool is permitted to export. The combined architecture need not expose unrestricted credential material, unrestricted data, or unconditional tool authority to the proposing agent.

A.22. E22 — Receipt-Gated Storage Release, Provisional Persistence, and Progressive Visibility

A.22.1. E22.1 Purpose

E22 applies staged effectuation to storage operations in which data, objects, model outputs, files, records, media, encrypted payloads, configuration state, or other persistent material may be written or staged before becoming fully durable, externally visible, retrievable, replicated, indexed, discoverable, decryptable, or otherwise effective for its intended consumers. The storage embodiment distinguishes among at least three logically different events: 1. data reaching a storage-capable component; 2. a bounded or provisional storage state being successfully established; and 3. the object becoming fully promoted, durable, visible, replicated, routable, discoverable, or semantically usable. A representative causal chain is:

Candidate Storage Act → Protected Validation → Bounded/Provisional Write → R0store → Promotion Authority → Full Storage Effect.

A storage write request, successful transmission of bytes to a storage process, or ordinary acknowledgement from an unprotected application need not itself establish authority for final persistent release.

A.22.2. E22.2 Storage Candidate Act Formation

The Candidate Act may identify one or more of:

  • object identifier, key, path, row, block range, volume, bucket, namespace, repository, tenant, account, or storage class;

  • payload digest or content commitment;

  • expected length, content type, compression form, encryption form, and encoding;

  • intended durability class;

  • replication factor or replica set;

  • visibility class;

  • discoverability or indexing status;

  • retention policy;

  • deletion or overwrite behavior;

  • access-control state;

  • decryption or unwrap authority;

  • target region, jurisdiction, device, controller, or service;

  • intended consumer or downstream application; and

  • maximum permitted consequence.

The protected maximum storage envelope may be denoted:

Σmax .

A phase-specific permitted storage envelope may be:

Σi ⊆ Σmax .

A.22.3. E22.3 Storage Effect Dimensions

A storage operation may be bounded independently along one or more technical dimensions, including:

  • number of bytes;

  • number of objects;

  • number of rows, pages, extents, or blocks;

  • namespace scope;

  • replica count;

  • geographic region;

  • retention duration;

  • access-control scope;

  • indexing visibility;

  • external publication state;

  • decryption state;

  • storage tier;

  • tenant visibility;

  • cache propagation;

  • backup propagation; or

  • downstream processing eligibility. Thus a “partial storage effect” need not mean only a smaller byte count. It may instead mean a complete object stored under deliberately restricted visibility or usability conditions.

A.22.4. E22.4 Provisional Storage State

A first phase may establish a real but bounded storage state, including:

  • quarantine namespace;

  • provisional bucket;

  • temporary object identifier;

  • non-indexed record;

  • non-public object version;

  • isolated replica;

  • encrypted object with withheld unwrap material;

  • short-retention object;

  • write-only object;

  • shadow index entry;

  • immutable staging area;

  • protected local persistent state not yet promoted globally; or

  • another storage state whose consequence is narrower than the full requested release. The provisional state is a real persistent or storage-system-recognized effect. It is not merely a simulation of writing the object.

A.22.5. E22.5 Storage Effect Descriptor

The PED may form a protected storage-phase descriptor binding the Candidate Act to the permitted phase. The descriptor may include:

  • Candidate Act digest;

  • object digest;

  • object identifier;

  • destination storage component;

  • namespace;

  • permitted byte range;

  • permitted replica set;

  • visibility state;

  • required persistence semantics;

  • retention state;

  • encryption state;

  • permitted promotion target;

  • required ECR issuer;

  • nonce and expiry;

  • policy epoch and revocation state; and

  • the next permitted storage transition.

A.22.6. E22.6 Real Bounded Write

The storage sink performs the bounded write. Examples include:

  • writing the complete object into a quarantine namespace;

  • writing only the first protected fragment;

  • writing a complete ciphertext while withholding the decryption key;

  • writing one replica before wider replication;

  • persisting a candidate model-state update in an isolated vector namespace;

  • writing a media object but withholding external publication;

  • committing a configuration artifact into protected storage but not making it active; or

  • persisting an export package in a non-routable storage class.

A.22.7. E22.7 Persistence Evidence

The storage system or protected observer may produce evidence of the actual stored state. Such evidence may include:

  • durable log sequence number;

  • object version ID;

  • storage transaction ID;

  • object digest verified after write;

  • block checksum set;

  • Merkle root;

  • replica acknowledgement set;

  • fsync or equivalent durable-write confirmation;

  • device-level flush confirmation;

  • storage-controller attestation;

  • secure-element or HSM-backed object state;

  • immutable-log reference;

  • object-lock state;

  • encryption-state confirmation; or

  • destination-side protected acknowledgement.

Let the protected storage observation at phase i be:

Oistore .

The corresponding receipt may be: Ristore .

A.22.8. E22.8 Persistence Acceptance Predicate

Continuation may require:

StorageAccepti = V alid(Ristore ) ∧ M atchObjecti ∧ M atchDestinationi ∧ Integrityi ∧ Durabilityi ∧ P olicyCurrenti ∧ RevocationCleari .

Where a particular storage class does not require durability, the relevant predicate may instead verify another protected state such as correct quarantine, encryption, or destination placement.

A.22.9. E22.9 Promotion Authority

After successful validation, the PED may derive or release authority to promote the stored object. Promotion may comprise:

  • moving or relabeling the object into a production namespace;

  • expanding access controls;

  • making an object externally retrievable;

  • publishing an object URL;

  • indexing the object;

  • replicating it to additional nodes or regions;

  • promoting a vector or model-state record into shared memory;

  • releasing a decryption or unwrap key;

  • enabling downstream processing;

  • increasing retention; or

  • changing a provisional object into a final durable object.

A promotion capability may be denoted: Ciprom .

The capability may bind: H(Ristore ) so that another object’s receipt cannot authorize promotion.

A.22.10. E22.10 Progressive Replication

A large storage operation may progress through replica stages:

1 → 2 → 3 → · · · → rmax .

Let: Ri denote the set of replicas confirmed after phase i. Protected policy may require: Ri ⊆ Ri+1 ⊆ Rmax .

Each replication stage may produce its own receipt or aggregate receipt.

A.22.11. E22.11 Progressive Visibility

Storage visibility may progress through states such as:

quarantine → internal → tenant-visible → authorized external → public.

No particular progression is required. The important property is that a broader visibility state may depend upon protected evidence from a narrower real storage state.

A.22.12. E22.12 Ciphertext-First Storage

A full object may be physically present in storage while semantic usability remains blocked because required decryption material is withheld. Let the stored ciphertext be: CTF = EncKF (F ).

The storage system may persist CTF before KF or an unwrap capability becomes available. Following valid storage receipt and any additional protected approval:

V alid(R0store ) → Release(KF )

or an equivalent key-unwrapping condition may occur. This variation reduces transfer latency while preserving staged semantic release.

A.22.13. E22.13 Human Approval After Storage Confirmation

A human may approve promotion only after reviewing protected evidence that the intended object is actually present at the expected destination. The protected interface may show:

  • object identity and digest;

  • storage destination;

  • actual stored size;

  • encryption state;

  • jurisdiction or region;

  • retention and access state;

  • requested promotion consequence; and

  • the validated storage receipt. The approval artifact may be bound to H(Ristore ).

A.22.14. E22.14 Automatic Promotion

Where policy permits, valid persistence evidence may automatically enable promotion:

V alid(Ristore ) ∧ StorageP olicyP assi ∧ RiskAcceptablei ⇒ P romotei+1 .

A.22.15. E22.15 Hybrid Promotion

A higher-assurance storage class may require both automated verification and human approval:

StorageAccepti ∧ HumanApprovali ⇒ P romotei+1 .

A.22.16. E22.16 Hardware-Enforced Storage Variation

The Finality Sink may be implemented at or below a storage controller, SSD controller, secure storage processor, DPU, SmartNIC, DMA controller, memory controller, trusted I/O path, storage HSM, or equivalent hardware component. The hardware may enforce:

  • permitted object ranges;

  • namespace selection;

  • phase-specific key use;

  • replica authorization;

  • secure erase or retention state;

  • write-once state;

  • anti-rollback state;

  • authenticated promotion command; and

  • release of cryptographic material only after receipt validation.

A.22.17. E22.17 Storage Controller Receipt

A storage controller may sign or MAC a receipt containing:

Ristore = P rotect(DA , ObjectID, ObjectDigest, V ersioni , StorageStatei , Counteri , Ni , Statusi ).

The receipt may be generated only after the storage controller has reached the protected state identified in the receipt.

A.22.18. E22.18 Crash After Provisional Write

If a provisional write succeeds but the caller crashes before receiving confirmation, the system enters an indeterminate state rather than blindly repeating the write where duplication or overwrite would be harmful. A storage idempotency identifier may be:

Iistore = H(DA ∥ ObjectID ∥ i ∥ Ni ).

The storage sink may atomically associate Iistore with the persisted state. Recovery may establish whether the write:

  • was committed;

  • was not committed;

  • was committed under a particular object version; or

  • remains indeterminate.

A.22.19. E22.19 Overwrite and Destructive Storage Operations

For overwrite, deletion, truncation, or lifecycle transition, the trial phase may preserve reversibility by:

  • creating a new version rather than replacing the old one;

  • retaining a protected snapshot;

  • moving the object into quarantine;

  • marking for deletion without immediate erasure;

  • performing tombstone creation before physical deletion; or

  • requiring an additional receipt before irreversible destruction. A destructive final phase may remain unavailable until the reversible protected state is confirmed.

A.22.20. E22.20 Storage Anti-Substitution

A receipt for Object A must not authorize promotion of Object B. The PED or sink may verify:

Digest(Ristore .Object) = Digest(Objectcandidate ).

Likewise, a receipt for one namespace, region, tenant, or replica class must not be silently reused for another where those properties are material.

A.22.21. E22.21 Alternate-Path Closure

Equivalent storage-effect paths may include:

  • direct object-store API;

  • local filesystem path;

  • raw block device;

  • database BLOB path;

  • backup/restore path;

  • replication service;

  • admin console;

  • lifecycle engine;

  • CDN origin path;

  • cache promotion path;

  • direct storage credential; and

  • privileged driver or controller interface. Where non-bypassable staged storage finality is required, such paths are disabled, constrained, or subjected to equivalent protected controls.

A.22.22. E22.22 SEND Example

A sensitive file intended for a recipient may first be stored in a non-public encrypted staging object. The storage service returns a protected receipt proving object digest, destination, and persistence. Only then may the system generate or release a recipient-scoped retrieval capability or decryption material. Accordingly, persistence of the bytes does not itself complete the SEND consequence.

A.22.23. E22.23 Payment Example

A payment instruction file, settlement batch, or signed payment artifact may first be committed to protected staging storage. A storage receipt proves the exact batch digest and destination. Only after verification may the settlement system consume or expose the artifact to the paymentexecution path. Thus storage finality and payment finality may be chained without treating them as identical events.

A.22.24. E22.24 Required Invariants

Invariant 1. A storage request is distinguishable from the protected storage consequence. Invariant 2. A bounded or provisional storage state may be real and externally persisted without granting full promotion or visibility. Invariant 3. Where staged storage is required, broader promotion depends on protected evidence of the preceding storage state. Invariant 4. The receipt is bound to the relevant object and storage context. Invariant 5. Alternate storage paths cannot trivially bypass required promotion control. Invariant 6. Crash or receipt loss does not require blind duplicate writing. Invariant 7. Software, hardware, destination-side, or combined enforcement may implement the architecture.

2 E23 – RECEIPT-GATED ROBOTIC ACTUATION AND PROGRESSIVE PHYS- ICAL EFFECTUATION

A.23. E23 — Receipt-Gated Robotic Actuation and Progressive Physical Effectuation

A.23.1. E23.1 Purpose

E23 applies staged effectuation to robots, autonomous machines, industrial manipulators, mobile robots, drones, vehicles, machine tools, medical or laboratory automation, warehouse systems, construction equipment, home automation, and other cyber-physical systems capable of producing physical consequences. The principal architecture separates: 1. computational generation of a motion or device command; 2. authority to initiate a bounded physical effect; 3. protected observation of what actually happened; and 4. authority to continue or enlarge the physical consequence. A representative flow is:

Proposed Physical Act → PED Validation → Bounded Actuation → Protected Physical Observation → R0phys → Continuation Authority.

A.23.2. E23.2 Candidate Physical Act

A robotic Candidate Act may bind:

  • actuator or joint identifier;

  • requested trajectory;

  • velocity, acceleration, jerk, torque, force, pressure, power, or energy envelope;

  • route, waypoint, position, or orientation;

  • gripper or tool state;

  • payload state;

  • proximity constraints;

  • geofence;

  • collision envelope;

  • time interval;

  • sensor requirements;

  • emergency-stop state;

  • expected effect;

  • maximum consequence envelope; and

  • required receipt or human approval class.

Let the maximum authorized physical envelope be:

Ωmax .

A phase-specific physical envelope is: Ωi ⊆ Ωmax .

A.23.3. E23.3 Physical Effect Is Not Command Acceptance

A controller accepting a command does not necessarily establish that the physical consequence occurred as requested. The architecture may therefore distinguish:

CommandAccepted ̸= P hysicalEf f ectConf irmed.

For example, a motor controller may accept a 5◦ movement command while a jammed actuator moves only 0.5◦ . Accordingly, a protected continuation decision may depend upon physical observation rather than only software acknowledgement.

A.23.4. E23.4 Phase-0 Physical Effect Selection

The initial bounded act may be limited by:

  • angle;

  • displacement;

  • velocity;

  • duration;

  • torque;

  • force;

  • altitude;

  • route segment;

  • energy;

  • payload change;

  • number of actuators;

  • machine cell;

  • operating zone;

  • or another measurable physical dimension. The bounded phase should be sufficiently real to exercise the relevant physical execution path while remaining within a policy-selected consequence envelope.

A.23.5. E23.5 Protected Physical Observer

Physical-effect evidence may be obtained from one or more protected observers, including:

  • rotary or linear encoder;

  • inertial measurement unit;

  • force or torque sensor;

  • current or voltage sensor;

  • pressure sensor;

  • proximity sensor;

  • lidar, radar, sonar, camera, or depth sensor;

  • limit switch;

  • motor-controller telemetry;

  • wheel odometry;

  • GNSS or protected location source;

  • actuator internal state;

  • safety PLC;

  • independent supervisory controller;

  • or a remote trusted observer. The observer need not itself decide policy. It may produce authenticated evidence for protected

evaluation.

A.23.6. E23.6 Expected and Observed Physical State

Let the expected bounded physical state after phase i be:

Xiphys

and the protected observed state be: Oiphys .

A generalized physical acceptance predicate may be:

dphys (Oiphys , Xiphys ) ≤ εi ,

where dphys is a protected comparison function and εi is the allowed phase-specific tolerance. The function may evaluate multiple variables rather than a single scalar.

A.23.7. E23.7 Multi-Dimensional Safety Envelope

For a state vector: xi = [x1 , x2 , . . . , xk ]T , a protected safe set may be: Sisaf e .

Continuation may require: xobs i ∈ Sisaf e .

The safe set may incorporate position, velocity, temperature, force, load, current, proximity, or other measured variables.

A.23.8. E23.8 Robotic Effect Confirmation Receipt

A protected robotic receipt may bind:

Riphys = P rotect(DA , ActuatorID, P hasei , Xiphys , Oiphys , SensorSeti , Ti , Ni , Statusi ).

The receipt may be generated by a motor controller, safety processor, secure sensor hub, PLC, TEE, secure MCU, vehicle ECU, flight controller, robotic safety controller, or another protected component.

A.23.9. E23.9 Automatic Continuation

Where policy permits:

V alid(Riphys ) ∧ Saf ei ∧ P olicyCurrenti ∧ RevocationCleari ⇒ Enable(Pi+1 ).

The next phase may increase motion, velocity, distance, duration, payload interaction, or another physical consequence.

A.23.10. E23.10 Human Continuation Approval

For sensitive physical acts, an authenticated human may review the protected result of the bounded movement before allowing broader operation. The approval interface may display:

  • requested action;

  • actual measured movement;

  • sensor confidence;

  • current physical state;

  • destination or route;

  • collision/safety status;

  • next proposed phase; and

  • consequence envelope. Human approval may be bound to the receipt digest and next-phase descriptor.

A.23.11. E23.11 Hybrid Safety Approval

A robotic system may require:

V alid(Riphys ) ∧ AutomaticSaf etyP assi ∧ HumanApprovali ⇒ Continuei .

This may be appropriate for high-consequence industrial, transportation, or human-proximate operations.

A.23.12. E23.12 Progressive Motion

A total requested trajectory Θ may be partitioned into:

Θ = θ0 + θ1 + · · · + θn .

Each component is a real effectuation phase. A valid receipt may be required before the next component becomes executable. Alternatively, the trajectory may be represented parametrically by q(t) and divided into protected time intervals: [t0 , t1 ], [t1 , t2 ], . . . , [tn−1 , tn ].

Continuation into interval i + 1 may depend upon protected evidence from interval i.

A.23.13. E23.13 Mobile Robot Route Segmentation

A mobile robot route may be divided into waypoint or geofence segments:

W0 → W1 → · · · → Wn .

At each waypoint, protected evidence may confirm:

  • location;

  • orientation;

  • speed;

  • obstacle state;

  • route integrity;

  • communications status;

  • payload state; and

  • policy status. Only then may authority for the next route segment become available.

A.23.14. E23.14 Drone / UAV Variation

A UAV may be authorized initially for a bounded altitude, distance, speed, or waypoint. Protected telemetry and onboard attestation may determine whether subsequent segments are enabled. Examples include:

  • 2 meter climb before a larger ascent;

  • one waypoint before mission continuation;

  • a low-speed approach before final landing;

  • bounded sensor activation before broader collection;

  • bounded radio emission before extended communication; or

  • a return-to-safe-state phase after an indeterminate condition.

A.23.15. E23.15 Vehicle Variation

A vehicle-control Candidate Act may be phased by:

  • steering angle;

  • speed increase;

  • acceleration interval;

  • braking interval;

  • lane-change segment;

  • route segment;

  • geofence; or

  • subsystem activation. Protected vehicle state may be used to prevent later phases where observed behavior diverges materially from expected state.

A.23.16. E23.16 Industrial Process Variation

An industrial process may phase:

  • valve opening;

  • pressure increase;

  • heating;

  • flow rate;

  • motor speed;

  • conveyor activation;

  • machine-cell activation;

  • load switching; or

  • chemical dosing. Protected process measurements may gate broader operation.

A.23.17. E23.17 Multiple Sensor Confirmation

A phase may require a sensor quorum. Let sensor observations be: phys phys phys Oi,1 , Oi,2 , . . . , Oi,s .

Protected continuation may require:

∑ s phys Accept(Oi,j ) ≥ ms . j=1

Different sensors may also be assigned different trust weights or mandatory roles.

A.23.18. E23.18 Sensor Disagreement

Where protected sensors disagree beyond a permitted threshold, the phase may enter: P HY SICAL_IN DET ERM IN AT E.

The architecture may:

  • hold position;

  • reduce energy;

  • stop further actuation;

  • request another sensor reading;

  • engage a safety controller;

  • require human review; or

  • execute a protected safe-state act.

A.23.19. E23.19 Bounded Safe-State Actuation

A safe-state response may itself be a protected Candidate Act. Examples include:

  • brake;

  • power reduction;

  • controlled stop;

  • gripper release where safe;

  • return to known pose;

  • retreat from a hazard zone;

  • hover;

  • land;

  • close valve; or

  • isolate machinery. The architecture need not assume that “do nothing” is always the safest response.

A.23.20. E23.20 Crash After Physical Effect

A difficult state occurs where the physical effect occurs but the controlling software crashes before receipt processing. A blind reissue may duplicate motion. Recovery may therefore use:

  • actuator phase counter;

  • encoder position;

  • controller journal;

  • secure monotonic counter;

  • trajectory identifier;

  • hardware command sequence number;

  • sensor snapshot; or

  • independently observed machine state. The system resolves whether the phase was effected before authorizing retry or continuation.

A.23.21. E23.21 Physical Rollback and Compensation

Physical actions may be:

  • reversible;

  • partially reversible;

  • compensable; or

  • irreversible. Where reversal is possible, rollback may itself be receipt-gated. Where reversal is impossible, a compensating act may be used, such as braking, counter-motion, isolation, release, refund of consumed resource, or human escalation.

A.23.22. E23.22 Energy-Bounded Effectuation

The architecture may bind authority to a maximum energy envelope:

Ei ≤ Emax .

A phase may end when the permitted energy, force, duration, or movement budget is exhausted, even if the originating agent continues requesting action.

A.23.23. E23.23 Hardware and Software Enforcement

Robotic staged finality may be enforced by one or more of:

  • application controller;

  • ROS or equivalent middleware gate;

  • operating-system privileged service;

  • real-time controller;

  • safety PLC;

  • motor-control MCU;

  • secure element;

  • vehicle ECU;

  • flight controller;

  • FPGA/ASIC;

  • TEE/HSM;

  • independent safety processor; or

  • actuator-local control logic. A software PED may plan the phase while protected hardware retains the missing actuation authority.

A.23.24. E23.24 Alternate-Path Closure

The system may constrain bypass through:

  • raw motor commands;

  • debug interfaces;

  • maintenance mode;

  • direct CAN or fieldbus commands;

  • alternate radio controller;

  • direct GPIO/PWM access;

  • privileged robotics middleware;

  • actuator vendor API;

  • manual remote-control channel; or

  • recovery interface. Where such paths remain effect-capable, they may be placed under equivalent finality control.

A.23.25. E23.25 SEND Example

An autonomous robot may propose sending a location, image, or telemetry package. The SEND operation may independently use the communication staged-finality chain: bounded trailer, recipient receipt, then full payload. Physical actuation and communication therefore may each have their own protected continuation state.

A.23.26. E23.26 Payment Example

A delivery robot may propose a payment, toll, charging purchase, or service settlement. The payment Candidate Act remains distinct from the motion Candidate Act. Completion of a route segment does not itself authorize arbitrary payment; a protected receipt may instead become one predicate in the payment-specific finality decision.

A.23.27. E23.27 Required Invariants

Invariant 1. Command generation or command acceptance does not necessarily prove physical effect. Invariant 2. A bounded real physical effect is observed using protected evidence where such evidence is required. Invariant 3. Broader actuation remains unavailable until the required preceding physical state is accepted. Invariant 4. Continued actuation stays within the authorized maximum physical envelope. Invariant 5. Sensor disagreement or indeterminate physical state does not automatically authorize broader motion. Invariant 6. Crash recovery avoids blind duplicate physical action where duplication is unsafe. Invariant 7. The enforcement point may be software, firmware, hardware, or distributed.

3 E24 – HARDWARE ACTUATOR, PROTECTED SENSOR CONFIRMATION, AND RECEIPT-DERIVED MOTION AUTHORITY

A.24. E24 — Hardware Actuator, Protected Sensor Confirmation, and Receipt-Derived Motion Authority

A.24.1. E24.1 Purpose

E24 provides a more concrete hardware-rooted embodiment of E23 in which the effectuation chain is enforced at or near the actuator itself. The embodiment is intended to demonstrate technical feasibility in a form where later physical motion can be electrically, cryptographically, logically, or microarchitecturally unavailable until a protected sensor-confirmed receipt from the preceding motion phase has been accepted. A representative architecture is: Application/Agent → PED or Safety Controller → C0act → Actuator Controller → Bounded Motion → Protected Sensor Hub → R0act → Secure Continuation Logic → C1act .

A.24.2. E24.2 Example Hardware Components

A non-limiting implementation may contain:

  • host CPU or application processor;

  • AI accelerator;

  • safety processor or secure MCU;

  • motor-control MCU;

  • power stage;

  • actuator or motor;

  • encoder;

  • current sensor;

  • limit switch;

  • inertial sensor;

  • secure element, TPM, TEE, or HSM;

  • protected NVRAM or monotonic counter;

  • authenticated internal bus; and

  • hardware emergency-stop or safety interlock. Several functions may be integrated into one SoC or distributed among components.

A.24.3. E24.3 Root of Actuation Authority

A protected hardware component may retain a root secret: act KR .

The host application need not possess this secret. A phase-specific actuator authority may be derived as: Kiact = KDF (KR act , DA , ActuatorID, P hasei , act Envelopei , Ni , Epochi , H(Ri−1 )).

For the initial phase, the prior-receipt field may be omitted or replaced by an initialization value.

A.24.4. E24.4 Actuation Capability

A bounded actuation capability may be: Ciact = P rotectKiact (Di , ActuatorID, Envelopei , Expiryi ).

The motor controller accepts a phase command only if the protected capability verifies and the requested act lies within the authorized envelope.

A.24.5. E24.5 Hardware Latch

A protected hardware latch may represent next-phase availability:

i+1 ∈ {0, 1}. Lact

Initially: Lact i+1 = 0.

Only after protected validation of the preceding effect receipt may the secure controller cause:

i+1 ← 1. Lact

While Lact i+1 = 0, the next-phase command is not executable through the protected actuator path.

A.24.6. E24.6 Concrete 90-Degree Example

Assume a requested movement of: Θreq = 90◦ .

The first bounded phase permits: θ0 = 5 ◦ .

The protected encoder measures: θ0obs = 4.98◦ .

Let the permitted tolerance be: ε0 = 0.10◦ .

The observation satisfies: |θ0obs − θ0 | = 0.02◦ ≤ 0.10◦ .

If all other protected predicates are also satisfied, the hardware may generate or accept:

R0act = V ALID

and enable a continuation phase. The remaining authorized trajectory is:

Θrem = 85◦ ,

which may be released in one phase or further partitioned.

A.24.7. E24.7 Progressive Hardware Motion

A progressive sequence may be: 5◦ → 15◦ → 30◦ → 40◦ , for a cumulative total of 90◦ . Each phase has its own:

  • phase identifier;

  • command envelope;

  • nonce;

  • hardware authority;

  • protected sensor observation;

  • receipt; and

  • consumption state.

A.24.8. E24.8 Multiple Measurement Channels

The controller may require both position and electrical measurements. For example:   |θi − θi | ≤ εθ,i , obs cmd

Ii ≤ Ii , obs max   obs Ti ≤ Timax ,

where Iiobs is observed current and Tiobs is observed temperature. A later phase may remain locked if any mandatory channel violates its bound.

A.24.9. E24.9 Sensor-Hub Receipt Generation

A protected sensor hub may generate: Riact = SignKsens (DA , ActuatorID, P hasei , θicmd , θiobs , Iiobs , Tiobs , Counteri , Ni , Statusi ).

The receipt may instead be MACed, attested, threshold-signed, or cryptographically protected by another mechanism.

A.24.10. E24.10 Sensor Authenticity

The system may bind the sensor to the actuator or machine using:

  • device-specific key;

  • secure element identity;

  • authenticated bus address;

  • calibration certificate;

  • measured boot state;

  • hardware attestation;

  • PUF-derived identity;

  • protected pairing state; or

  • equivalent evidence. A valid receipt from an unrelated sensor does not satisfy the actuator’s continuation predicate where device binding is required.

A.24.11. E24.11 Command/Sensor Pairing

A phase receipt may bind both the command digest and the observation digest:

Riact ⊃ H(Commandi ) ∥ H(Observationi ).

This prevents a valid observation from one command from being substituted for another.

A.24.12. E24.12 Counter-Based Anti-Replay

The actuator controller may maintain a monotonic counter:

cact i .

A capability is valid only where its expected counter equals protected local state. After consumption: cact act i+1 = ci + 1.

A replayed phase capability using an old counter is rejected.

A.24.13. E24.13 Receipt Consumption in Hardware

The secure continuation controller may atomically: 1. verify Riact ; 2. verify current phase and counter; 3. mark Riact consumed; 4. advance the protected phase index; act 5. derive or unseal Ki+1 ; and 6. enable the next hardware latch or command envelope. This reduces the possibility that a single successful movement receipt authorizes multiple later movements.

A.24.14. E24.14 Missing-Execution-Material Variation

Instead of exposing a next-phase key, the actuator may require missing execution material retained entirely inside protected hardware. Examples include:

  • PWM enable mask;

  • motor-driver gate state;

  • command authenticator;

  • secure DMA descriptor;

  • protected bus authorization;

  • key share;

  • encrypted microcode block;

  • register unlock value; or

  • secure-monitor transition. The missing material becomes available only after validated receipt state.

A.24.15. E24.15 Secure Boot and Measured Controller State

The actuator controller or sensor hub may require an approved software/firmware measurement before participating in receipt generation or next-phase authority derivation. A phase capability may therefore bind: M easurementctrl and/or: M easurementsensor .

If the measured state changes unexpectedly, later phases may be denied or require reattestation.

A.24.16. E24.16 Power-Stage Enforcement

In one variation, final enforcement occurs below the ordinary motor-control software at the power-stage enable path. A protected gate controls whether the driver may energize the actuator beyond the current phase envelope. Thus compromise of higher-level application software does not by itself create full physical authority.

A.24.17. E24.17 Bus-Level Enforcement

A secure CAN, SPI, I2C, Ethernet, industrial fieldbus, PCIe, or proprietary bus controller may mediate phase-specific commands. The bus enforcement component may reject:

  • commands lacking a valid phase authenticator;

  • commands for the wrong actuator;

  • commands exceeding the phase envelope;

  • stale counters;

  • wrong policy epochs; or

  • commands that skip mandatory phases.

A.24.18. E24.18 Human Approval in the Hardware Chain

For sensitive phases, a human approval artifact may become an input to hardware continuation authority: act act Ki+1 = KDF (KR , DA , H(Riact ), H(Ahuman i ), i + 1).

The secure controller need not trust an ordinary UI assertion that approval occurred; it can require a protected approval artifact or equivalent authenticated state.

A.24.19. E24.19 Automatic Hardware Continuation

For approved autonomous operation, the secure controller may automatically derive the next phase where:

V alid(Riact ) ∧ InT olerancei ∧ Saf etyP assi ∧ P olicyV alidi ⇒ HardwareContinuei .

No human is required where protected policy permits automatic continuation.

A.24.20. E24.20 Hybrid Hardware Continuation

A higher-assurance implementation may require both protected automatic checks and human approval: V alid(Riact ) ∧ Saf etyP assi ∧ HumanApprovali ⇒ HardwareContinuei .

A.24.21. E24.21 Sensor Failure

If the required sensor is unavailable, stale, unauthenticated, or inconsistent, the architecture may:

  • hold the current phase;

  • reduce the permitted envelope;

  • use an approved redundant sensor set;

  • request protected human review;

  • move to a safe state; or

  • deny further effectuation. Absence of mandatory observation does not automatically count as successful effectuation.

A.24.22. E24.22 Mechanical Backlash and Tolerance Modeling

The permitted comparison need not require exact equality where physical systems exhibit backlash, compliance, delay, or sensor noise. Protected policy may specify:

εi = f (ActuatorClass, Loadi , V elocityi , Calibrationi , Saf etyClass).

The tolerance function is protected policy rather than an unrestricted value supplied by the proposing agent.

A.24.23. E24.23 Time-Bounded Physical Confirmation

A receipt may be valid only if the observation is obtained within a protected time window:

0 ≤ Tireceipt − Ticommand ≤ ∆tmax,i .

A stale position reading must not be reused as confirmation of a new command.

A.24.24. E24.24 Power Loss During Phase

Protected NVRAM, monotonic counters, controller logs, or actuator position sensing may permit reconciliation after power loss. Possible states include:

  • phase proven not started;

  • phase started but incomplete;

  • phase completed and receipt recoverable;

  • physical state measurable but cryptographic state incomplete; or

  • still indeterminate. The recovery workflow avoids assuming that power loss implies no physical motion occurred.

A.24.25. E24.25 Alternate Hardware Path Closure

The protected architecture may control or disable:

  • debug headers;

  • vendor maintenance ports;

  • direct motor-driver registers;

  • unprotected PWM paths;

  • bootloader commands;

  • raw fieldbus frames;

  • secondary control CPUs;

  • alternate wireless control paths;

  • factory test mode; or

  • direct power-stage enable lines. Where a path can create an equivalent broader physical effect, it is treated as an effect-capable path for finality purposes.

A.24.26. E24.26 Multi-Actuator Coordination

For coordinated machines, phase i may involve a set of actuators:

Ai = {a1 , a2 , . . . , ak }.

Continuation may require every mandatory actuator to report acceptable state: ∧ act Accept(Ri,a ) = T RU E. a∈Ai

Alternatively, protected policy may permit threshold or role-specific completion.

A.24.27. E24.27 Independent Safety Controller

A separate safety controller may retain veto authority over every phase even after receiptderived continuation authority exists.

Therefore: ContinuationAuthorityi = T RU E ̸⇒ Actuationi = T RU E where a mandatory safety interlock remains false. This preserves the distinction between staged continuation authority and independent safety interlocks.

A.24.28. E24.28 SEND Example

A robotic system that captures a sensor image may stage physical and communication effects independently. A verified actuator position may authorize image capture, while SEND of the image may still require recipient-bound trailer/receipt control before full communication. Thus the physical receipt does not automatically substitute for a communication receipt.

A.24.29. E24.29 Payment Example

A machine may consume power, charging service, toll access, or a physical commodity. A sensorconfirmed physical event may become one protected input to a payment Candidate Act, but the payment remains separately gated by its own destination, amount, credential, and receipt conditions.

A.24.30. E24.30 Required Invariants

Invariant 1. The later physical phase may be technically unavailable at hardware level until protected receipt validation. Invariant 2. Phase authority is bound to the intended actuator, command envelope, and protected phase state. Invariant 3. Protected sensor evidence corresponds to the commanded physical phase rather than merely an unrelated device reading. Invariant 4. Replay, stale receipt, stale command, and phase skipping are rejected where required. Invariant 5. Failure or loss of mandatory sensor evidence prevents unauthorized progression. Invariant 6. Hardware crash or power loss is reconciled against actual physical and protected state rather than presumed safe by default. Invariant 7. Human approval, automatic approval, or hybrid approval may be incorporated without giving the proposing agent authority to forge the approval state. Invariant 8. Alternate hardware paths capable of equivalent actuation are controlled where non-bypassability is required.

4 FROZEN RELATIONSHIP BETWEEN E22, E23 AND E24 E22, E23, and E24 apply the same staged-effectuation principle to progressively more physical enforcement boundaries.

Provisional Real Storage → Ristore → Promotion/Visibility Authority.

Bounded Physical Effect → Riphys → Broader Physical Authority.

Hardware-Bounded Motion → Riact → Receipt-Derived Hardware Continuation.

The common invariant remains that a computational proposal or initial approval does not necessarily constitute unconditional authority to complete the full consequential act.

A.25. E25 — Receipt-Gated Vehicle Effectuation and Progressive Vehicular Authority

A.25.1. E25.1 Purpose

E25 applies the staged-effectuation architecture to a vehicle whose computational system, autonomous controller, driver-assistance system, remote operator, route planner, fleet controller, or other source proposes an act capable of causing a physical vehicular consequence. The Candidate Act may concern propulsion, braking, steering, gear state, route movement, parking, lane movement, docking, charging connection, door state, cargo handling, or another vehicle operation. The embodiment separates at least three technical events: 1. generation or selection of a proposed vehicle act; 2. protected authorization of a bounded or complete vehicular effect; and 3. actual effectuation through an effect-capable vehicle boundary. A vehicle planner therefore does not obtain unconditional authority merely by producing a trajectory, command, or route. A representative staged relationship is:

V ehicle Candidate Act → Bounded V ehicle Effect → P rotected V ehicle Receipt → Continuation Authority → Broader V ehicle Effect

A.25.2. E25.2 Candidate Vehicle Acts

A Candidate Act may include, without limitation:

  • accelerate to a requested speed;

  • decelerate or brake;

  • steer to a requested heading;

  • change lane;

  • enter or leave a road segment;

  • move from one parking location to another;

  • reverse;

  • perform a parking maneuver;

  • begin a trip;

  • continue through a route segment;

  • cross a defined boundary;

  • dock at a station;

  • couple or uncouple a trailer or equipment module;

  • open or close an externally consequential vehicle mechanism;

  • activate a powered loading system;

  • enable autonomous movement;

  • transfer control between automated and human control modes. The Candidate Act may be generated by an AI model, deterministic planner, optimization engine, human interface, remote operator, fleet-management system, or combination thereof.

A.25.3. E25.3 Vehicle Act Binding

The protected system may bind the vehicle act to a canonical representation or other deterministic act representation. A protected vehicle act descriptor may identify:

  • vehicle identity;

  • current protected vehicle state;

  • origin;

  • destination;

  • route segment;

  • requested path;

  • permitted speed range;

  • permitted acceleration range;

  • permitted steering range;

  • maximum distance;

  • maximum duration;

  • propulsion mode;

  • braking mode;

  • environmental constraints;

  • passenger or cargo constraint;

  • operator identity;

  • policy epoch;

  • revocation state;

  • and the intended Finality Sink or equivalent vehicle effectuation boundary.

The protected system may form:

DV = H(Canon(AV )) where AV denotes the Candidate Vehicle Act. The precise canonicalization mechanism is not mandatory. The required property is that later vehicle authority remains associated with the authorized act or authorized act envelope.

A.25.4. E25.4 Maximum Vehicle Effectuation Envelope

Before movement, protected policy may establish a maximum permitted vehicle-effectuation envelope. Let:

VMAX represent the maximum authorized vehicle-effect envelope. The envelope may constrain one or more of:

  • geographical region;

  • road or lane;

  • maximum speed;

  • maximum acceleration;

  • maximum deceleration;

  • maximum steering angle;

  • maximum travel distance;

  • maximum travel duration;

  • destination;

  • route family;

  • number of maneuvers;

  • energy or propulsion expenditure;

  • passenger or cargo condition;

  • actuation mode;

  • or another physical or operational dimension. Receipt success must not, by itself, authorize a vehicle act outside VMAX .

A.25.5. E25.5 Protected Vehicle State

The PED may obtain protected vehicle state from one or more trusted or protected sources. State may include:

  • wheel speed;

  • vehicle speed;

  • steering angle;

  • brake state;

  • propulsion state;

  • gear state;

  • battery or fuel state;

  • localization state;

  • inertial state;

  • route position;

  • obstacle state;

  • tire or traction state;

  • door or restraint state;

  • controller health;

  • sensor health;

  • actuator health;

  • policy state;

  • secure-boot or firmware measurement;

  • human-control state;

  • remote-control state;

  • network state;

  • and prior phase-receipt state. The proposing computational component need not be permitted to rewrite this protected state.

A.25.6. E25.6 Vehicle State Vector

For mathematical description, a protected vehicle state may be represented as:

T xi = [ pi vi ai ψi ψi̇ δi βi ] where components may represent position, velocity, acceleration, heading, yaw rate, steering state, braking or another implementation-specific physical state. No particular state vector is mandatory.

A.25.7. E25.7 Protected Safe-State Set

Protected policy may define an acceptable state set:

ΩV A continuation predicate may require:

xi ∈ Ω V

after completion of a bounded vehicle phase. The safe-state set may be fixed or dynamic. For example, the acceptable state after a bounded maneuver may depend upon current route, permitted speed, obstacle state, road geometry, vehicle condition, or operator instruction.

A.25.8. E25.8 Phase-0 Vehicle Demonstration

Where staged vehicle effectuation is selected, Phase 0 may cause a real but bounded vehicle effect. Examples include:

  • move two metres at limited speed;

  • release the brake and move only within a defined parking envelope;

  • apply a bounded steering movement;

  • perform a low-speed lane-centering correction;

  • execute one short route segment;

  • perform one braking pulse within a protected test envelope;

  • engage propulsion only up to a bounded torque or speed;

  • move from a dock position to a protected staging position. The Phase-0 effect is a real physical consequence and is not merely a simulated trajectory.

A.25.9. E25.9 Example Bounded Vehicle Phase

A requested movement may be:

Distancerequested = 500 m Protected policy may first authorize:

Distance0 = 2 m with:

Speed0 ≤ 5 km/h The real two-metre movement occurs through the protected vehicle effectuation boundary. A protected observer then confirms the actual result before broader movement authority is made available.

A.25.10. E25.10 Vehicle Finality Sink

The vehicle Finality Sink or equivalent effectuation-control component may reside at or control:

  • propulsion controller;

  • brake controller;

  • steering controller;

  • drive-by-wire controller;

  • powertrain controller;

  • transmission controller;

  • body controller;

  • secure gateway;

  • vehicle control unit;

  • domain controller;

  • zonal controller;

  • safety controller;

  • motor inverter;

  • actuator control module;

  • or another component without which the physical vehicle effect cannot validly occur. The sink may be software-enforced, hardware-enforced, or jointly enforced.

A.25.11. E25.11 Vehicle Effect Observation

The result of a bounded vehicle act may be observed using one or more protected sources such as:

  • wheel encoder;

  • inertial measurement unit;

  • steering sensor;

  • brake-pressure sensor;

  • propulsion controller;

  • secure odometry;

  • protected localization component;

  • hardware counter;

  • vehicle control unit;

  • protected sensor fusion;

  • remote trusted observer;

  • or another effect-relevant state source. The observer should preferably be sufficiently independent from the proposing planner that the planner cannot merely assert that the maneuver succeeded.

A.25.12. E25.12 Vehicle Effect Receipt

After a bounded vehicle effect, the protected observer or sink may generate a vehicle-effect receipt.

Let:

RiV represent the receipt for vehicle phase i. It may bind:

  • DV ;

  • phase identifier;

  • authorized movement envelope;

  • actual observed state;

  • start state;

  • end state;

  • distance;

  • speed range;

  • steering or braking result;

  • vehicle identity;

  • sink identity;

  • sensor identity;

  • nonce;

  • timestamp or protected time state;

  • policy epoch;

  • status;

  • prior receipt commitment;

  • and next-stage eligibility evidence. The receipt may be signed, MACed, attested, hash-linked, stored in protected state, or otherwise authenticated.

A.25.13. E25.13 Vehicle Continuation Predicate

A general continuation rule may be:

V Enable(Pi+1 ) = V alid(RiV ) ∧ M atchAct(RiV , DV ) V ∧ W ithinV ehicleEnvelope(Pi+1 ) ∧ StateAcceptable(xi ) ∧ P olicyCurrent ∧ RevocationClear ∧ ApprovalSatisfiedi+1 . Where a required term is false or indeterminate, broader vehicle authority remains unavailable.

A.25.14. E25.14 Automatic Vehicle Continuation

Protected policy may automatically release the next phase if required receipt, state, and risk conditions are acceptable. This can support low-latency operation where repeated human approval would be impractical. For example:

V alid(RiV ) ∧ xi ∈ ΩV ∧ RiskAcceptablei ⇒ Enable(Pi+1 V ) The vehicle planner itself need not have authority to mark these conditions as satisfied.

A.25.15. E25.15 Human Vehicle Continuation

A protected human approval surface may present:

  • requested maneuver;

  • real bounded movement already performed;

  • observed final state;

  • current vehicle position;

  • requested next movement;

  • route or destination;

  • current risk indication;

  • receipt status;

  • and consequence of continuing. A driver, passenger, remote operator, fleet supervisor, or other authorized human may approve, deny, restrict, delay, or terminate continuation.

A.25.16. E25.16 Hybrid Vehicle Continuation

A higher-assurance rule may require both automatic protected conditions and protected human authorization. For example:

V alid(RiV ) ∧ V ehicleP olicyP assi ∧ HumanApprovali ⇒ Enable(Pi+1 V ) A threshold or role-separated approval model may also be used.

A.25.17. E25.17 Progressive Route Segmentation

A route may be divided into protected segments:

R = {Seg0 , Seg1 , ... , Segn } Each completed segment may produce a protected receipt. The next segment remains unavailable until the required prior receipt and current protected state are accepted. The segments need not be equal in length. Phase size may adapt to vehicle speed, traffic conditions, localization confidence, route certainty, obstacle state, policy, or other protected criteria.

A.25.18. E25.18 Progressive Speed Envelope

Vehicle authority may expand by speed rather than distance. Example:

5 km/h → 15 km/h → 30 km/h → AuthorizedM aximum Receipt failure at a lower speed can prevent release of a higher speed envelope.

A.25.19. E25.19 Progressive Steering Envelope

The system may constrain steering effectuation by maximum permitted steering angle or curvature. For example:

|δi | ≤ δmax,i

where δmax,i may increase only after accepted protected evidence.

A.25.20. E25.20 Braking and Emergency-State Variation

A safety-critical braking path may be treated differently from ordinary progressive authority. Protected policy may allow an immediate emergency reduction of consequence even when ordinary forward progression is blocked. Thus a fail-closed continuation rule need not prevent a fail-safe or fail-limited emergency action whose purpose is to reduce physical hazard. Such emergency authority may itself be narrowly scoped to braking, power reduction, safe-stop movement, or another hazard-reduction operation.

A.25.21. E25.21 Transfer of Control

A Candidate Act may request transfer between:

  • autonomous control;

  • assisted control;

  • human control;

  • remote operator control;

  • protected safe-state controller. The transfer itself may be receipt-gated. For example, a vehicle may not grant higher-speed autonomous authority until protected state confirms that the intended control domain is active and the previous controller has relinquished conflicting authority.

A.25.22. E25.22 Vehicle Credential Separation

The planning component may possess no reusable credential capable of directly driving vehicle actuators. Instead, a protected controller may expose only phase-bounded authority. The protected authority may be:

  • one-time command authenticator;

  • short-lived capability;

  • hardware key share;

  • protected register state;

  • phase-bound MAC key;

  • signed control envelope;

  • secure gateway permit;

  • or another non-bearer technical condition.

A.25.23. E25.23 Hardware-Rooted Vehicle Variation

A hardware-rooted implementation may place protected keys and phase state in:

  • secure processor;

  • safety MCU;

  • TEE;

  • HSM;

  • secure element;

  • vehicle security controller;

  • protected gateway;

  • actuator controller;

  • or dedicated hardware security block. A downstream controller may accept a propulsion, braking, or steering command only if the hardware-derived phase authority is valid.

A.25.24. E25.24 Vehicle Phase Key

A vehicle phase key may be derived as:

V V Ki+1 = KDF (KR , DV , H(RiV ), i + 1, V ehicleID) The exact KDF is non-limiting. The protected property is that later vehicle authority can be made cryptographically dependent upon accepted earlier real-effect evidence.

A.25.25. E25.25 Multi-Controller Vehicle Variation

Different vehicle effects may use different finality sinks. For example:

  • propulsion sink;

  • braking sink;

  • steering sink;

  • cargo-actuation sink. A composite maneuver may require coordinated protected receipts from multiple controllers. A broader phase may require all mandatory subsystem receipts or an implementation-specific protected quorum.

A.25.26. E25.26 Fleet Variation

A fleet controller may authorize a bounded effect on one vehicle before authorizing the same class of act across a fleet. Example:

1 vehicle → 10 vehicles → 100 vehicles → AuthorizedF leet Each expansion may be conditioned on protected receipts from prior vehicles or cohorts. This can be combined with E17 cloud-rollout logic while preserving vehicle-local effectuation control.

A.25.27. E25.27 Parking and Docking Variation

A parking or docking act may be progressively released by distance, speed, spatial zone, steering envelope, or proximity to the final target. The first real effect may move the vehicle only into a protected staging region. Receipt-confirmed localization and actuator state may then permit the final parking, charging, coupling, or docking movement.

A.25.28. E25.28 Dynamic Environment Change

A successful earlier receipt does not freeze the environment. Before each later phase, the PED may revalidate current state. If a new obstacle, route restriction, revocation, operator instruction, or protected risk state arises, the next phase may be reduced, delayed, redirected, or denied. Thus:

V alid(RiV ) ⇏ U nconditionalContinuation

A.25.29. E25.29 Indeterminate Vehicle Effect

If protected state cannot determine whether a vehicle phase occurred as intended:

Status(RiV ) = IN DET ERM IN AT E broader authority remains blocked. The system may reconcile using protected odometry, actuator counters, control-unit state, sensor history, secure logs, or another protected state source.

A.25.30. E25.30 Loss of Communication

Loss of cloud, network, remote operator, or fleet connectivity need not create unrestricted local authority. Protected policy may transition the vehicle to:

  • safe stop;

  • limited-speed mode;

  • bounded local navigation;

  • return-to-safe location;

  • human-only control;

  • or another fail-limited state. The exact response depends on implementation and hazard model.

A.25.31. E25.31 Anti-Bypass

Equivalent vehicle effect paths may include:

  • direct CAN command;

  • automotive Ethernet control path;

  • diagnostic interface;

  • maintenance interface;

  • engineering mode;

  • alternate ECU;

  • raw actuator command;

  • service tool;

  • recovery firmware;

  • remote-management path;

  • privileged application;

  • or physical control gateway. Where non-bypassability is required, equivalent effect-capable paths are disabled, mediated, cryptographically restricted, hardware gated, or subjected to corresponding protected finality checks.

A.25.32. E25.32 Vehicle Crash / Restart Recovery

If the protected controller restarts after a physical movement, it must not assume that the last command failed merely because the receipt was not delivered. The recovery process may compare:

  • last accepted phase identifier;

  • hardware counter;

  • actual vehicle state;

  • idempotency identifier;

  • actuator state;

  • secure journal;

  • and pending continuation state. Only after reconciliation may a retry or next phase be authorized.

A.25.33. E25.33 Required Invariants

The frozen core of E25 includes: 1. the vehicle planner or Candidate Act Source is distinguishable from the protected physical effectuation authority; 2. the vehicle effect is constrained by an authorized envelope; 3. where staged operation is selected, at least one bounded real vehicle effect precedes broader authority; 4. protected evidence of the prior physical state transition is evaluated before required broader continuation; 5. prior success does not expand authority beyond the authorized maximum; 6. failure or indeterminate state prevents unauthorized broader physical progression; 7. emergency hazard-reduction authority may be separately and narrowly defined; 8. software, hardware, or combined enforcement may be used; 9. equivalent alternate actuator paths are correspondingly controlled where necessary for nonbypassability.

ATION

A.26. E26 — Receipt-Gated UAV and Mobile-Robot Effectuation

A.26.1. E26.1 Purpose

E26 applies receipt-gated progressive effectuation to unmanned aerial vehicles, drones, autonomous ground vehicles, warehouse robots, delivery robots, inspection robots, mobile manipulators, and other mobile machines whose software can cause movement through a physical environment. The embodiment is especially useful where a planner or AI system may generate a complete mission, while protected authority is released only in bounded stages. Representative flow:

M ission P roposal → Bounded M obility P hase → P rotected M obility Receipt → N ext M obility Authority → Broader M ission Effect

A.26.2. E26.2 Candidate Mobility Acts

Candidate Acts may include:

  • takeoff;

  • hover;

  • climb;

  • descend;

  • yaw;

  • translate;

  • travel to waypoint;

  • traverse corridor;

  • enter zone;

  • leave zone;

  • land;

  • dock;

  • return to base;

  • pick up or deliver an object;

  • activate mobile manipulation;

  • follow a target;

  • inspect a structure;

  • perform one segment of a delivery or survey mission.

A.26.3. E26.3 Mission Envelope

A protected mission envelope may define:

MMAX which may constrain:

  • allowed geographic region;

  • altitude range;

  • speed range;

  • route or corridor;

  • distance;

  • duration;

  • energy expenditure;

  • permitted payload operation;

  • allowed landing zones;

  • communications state;

  • human-supervision requirement;

  • sensor-health requirement;

  • and mission termination conditions.

No successful receipt may validly enlarge the mission beyond MMAX absent a new protected authorization.

A.26.4. E26.4 Mobility Phase Plan

The mission may be represented as:

W = {W0 , W1 , ... , Wn } where each Wi may be a waypoint, corridor, mobility segment, protected zone transition, or another bounded movement phase. A phase need not correspond to a single geographic waypoint. It may instead be defined by altitude, time, energy, speed, task completion, or another effect dimension.

A.26.5. E26.5 UAV Initial Demonstration

A UAV may first perform a real but bounded effect such as:

  • arm propulsion without takeoff;

  • raise thrust within a bounded range;

  • take off to a low protected altitude;

  • hover for a short interval;

  • move a short horizontal distance;

  • rotate within a bounded yaw range;

  • reach a protected staging waypoint. A protected observer verifies the result before broader flight authority is released.

A.26.6. E26.6 Example UAV Sequence

A planned mission may require travel to a remote destination. Protected phases may be:

T akeoff to 2m → R0 → Hover 5s → R1 → W aypoint 1 → R2 → W aypoint 2 → ⋯ The receipts may be required prerequisites for subsequent propulsion or navigation authority.

A.26.7. E26.7 Mobile Ground Robot Sequence

A warehouse or delivery robot may progress as:

0.5m → R0 → 5m → R1 → Corridor A → R2 → Destination The phase boundaries may be chosen according to route risk, human proximity, localization confidence, obstacle density, or policy.

A.26.8. E26.8 Protected Mobility Controller

Protected effectuation authority may reside in or be enforced by:

  • flight controller;

  • autopilot;

  • safety controller;

  • motor controller;

  • propulsion ESC;

  • protected navigation controller;

  • secure gateway;

  • robotics safety MCU;

  • drive controller;

  • wheel controller;

  • motor inverter;

  • secure element;

  • TEE;

  • HSM;

  • or another effect-capable protected component.

A.26.9. E26.9 Protected Mobility Observation

Protected observations may include:

  • inertial state;

  • altitude;

  • position;

  • speed;

  • heading;

  • motor state;

  • rotor state;

  • wheel state;

  • battery state;

  • localization confidence;

  • obstacle state;

  • controller health;

  • sensor health;

  • geofence state;

  • link state;

  • payload state;

  • landing state;

  • or another mobility-relevant condition.

A.26.10. E26.10 Mobility State Vector

An implementation may represent mobility state as:

T zi = [pi vi qi ωi hi ei ] where the components may represent position, velocity, orientation, angular rate, altitude, energy state, or other physical variables. The precise state representation is non-limiting.

A.26.11. E26.11 Protected Mobility Receipt

Let:

RiM represent the receipt for mobility phase i. It may bind:

  • mission digest;

  • phase or waypoint identifier;

  • permitted mobility envelope;

  • actual observed position or state;

  • route segment;

  • altitude;

  • speed;

  • duration;

  • propulsion or wheel state;

  • energy state;

  • sink identity;

  • observer identity;

  • nonce;

  • policy epoch;

  • status;

  • prior receipt commitment;

  • and current geofence or protected-zone state.

A.26.12. E26.12 Geofence / Zone Constraint

Protected policy may define a permitted mobility region:

Γi Continuation may require:

pi ∈ Γ i

and a proposed next phase may be rejected if its predicted or commanded envelope lies outside the authorized region. The geofence or zone may change dynamically.

A.26.13. E26.13 Altitude-Bounded Progression

A UAV may receive progressively larger altitude authority. For example:

2m → 10m → 30m → AuthorizedAltitudeM aximum Each increase may require an accepted protected receipt from the previous phase.

A.26.14. E26.14 Distance-Bounded Progression

A mobile robot may receive distance authority in increments:

1m → 10m → 50m → M issionSegment The next increment may be reduced rather than enlarged if protected risk increases.

A.26.15. E26.15 Energy-Bounded Progression

Authority may also be bounded by energy expenditure. Let:

Eimob represent permitted energy for phase i. Protected policy may enforce:

Eimob ≤ EMAX mob

and may require a valid prior receipt before a larger energy envelope is released.

A.26.16. E26.16 Payload-Operation Separation

Mobility authority need not automatically authorize payload effectuation. A UAV may be permitted to fly to a location while a separate protected authority governs:

  • release of payload;

  • camera activation;

  • data transmission;

  • robotic-arm use;

  • spraying;

  • sampling;

  • package drop;

  • or another payload consequence.

Thus:

F lightAuthority ⇏ P ayloadAuthority unless protected policy expressly binds them.

A.26.17. E26.17 Takeoff Versus Mission Authority

A protected architecture may distinguish:

Authorityarm ≠ Authoritytakeoff ≠ Authoritymission A successful propulsion-arm state need not authorize takeoff, and successful takeoff need not authorize the complete mission.

A.26.18. E26.18 Landing Authority

Landing may itself be treated as a protected physical effect. The system may require protected evidence of:

  • landing-zone identity;

  • permitted location;

  • altitude;

  • descent profile;

  • obstacle condition;

  • and sink state before releasing final descent or touchdown authority.

A.26.19. E26.19 Human Approval Variation

A protected human may authorize:

  • complete mission envelope at the start;

  • each waypoint or route segment;

  • takeoff only;

  • entry into sensitive zones;

  • payload operation;

  • final delivery;

  • or emergency continuation. The protected approval surface may display verified evidence from completed phases rather than relying only on the planner’s prediction.

A.26.20. E26.20 Automatic Continuation

Autonomous continuation may occur where protected receipts and current state satisfy policy. For example:

Enable(Wi+1 ) = V alid(RiM ) ∧ P ositionAcceptablei ∧ SensorHealthi ∧ EnergySufficienti ∧ W ithinM issionEnvelope(Wi+1 ) ∧ N otRevokedi .

A.26.21. E26.21 Hybrid Continuation

A hybrid policy may automatically advance ordinary phases but require protected human approval for:

  • entering a designated zone;

  • crossing a distance threshold;

  • raising altitude above a threshold;

  • activating payload;

  • approaching humans or critical infrastructure;

  • or releasing final delivery.

A.26.22. E26.22 GNSS / Localization Uncertainty Variation

If localization becomes uncertain, prior success does not imply continued authority. Protected policy may reduce the next phase, hold position, land, stop, return, or require another localization source. The architecture can distinguish:

U N KN OW N ≠ SAF E and may refuse broader progression while localization state is unresolved.

A.26.23. E26.23 Sensor Disagreement

Where multiple sensors disagree, the mobility receipt may become indeterminate rather than selecting an optimistic interpretation. Protected logic may require:

  • sensor quorum;

  • confidence threshold;

  • protected fusion result;

  • human review;

  • reduced mobility envelope;

  • or safe termination.

A.26.24. E26.24 Protected Sensor Quorum

If n protected observers produce mobility evidence, continuation may require:

n ∑ V alid(RiM,j ) ≥ m j=1

with additional role constraints where necessary. This is a mobility-specific use of the already disclosed quorum principle.

A UAV or mobile robot may lose communication with a cloud service, operator, or network. The absence of communication need not release unrestricted autonomous authority. Protected policy may transition to:

  • hold;

  • hover;

  • land;

  • stop;

  • return-to-base;

  • bounded local navigation;

  • or another predefined fail-limited behavior.

A.26.26. E26.26 Energy Depletion

If battery or energy state falls below a protected threshold, planned mission continuation may be denied even if the previous receipt was valid. The system may prioritize a protected recovery or safe-state maneuver. Thus receipt validity is necessary but not always sufficient for continuation.

A.26.27. E26.27 Crash After Movement

If a controller crashes after the robot moved but before the receipt was propagated, the architecture may reconcile actual state using:

  • flight controller log;

  • motor counter;

  • odometry;

  • protected position history;

  • secure journal;

  • actuator state;

  • or another protected source. Blind replay of a consequential mobility phase is avoided where it could duplicate movement.

A.26.28. E26.28 Swarm / Multi-Robot Variation

A protected controller may authorize one unit or small subset before expanding to a larger group. For example:

1 robot → 5 robots → 25 robots → AuthorizedGroup The broader group phase may depend upon protected receipts from the earlier subset. Different robots may produce independent receipts, an aggregate receipt, or a quorum result.

A.26.29. E26.29 Cooperative Mobility

Where two or more robots must coordinate, the next phase may require receipt evidence that required peers reached compatible states. For example, a protected convoy may require that all mandatory members reach a staging point before the next movement phase is enabled.

A.26.30. E26.30 Mobile Manipulator Variation

A mobile robot may separate mobility authority from manipulator authority. Example: 1. move to staging location; 2. verify protected mobility receipt; 3. authorize bounded arm motion; 4. verify protected arm-effect receipt; 5. authorize grasp, placement, or broader task. This prevents successful navigation from automatically granting unrestricted manipulation authority.

A.26.31. E26.31 Anti-Bypass

Equivalent mobility-effect paths may include:

  • raw motor interface;

  • flight-control debug interface;

  • maintenance channel;

  • alternate navigation controller;

  • direct motor command;

  • service port;

  • recovery mode;

  • remote-control channel;

  • hardware bus;

  • or privileged operating-system path. Where the staged architecture is intended to be non-bypassable, those paths are correspondingly mediated or restricted.

A.26.32. E26.32 Required Invariants

The frozen core of E26 includes: 1. mission generation is not itself unconditional mobility authority; 2. the mission remains bounded by a protected maximum envelope; 3. where staged operation is selected, real bounded mobility produces protected evidence before required broader progression; 4. position, motion, sensor, energy, policy, or other current protected state may be revalidated at every phase; 5. successful flight or movement does not automatically authorize payload effectuation; 6. uncertain location or indeterminate physical outcome does not become implicit authorization; 7. fail-limited recovery behavior may be separately authorized; 8. alternate propulsion or mobility paths are controlled where needed for non-bypassability.

PROCESS-CONTROL EFFECTUATION

A.27. E27 — Receipt-Gated Industrial, PLC, Machine, and Process-Control Effectuation

A.27.1. E27.1 Purpose

E27 applies the receipt-gated effectuation architecture to industrial control systems, programmable logic controllers, manufacturing systems, process plants, machine tools, energy systems, material-handling equipment, industrial robots, pumps, valves, drives, and other operational technology capable of causing consequential physical or process-state changes. The architecture separates a supervisory computation, AI optimizer, scheduling engine, engineering workstation, human-machine interface, or other Candidate Act Source from the protected authority required to make an industrial act effective. Representative relationship:

Industrial Candidate Act → Bounded P rocess Effect → P rotected P rocess Receipt → N ext P rocess Authority → Broader Industrial Effect

A.27.2. E27.2 Candidate Industrial Acts

Candidate Acts may include:

  • start or stop machine;

  • open or close valve;

  • change pump speed;

  • change motor speed or torque;

  • energize or de-energize circuit;

  • change setpoint;

  • change temperature or pressure target;

  • initiate production cycle;

  • modify batch quantity;

  • activate conveyor;

  • move industrial robot;

  • commit CNC operation;

  • release material;

  • change flow rate;

  • change process recipe;

  • switch source or destination;

  • alter power-distribution state;

  • change controller mode;

  • or another machine/process consequence.

A.27.3. E27.3 Industrial Effectuation Envelope

Protected policy may define:

IMAX as the maximum authorized industrial-effect envelope. It may constrain:

  • machine identity;

  • production line;

  • process unit;

  • batch size;

  • quantity;

  • setpoint range;

  • pressure range;

  • temperature range;

  • flow range;

  • speed;

  • torque;

  • electrical power;

  • duration;

  • number of cycles;

  • spatial zone;

  • material identity;

  • recipe;

  • operator role;

  • or another operational parameter. A series of successful receipts must not silently enlarge authority beyond IMAX .

A.27.4. E27.4 Protected Industrial Enforcement Domain

The PED may reside in or include:

  • safety PLC;

  • standard PLC with protected partition;

  • industrial controller;

  • secure gateway;

  • process-control server;

  • drive controller;

  • robot controller;

  • machine controller;

  • distributed-control-system component;

  • field gateway;

  • secure remote I/O;

  • HSM;

  • TEE;

  • secure MCU;

  • FPGA;

  • ASIC;

  • protected industrial computer;

  • or another protected control component. The architecture does not require a single physical PED.

A.27.5. E27.5 Process State Acquisition

Protected state may include:

  • machine mode;

  • interlock state;

  • emergency-stop state;

  • pressure;

  • temperature;

  • flow;

  • vibration;

  • speed;

  • torque;

  • current;

  • voltage;

  • position;

  • material level;

  • valve position;

  • sensor health;

  • actuator health;

  • controller state;

  • recipe state;

  • batch state;

  • maintenance state;

  • operator state;

  • network state;

  • policy epoch;

  • and prior phase state.

A.27.6. E27.6 Bounded Industrial Trial

A staged industrial operation may first permit a real but limited effect. Examples include:

  • run one machine cycle before a full batch;

  • open a valve five percent before wider opening;

  • energize one protected subsystem before the full line;

  • move an industrial robot through a short protected trajectory;

  • process one workpiece before a larger production run;

  • change a setpoint by a small bounded increment;

  • activate one conveyor section before the complete line;

  • execute one CNC feature before the remaining operation;

  • enable one server-room cooling unit before a coordinated cooling change;

  • switch one low-consequence load before a larger power-distribution change.

A.27.7. E27.7 Example Valve Sequence

Requested valve position:

100% Phase 0 may authorize:

5% A protected position sensor and process observer confirm actual state. If the observed process remains within the permitted range, later authority may permit:

20% → 50% → 100% or another protected progression.

A.27.8. E27.8 Example Machine-Cycle Sequence

A requested production run may comprise 10,000 items. Protected progression may be:

1 item → R0 → 10 items → R1 → 100 items → R2 → AuthorizedRun The phase size may increase only after protected process receipts are accepted.

A.27.9. E27.9 Industrial Process State Vector

An implementation may represent protected process state as:

T yi = [Ti Pi Fi Vi Ii ωi qi ] where the components may represent temperature, pressure, flow, voltage, current, rotational speed, quality state, or another implementation-specific process variable. The notation is illustrative and non-limiting.

A.27.10. E27.10 Protected Operating Region

Protected policy may define an acceptable operating region:

ΩI Continuation may require:

yi ∈ Ω I

after the bounded effect. The operating region may be static or dynamically determined from current process state, machine mode, material type, recipe, safety state, or another protected input.

A.27.11. E27.11 Process Effect Receipt

Let:

RiI represent the protected receipt for industrial phase i. It may bind:

  • Candidate Act digest;

  • machine or process identity;

  • phase identifier;

  • authorized process envelope;

  • actual observed state;

  • sensor evidence;

  • actuator evidence;

  • controller identity;

  • material or batch identity;

  • recipe state;

  • nonce;

  • protected time;

  • policy epoch;

  • prior receipt commitment;

  • status;

  • and next-phase eligibility evidence.

A.27.12. E27.12 Process Receipt Status

A process receipt may indicate:

  • SUCCESS;

  • FAILURE;

  • REJECTED;

  • PARTIAL;

  • ROLLED_BACK;

  • COMPENSATED;

  • INDETERMINATE;

  • SAFE_STOP;

  • or another protected status. The receipt need not assert that the overall business objective succeeded. It may confirm a narrower physical or control-system fact.

A.27.13. E27.13 Automatic Industrial Continuation

Protected policy may automatically release the next phase where:

I Enable(Pi+1 ) = V alid(RiI ) ∧ P rocessStateAcceptable(yi ) I ∧ InterlocksSatisfiedi ∧ W ithinIndustrialEnvelope(Pi+1 ) ∧ P olicyCurrent ∧ RevocationClear. The supervisory AI, optimizer, or application does not need authority to self-certify these conditions.

A.27.14. E27.14 Protected Human Approval

An operator, supervisor, engineer, or other authorized human may be required to approve progression after reviewing protected receipt evidence. The approval surface may show:

  • requested operation;

  • actual bounded process change;

  • sensor values;

  • machine identity;

  • current process state;

  • interlock state;

  • alarm state;

  • next proposed effect;

  • and protected receipt status.

A.27.15. E27.15 Hybrid Industrial Approval

A higher-assurance implementation may require:

V alid(RiI ) ∧ AutoP rocessP assi ∧ HumanApprovali ⇒ Enable(Pi+1 I ) Different roles may approve different effect classes.

A.27.16. E27.16 Safety-System Separation

A process controller, optimizer, or AI system may remain separate from a safety controller or other protected hazard-reduction function. A safety system may retain authority to stop, isolate, depressurize, de-energize, brake, or otherwise reduce hazard even when normal process continuation is denied. The architecture therefore need not equate fail-closed production with blocking all safety actions.

A.27.17. E27.17 One-Cycle Demonstration

A machine may perform exactly one real production or machine cycle. A protected receipt may confirm:

  • cycle completion;

  • measured position;

  • force;

  • torque;

  • temperature;

  • dimensional result;

  • sensor health;

  • and machine state. Only then may the next cycle count be released.

A.27.18. E27.18 Progressive Batch Authority

Batch authority may expand according to:

B0 < B1 < ⋯ < Bn ≤ BMAX where Bi represents cumulative or per-phase batch quantity. A failed or indeterminate phase may freeze remaining batch authority.

A.27.19. E27.19 Progressive Setpoint Change

Rather than immediately moving from setpoint s0 to sF , the controller may use:

s0 → s 1 → s 2 → ⋯ → s F with protected process confirmation after each consequential change. This may be useful where rapid setpoint changes could create undesirable transients.

A.27.20. E27.20 Rate-Limited Effectuation

A protected controller may limit the rate of change:

ds ∣ ∣ ≤ ρMAX dt and may require accepted receipt evidence before enlarging ρMAX or the target envelope.

A.27.21. E27.21 Industrial Robot Variation

An industrial robot may use the physical-actuation principles of E23-E24 with additional industrial process constraints. A protected sequence may be: 1. authorize short trajectory; 2. verify protected pose and force state; 3. authorize approach; 4. verify object or fixture state; 5. authorize grasp or tool operation; 6. verify result; 7. authorize broader production cycle.

A.27.22. E27.22 CNC / Machine Tool Variation

A CNC system may divide a requested machining operation into protected segments. The protected system may bind authority to:

  • tool identity;

  • spindle speed;

  • feed rate;

  • workpiece identity;

  • coordinate envelope;

  • operation number;

  • permitted depth;

  • and process state. The machine may not receive full-program authority merely because the first toolpath segment succeeded.

A.27.23. E27.23 Power and Electrical Variation

Industrial effectuation may include energizing loads, changing switching state, modifying inverter behavior, or altering power distribution. A bounded phase may energize one load or a reduced power envelope before a larger effect is released.

Protected receipts may include breaker state, current, voltage, protection state, or other effectrelevant evidence.

A.27.24. E27.24 Pump / Valve / Flow Variation

A pump or valve may be progressively enabled by flow, pressure, time, or position. For example:

F low0 < F low1 < ⋯ ≤ F lowMAX A protected sensor confirms each phase before the next flow authority is made available.

A.27.25. E27.25 Thermal Process Variation

A thermal process may progressively increase temperature or heat input. A protected controller may require actual temperature response and sensor-health evidence before a broader heat envelope is released. The next stage can be reduced or terminated if the measured response diverges from the protected range.

A.27.26. E27.26 Material Release Variation

A process may stage the release of physical material. Example:

1 unit → 10 units → 100 units → AuthorizedQuantity Protected scales, counters, flow meters, or inventory-state systems may produce effect receipts.

A.27.27. E27.27 Distributed Process Variation

Different process phases may occur across multiple controllers or locations. A downstream unit may require protected receipt evidence from an upstream unit before accepting material, energy, or process authority. The receipt chain can therefore span multiple industrial effectuation boundaries.

A.27.28. E27.28 Multi-Controller Quorum

A consequential industrial transition may require multiple protected authorities. For example:

  • process controller approval;

  • safety controller approval;

  • maintenance-state clearance;

  • operator approval;

  • quality-system approval. A threshold or conjunction rule may be applied using the principles already disclosed in E11.

A.27.29. E27.29 Deterministic / Low-Latency Path

A time-sensitive industrial implementation may perform the critical continuation check locally inside a protected controller rather than requiring a remote cloud round trip. The system may pre-load protected policy, phase state, keys, and permitted envelopes so that local receipt verification and next-phase release occur within the required control interval. This embodiment is intended to preserve execution-finality semantics without requiring a particular network latency.

A.27.30. E27.30 Offline Industrial Operation

An industrial system may continue within a previously authorized local envelope while disconnected from an external network. Offline operation does not imply unlimited authority. The local protected domain may enforce:

  • maximum duration;

  • maximum number of cycles;

  • maximum material quantity;

  • maximum setpoint range;

  • local receipt requirements;

  • and mandatory reauthorization after reconnect or epoch change.

A.27.31. E27.31 Maintenance Mode

Maintenance mode may create distinct authority from production mode. A maintenance credential should not automatically authorize ordinary production effectuation, and a production credential should not necessarily authorize maintenance overrides. Protected state may bind authority to:

M ode ∈ {P RODU CT ION , M AIN T EN AN CE, T EST , RECOV ERY }

A.27.32. E27.32 Engineering Workstation Separation

An engineering workstation may propose logic, recipes, setpoints, or configuration changes without having direct authority to cause their full process consequences. A protected industrial gate may require staged validation, protected receipt evidence, or human approval before the changed configuration becomes effect-capable.

A.27.33. E27.33 PLC Logic Update Variation

A controller update may be staged: 1. load candidate logic into non-effective or shadow state; 2. validate protected digest and configuration; 3. activate on one bounded machine or process unit; 4. obtain receipt evidence; 5. promote to broader equipment only after protected acceptance. This can be combined with E17 software-deployment principles.

A.27.34. E27.34 Process Recipe Update

A recipe or control parameter set may be treated as a Candidate Act whose semantic consequence occurs only when it controls real equipment. A bounded batch may therefore be used as the real demonstration phase. The protected receipt binds the actual recipe version and observed process result before the recipe is enabled more broadly.

A.27.35. E27.35 Sensor Failure

If a required protected sensor fails, the system may not substitute an untrusted optimistic value. Possible protected responses include:

  • hold;

  • reduce effect envelope;

  • use protected redundant sensor;

  • request human intervention;

  • enter safe state;

  • or mark the phase indeterminate.

A.27.36. E27.36 Actuator Failure

If a commanded actuator does not reach the expected bounded state, the receipt may be FAILURE, PARTIAL, or INDETERMINATE. The system may prevent the next broader phase and initiate protected compensation, isolation, or safe shutdown.

A.27.37. E27.37 Crash After Industrial Effect

If an industrial effect occurred but the controller crashed before a receipt was propagated, blind replay may be hazardous. The recovery workflow may inspect:

  • machine counter;

  • batch identifier;

  • actuator position;

  • PLC retained state;

  • historian or protected journal;

  • secure transaction identifier;

  • sensor state;

  • or another authoritative process source. Only then may retry or continuation be considered.

A.27.38. E27.38 Process Idempotency

Where practical, a phase may include an idempotency identifier:

IiI = H(DA ∥ M achineID ∥ P hasei ∥ Ni ) A protected controller may record the identifier atomically or near-atomically with the industrial effect.

A.27.39. E27.39 Anti-Bypass

Equivalent industrial effect paths may include:

  • HMI command;

  • engineering workstation;

  • direct PLC programming;

  • fieldbus command;

  • maintenance port;

  • local manual override;

  • remote service interface;

  • drive configuration interface;

  • safety bypass;

  • raw I/O control;

  • alternate credential;

  • recovery mode;

  • or privileged operating-system path. Where the receipt-gated architecture is intended to govern the effect, those alternate routes are disabled, scoped, logged, cryptographically restricted, physically interlocked, or subjected to equivalent protected finality requirements.

A.27.40. E27.40 SEND Analogue

The same control principle can be understood in a communication system: 1. a bounded real message or protected trailer is sent; 2. a protected receipt confirms the intended path or recipient; 3. only then is the remaining communication authority released. The industrial counterpart is a bounded real physical/process effect followed by protected confirmation before broader machine authority.

A.27.41. E27.41 Payment Analogue

Likewise, a payment system may first perform a bounded reservation or verification transfer and release the remaining authorized amount only after a protected receipt. The industrial counterpart may first release a bounded quantity, energy amount, cycle count, or setpoint change and release the remainder only after protected process evidence.

A.27.42. E27.42 Required Invariants

The frozen core of E27 includes: 1. supervisory computation, AI optimization, HMI input, or engineering proposal is not itself unconditional industrial effectuation authority; 2. industrial authority is bounded by a protected maximum envelope; 3. where staged operation is selected, a real bounded process or machine effect produces protected evidence before required broader continuation; 4. current interlock, process, safety, policy, and revocation state may be revalidated between phases; 5. a successful bounded effect does not authorize operation outside the maximum envelope; 6. sensor, actuator, crash, or process uncertainty may create a blocked or indeterminate state rather than implicit authorization; 7. hazard-reduction and safe-shutdown paths may retain separately scoped authority; 8. time-critical implementations may enforce the receipt gate locally; 9. alternate machine/process paths are controlled where needed to preserve non-bypassability.

FROZEN RELATIONSHIP BETWEEN E25, E26 AND E27

V ehicle P roposal → Bounded Real M ovement → V ehicle Receipt → Broader V ehicle Authority

M ission P roposal → Bounded M obility P hase → M obility Receipt → N ext M ission P hase

P rocess P roposal → Bounded Real P rocess Effect → P rocess Receipt → Broader P rocess Authority The common architecture is that a computationally generated plan is not itself unconditional authority for the full physical consequence. A protected boundary may first permit a bounded real effect, obtain protected evidence of what actually occurred, and make later authority technically dependent on that evidence.

A.28. E28 — Receipt-Gated Telecom Effectuation and Progressive Network Authority

A.28.1. E28.1 Purpose

E28 applies the staged-effectuation architecture to telecommunications systems in which a computational source proposes a network, subscriber, routing, signaling, session, service, or trafficcontrol act capable of creating a consequential change in a live communications infrastructure. The Candidate Act may originate from an AI controller, telecom orchestration system, policy engine, network-management application, SDN controller, service-management system, subscribermanagement function, radio-access controller, core-network function, edge platform, human operator, or another computational source. The central relationship is:

T elecom Candidate Act → Bounded Live N etwork Effect → P rotected T elecom Receipt → Continuat

The computational production of a network plan, configuration, route, subscriber policy, or control decision does not itself constitute unconditional authority to make the corresponding live network consequence effective.

A.28.2. E28.2 Candidate Telecom Acts

A Candidate Act may include, without limitation:

  • establishing, modifying, or terminating a communications session;

  • changing a subscriber or device policy;

  • enabling a network slice or service class;

  • modifying a QoS profile;

  • changing routing, steering, forwarding, or next-hop state;

  • enabling or disabling a service path;

  • changing a bearer, tunnel, or flow configuration;

  • updating a policy-control decision;

  • modifying admission-control behavior;

  • changing a radio or core-network configuration;

  • releasing or withholding a communication;

  • changing message-delivery policy;

  • modifying traffic exposure to an application or edge service;

  • changing charging or quota-control state;

  • activating a feature for a subscriber, cohort, cell, region, tenant, or network domain;

  • performing a handover or route transition;

  • enabling a roaming, interconnect, or partner path;

  • changing a service-chain function;

  • or another act capable of affecting live communications.

A.28.3. E28.3 Telecom Act Binding

A protected telecom act descriptor may bind the Candidate Act to relevant technical context, including:

  • service type;

  • subscriber or endpoint identity;

  • device identity;

  • flow identity;

  • source and destination;

  • network domain;

  • cell, region, access point, or edge site;

  • route or service chain;

  • traffic class;

  • permitted throughput or rate;

  • session identifier;

  • slice identifier;

  • policy epoch;

  • revocation state;

  • network-function identity;

  • sink identity;

  • time window;

  • and maximum permitted consequence.

The system may form:

DT EL = H(Canon(AT EL )) where AT EL denotes the Candidate Telecom Act. The precise representation is not mandatory. The required property is that later authority remains associated with the authorized telecommunications act or authorized act envelope.

A.28.4. E28.4 Maximum Telecom Effectuation Envelope

Protected policy may define:

TMAX as the maximum telecom consequence permitted under the relevant authorization. The envelope may constrain one or more of:

  • number of subscribers;

  • number of devices;

  • number of sessions;

  • traffic fraction;

  • geographic region;

  • network slice;

  • cell set;

  • destination set;

  • permitted service type;

  • rate or bandwidth;

  • duration;

  • routing domain;

  • allowed network functions;

  • allowed protocol or transport class;

  • permitted interconnect;

  • permitted data exposure;

  • permitted message scope;

  • or another live-network dimension. Prior receipt success must not itself authorize a consequence outside TMAX .

A.28.5. E28.5 Protected Network State

Before or between phases, the PED may obtain protected state from one or more network functions, gateways, telemetry systems, hardware elements, policy engines, subscriber databases, transaction stores, or protected observers. Such state may include:

  • current route state;

  • flow counters;

  • session state;

  • bearer or tunnel state;

  • subscriber authorization;

  • network-function health;

  • cell or region state;

  • congestion state;

  • packet loss;

  • latency;

  • error rate;

  • policy state;

  • revocation state;

  • credential state;

  • attestation state;

  • configuration digest;

  • software or firmware measurement;

  • prior-phase receipt state;

  • and destination confirmation state. The proposing controller need not be able to rewrite this protected state.

A.28.6. E28.6 Phase-0 Live Telecom Effect

Where staged effectuation is selected, Phase 0 produces a real live-network consequence bounded relative to the requested full consequence. Examples include:

  • enable a service for one subscriber before a large cohort;

  • route one protected test flow through a new path before a larger traffic fraction;

  • activate one cell or edge site before a region;

  • apply a new QoS policy to one flow before a service class;

  • establish one actual session before a large session batch;

  • transmit a bounded protected message before a larger communication release;

  • enable one destination or interconnect before a larger destination set;

  • move a small traffic fraction to a new network function before broader steering;

  • enable a feature for one device class before the full fleet. The Phase-0 operation is not merely simulation. At least one live network state relevant to the requested consequence changes.

A.28.7. E28.7 Telecom Phase Scope

A telecom phase may be bounded by a target set:

Ui ⊆ UMAX where Ui represents the subscriber, device, session, flow, cell, or endpoint set affected by phase i. A traffic-fraction embodiment may additionally use:

0 < φiT EL ≤ 1

where φiT EL denotes the fraction of eligible traffic released into the phase. A progressive sequence may satisfy:

φ0T EL < φ1T EL < ⋯ ≤ φMAX T EL

where monotonic progression is appropriate.

A.28.8. E28.8 Phase-Specific Telecom Authority

The PED may create or release authority sufficient only for the selected telecom phase. Such authority may comprise:

  • a scoped network capability;

  • a signed policy object;

  • a route-install authorization;

  • a flow-rule authorization;

  • a limited subscriber-policy update;

  • a one-time service activation;

  • a network-function command authenticator;

  • a hardware release value;

  • a DPU or SmartNIC rule-enablement value;

  • a gateway permit state;

  • or another bounded technical condition. The authority may bind DT EL , phase identity, target set, sink identity, expiry, policy epoch, revocation state, and prior receipt evidence.

A.28.9. E28.9 Effectuation Boundary

The telecom Finality Sink or equivalent effectuation boundary may reside in or adjacent to:

  • a packet gateway;

  • user-plane function;

  • policy-control function;

  • session-management function;

  • subscriber-management function;

  • SDN switch or controller boundary;

  • service-mesh or API gateway;

  • message gateway;

  • telecom application server;

  • edge node;

  • DPU;

  • SmartNIC;

  • NIC;

  • baseband or modem path;

  • secure network processor;

  • or another component technically capable of making the network act effective. The architecture does not require one standardized telecom function name.

A.28.10. E28.10 Protected Telecom Receipt

After the bounded live-network phase, a protected observer may generate:

RiT EL The receipt may bind:

  • DT EL ;

  • phase identifier;

  • actual target set;

  • route or function identity;

  • live-session or flow identifier;

  • observed counters;

  • actual network result;

  • destination or endpoint evidence;

  • sink identity;

  • observer identity;

  • time;

  • nonce;

  • policy epoch;

  • and status. The receipt may be signed, MACed, attested, hash-linked, hardware-protected, or otherwise authenticated.

A.28.11. E28.11 Telecom Health Vector

Where a protected health representation is useful, the system may form:

T hT i EL = [Lossi Latencyi Errori Congestioni Availabilityi ] The listed components are illustrative and not mandatory. Continuation may require:

hT i EL ∈ ΩT EL where ΩT EL represents a protected acceptable telecom-operating region.

A.28.12. E28.12 Receipt-Gated Continuation

A representative continuation condition is:

Enable(Pi+1 ) = V alid(RiT EL )∧W ithinT elecomEnvelope(Pi+1 )∧N etworkStateAcceptablei ∧P olicyCurr

If any required condition fails, the next broader phase remains unavailable.

A.28.13. E28.13 Progressive Subscriber or Device Rollout

A feature may be released progressively to:

|U0 | < |U1 | < ⋯ ≤ |UMAX | Each expansion may depend upon a protected receipt from the prior live cohort. The cohort may be selected by protected policy, randomization, topology, geography, device class, customer class, risk class, or another non-agent-controlled criterion.

A.28.14. E28.14 Progressive Traffic Steering

A traffic-steering embodiment may release increasing fractions through a new path or service function. Example:

1% → 5% → 20% → 50% → 100% Each phase remains bounded by the authorized maximum and may be stopped or reduced if protected evidence indicates unacceptable behavior.

A.28.15. E28.15 Route and Service-Chain Verification

The system may bind a phase to an expected route or service-function sequence. Let:

CTi EL = {ci,1 , ci,2 , ... , ci,k } represent an ordered or partially ordered set of network components or service functions expected for phase i. The protected observer may confirm that the actual route or service chain satisfies the authorized constraint before broader progression. An unauthorized function substitution may invalidate the receipt.

A.28.16. E28.16 Message-SEND Telecom Variant

A telecom system carrying a message, alert, file, or signaling object may first deliver a bounded protected object to the real destination. A destination-side or network-side receipt confirms the actual endpoint or delivery path. Only thereafter may the full communication, larger payload, decryption material, broader recipient set, or continued message stream be released. This is the telecom-specific realization of the earlier SEND staged-effectuation pattern.

A.28.17. E28.17 Session Establishment Variant

A large session batch may be preceded by one or more real bounded session establishments. A receipt may confirm:

  • endpoint identity;

  • session creation;

  • negotiated transport state;

  • policy application;

  • route selection;

  • or another protected technical fact. The later batch or broader session release remains unavailable until the required session receipt is accepted.

A.28.18. E28.18 Network-Slice / Service-Class Variant

A network slice, service class, tenant network, or isolated service domain may be activated in a bounded phase. Phase 0 may affect only:

  • one subscriber;

  • one test device;

  • one cell;

  • one region;

  • one application;

  • one traffic class;

  • or one protected service instance. Protected evidence from the bounded activation may gate broader slice or service-class exposure.

A.28.19. E28.19 Edge and Multi-Access Variant

A staged effect may occur first at one edge node or access domain. A receipt may confirm:

  • successful route installation;

  • destination reachability;

  • service health;

  • policy conformance;

  • or protected traffic handling. Only after acceptance may the effect expand to additional edge sites, access technologies, or regional domains.

A.28.20. E28.20 Hardware-Rooted Telecom Enforcement

A hardware-rooted implementation may place critical phase state or authority in:

  • DPU;

  • SmartNIC;

  • NIC security engine;

  • baseband security processor;

  • modem secure subsystem;

  • secure element;

  • HSM;

  • TEE;

  • FPGA;

  • ASIC;

  • switch silicon;

  • router security module;

  • or another protected hardware component. The hardware may reject a phase transition unless a valid prior receipt or derived phase authorization is present.

A.28.21. E28.21 Local Low-Latency Enforcement

Where a remote round trip would be too slow, a protected local telecom component may hold the necessary policy, state, and verification material. The sequence may become:

Local Bounded Effect → Local P rotected Observation → Local Receipt V alidation → N ext Local Auth

A remote controller may receive the receipt later for audit or synchronization without being on the critical path.

A.28.22. E28.22 Human Approval

A protected human may approve:

  • the initial telecom act;

  • the maximum network envelope;

  • the first bounded phase;

  • expansion after a receipt;

  • a high-risk route change;

  • a broad subscriber rollout;

  • or a recovery after failure. The approval may be bound to DT EL , RiT EL , phase scope, target set, network region, and expiry.

A.28.23. E28.23 Automatic Approval

Protected policy may automatically advance where the receipt and current network state satisfy required predicates. For example:

V alid(RiT EL ) ∧ hTi EL ∈ ΩT EL ∧ W ithinT elecomEnvelope(Pi+1 ) ⇒ AutoContinue The proposing AI or network optimizer need not control this decision.

A.28.24. E28.24 Hybrid Approval

An implementation may automatically advance low-consequence phases but require a protected human for broader scope, inter-domain changes, large subscriber populations, or high-risk service classes. A receipt therefore informs both automatic and human continuation logic.

A.28.25. E28.25 Failure and Rollback

If a bounded telecom phase fails, the system may:

  • stop progression;

  • restore a prior route;

  • withdraw a policy;

  • reduce traffic fraction;

  • isolate an affected cohort;

  • fail back to a prior network function;

  • require human review;

  • or terminate the requested change. The rollback path may itself be protected and may use separate hazard-reduction or continuity authority.

A.28.26. E28.26 Indeterminate Telecom State

If the system cannot determine whether the live network change took effect, it may enter:

T EL_IN DET ERM IN AT E The PED may reconcile using:

  • network-function state;

  • flow-table state;

  • session records;

  • subscriber database state;

  • counters;

  • protected logs;

  • transaction identifiers;

  • endpoint confirmation;

  • or hardware state. Broader effectuation remains blocked until a permitted reconciliation outcome is established.

A.28.27. E28.27 Crash After Network Effect

A network change may occur before its receipt reaches the controller. The phase may therefore use an idempotency identifier:

IiT EL = H(DT EL ∥ P hasei ∥ Ni ) The sink or protected network function may atomically bind the identifier to the applied livenetwork change. After restart, the system can distinguish a previously effected phase from one that never occurred.

A.28.28. E28.28 Alternate-Path Closure

The staged telecom path should not be trivially bypassable through an equivalent full-effect route. Relevant paths may include:

  • direct network-management interfaces;

  • emergency or recovery interfaces;

  • alternate controller credentials;

  • low-level switch or router configuration paths;

  • raw flow-programming interfaces;

  • direct subscriber-database mutation;

  • alternate message gateways;

  • shadow policy systems;

  • or another act-equivalent network path. Such paths may be disabled, scoped, mediated, cryptographically locked, or subjected to equivalent protected verification.

A.28.29. E28.29 Multi-Domain Telecom Progression

A telecom act may cross multiple administrative or technical domains. Each domain may issue its own protected receipt. Continuation may require a set or quorum of domain receipts before the end-to-end consequence expands. A downstream domain may refuse expansion even if an upstream domain has already succeeded.

A.28.30. E28.30 E28 Required Invariants

The frozen core of E28 is: 1. a telecom proposal is distinguishable from live telecom effectuation; 2. a protected maximum telecom envelope bounds the permitted consequence; 3. where staged mode is selected, at least one bounded phase causes a real live-network effect; 4. protected evidence of that effect may gate a broader or subsequent network effect;

5. a successful receipt does not authorize expansion beyond the maximum envelope; 6. network uncertainty may block progression rather than being treated as success; 7. the proposing controller need not possess unrestricted live-network authority; 8. software, hardware, or split enforcement may be used; 9. act-equivalent alternate paths are controlled where needed to preserve non-bypassability.

TERRESTRIAL NETWORK EFFECTUATION

A.29. E29 — Receipt-Gated Radio, Satellite, and Non-Terrestrial Network Effectuation

A.29.1. E29.1 Purpose

E29 applies the staged-effectuation architecture to radio-frequency, wireless, satellite, spacecommunications, high-altitude, relay, and non-terrestrial network operations in which a computational source proposes an action capable of creating an externally consequential transmission, link, beam, waveform, channel, relay, payload, or communications-state change. A representative relationship is:

Radio/N T N Candidate Act → Bounded Real RF /Link Effect → P rotected RF /Link Receipt → Con

The architecture may operate at a transmitter, receiver, gateway, modem, satellite payload, ground station, relay, baseband, beamformer, secure radio, or another protected communications boundary.

A.29.2. E29.2 Candidate Radio and NTN Acts

A Candidate Act may include:

  • transmit a frame, packet, burst, stream, or message;

  • select or change a frequency or channel;

  • change transmit power;

  • change bandwidth;

  • change waveform or modulation parameters;

  • activate a beam;

  • steer a beam;

  • change coding or redundancy;

  • open or close a radio link;

  • perform handover;

  • select a gateway;

  • select an inter-satellite or relay path;

  • activate a payload communications function;

  • allocate a time/frequency resource;

  • change a satellite service footprint;

  • change an NTN route;

  • activate a ground-to-space or space-to-ground path;

  • release an encrypted payload or decryption key;

  • or another radio/NTN consequence.

A.29.3. E29.3 Protected RF/NTN Act Binding

The protected act descriptor may bind:

  • transmitter identity;

  • receiver identity;

  • satellite or relay identity;

  • gateway identity;

  • frequency or channel;

  • power limit;

  • bandwidth;

  • beam identifier;

  • pointing or footprint constraint;

  • modulation or waveform class;

  • duration;

  • payload identity;

  • destination;

  • route or hop sequence;

  • time window;

  • policy epoch;

  • revocation state;

  • and maximum permitted radio/NTN consequence.

The system may form:

DRF = H(Canon(ARF )) where ARF denotes the Candidate Radio/NTN Act.

A.29.4. E29.4 Maximum Radio/NTN Effectuation Envelope

Protected policy may define:

ERF MAX

as the maximum permitted radio or NTN consequence. The envelope may constrain:

  • power;

  • duration;

  • frequency range;

  • bandwidth;

  • beam direction;

  • beam footprint;

  • receiver set;

  • gateway set;

  • route or relay path;

  • satellite or payload function;

  • geographic area;

  • traffic volume;

  • data object;

  • protocol or waveform class;

  • and phase count.

A.29.5. E29.5 Phase-0 Real RF Effect

A bounded Phase-0 effect may comprise, for example:

  • a low-power transmission;

  • a short-duration burst;

  • a narrow-bandwidth transmission;

  • one protected verification frame;

  • one bounded encrypted object;

  • one beam to a limited footprint;

  • one gateway path;

  • one satellite relay hop;

  • one short session;

  • one bounded payload-service activation;

  • or another deliberately restricted but real radio effect. The effect occurs through the actual RF, optical-wireless, satellite, or NTN path rather than solely in simulation.

A.29.6. E29.6 Phase-Specific RF Parameters

A phase may be bounded by one or more parameters such as:

pitx , BiRF , Δti , bi where, locally:

  • pitx may represent transmit-power scope;

  • BiRF may represent authorized bandwidth;

  • Δti may represent authorized transmission duration;

  • bi may identify a beam, footprint, or directional transmission state. The architecture does not require these particular radio parameters.

A.29.7. E29.7 Protected Receiver-Side Observation

The actual receiving endpoint or another protected observer may confirm one or more technical facts such as:

  • protected frame received;

  • expected transmitter authenticated;

  • expected receiver reached;

  • expected route or relay used;

  • signal arrived within a permitted condition;

  • integrity verified;

  • bounded object stored;

  • expected beam or footprint observed;

  • expected gateway or satellite identity confirmed. This observation may be more probative than transmitter-side intent alone.

A.29.8. E29.8 RF Effect Receipt

A protected receipt may be generated as:

RiRF and may bind:

  • DRF ;

  • phase identifier;

  • transmitter;

  • receiver;

  • gateway;

  • satellite or relay;

  • actual RF parameters;

  • actual route or hop evidence;

  • protected observation;

  • time;

  • nonce;

  • policy epoch;

  • and status.

A.29.9. E29.9 Receiver Confirmation Receipt

Where destination-side confirmation is required, a receiving system may issue:

RiRX The continuation predicate may require both local transmission evidence and remote receiver evidence:

V alid(RiRF ) ∧ V alid(RiRX ) before the broader phase is enabled.

A.29.10. E29.10 Beam-Progression Embodiment

A radio or satellite system may begin with a narrow or low-consequence beam configuration. After protected receipt evidence, it may progress to:

  • a wider footprint;

  • a different beam;

  • multiple beams;

  • longer duration;

  • higher throughput;

  • or a larger receiver set. A protected maximum envelope prevents prior success from becoming unrestricted beam authority.

A.29.11. E29.11 Power-Progression Embodiment

Transmit power may progress according to a protected schedule. For example:

p0tx < p1tx < ⋯ ≤ pMAX tx

where each increase is permitted only after required receipt validation and current policy checks. A higher-power phase is not automatically authorized merely because a lower-power phase succeeded.

A.29.12. E29.12 Duration-Progression Embodiment

A system may first authorize a short-duration transmission and then expand the permitted interval. For example:

Δt0 < Δt1 < ⋯ ≤ ΔtMAX A receipt may prove that the prior bounded transmission reached the intended receiver or behaved within the expected technical envelope.

A.29.13. E29.13 Bandwidth / Resource-Block Progression

A radio system may begin with limited spectral or time-frequency resources and expand only after protected evidence. The bounded stage may use:

  • one channel;

  • one carrier;

  • one sub-band;

  • one timeslot;

  • one resource-block set;

  • one protected waveform instance;

  • or another limited radio resource.

A.29.14. E29.14 Gateway Verification

Before broader satellite or NTN traffic is released, a bounded stage may verify the actual gateway path. A gateway receipt may bind:

  • gateway identity;

  • route identity;

  • satellite or relay identity;

  • protected session identifier;

  • bounded traffic result;

  • and next-stage eligibility. An unauthorized gateway substitution may block continuation.

A.29.15. E29.15 Multi-Hop / Relay Path

A non-terrestrial or relay path may include multiple hops.

Let:

Hi = {hi,1 , hi,2 , ... , hi,k } represent the authorized hop sequence or hop set for phase i. Protected evidence may be collected from one or more hops. Continuation may require:

RouteAcceptable(Hi ) = T RU E in addition to ordinary receipt validation.

A.29.16. E29.16 Aggregate Relay Receipt

Where multiple relay or gateway receipts exist, the system may create an aggregate protected commitment:

RiAGG = Commit(Ri,1 , Ri,2 , ... , Ri,k ) The aggregate may be a hash tree, threshold signature, multi-signature, protected summary, or other authenticated construction. The construction is non-limiting.

A.29.17. E29.17 Store-and-Forward NTN Variant

In a delayed or intermittently connected NTN environment, the full receipt may not return immediately. The system may therefore:

  • allow only a bounded locally authorized phase;

  • store the protected result;

  • await later authenticated return evidence;

  • reconcile the phase state;

  • and release broader authority only after the delayed receipt is accepted. This permits receipt-gated operation without assuming continuously available connectivity.

A.29.18. E29.18 Long-Latency Local Continuation

Where a round trip to a remote ground or cloud authority is impractical, a protected local radio, satellite, or gateway component may hold phase policy and cryptographic continuation material. The local sequence may be:

Bounded RF Effect → Local P rotected Observation → Local Receipt → Local N ext P hase

The resulting receipts may later be synchronized with a remote authority.

A.29.19. E29.19 Cryptographic Phase Release

A protected component may derive a next-stage key or command authenticator from the prior accepted receipt. For example:

RF RF Ki+1 = KDF (KR , DRF , H(RiRF ), i + 1) The later transmission authority therefore becomes technically dependent on accepted evidence from the earlier real radio phase.

A.29.20. E29.20 Destination-Key Release

A full encrypted communication may be pre-staged through the radio or satellite network while semantic release remains unavailable. After a valid bounded-path or receiver receipt, the protected system may release:

  • a decryption key;

  • a key share;

  • unwrap authority;

  • a session continuation value;

  • or equivalent missing execution material. This can separate transport completion from semantic disclosure.

A.29.21. E29.21 Satellite Payload Communications Variant

A satellite payload may perform a bounded communications action before broader service activation. Examples include:

  • one protected beacon;

  • one test frame;

  • one gateway session;

  • one beam;

  • one tenant channel;

  • one bounded data object;

  • or one short-duration service interval. Receipt evidence from a ground station, destination, onboard protected observer, or combination may gate broader payload communications authority.

A satellite or relay network may verify one real cross-link or relay path before permitting broader path use. A protected receipt may bind:

  • source node;

  • destination node;

  • intermediate relay identity;

  • link identifier;

  • observed integrity;

  • and phase status. The later path authority may be scoped to the verified cross-link topology or authorized route class.

A.29.23. E29.23 Handover Variant

A wireless or NTN system may first move a bounded session, flow, or traffic fraction to a new link or serving node. Receipt evidence may confirm that the handover actually completed and that the resulting state satisfies protected conditions before additional sessions or traffic are moved.

A.29.24. E29.24 Human Approval

A protected human may approve:

  • a maximum RF envelope;

  • a new gateway;

  • a new beam footprint;

  • a broader receiver set;

  • a high-power phase;

  • a satellite payload-service activation;

  • or recovery after an indeterminate state.

The approval may bind the current receipt and exact continuation scope.

A.29.25. E29.25 Automatic Approval

A protected policy engine may automatically continue where:

V alid(RiRF )∧W ithinRF Envelope(Pi+1 )∧LinkStateAcceptablei ∧P olicyCurrenti ∧RevocationCleari

is satisfied. The proposing radio optimizer need not be able to mark these conditions as true.

A.29.26. E29.26 Hybrid Approval

A system may automatically advance low-power, short-duration, or small-footprint phases but require a protected human or additional authority for broader or more consequential phases.

A.29.27. E29.27 Failure and Indeterminate Link State

If a receipt reports failure, rejection, unacceptable observation, or indeterminate state, broader radio/NTN progression remains unavailable. Reconciliation may query:

  • transmitter state;

  • receiver state;

  • gateway logs;

  • onboard protected logs;

  • link counters;

  • satellite telemetry;

  • transaction or frame identifiers;

  • and protected hardware state.

A.29.28. E29.28 Duplicate Transmission Protection

A consequential radio transmission may use a protected idempotency or sequence identifier. For example:

IiRF = H(DRF ∥ P hasei ∥ Ni ) A receiver, gateway, or protected sink may reject an unauthorized duplicate associated with the same single-use phase authority.

A.29.29. E29.29 Anti-Bypass

Alternative paths capable of creating the broader RF or NTN consequence may be subjected to corresponding control. Examples include:

  • direct modem control;

  • raw radio commands;

  • alternate gateway credentials;

  • low-level beamformer control;

  • maintenance interfaces;

  • payload-debug paths;

  • direct baseband programming;

  • fallback satellite routing;

  • or another effect-equivalent path.

A.29.30. E29.30 E29 Required Invariants

The frozen core of E29 is: 1. radio/NTN proposal is distinguishable from actual transmission or link effect; 2. a protected maximum radio/NTN envelope bounds authority; 3. where staged mode applies, the initial stage creates a real bounded RF/link consequence; 4. protected evidence from the sink, receiver, gateway, relay, or protected observer may gate broader authority; 5. missing or indeterminate evidence blocks unauthorized broader progression; 6. long-latency and store-and-forward environments may use local protected gating and later synchronization; 7. phase authority may be cryptographically derived from earlier receipt evidence; 8. software, firmware, hardware, or distributed enforcement may be used; 9. equivalent alternate radio-control paths are controlled where needed for non-bypassability.

EGRESS EFFECTUATION

A.30. E30 — Receipt-Gated GPU, Accelerator, and Compute-Egress Effectuation

A.30.1. E30.1 Purpose

E30 applies the architecture to GPUs, AI accelerators, neural-processing units, tensor processors, compute cards, accelerator clusters, confidential-computing accelerators, DMA-capable devices, and related compute fabrics. The embodiment distinguishes computation from authority to create an external or durable consequence. A system may therefore permit substantial computation while separately controlling whether the resulting operation may:

  • leave protected accelerator memory;

  • reach a host or network;

  • update durable model state;

  • modify external storage;

  • invoke another device;

  • release sensitive output;

  • or become an externally consequential act.

A representative relationship is:

Accelerator Candidate Act → Bounded Real Compute/Device Effect → P rotected Accelerator Receip

A.30.2. E30.2 Candidate Accelerator Acts

A Candidate Act may include:

  • dispatch a kernel;

  • execute a graph;

  • run an inference batch;

  • execute a training step;

  • update accelerator-local state;

  • write a memory region;

  • initiate DMA;

  • export a tensor or result;

  • send data over a high-speed fabric;

  • transfer data to a NIC or DPU;

  • expose an output to a host process;

  • decrypt or unwrap accelerator-resident data;

  • activate a cluster-wide job;

  • expand a job to more devices;

  • enable a new memory or fabric path;

  • or another accelerator consequence.

A.30.3. E30.3 Accelerator Act Binding

The protected system may bind a Candidate Accelerator Act to:

  • accelerator identity;

  • device or cluster identity;

  • command queue;

  • kernel or graph identity;

  • code digest;

  • model digest;

  • input identity;

  • memory range;

  • output range;

  • destination;

  • DMA target;

  • fabric peer;

  • host process;

  • VM or confidential workload;

  • tenant;

  • permitted batch size;

  • permitted runtime;

  • permitted egress;

  • policy epoch;

  • revocation state;

  • and maximum consequence.

The system may form:

DACC = H(Canon(AACC )) where AACC denotes the Candidate Accelerator Act.

A.30.4. E30.4 Maximum Accelerator Effectuation Envelope

Protected policy may define:

GMAX as the maximum permitted accelerator consequence. It may constrain:

  • device set;

  • memory region;

  • kernel or graph set;

  • batch size;

  • execution count;

  • runtime;

  • output size;

  • destination set;

  • DMA range;

  • host-visible memory;

  • network-visible output;

  • model or dataset scope;

  • accelerator-fabric path;

  • privilege level;

  • or another compute or egress dimension.

A.30.5. E30.5 Compute Versus Effectuation Separation

The accelerator may be permitted to calculate a result without thereby obtaining authority to expose, commit, transmit, or otherwise effectuate that result externally. For example:

ComputeComplete = T RU E ⇏ ExternalReleaseAuthorized = T RU E This separation is particularly important where model inference, training, or transformation can occur inside a protected accelerator but the resulting output has not yet crossed an effectuation boundary.

A.30.6. E30.6 Phase-0 Bounded Accelerator Effect

A bounded first phase may include:

  • execute on one accelerator before a cluster;

  • process one small batch before a larger batch;

  • write one protected local buffer before a broader memory range;

  • export one bounded digest or result fragment before a complete output;

  • perform one DMA transfer to a protected staging region before a final destination;

  • activate one fabric peer before a larger peer set;

  • release one encrypted output segment before semantic decryption;

  • execute one kernel or graph stage before a larger pipeline. The Phase-0 operation is real. It changes accelerator, memory, fabric, staging, or destination state in a bounded manner.

A.30.7. E30.7 Device-Set Progression

Let:

DACC i

represent the accelerator-device set authorized for phase i. A progressive rollout may satisfy:

DACC 0 ⊂ DACC 1 ⊂ ⋯ ⊆ DACC MAX

where expansion is appropriate. The next device set becomes available only after the required prior-phase evidence is accepted.

A.30.8. E30.8 Memory-Region Scope

A phase may be restricted to a protected memory region:

MACC i

The sink or memory-control component may reject access outside that region. A later receipt may authorize a larger region, a different region, or a destination-specific export from the region.

A.30.9. E30.9 Protected Accelerator State

The PED or protected device logic may obtain state such as:

  • device identity;

  • firmware measurement;

  • secure-boot state;

  • command-queue state;

  • memory-protection state;

  • IOMMU state;

  • confidential-compute state;

  • tenant identity;

  • current job identity;

  • kernel or graph identity;

  • device-health state;

  • error counters;

  • thermal state;

  • memory-integrity state;

  • fabric-link state;

  • destination identity;

  • prior receipt state;

  • and phase-latch state.

A.30.10. E30.10 Accelerator Effect Receipt

After a bounded phase, protected logic may generate:

RiACC The receipt may bind:

  • DACC ;

  • accelerator identity;

  • phase identifier;

  • command or graph identity;

  • device set;

  • memory region;

  • observed result digest;

  • DMA or fabric destination;

  • output-release state;

  • hardware measurement;

  • time;

  • nonce;

  • policy epoch;

  • and status.

A.30.11. E30.11 Protected Device State Vector

An implementation may represent selected accelerator health or effectuation state as:

T gi = [Healthi Errori M emoryIntegrityi F abricStatei EgressStatei ] Continuation may require:

gi ∈ ΩACC

where ΩACC is a protected acceptable accelerator-state region.

A.30.12. E30.12 Command-Queue Gate

A protected component may prevent a phase command from becoming executable until required authority is present. The gate may reside at:

  • driver boundary;

  • kernel module;

  • runtime;

  • hypervisor;

  • confidential-compute monitor;

  • device firmware;

  • security processor;

  • command processor;

  • doorbell path;

  • MMIO gate;

  • or another device-command boundary. The precise placement is non-limiting.

A.30.13. E30.13 Protected Command Release

The system may withhold a command descriptor, authenticator, queue-release value, doorbell enablement, key, or hardware state required for the next phase. Only after protected receipt verification is the missing command material released. Thus the next phase may be technically unavailable even if ordinary software has already constructed the command.

A.30.14. E30.14 DMA Effectuation Gate

A DMA-capable accelerator may compute locally while a protected boundary separately controls whether data can be written to an external memory or device. A phase may authorize DMA only to:

  • a staging buffer;

  • a protected host page range;

  • a DPU buffer;

  • a specific NIC queue;

  • a specific storage target;

  • or another bounded destination. The full DMA path remains unavailable until prior receipt conditions are satisfied.

A.30.15. E30.15 IOMMU / Memory-Controller Variation

An IOMMU, memory controller, secure memory subsystem, or equivalent device may participate in the Finality Sink function. It may verify:

  • authorized device;

  • memory range;

  • phase identity;

  • destination;

  • access type;

  • and current protected state. A valid compute result alone does not override the protected memory-access constraint.

A.30.16. E30.16 Fabric-Gated Progression

Accelerator fabrics may include PCIe, CXL, device-to-device links, GPU interconnects, or other high-speed fabrics. A phase may authorize communication only to a bounded peer set. Let:

FACC i

represent the permitted accelerator-fabric peer or path set for phase i. A later receipt may enable a broader peer set, subject to the maximum envelope.

A.30.17. E30.17 DPU / SmartNIC Egress Gate

A DPU, SmartNIC, NIC, or secure network processor may prevent accelerator output from becoming network-visible until protected continuation conditions succeed. The accelerator may complete computation while the DPU or SmartNIC withholds network release. A receipt from the compute phase, destination path, or both may then unlock a bounded or full egress phase.

A.30.18. E30.18 Output-Key Release

A protected accelerator may produce encrypted output. The system may withhold an output-release key:

KiOUT until the required phase receipt is accepted. Thus:

CiphertextAvailable = T RU E ⇏ SemanticOutputAvailable = T RU E The key may be destination-bound, phase-bound, tenant-bound, or receipt-derived.

A.30.19. E30.19 Receipt-Derived Output Authority

A strong embodiment derives the next output-release authority from a prior protected receipt. For example:

OUT ACC Ki+1 = KDF (KR , DACC , H(RiACC ), i + 1, Destination) The named KDF is illustrative. Equivalent protected derivation or unsealing mechanisms may be used.

A.30.20. E30.20 One-Accelerator-to-Cluster Progression

A large compute job may first execute on one protected accelerator or one small accelerator group. Protected evidence may confirm:

  • code identity;

  • model identity;

  • bounded output integrity;

  • memory behavior;

  • device health;

  • fabric behavior;

  • or destination handling. Only thereafter may the job expand to a larger accelerator set.

A.30.21. E30.21 Batch-Size Progression

A job may begin with bounded batch size:

JOB B0JOB < B1JOB < ⋯ ≤ BMAX Each larger batch may require accepted evidence from the preceding real phase. The batch notation is local to E30 and does not alter earlier uses of B .

A.30.22. E30.22 Progressive Output Release

A large output may be released in phases:

  • digest only;

  • metadata only;

  • one output segment;

  • one encrypted chunk;

  • a bounded sample;

  • a larger output subset;

  • complete ciphertext;

  • final decryption authority. This permits computation and transport to progress without immediately creating the complete semantic consequence.

A.30.23. E30.23 Confidential-Computing Variant

A confidential VM, TEE, accelerator enclave, or other protected compute environment may hold the phase state and cryptographic authority. Attestation may bind:

  • workload measurement;

  • accelerator measurement;

  • model identity;

  • tenant identity;

  • policy;

  • and phase state.

A valid attestation alone need not constitute permission for unrestricted egress; the receipt-gated effectuation condition may still be required.

A.30.24. E30.24 GPU Security-Processor Variation

A GPU or accelerator security processor may maintain:

  • root key;

  • phase counter;

  • receipt-consumption state;

  • permitted memory region;

  • permitted destination;

  • command-release state;

  • or output-key state. Ordinary host software may be unable to force advancement without satisfying the protected receipt predicate.

A.30.25. E30.25 Multi-Accelerator Receipt Aggregation

Where a phase spans multiple devices, each device may issue:

ACC Ri,j for accelerator j. Continuation may require:

n ACC ∑ V alid(Ri,j )≥m j=1

or another protected aggregate condition. The required threshold may depend on the workload and policy.

A.30.26. E30.26 Partial Device Failure

If some accelerators succeed and others fail, the system may:

  • continue only on the successful set;

  • reduce the next device set;

  • isolate failed devices;

  • re-run a bounded phase;

  • require human review;

  • or terminate. A successful subset must not silently become authority to bypass failed-device constraints.

A.30.27. E30.27 Human Approval

A protected human may approve:

  • the maximum accelerator envelope;

  • a cluster expansion;

  • release of sensitive output;

  • broader memory access;

  • a new egress destination;

  • a high-value model or dataset operation;

  • or recovery after an indeterminate device state.

A.30.28. E30.28 Automatic Approval

Protected logic may automatically continue where:

V alid(RiACC )∧gi ∈ ΩACC ∧W ithinAcceleratorEnvelope(Pi+1 )∧P olicyCurrenti ∧RevocationCleari

is satisfied. The AI workload itself need not control this decision.

A.30.29. E30.29 Hybrid Approval

An implementation may automatically expand low-consequence compute phases while requiring human or multi-authority approval for:

  • external egress;

  • large cluster activation;

  • sensitive data exposure;

  • durable external state change;

  • or broader privilege.

A.30.30. E30.30 SEND Example

An AI model may generate a message entirely on an accelerator. The computation may complete, but the message remains inside protected memory or encrypted staging. A bounded recipient-verification or trailer phase occurs first. After a valid receipt, the protected egress gate releases the complete message, ciphertext, or decryption key to the authorized communication path. Thus model generation does not itself constitute SEND authority.

A.30.31. E30.31 Payment Example

An accelerator may compute a payment recommendation, fraud score, amount, or transaction object. The resulting object remains non-effective until protected payment authority is released through the relevant receipt-gated payment boundary. A successful GPU computation therefore does not itself authorize funds movement.

A.30.32. E30.32 Crash / Reset / Device-Recovery State

An accelerator may reset after a bounded effect but before the host records the receipt. Protected recovery may use:

  • device monotonic counter;

  • protected phase journal;

  • command identifier;

  • memory-state digest;

  • DPU or host-side protected record;

  • destination record;

  • or hardware receipt store. The system should not blindly reissue a potentially consequential phase if the prior effect may already have occurred.

A.30.33. E30.33 Idempotency

A phase-specific accelerator effect may use:

IiACC = H(DACC ∥ P hasei ∥ Ni ) The relevant sink, queue gate, DPU, memory controller, or destination may record the identifier atomically with the effect where practical.

A.30.34. E30.34 Revocation During Compute

A long-running compute phase may begin while authorization is valid and finish after revocation. The architecture may distinguish:

  • permission to continue internal computation;

  • permission to release output;

  • permission to commit durable external state;

  • permission to communicate to another device;

  • and permission to begin another phase. Revocation may therefore block later consequence even if internal computation has already completed.

A.30.35. E30.35 Alternate-Path Closure

Relevant bypass paths may include:

  • raw device-driver access;

  • alternate command queue;

  • privileged MMIO;

  • unprotected DMA mapping;

  • debug interface;

  • peer-to-peer fabric path;

  • direct NIC path;

  • alternate decryption key;

  • host memory copy path;

  • recovery firmware;

  • or another effect-equivalent accelerator path. Such paths may be disabled, mediated, scoped, cryptographically gated, or subjected to equivalent finality verification.

A.30.36. E30.36 E30 Required Invariants

The frozen core of E30 is: 1. accelerator computation is distinguishable from authority to create the final external or durable consequence; 2. a protected maximum accelerator envelope bounds compute, memory, device, fabric, and/or egress consequence; 3. where staged mode applies, an initial real bounded compute/device effect is observed and evidenced; 4. broader compute, memory, fabric, DMA, or egress authority may depend technically on accepted prior evidence; 5. completion of computation alone does not require release of sensitive or consequential output; 6. revocation, failure, or indeterminate state may block later consequence even after computation has occurred; 7. software, firmware, DPU, SmartNIC, IOMMU, memory-controller, accelerator-securityprocessor, or other hardware enforcement may be used; 8. alternate effect-capable device paths are controlled where needed to preserve nonbypassability; 9. SEND, payment, and other external acts remain separately subject to their corresponding effectuation boundaries.

FROZEN RELATIONSHIP BETWEEN E28, E29 AND E30

N etwork P roposal → Bounded Live N etwork Effect → T elecom Receipt → Broader N etwork Authori

RF /N T N P roposal → Bounded Real Link/T ransmission Effect → RF /Link Receipt → Broader RF

Compute P roposal → Bounded Real Compute/Device Effect → Accelerator Receipt → Broader Comp The common architecture is that computation, optimization, route selection, transmission planning, or accelerator execution does not itself constitute unconditional authority for the complete external consequence. Protected evidence from a bounded real effect may become a technical prerequisite for broader effectuation.

A.31. E31 — Receipt-Gated Model-State Update, Protected Memory Commit, and Progressive Model-State Effectuation

A.31.1. E31.1 Purpose

E31 applies the staged-effectuation architecture to persistent or consequential state associated with an AI model, agent, model-serving system, retrieval system, learned component, adaptive controller, or autonomous computational system. The embodiment addresses the distinction between computing a proposed state change and making that change authoritative for subsequent operation. A model, agent, optimizer, trainer, adaptation routine, tool, application, or human operator may propose a state modification. The proposal itself need not become durable, trusted, deployable, or execution-relevant state merely because it was computed. The central relationship is:

P roposed M odel State Change → Bounded P rotected State U pdate → Observed State Receipt → Conti

E31 may be used independently or together with E16 database promotion, E18 model deployment, E19 tool-use control, E20 credential release, E21 data export, E30 accelerator effectuation, or another embodiment.

A.31.2. E31.2 Model-State Scope

For purposes of this embodiment, model state may include, without limitation:

  • model parameters or weights;

  • adapter parameters;

  • low-rank adaptation state;

  • fine-tuning state;

  • optimizer state;

  • routing or gating state;

  • model-selection state;

  • persistent agent memory;

  • long-term memory objects;

  • vector-store entries used as durable model memory;

  • retrieval indexes or protected retrieval metadata;

  • tool-use policy state;

  • action-policy state;

  • planning memory;

  • protected conversation-derived memory;

  • task-state memory;

  • safety or execution-control configuration;

  • trusted prompt/configuration state;

  • policy tables;

  • preference state;

  • model-serving metadata;

  • model registry state;

  • calibration state;

  • reward or evaluation state;

  • protected provenance state;

  • state of a learned or adaptive control system;

  • or another persistent state capable of changing later computational or external behavior. Temporary internal computation that is never promoted into a protected or persistent state may remain outside this embodiment unless protected policy elects to treat it as consequential state.

A.31.3. E31.3 Candidate Model-State Update

Let:

AMS denote a Candidate Model-State Update. The Candidate Model-State Update may identify:

  • source model or agent;

  • target model or agent;

  • target state class;

  • object or parameter set;

  • prior-state version;

  • proposed new-state version;

  • change-set;

  • provenance;

  • source data or source event identifier;

  • update reason;

  • policy epoch;

  • approval requirement;

  • intended deployment scope;

  • permitted downstream effect class;

  • and maximum authority that may result from the state update.

A protected representation may be formed:

DMS = H(Canon(AMS )) or another deterministic binding may be used.

A.31.4. E31.4 State-Authority Separation

A central property of E31 is that:

P roposedState ≠ AuthoritativeState until the required protected promotion conditions have been satisfied. An agent may therefore be permitted to:

  • calculate a memory entry;

  • suggest a preference update;

  • produce an adapter delta;

  • generate a learned policy update;

  • create a candidate model version;

  • or derive a new model-state object; without being able to make the proposal authoritative for subsequent operation.

A.31.5. E31.5 Provisional Model-State Region

A proposed state change may first be placed into a provisional, shadow, quarantined, candidate, staging, or non-authoritative region. Let:

SMS prov

denote such a provisional model-state region. The provisional region may be implemented in:

  • protected memory;

  • a database namespace;

  • object storage;

  • a model registry;

  • a vector database;

  • a trusted execution environment;

  • a secure element;

  • protected accelerator memory;

  • a firmware-controlled partition;

  • a remote protected service;

  • or another storage domain. Material in the provisional region may be readable for evaluation while remaining unavailable as authoritative live state.

A.31.6. E31.6 Authoritative Model-State Region

Let:

SMS auth

denote the authoritative state region used by the live model, agent, or serving system. Promotion from provisional to authoritative state may require protected continuation authority. An implementation may therefore enforce:

MS W rite(Sprov ) ⇏ W rite(SMS auth )

without a separate protected decision.

A.31.7. E31.7 Bounded Phase-0 State Update

Phase 0 may make a real but bounded state modification. Examples include:

  • commit one candidate memory item but not the full memory batch;

  • update one adapter layer before the complete adapter set;

  • activate a model-state change for one test replica before all replicas;

  • expose the candidate memory to one protected evaluation session;

  • update one routing rule before a complete routing policy;

  • promote one vector-memory record while holding the remainder;

  • update one low-risk preference field before a broader profile state;

  • apply one bounded parameter delta under a maximum norm or scope;

  • activate the state for a constrained tool-free evaluation environment;

  • or make the new state authoritative only for a protected cohort. The initial state update is real because at least one protected system component begins using the changed state.

A.31.8. E31.8 Model-State Effectuation Envelope

Protected policy may define:

EMS MAX

as the maximum model-state consequence authorized for the Candidate Model-State Update. The envelope may constrain:

  • parameter subset;

  • layer subset;

  • adapter subset;

  • memory-object count;

  • memory namespace;

  • model replicas;

  • tenants;

  • user cohort;

  • retrieval scope;

  • permitted tools;

  • permitted destinations;

  • allowed downstream action classes;

  • duration;

  • model version;

  • deployment domain;

  • data-source provenance class;

  • or another state dimension. A successful bounded update must not itself enlarge the maximum envelope.

A.31.9. E31.9 Delta-Bounded Parameter Update

Where a numeric model update is used, a protected bound may be defined over a candidate delta:

Δθi for phase i. An illustrative bounded-update condition is:

‖Δθi ‖ ≤ λi where λi is a protected phase-specific update bound. The norm, distance, metric, or bound may be replaced by any suitable model-state constraint and is not mandatory.

A.31.10. E31.10 Protected Evaluation of Updated State

After the bounded state update becomes effective within its restricted scope, protected evaluation may measure one or more properties, including:

  • state integrity;

  • state availability;

  • correct model-version binding;

  • correct memory-object binding;

  • absence of unauthorized namespace changes;

  • evaluation accuracy;

  • regression metrics;

  • safety predicates;

  • output stability;

  • downstream tool-use behavior;

  • resource consumption;

  • execution-finality behavior;

  • latency;

  • destination behavior;

  • retrieval correctness;

  • or another protected acceptance condition. The evaluation itself may be performed by the same PED, a separate evaluator, a model monitor, hardware observer, trusted service, or destination-side verifier.

A.31.11. E31.11 Model-State Receipt

Following the real bounded update, the protected system may produce:

RiMS binding one or more of:

  • DMS ;

  • prior state version;

  • resulting state version;

  • affected state subset;

  • state digest;

  • evaluation result;

  • model identity;

  • serving replica or device identity;

  • policy epoch;

  • phase identifier;

  • nonce;

  • timestamp or trusted-time evidence;

  • observer identity;

  • and next-stage eligibility state. A receipt may be signed, MACed, attested, hash-chained, hardware-protected, or otherwise authenticated.

A.31.12. E31.12 State-Version Binding

Let:

viMS denote the protected model-state version after phase i. A receipt may bind:

MS MS (vi−1 , vi ) so that continuation authority cannot be validly applied to an unrelated state lineage. A later phase may require:

CurrentV ersion = viMS before it can proceed.

A.31.13. E31.13 State-Digest Binding

Let:

GMS i = H(StateMS i ) or an equivalent protected commitment identify the resulting state. Continuation may require:

ObservedDigest = GMS i

or an equivalent membership/provenance proof. The exact state need not always be revealed if a protected commitment or privacy-preserving proof is sufficient.

A.31.14. E31.14 Automatic Continuation

Automatic progression may occur where:

V alid(RiMS )∧StateAcceptableMS i ∧P olicyCurrent∧RevocationClear∧W ithinM odelStateEnvelope(Pi+

is true. The proposing model or agent need not be permitted to mark these predicates as satisfied.

A.31.15. E31.15 Human Continuation

A protected human may review:

  • what state changed;

  • prior and new version;

  • affected model or agent;

  • evaluation evidence;

  • model behavior under bounded activation;

  • downstream consequence scope;

  • provenance;

  • and the next proposed expansion. The human may approve, deny, restrict, delay, or require further bounded evaluation. The human decision may be bound to RiMS and to the next state scope.

A.31.16. E31.16 Hybrid Continuation

A hybrid continuation may require:

V alid(RiMS ) ∧ AutoM odelStateP assi ∧ HumanApprovali before broader promotion. The system may also require hardware approval, destination confirmation, or a threshold of independent authorities.

A.31.17. E31.17 Progressive Memory Promotion

A persistent agent-memory embodiment may proceed as: 1. Candidate memory is created. 2. Candidate memory is written only to a provisional memory namespace. 3. A bounded evaluation session uses that memory. 4. A protected receipt confirms the exact memory object, source, and observed behavior. 5. Protected policy or a human approves promotion. 6. The memory object is promoted to the authoritative memory namespace. 7. A final receipt records authoritative promotion. The agent cannot promote the memory solely by asserting that the memory is valid.

A.31.18. E31.18 Progressive Vector-Memory Update

A vector-memory or retrieval-memory embodiment may bind:

  • source document digest;

  • embedding-model identity;

  • vector identifier;

  • namespace;

  • access policy;

  • user or tenant scope;

  • retrieval permissions;

  • provenance;

  • and downstream effect scope. The first phase may place the vector in a non-authoritative index. A bounded retrieval test produces R0MS . Only then may the vector be admitted to the authoritative retrieval index.

A.31.19. E31.19 Parameter / Adapter Promotion

A model adapter may be staged through:

Adaptercandidate → Replica0 → R0MS → ReplicaSet1 → R1MS → P roduction The adapter artifact itself may already exist, while authority to make it effective across progressively broader serving scope remains receipt-gated.

A.31.20. E31.20 Protected Policy-State Update

The state being changed may itself control later permissions. Examples include:

  • tool allowlists;

  • model routing policy;

  • action-risk thresholds;

  • destination permissions;

  • data-access policy;

  • execution-finality policy;

  • protected automation rules;

  • or human-approval thresholds. Because such state can indirectly enlarge later authority, E31 may require a stricter promotion path than ordinary application configuration.

A.31.21. E31.21 No Self-Authorization Through State Mutation

A model or agent must not obtain broader authority merely by writing state that declares itself trusted, approved, low-risk, or authorized. A protected implementation may enforce:

AgentW rite(T rustState) ⇏ T rustState = Authoritative unless a protected promotion path independently validates the change.

A.31.22. E31.22 Rollback and Previous-State Preservation

The system may preserve:

StateMS i−1

until the next phase is accepted. If RiMS = F AILU RE , the system may:

  • restore the prior state;

  • disable the candidate state;

  • quarantine the changed object;

  • stop deployment expansion;

  • require human review;

  • or create a compensating state update. Rollback itself may be protected where restoring an old state could reintroduce revoked or unsafe authority.

A.31.23. E31.23 Crash and Indeterminate State

If a system crashes after model-state promotion but before receipt return, blind reapplication may duplicate or corrupt the update. A phase-specific idempotency identifier may be used:

IiMS = H(DMS ∥ vi−1 MS ∥ P hasei ∥ Ni ) Protected reconciliation may determine whether the update was:

  • applied;

  • not applied;

  • partially applied;

  • rolled back;

  • or still indeterminate. Broader promotion remains blocked while the required state is indeterminate.

A.31.24. E31.24 Multi-Replica Model State

For replicated serving systems, phase i may affect a subset:

RMS i ⊆ RMS MAX

where the set contains model-serving replicas, devices, accelerators, or execution nodes. A protected aggregate receipt may require confirmation from all selected replicas or a protected quorum before expansion.

A.31.25. E31.25 Hardware-Rooted Model-State Promotion

A hardware implementation may keep the authoritative model-state key, registry key, or activation secret inside:

  • TEE;

  • HSM;

  • secure element;

  • accelerator security processor;

  • TPM-backed service;

  • DPU/SmartNIC security domain;

  • or another protected component. A candidate state may be stored but remain unusable until the hardware accepts the required prior receipt and releases phase-specific activation material.

A.31.26. E31.26 Accelerator-Resident State

Where model state resides in GPU or accelerator memory, E31 may combine with E30. A protected control path may require:

V alid(RiMS ) ∧ V alid(RiACC ) before the next model-state phase becomes active on the accelerator. This can bind both the state transition and the device on which the state is allowed to become effective.

A.31.27. E31.27 SEND Analogue

A communication system may treat an automatically learned recipient preference as provisional state. Example: 1. an agent proposes that future reports be automatically sent to recipient X ; 2. the preference is stored provisionally; 3. a bounded protected communication to X occurs; 4. the receiving endpoint confirms the intended identity; 5. a protected receipt is returned; 6. only then may the recipient preference become authoritative for later SEND operations. Thus a learned memory does not silently become authority to communicate externally.

A.31.28. E31.28 Payment Analogue

A financial agent may propose a learned beneficiary preference or recurring-payment rule. The rule may first remain provisional. A bounded verification transfer or protected destination confirmation produces a receipt. Only after protected validation may the beneficiary or recurringpayment state become authoritative within the authorized maximum envelope. The state update does not itself authorize payment beyond independently applicable payment controls.

A.31.29. E31.29 Anti-Bypass

An implementation intended to protect model-state finality should correspondingly control alternate paths capable of writing authoritative state, including:

  • direct database writes;

  • administrative consoles;

  • model-registry APIs;

  • direct object-store writes;

  • vector-index mutation APIs;

  • debug paths;

  • model-serving hot-reload interfaces;

  • accelerator memory loaders;

  • hidden configuration channels;

  • or equivalent state-changing routes. An unprotected alternate path must not make a protected promotion gate merely advisory.

A.31.30. E31.30 Required Invariants

The frozen core of E31 includes: 1. a model-state proposal is distinguishable from authoritative model state; 2. at least one protected path controls promotion into authoritative state; 3. a staged embodiment may make a bounded real state change before broader promotion; 4. protected evidence of the bounded state change may become a prerequisite for later promotion; 5. later state scope cannot exceed the maximum authorized model-state envelope merely because earlier evaluation succeeds; 6. the proposing model or agent cannot create authoritative approval solely by writing its own approval/trust state; 7. failure or indeterminate state blocks unauthorized broader promotion; 8. software, hardware, or split enforcement may be used.

FIGURATION UPDATE WITH PROGRESSIVE ACTIVATION

A.32. E32 — Receipt-Gated Software, Firmware, and Configuration Update with Progressive Activation

A.32.1. E32.1 Purpose

E32 applies staged effectuation to software, firmware, configuration, boot-image, package, application, operating-system, driver, controller, appliance, embedded-device, and infrastructure update operations. The embodiment distinguishes possession of an update artifact from authority to make that artifact effective. The central relationship is:

U pdate Artifact → Bounded Activation → P rotected U pdate Receipt → Continuation Authority → Br

An update may therefore be downloaded, cached, replicated, or staged without being authorized to become active everywhere.

A.32.2. E32.2 Candidate Update Act

Let:

AUP D denote a Candidate Update Act. The Candidate Update Act may identify:

  • package or image;

  • artifact digest;

  • signer;

  • software version;

  • firmware version;

  • configuration version;

  • target device or target class;

  • deployment cohort;

  • prerequisite version;

  • rollback version;

  • update slot;

  • activation time;

  • reboot requirement;

  • policy epoch;

  • allowed geographic region;

  • maximum target set;

  • and permitted post-update authority.

A protected act identifier may be:

DUP D = H(Canon(AUP D )) or an equivalent binding.

A.32.3. E32.3 Update Artifact Binding

Let:

GUP D = H(ArtifactUP D ) identify the exact update artifact or a protected manifest commitment. The activation authority may bind both:

DUP D and:

GUP D so that approval for one update cannot be substituted for another artifact.

A.32.4. E32.4 Staging Versus Activation

An update may pass through separate states such as:

Downloaded → V erified → Staged → Activated → Observed → P romoted Downloading or staging alone need not create the operational consequence associated with activation. This separation allows low-latency pre-positioning while preserving protected control of the final activation boundary.

A.32.5. E32.5 Maximum Update Envelope

Protected policy may define:

EUP MAX D

constraining:

  • device count;

  • device class;

  • tenant set;

  • geographic region;

  • server set;

  • service set;

  • boot slot;

  • component type;

  • firmware subsystem;

  • permitted version transition;

  • activation duration;

  • rollback authority;

  • and post-update capability. No prior successful canary receipt independently enlarges this maximum envelope.

A.32.6. E32.6 Phase-0 Real Update

Phase 0 may activate the real update on a deliberately bounded target. Examples include:

  • one server;

  • one VM;

  • one container host;

  • one network appliance;

  • one handset;

  • one vehicle controller;

  • one PLC;

  • one modem;

  • one satellite subsystem;

  • one GPU node;

  • one embedded device;

  • one availability zone;

  • one protected tenant;

  • one device class sample;

  • or one inactive A/B update slot that is actually booted and evaluated. The update must create a real operational state change within the bounded target if the embodiment relies upon real-update evidence.

A.32.7. E32.7 Target-Cohort Progression

Let:

DUP i D

denote the target device or system set for phase i. A progressive rollout may satisfy:

DUP D ⊂ DUP D ⊂ ⋯ ⊆ DUP MAX D

where nested cohort growth is appropriate. Non-nested cohorts may also be used where different regions, device classes, or hardware revisions require independent progression.

A.32.8. E32.8 Update Manifest

A protected Update Manifest may bind:

  • artifact digest;

  • version;

  • signer identity;

  • target hardware/software class;

  • prerequisite version;

  • permitted downgrade/upgrade direction;

  • secure-boot measurement;

  • boot slot;

  • post-install measurement;

  • expected services;

  • expected configuration;

  • rollback path;

  • receipt requirements;

  • and maximum activation scope. The manifest may itself be signed or authenticated by a protected authority.

A.32.9. E32.9 Phase-Specific Activation Authority

The PED may create:

CiUP D sufficient only to activate the update for phase i. The authority may comprise:

  • signed activation manifest;

  • update-slot unlock value;

  • boot authorization;

  • hardware monotonic-counter transition;

  • package-manager authorization;

  • firmware-install key;

  • device-specific update credential;

  • configuration-promotion token;

  • KMS release;

  • or another technical enablement condition.

A.32.10. E32.10 Protected Installation and Activation

The protected sink may verify:

  • DUP D ;

  • GUP D ;

  • target identity;

  • current version;

  • update path;

  • signature or MAC;

  • policy epoch;

  • revocation state;

  • phase identifier;

  • activation scope;

  • secure-boot state;

  • and anti-replay state. Only then may the update become operational.

A.32.11. E32.11 Post-Activation Observation

Following activation, a protected observer may evaluate:

  • successful boot;

  • expected software measurement;

  • expected firmware measurement;

  • service health;

  • crash rate;

  • network reachability;

  • data integrity;

  • policy integrity;

  • security-control availability;

  • resource use;

  • latency;

  • actuator state;

  • radio behavior;

  • model behavior;

  • storage behavior;

  • or another relevant condition.

A.32.12. E32.12 Update Effect Receipt

The system may generate:

RiUP D binding:

  • update act digest;

  • artifact digest;

  • target identity;

  • pre-update version;

  • post-update version;

  • post-update measurement;

  • boot slot;

  • health state;

  • observer identity;

  • phase identifier;

  • nonce;

  • and completion status.

A.32.13. E32.13 Measured-Boot / Secure-Boot Receipt

A hardware-rooted variation may use measured boot or secure boot.

Let:

μboot i

denote an illustrative post-update measured-boot value. Continuation may require:

μboot i ∈ ΩUP D boot

where ΩUP D boot represents an allowed measurement set or protected acceptable boot-state region. The exact attestation scheme is implementation-dependent.

A.32.14. E32.14 Automatic Rollout Continuation

Automatic progression may require:

V alid(RiUP D )∧HealthAcceptableUP i D ∧P olicyCurrent∧RevocationClear∧W ithinU pdateEnvelope(Pi+1

UP D before Ci+1 is released.

A.32.15. E32.15 Human Approval Between Update Phases

A human operator may review:

  • exact artifact;

  • exact version transition;

  • target cohort;

  • post-update health;

  • errors or regressions;

  • security measurements;

  • rollback availability;

  • and consequence of broader rollout. The human approval may be cryptographically bound to RiUP D and to the next cohort.

A.32.16. E32.16 Hybrid Update Approval

A high-assurance update may require:

V alid(RiUP D ) ∧ AutoU pdateP assi ∧ HumanApprovali or a threshold including vendor, enterprise, device, and hardware authorities.

A.32.17. E32.17 A/B Partition Update

A device may maintain:

  • active slot A;

  • inactive slot B . The update is written to the inactive slot. A protected boot component may permit one bounded boot into slot B . A protected receipt confirms the resulting measurement and health state. Only thereafter may slot B become the preferred or durable active slot. If the receipt is unacceptable, the device may return to slot A.

A.32.18. E32.18 Firmware Update

A firmware embodiment may apply to:

  • BIOS/UEFI;

  • BMC;

  • NIC firmware;

  • SmartNIC/DPU firmware;

  • SSD/controller firmware;

  • modem/baseband firmware;

  • GPU/accelerator firmware;

  • secure-element firmware;

  • embedded MCU firmware;

  • vehicle ECU firmware;

  • industrial-controller firmware;

  • satellite subsystem firmware;

  • or other device firmware. A protected hardware root may withhold activation authority until the exact firmware image and current device state satisfy policy.

A.32.19. E32.19 Configuration Update

The update may be configuration rather than executable code. Examples include:

  • routing policy;

  • firewall policy;

  • model-serving configuration;

  • device calibration;

  • feature flags;

  • execution-finality policy;

  • safety thresholds;

  • radio configuration;

  • cloud infrastructure configuration;

  • or industrial setpoint configuration. Because configuration can create consequential behavior, E32 may apply the same receipt-gated activation model.

A.32.20. E32.20 Dependency-Aware Update

An update may require a dependency set:

QUP D such as minimum firmware version, compatible driver version, model version, schema version, cryptographic module version, or device revision. Activation may require:

DependenciesSatisfied(QUP D ) = T RU E before the update becomes effective.

A.32.21. E32.21 Multi-Component Atomic Update

A protected update may involve multiple components that should advance consistently. For example:

  • application + database schema;

  • driver + firmware;

  • model + tokenizer;

  • controller + policy file;

  • bootloader + firmware;

  • network function + routing policy. The system may withhold final promotion until receipts from the required component set are accepted.

A.32.22. E32.22 Progressive Percentage Rollout

A fleet update may use an activation fraction:

ρiUP D with:

0 < ρ0UP D < ρ1UP D < ⋯ ≤ 1 where percentage-based progression is appropriate. The fraction may be adjusted downward or halted when protected health criteria degrade.

A.32.23. E32.23 Device-Class Segmentation

Different hardware revisions may have separate phase chains. For example:

ClassA ∶ P0A → R0A → P1A and:

ClassB ∶ P0B → R0B → P1B A receipt from Class A need not authorize Class B unless protected policy explicitly permits equivalence.

A.32.24. E32.24 Rollback Authority

Rollback may itself require protected authority. This is important where:

  • the previous version is revoked;

  • downgrade could reintroduce a vulnerability;

  • rollback would restore a deprecated cryptographic state;

  • old policy would grant broader authority;

  • or data/schema changes are not backward compatible.

Therefore:

RollbackAllowed ≠ T RU E merely because a new version fails.

A.32.25. E32.25 Update Failure

If:

RiUP D = F AILU RE then later activation phases remain unavailable unless a new protected decision authorizes another path. Responses may include:

  • rollback;

  • hold;

  • isolate target;

  • reduce cohort;

  • replace artifact;

  • patch configuration;

  • human escalation;

  • or terminate rollout.

A.32.26. E32.26 Indeterminate Update

If activation may have occurred but receipt delivery failed, the system should not blindly reinstall or advance. A phase-specific idempotency identifier may be:

IiUP D = H(DUP D ∥ GUP D ∥ Devicei ∥ P hasei ∥ Ni ) Reconciliation may query protected boot state, version registers, package database, firmware counters, attestation measurements, or other authoritative state.

A.32.27. E32.27 Anti-Rollback Counter

A hardware or firmware embodiment may maintain a monotonic counter:

cUP D or protected version floor. An update or rollback command may be accepted only if the resulting version satisfies protected monotonicity or an explicitly authorized exception.

A.32.28. E32.28 Cryptographic Activation Material

A staged update may be pre-positioned as ciphertext while activation material remains unavailable. After a valid receipt from an earlier cohort, the PED may release:

  • decryption key;

  • unwrap key;

  • signature authorization;

  • boot key;

  • slot-activation secret;

  • or equivalent material for the next cohort.

A.32.29. E32.29 Offline Device Update

A device without continuous network connectivity may enforce E32 locally. The update package may contain:

  • signed phase policy;

  • bounded activation authority;

  • expected measurements;

  • expiration;

  • maximum version transition;

  • and local receipt requirements. A local hardware root may advance only according to the preauthorized phase policy, later synchronizing receipts when connectivity returns.

A.32.30. E32.30 SEND Analogue

A communication-client update may first activate on one protected client or tenant. The client sends a bounded protected message and obtains a verified delivery receipt. Only then may the updated communication behavior be activated for a larger population. This preserves the principle that a successful software install alone does not prove correct external SEND behavior.

A.32.31. E32.31 Payment Analogue

A payment-processing update may first activate for a bounded protected transaction class or one low-value verification flow. A protected payment receipt confirms actual rail behavior. Broader payment authority remains unavailable until that receipt and applicable policy are accepted.

A.32.32. E32.32 Alternate-Path Closure

Equivalent activation routes may include:

  • direct package manager;

  • administrator shell;

  • bootloader recovery mode;

  • vendor update utility;

  • firmware flashing port;

  • debug interface;

  • BMC path;

  • device-management API;

  • container image override;

  • configuration-management bypass;

  • or another path capable of making the update effective. Where non-bypassability is required, such paths are disabled, mediated, cryptographically locked, or placed under equivalent protected control.

A.32.33. E32.33 Required Invariants

The frozen core of E32 includes: 1. update possession/staging is distinguishable from update activation; 2. update authority is bound to the intended artifact or permitted artifact class; 3. a staged embodiment may first activate the update on a bounded real target; 4. protected evidence from the bounded activation may become a prerequisite for broader activation; 5. later rollout cannot exceed the maximum update envelope merely because earlier targets succeed; 6. failure or indeterminate state blocks unauthorized broader rollout; 7. rollback may itself be policy-controlled; 8. software, firmware, hardware, and configuration updates may use the architecture; 9. alternate activation routes are correspondingly controlled where required for non-bypassability.

SINK, AND DISTRIBUTED RECEIPT-GATED EFFECTUATION

A.33. E33 — Multi-Destination, Multi-Recipient, Multi-Sink, and Distributed Receipt-Gated Effectuation

A.33.1. E33.1 Purpose

E33 applies staged effectuation where a single Candidate Act or protected effectuation plan may affect multiple destinations, recipients, sinks, endpoints, devices, accounts, regions, services, machines, or other consequence-bearing targets. The embodiment prevents success at one destination from automatically becoming authority for all other destinations unless protected policy expressly defines that relationship. The central relationship is:

Candidate M ultiDestination Act → Bounded Destination Set → DestinationBound Receipts → P rote

A.33.2. E33.2 Candidate Multi-Destination Act

Let:

AMD denote a Candidate Multi-Destination Act. The act may represent:

  • sending one message to multiple recipients;

  • transferring a file to multiple destinations;

  • distributing software to multiple devices;

  • executing payments to multiple beneficiaries;

  • deploying a model to multiple regions;

  • changing policy across multiple network domains;

  • operating multiple robots or actuators;

  • exporting data to multiple processors or storage systems;

  • releasing credentials to multiple services;

  • or another act whose consequence spans more than one target.

A protected act digest may be:

DMD = H(Canon(AMD ))

A.33.3. E33.3 Maximum Destination Set

Let:

ZMAX denote the maximum authorized destination/recipient/target set. A phase-specific active set is:

Zi ⊆ ZMAX The architecture may enforce:

Zi+1 ⊈ ZMAX ⇒ Enable(Pi+1 ) = F ALSE so a valid receipt chain cannot create unauthorized target expansion.

A.33.4. E33.4 Destination Identity Binding

Each destination may have a protected destination identity:

zj and destination-specific receipt:

MD Ri,j A receipt generated for zj should not normally authorize effectuation to a materially different destination zk unless protected policy defines a valid equivalence class.

A.33.5. E33.5 Destination Descriptor

A destination descriptor may bind:

  • destination identifier;

  • recipient identity;

  • account;

  • device;

  • endpoint;

  • network address;

  • service identity;

  • region;

  • jurisdiction;

  • sink identity;

  • public key or credential identity;

  • permitted effect class;

  • data classification;

  • maximum amount or scope;

  • and phase eligibility. The descriptor may be included in the Candidate Act, a separate protected target list, or a phase plan.

A.33.6. E33.6 Bounded Initial Destination Set

Phase 0 may operate on:

Z0 where:

|Z0 | < |ZMAX | for a staged multi-destination embodiment. Examples include:

  • one recipient before a distribution list;

  • one payment beneficiary before a payout batch;

  • one region before a global deployment;

  • one device before a fleet;

  • one storage destination before replication;

  • one network peer before broader routing;

  • one robot before a robot group;

  • one model-serving cluster before all clusters.

A.33.7. E33.7 Destination-Specific Effectuation Authority

The PED may issue destination-specific authority:

MD Ci,j bound to destination zj and phase i. A general protected property is:

MD Ci,j ⇏ Authority(zk ) for an unauthorized zk .

A.33.8. E33.8 Destination-Specific Cryptographic Material

A strong cryptographic variation may derive:

MD MD AGG Ki,j = KDF (KR , DMD , zj , H(Ri−1 ), i) where applicable. The exact KDF is non-limiting. The protected property is that effectuation material for one destination is not freely reusable for another destination.

A.33.9. E33.9 Parallel Destination Effectuation

A phase may operate on several destinations in parallel:

{z1 , z2 , ... , zk } Each destination may produce an independently protected receipt. The system need not force sequential per-destination execution where parallel execution is permitted by protected policy.

A.33.10. E33.10 Aggregate Receipt Set

For phase i, let:

RMD i MD = {Ri,1 MD , Ri,2 MD , ... , Ri,k } represent the destination-receipt set. A protected aggregate receipt may commit to the set:

RiAGG = P rotect(DMD , P hasei , Commit(RMD i ), Statusi ) where Commit may be a Merkle root, hash-list commitment, authenticated set commitment, threshold attestation, or equivalent mechanism.

A.33.11. E33.11 All-Destination Confirmation Rule

A strict phase may require:

MD ∀zj ∈ Zi ∶ V alid(Ri,j ) = T RU E before broader progression. This may be appropriate where all selected targets must behave correctly before any expansion.

A.33.12. E33.12 Quorum Destination Confirmation

Another phase may require:

MD ∑ 1[V alid(Ri,j )] ≥ qi zj ∈Zi

where qi is a protected destination-confirmation threshold. The system may also require that no designated critical destination has failed.

A.33.13. E33.13 Weighted Destination Confirmation

Destinations may have protected weights:

wjMD and continuation may require:

∑ wjMD ⋅ 1[V alid(Ri,j MD )] ≥ τiMD j

where τiMD is a protected weighted threshold. This may be useful where certain regions, devices, or authorities have different assurance significance.

A.33.14. E33.14 Critical-Destination Predicate

Let:

Zcrit ⊆ Zi represent critical destinations. Continuation may require:

MD ∀zj ∈ Zcrit ∶ V alid(Ri,j ) = T RU E regardless of the aggregate success rate.

A.33.15. E33.15 Partial Success

If only a subset succeeds:

Zsucc,i ⊂ Zi then protected policy may:

  • continue only for successful destinations;

  • retry failed destinations under new authority;

  • remove failed destinations;

  • require human review;

  • reduce next-phase scope;

  • substitute an explicitly authorized destination;

  • or terminate the entire operation. Partial success does not automatically imply permission to reroute to an unapproved destination.

A.33.16. E33.16 Failed-Destination Set

Let:

Zfail,i denote destinations with protected failure status. The next phase may explicitly exclude:

Zfail,i unless a new protected decision authorizes retry or remediation.

A.33.17. E33.17 Indeterminate-Destination Set

Let:

Zind,i denote destinations whose effect state is indeterminate. The architecture may freeze only those destinations, or the entire phase, depending on protected policy. For non-idempotent effects such as payments or messages, blind retry to an indeterminate destination may be prohibited.

A.33.18. E33.18 Per-Destination Reconciliation

Each destination may use its own idempotency identifier:

MD Ii,j = H(DMD ∥ zj ∥ P hasei ∥ Ni,j ) Reconciliation may determine:

  • PROVEN_EFFECTED;

  • PROVEN_NOT_EFFECTED;

  • STILL_INDETERMINATE;

  • or another protected status for each destination independently.

A.33.19. E33.19 Progressive Destination Expansion

A progressive rollout may use:

Z0 ⊂ Z1 ⊂ ⋯ ⊆ ZMAX where nested expansion is appropriate. The next set may be determined adaptively from prior receipt quality, destination class, risk, policy, jurisdiction, latency, cost, or human approval.

A.33.20. E33.20 Destination-Class Progression

Destinations may be partitioned into classes:

  • internal;

  • external;

  • trusted partner;

  • high-risk;

  • regulated;

  • geographic region;

  • device class;

  • account class;

  • service class;

  • or another protected category. A low-risk class may progress automatically while a high-risk class requires human approval.

A.33.21. E33.21 Multi-Recipient SEND Workflow

A communication embodiment may proceed as: 1. create a maximum authorized recipient set; 2. select one or a small bounded recipient subset; 3. send a real protected trailer or bounded communication; 4. obtain destination-specific receipts; 5. verify identity, delivery path, and receipt validity; 6. form an aggregate decision; 7. release the full message or additional recipients only where protected continuation conditions are satisfied. A receipt from recipient A does not by itself authorize disclosure to recipient B .

A.33.22. E33.22 Group Message With Per-Recipient Keys

A group message may be encrypted once or represented through a shared content object, while recipient-specific key-wrapping material remains independently controlled. For recipient zj :

MD Kwrap,j may be released only after the required recipient-specific conditions are satisfied. This permits a common ciphertext object while preserving per-recipient effectuation control.

A.33.23. E33.23 Multi-Beneficiary Payment Workflow

A payment batch may define:

ZMAX = {Account1 , ... , Accountn } The system may first execute bounded transfers to a subset, validate payment-rail receipts, and then authorize remaining beneficiaries according to protected policy. A successful transfer to one beneficiary must not be treated as proof that another beneficiary identity, bank route, currency, or settlement path is correct.

A.33.24. E33.24 Multi-Region Deployment Workflow

A cloud/model/software deployment may progress through:

AGG Region1 → R1 → {Region2 , Region3 } → R2,3 → GlobalSet with protected health evidence and destination-specific state at each stage.

A.33.25. E33.25 Multi-Sink Effectuation

Different destinations may use different Finality Sinks. Let:

Sink(zj ) denote the sink expected for destination zj . The destination authority may bind:

(zj , Sink(zj )) so a valid receipt from one sink cannot silently substitute for another required sink.

A.33.26. E33.26 Heterogeneous Sink Types

A multi-destination act may span heterogeneous sinks, for example:

  • payment gateway;

  • message gateway;

  • storage controller;

  • device actuator;

  • cloud deployment controller;

  • hardware security module;

  • telecom gateway;

  • and remote destination service. Protected policy may require different receipt predicates for each sink type before aggregate continuation.

A.33.27. E33.27 Cross-Jurisdiction Destination Control

A destination may carry jurisdiction or policy metadata. A protected next-set function may be:

Zi+1 = f(RMD i , P olicyi , Riski , J urisdictioni , Approvali ) A successful receipt in one jurisdiction does not necessarily authorize progression into another jurisdiction.

A.33.28. E33.28 Human Approval of Destination Expansion

A protected human may review:

  • destinations already effected;

  • successful and failed receipt sets;

  • proposed new destination set;

  • recipient identities;

  • data or amount involved;

  • jurisdiction;

  • risk;

  • and maximum remaining consequence.

Human approval may be bound to the exact next set:

Zi+1 rather than to an open-ended future distribution.

A.33.29. E33.29 Automatic Destination Expansion

Automatic progression may require:

AggregateV alid(RMD i )∧DestinationP olicyP assi ∧W ithinDestinationEnvelope(Zi+1 )∧RevocationClea

before the next set is enabled.

A.33.30. E33.30 Hybrid Destination Expansion

A hybrid embodiment may automatically expand within one class but require human approval for another. For example:

zj ∈ T rustedClass ⇒ Auto and:

zj ∈ ExternalHighRiskClass ⇒ HumanApproval The class labels and thresholds remain protected policy.

A.33.31. E33.31 Destination Revocation

A destination may be revoked after earlier phases. If:

Revoked(zj ) = T RU E then unused destination-specific authority for zj becomes invalid even if the aggregate act remains authorized for other destinations.

A.33.32. E33.32 Destination Substitution

Substitution of a failed or unavailable destination should require protected policy. A replacement destination:

zj′ must not inherit authority merely because zj was previously authorized. A protected rebind may require new destination identity validation, policy evaluation, and approval.

A.33.33. E33.33 Duplicate-Destination and Alias Handling

Two identifiers may resolve to the same underlying destination. The system may canonicalize destination identity to prevent duplicate effects where:

  • aliases;

  • redirects;

  • account aliases;

  • replicated endpoint names;

  • multiple network addresses;

  • or service discovery entries refer to the same consequential target. Protected duplicate detection may therefore operate on a canonical destination identity rather than only presentation strings.

A.33.34. E33.34 Destination-Path Binding

Where route matters, receipt validity may bind not only destination identity but the permitted path, gateway, region, or service chain. This may be used for:

  • regulated data routing;

  • payment rails;

  • telecom interconnect;

  • secure messaging;

  • cross-region storage;

  • or hardware control paths.

A.33.35. E33.35 Recipient Privacy Variation

A multi-recipient system need not expose the entire recipient list to every component. The aggregate commitment may use:

  • Merkle root;

  • blinded identifier set;

  • privacy-preserving membership proof;

  • destination-local tokens;

  • or another protected commitment. The system may prove that a destination belongs to the authorized set without revealing unrelated recipients.

A.33.36. E33.36 Threshold Cryptography Across Destinations

E33 may combine with E11. For example, a later group key or continuation authority may require protected receipt shares from q of n destinations or independent sink observers. The resulting authority may remain bound to the next destination set and maximum effect envelope.

A.33.37. E33.37 Hardware-Enforced Multi-Destination Release

A hardware security component may hold destination-specific keys or unwrap material. The component may release:

MD Ki,j only if:

  • the prior required aggregate receipt is valid;

  • destination zj is authorized;

  • phase i is current;

  • policy is current;

  • revocation is clear;

  • and the maximum destination envelope is not exceeded.

A.33.38. E33.38 Multi-Destination Receipt Tree

For large target populations, the receipt set may be represented as a tree. A protected root:

RootMD i

may commit to destination-specific leaves containing destination identity, effect status, nonce, sink, and result. A later phase may verify membership or aggregate predicates without transporting every receipt to every component.

A.33.39. E33.39 Completion Semantics

The multi-destination operation may define several completion classes:

  • ALL_DESTINATIONS_COMPLETED;

  • REQUIRED_QUORUM_COMPLETED;

  • CRITICAL_DESTINATIONS_COMPLETED;

  • PARTIAL_COMPLETION;

  • COMPENSATED;

  • FAILED;

  • INDETERMINATE. The selected completion semantics are protected policy and should not be inferred merely from a raw success percentage.

A.33.40. E33.40 Final Multi-Destination Receipt

A final receipt may bind:

RFMD = P rotect(DMD , Commit(Zeffected ), Commit(RMD final ), F inalStatus)

This may provide compact evidence of which authorized destinations actually received or experienced the effect.

A.33.41. E33.41 Alternate-Path Closure

A multi-destination architecture may be bypassed if an actor can use another credential, endpoint, route, batch API, broadcast interface, group key, administrator function, or direct hardware path to reach additional destinations without the required destination-bound authority. Such paths may therefore be:

  • disabled;

  • mediated;

  • separately authorized;

  • cryptographically bound;

  • destination-filtered;

  • or placed under equivalent receipt-gated control.

A.33.42. E33.42 Required Invariants

The frozen core of E33 includes: 1. the maximum authorized destination set is distinguishable from the currently enabled destination set; 2. destination-specific authority is bound to the intended target or a protected target class; 3. receipt from one destination does not automatically authorize a materially different destination; 4. a bounded destination subset may be effected before a broader set; 5. protected destination receipts may be aggregated under all, quorum, weighted, critical-target, or other protected rules; 6. partial, failed, and indeterminate destination states remain distinguishable; 7. broader progression cannot exceed the maximum authorized destination set; 8. human, automatic, and hybrid expansion are supported; 9. software, hardware, or split enforcement may be used; 10. alternate paths capable of unauthorized destination expansion are correspondingly controlled where non-bypassability is required.

FROZEN RELATIONSHIP BETWEEN E31, E32 AND E33 The three embodiments extend the receipt-gated architecture into three different consequence domains.

E31 P roposed M odel State → Bounded Authoritative U se → State Receipt → Broader State P romotion The focus is what becomes authoritative internal state for later model/agent behavior.

E32 Staged U pdate → Bounded Real Activation → U pdate Receipt → Broader Activation The focus is what software/firmware/configuration becomes operational.

E33 Bounded Destination Set → Destination Receipts → Aggregate P rotected Decision → Broader Destin The focus is where the consequence is permitted to propagate. These embodiments may be combined. For example, a new model state (E31) may require a software/model-serving update (E32), which may then be activated across progressively larger destination or regional sets (E33).

A.34. E34 — Replicated, Quorum-Confirmed, and Consensus Receipt-Gated Effectuation

A.34.1. E34.1 Purpose

E34 applies receipt-gated effectuation to systems in which a consequential act, state transition, communication, payment state, deployment state, control decision, storage mutation, model-state update, or hardware command is represented, executed, observed, or committed across multiple replicas, observers, nodes, services, controllers, or protected authorities. The embodiment addresses a central distributed-systems problem: a single local success indication may be insufficient to establish that a consequential act has reached the required replicated state. Accordingly, E34 permits continuation authority to depend upon a protected set of replica-specific receipts and a protected quorum, consensus, commit-certificate, or equivalent aggregate confirmation rule. The central relationship is:

Candidate Act → Bounded Replicated Effect → Replica Receipts → P rotected Quorum/Consensus Confirmation → Broader or F inal Effectuation

E34 may operate with E03 multi-phase progression, E16 database promotion, E17 cloud rollout, E25-E27 physical systems, E28 telecom, E29 NTN/satellite, E30 accelerator systems, E31 model-state update, E32 software/firmware update, E33 multi-destination effectuation, or another embodiment.

A.34.2. E34.2 Replicated Effectuation Set

Let:

NREP = {n1 , n2 , ... , nm }

represent the protected set of replicas, observers, authorities, nodes, devices, controllers, or services relevant to a replicated effectuation decision. Members may comprise, without limitation:

  • database replicas;

  • transaction replicas;

  • consensus nodes;

  • message brokers;

  • storage replicas;

  • cloud nodes;

  • availability-zone controllers;

  • regional controllers;

  • device controllers;

  • redundant safety controllers;

  • telecom network functions;

  • satellite or ground-segment controllers;

  • accelerator nodes;

  • secure enclaves;

  • HSMs;

  • independent effect observers;

  • destination-side observers;

  • or another protected component whose state contributes to continuation authority. The set may be static or protectedly reconfigured.

A.34.3. E34.3 Replica-Specific Phase Authority

For phase i, a protected system may issue replica-specific authority:

REP Ci,j

for replica or protected participant nj .

The authority may bind:

  • Candidate Act digest;

  • phase identifier;

  • replica identity;

  • replica role;

  • permitted operation;

  • permitted state transition;

  • expected prior version;

  • expected destination;

  • nonce;

  • policy epoch;

  • revocation state;

  • and maximum local consequence. A replica-specific authority for one participant need not authorize another participant.

A.34.4. E34.4 Real Replicated Effect

Phase i may cause a real effect at one or more members of NREP . Examples include:

  • one or more database replicas persist a bounded record set;

  • one or more message brokers durably enqueue a bounded communication;

  • one or more cloud nodes activate a bounded deployment;

  • one or more hardware controllers adopt a bounded command state;

  • one or more payment-side systems record a reservation or accepted state;

  • one or more telecom nodes activate a bounded policy;

  • one or more model-serving replicas adopt a bounded model-state change;

  • or one or more protected observers confirm a real external effect. The architecture does not require every member to perform the same physical operation. Different members may contribute different protected roles to the aggregate confirmation.

A.34.5. E34.5 Replica Receipt

Each participating member may generate a protected receipt:

REP Ri,j

binding, where applicable:

  • act identity;

  • phase identity;

  • replica identity;

  • replica role;

  • actual observed operation;

  • actual resulting local state;

  • prior-state version;

  • new-state version;

  • transaction or log position;

  • nonce;

  • protected time or sequence state;

  • status;

  • and prior receipt-chain material. A receipt from nj is not automatically substitutable for a receipt required from nk .

A.34.6. E34.6 Replica Role Binding

Protected policy may assign roles to replicas. Example roles include:

  • proposer;

  • effecting replica;

  • witness;

  • storage replica;

  • destination witness;

  • safety controller;

  • ledger witness;

  • quorum voter;

  • independent verifier;

  • hardware observer;

  • or commit-certifying authority. A continuation rule may require not merely a count of receipts, but receipts from defined role classes.

For example:

Required = 2 StorageReceipts ∧ 1 IndependentObserver ∧ 1 SafetyController

A.34.7. E34.7 Protected Receipt Set

For phase i, the protected receipt verifier may form:

RREP i REP = {Ri,1 REP , Ri,2 , ...}

The set may contain:

  • successful receipts;

  • failed receipts;

  • rejected receipts;

  • negative receipts;

  • indeterminate receipts;

  • stale receipts;

  • conflicting receipts;

  • or receipts excluded by protected policy. Only receipts satisfying the required validation rules contribute to continuation.

A.34.8. E34.8 Quorum Rule

A count-based quorum may require:

m REP ∑ V alid(Ri,j ) ≥ qiREP j=1

where qiREP is the protected minimum valid-confirmation count. The threshold may be:

  • fixed;

  • phase-dependent;

  • risk-dependent;

  • role-dependent;

  • destination-dependent;

  • dynamically raised;

  • or determined by protected policy. A quorum count is one embodiment, not a mandatory consensus protocol.

A.34.9. E34.9 Weighted Quorum

Protected participants may have different weights. Let:

wjREP

represent the protected weight of participant nj . Continuation may require:

m ∑ wjREP ⋅ V alid(Ri,j REP ) ≥ τiREP j=1

where τiREP is a protected weighted threshold. Weight may reflect role, trust level, hardware protection, organizational independence, geographic independence, or another protected criterion.

A.34.10. E34.10 Role-Constrained Quorum

A stronger rule may require both numerical quorum and mandatory-role satisfaction. For example:

Quorumi ∧ DestinationW itnessi ∧ HardwareW itnessi ∧ P olicyAuthorityi

may all be required before continuation. Thus three receipts from the same role class cannot necessarily replace one required independent role.

A.34.11. E34.11 Consensus Confirmation

Where an implementation uses a consensus protocol, replicated state machine, distributed transaction protocol, or equivalent agreement mechanism, continuation may depend upon a protected confirmation that the relevant effect has reached the required consensus state. This may be represented as:

ConsensusConfirmedi = T RU E

only when the protected conditions associated with the chosen protocol have been satisfied. E34 does not require any particular consensus algorithm.

A.34.12. E34.12 Commit Certificate

A protected aggregate confirmation may be represented by a Commit Certificate:

CCi

The Commit Certificate may bind:

  • Candidate Act digest;

  • phase identifier;

  • protected membership/version state;

  • receipt-set commitment;

  • quorum rule;

  • satisfied role constraints;

  • resulting replicated state version;

  • protected decision status;

  • policy epoch;

  • and continuation eligibility. The Commit Certificate may be a signed object, multi-signature, threshold signature, attestation, ledger commitment, Merkle-root-bound structure, or another protected aggregate artifact.

A.34.13. E34.13 Commit Certificate Construction

One illustrative construction is:

CCi = P rotect(DA , P hasei , Root(RREP i ), ViREP , QREP i , P olicyEpoch)

where QREP i represents the protected quorum/consensus result and ViREP represents the resulting replicated-state version. The construction is illustrative and non-limiting.

A.34.14. E34.14 Receipt-Tree Aggregation

A large replicated system need not place every receipt directly inside a continuation artifact. The system may compute:

RootREP i REP = M erkleRoot(Ri,1 REP , ... , Ri,k )

or use another authenticated aggregate commitment. The protected verifier may retain enough information to prove which receipts participated in the quorum result.

A.34.15. E34.15 Replicated-State Version Binding

Continuation authority may bind the replicated-state version:

ViREP

or an equivalent log position, term, epoch, sequence number, transaction version, block height, generation identifier, or protected state digest. This prevents a valid receipt from an obsolete replicated state from being reused as if it described the current state.

A.34.16. E34.16 Membership Version Binding

Where the participating set changes, protected policy may maintain:

M embEpochi

representing the membership configuration applicable to phase i. A receipt created under an obsolete membership configuration need not satisfy a quorum defined under a later membership configuration. Protected reconfiguration may itself require receipt-gated effectuation.

A.34.17. E34.17 Replica Lag

Some replicas may be valid but delayed. Let:

Lagi,j

represent a protected measure or classification of replica lag. Protected policy may:

  • accept bounded lag;

  • exclude stale replicas from quorum;

  • delay continuation;

  • require stronger quorum;

  • require catch-up evidence;

  • or route future phases away from the lagging replica. A lagging replica must not be silently treated as having observed an effect it has not yet confirmed.

A.34.18. E34.18 Partial Replica Success

After a real phase, participants may partition into:

NREP succ,i , NREP fail,i , NREP ind,i

representing proven-successful, proven-failed, and indeterminate members. Continuation policy may depend on the composition of these sets rather than on a single binary system status.

A.34.19. E34.19 Critical Replica Requirement

Protected policy may identify:

NREP crit

as a critical participant set. Even if a numerical quorum succeeds, continuation may remain blocked where a mandatory critical participant has not confirmed the required state. For example, a payment-side quorum may still require the receiving institution’s protected confirmation; a robotic system may still require a safety-controller receipt; a storage system may still require the authoritative metadata controller.

A.34.20. E34.20 Split-Brain Detection

A replicated system may produce mutually incompatible protected observations. Example:

REP Ri,a ⇒ State = X

while:

REP Ri,b ⇒ State = Y

with:

X≠Y

where the two states cannot both satisfy the relevant protected invariant. The system enters a Split-Brain Effect State rather than arbitrarily selecting one outcome.

A.34.21. E34.21 Split-Brain Effect State

A protected split-brain state may cause:

Enable(Pi+1 ) = F ALSE

until reconciliation determines an acceptable authoritative state. Possible responses include:

  • freeze progression;

  • isolate inconsistent replicas;

  • require a stronger authority;

  • select an authoritative log or state source;

  • re-run bounded verification;

  • require human review;

  • or terminate the candidate act.

A.34.22. E34.22 Byzantine or Malicious Replica Variation

Where threat models include malicious or compromised replicas, the quorum/consensus rule may require sufficient independent protected confirmations such that one or more malicious participants cannot independently unlock broader effectuation. The embodiment may use:

  • threshold signatures;

  • hardware-attested participants;

  • organizationally independent witnesses;

  • diversity of implementation;

  • protected membership;

  • fault thresholds;

  • or another Byzantine-resilient mechanism. E34 does not require a specific Byzantine consensus algorithm.

A.34.23. E34.23 Same-Organization Replica Variation

Replicas need not be operated by different organizations. A cloud provider may use multiple protected nodes or services under one administrative domain while still requiring independent protected receipt paths. The technical property is that the continuation decision depends on the required independently generated protected state evidence, not merely on an unverified assertion by the proposing process.

A.34.24. E34.24 Cross-Organization Replica Variation

Alternatively, protected confirmations may come from different organizations, institutions, trust domains, jurisdictions, or infrastructure operators. Examples include:

  • sender and receiver institutions;

  • cloud provider and customer enclave;

  • telecom operator and destination network;

  • spacecraft and ground station;

  • payer system and payee-side institution;

  • device vendor and enterprise controller;

  • or multiple regulated/independent authorities.

A.34.25. E34.25 Phase-Specific Quorum

Different phases may require different thresholds. For example:

q0REP = 2, q1REP = 3, q2REP = 5 as consequence increases. A later phase may also require a different role composition, not merely a larger count.

A.34.26. E34.26 Risk-Adaptive Quorum

The protected quorum requirement may depend on risk. Illustratively:

REP qi+1 = f(Riski , EffectScopei+1 , ReceiptQualityi , P olicyi ) Higher consequence or lower confidence may require more independent confirmations.

A.34.27. E34.27 Human Approval After Quorum

A protected human approval may be required after quorum or consensus confirmation. Flow:

Replica Effects → Replica Receipts → CCi → HumanReview → Pi+1 The human therefore reviews protected aggregate evidence rather than a mere unverified success message.

A.34.28. E34.28 Automatic Continuation After Quorum

Automatic continuation may occur where:

V alid(CCi ) ∧ P olicyP assi ∧ RiskAcceptablei ∧ W ithinEnvelope(Pi+1 ) is true. The proposing agent need not possess authority to manufacture CCi .

A.34.29. E34.29 Hybrid Continuation

A hybrid implementation may require:

V alid(CCi ) ∧ AutomaticP rotectedDecisioni ∧ HumanApprovali

before broader effectuation. Threshold authority from E11 may also be used to combine multiple protected decision sources.

A.34.30. E34.30 Receipt-Derived Continuation Authority

Continuation authority may be bound to the Commit Certificate:

REP Ci+1 = Derive(DA , H(CCi ), P hasei+1 , Scopei+1 )

or equivalent missing execution material may be released only after CCi validates.

A.34.31. E34.31 Hardware-Rooted Aggregate Confirmation

An HSM, TEE, secure element, security coprocessor, DPU, SmartNIC, controller, FPGA, ASIC, or other protected component may verify the required replica receipts and expose only a phase-specific continuation authority. Ordinary software may therefore be unable to bypass the distributed confirmation requirement by directly generating the next-stage capability.

A.34.32. E34.32 Database Replication Example

A bounded mutation is written to a replicated database. Phase 0 may require:

  • leader acceptance;

  • at least two durable follower acknowledgements;

  • protected commit-index confirmation;

  • and no detected conflict. Only then may a broader data migration, secondary mutation, external notification, or irreversible follow-on action be released. The database’s own replication semantics may be used where they provide the required protected evidence, or E34 may layer an additional protected receipt mechanism above them.

A.34.33. E34.33 Distributed Storage Example

A sensitive object may be written to a bounded storage replica set. Replica receipts confirm:

  • object digest;

  • protected destination;

  • encryption state;

  • storage generation;

  • durability class;

  • and local acceptance. Broader visibility, decryption-key release, deletion of the source copy, or distribution to additional storage regions may depend on the protected aggregate confirmation.

A.34.34. E34.34 SEND / Messaging Example

A consequential communication may be delivered through redundant brokers or destination-side services. A protected continuation rule may require:

  • broker acceptance receipt;

  • destination-domain receipt;

  • and intended-recipient endpoint receipt; before releasing a larger attachment, decryption key, follow-up command, or broader recipient set. A mere sender-side “queued” state need not be treated as proof of recipient-side effect.

A.34.35. E34.35 Payment Example

A bounded payment phase may produce protected evidence from multiple points, such as:

  • originating payment processor;

  • transaction rail;

  • beneficiary-side institution;

  • settlement/ledger observer;

  • or escrow/conditional-holding component. Continuation to the remaining payment amount may require a protected quorum/role rule appropriate to the infrastructure. E34 does not assume that every payment system exposes the same confirmation semantics.

A.34.36. E34.36 Cloud Deployment Example

A bounded deployment may be activated across a small replica set. Protected receipts may confirm:

  • artifact identity;

  • node health;

  • configuration digest;

  • traffic state;

  • policy state;

  • and actual activation. A Commit Certificate may then authorize broader rollout to additional nodes, zones, or regions.

A.34.37. E34.37 Telecom Example

A network-control update may be applied to a bounded subset of network functions. Protected confirmations may come from:

  • control plane;

  • data plane;

  • gateway;

  • baseband or radio unit;

  • destination network;

  • or independent telemetry authority. Broader rollout may remain blocked until the required protected quorum is satisfied.

A.34.38. E34.38 Physical-Control Example

A redundant robotic or industrial controller may require multiple protected observations of the bounded physical effect. For example:

  • local encoder receipt;

  • independent safety sensor receipt;

  • controller-state receipt;

  • and remote supervisory receipt. A later, larger movement remains unavailable unless the configured quorum/role predicate is satisfied.

A.34.39. E34.39 Replica Failure During Phase

If one or more replicas fail during a phase, protected policy may:

  • continue if quorum and critical-role requirements remain satisfied;

  • reduce the next-phase scope;

  • substitute a preauthorized replica;

  • require reconfiguration;

  • enter reconciliation;

  • or terminate progression. A failed replica is not silently counted as a successful receipt.

A.34.40. E34.40 Membership Change During Phase

If the protected membership configuration changes while a phase is active, the system may:

  • complete under the old membership epoch;

  • abort and restart under the new epoch;

  • require both old and new quorum rules;

  • or freeze progression pending protected review. The selected rule should be bound to protected state so that membership cannot be changed merely to manufacture an easier quorum.

A.34.41. E34.41 Late Receipt Handling

A receipt arriving after quorum has already been formed may be:

  • retained as supplementary evidence;

  • used to update replica health;

  • ignored for the already-consumed continuation decision;

  • used for reconciliation;

  • or treated as conflicting evidence if it contradicts the committed state. It must not independently cause duplicate continuation after the relevant aggregate authority has already been consumed.

A.34.42. E34.42 Quorum Receipt Consumption

Where a Commit Certificate or aggregate confirmation is single-use for a transition:

Consumed(CCi ) = T RU E

may be recorded atomically with issuance or consumption of the next-stage authority. Replay of CCi must not produce duplicate unauthorized broader effectuation.

A.34.43. E34.43 Replica Receipt Replay Protection

Replica receipts may bind:

  • phase nonce;

  • transaction identifier;

  • replicated-state version;

  • membership epoch;

  • receipt sequence;

  • and replica identity. A receipt from an earlier phase or earlier membership configuration must not silently satisfy a later quorum.

A.34.44. E34.44 Conflicting Aggregate Certificates

If two incompatible aggregate certificates appear for the same protected transition, the system may treat this as a high-assurance conflict state. Broader effectuation may be blocked until:

  • certificate provenance is verified;

  • membership state is reconciled;

  • revoked keys are checked;

  • protected logs are inspected;

  • and an authoritative state is established.

A.34.45. E34.45 Network Partition

During a network partition, different participant subsets may observe different states. Protected policy may require that no partition lacking the necessary protected quorum and critical-role composition can generate continuation authority. Where both partitions can independently satisfy a quorum under the selected protocol, additional consensus/fencing/epoch rules may be required to prevent contradictory effectuation chains.

A.34.46. E34.46 Fencing and Epoch Authority

A protected fencing value, lease epoch, term, generation, or equivalent monotonically controlled state may be incorporated into authority and receipts. A participant with an obsolete fencing value cannot validly extend the current effectuation chain. This may be particularly useful for database leaders, storage controllers, cloud orchestration, and industrial controllers.

A.34.47. E34.47 Reconciliation After Replica Divergence

Reconciliation may compare:

  • protected logs;

  • replica versions;

  • transaction IDs;

  • sink records;

  • destination state;

  • hardware counters;

  • commit certificates;

  • receipt trees;

  • and current membership state.

The result may identify:

  • authoritative committed state;

  • non-authoritative divergent state;

  • still-indeterminate state;

  • or a state requiring protected human intervention.

A.34.48. E34.48 Anti-Bypass Requirement

Where replicated confirmation is required for a consequence, an alternate path must not permit the same or broader consequence based solely on one unverified replica. Relevant bypasses may include:

  • direct leader API;

  • direct database connection;

  • administrative write path;

  • raw storage path;

  • privileged network route;

  • local hardware register;

  • unprotected deployment API;

  • alternate credential;

  • or another effect-equivalent route.

A.34.49. E34.49 Software Implementation

A software embodiment may comprise: Candidate Source → Protected Replication Coordinator → Replicas / Protected Observers → Receipt Aggregator / Quorum Verifier → Continuation Authority → Next Effectuation Boundary.

A.34.50. E34.50 Hardware / Split Implementation

A split embodiment may use software to collect receipts while protected hardware independently verifies:

  • participant keys;

  • membership epoch;

  • quorum threshold;

  • critical-role satisfaction;

  • receipt freshness;

  • and current phase state. The hardware releases the next key, latch state, signing operation, network capability, or actuator enable only when the aggregate predicate succeeds.

A.34.51. E34.51 Required Invariants

The minimum frozen conceptual invariants of E34 are:

Invariant 1 Where protected policy requires replicated confirmation, a single unverified local success indication is insufficient to unlock broader effectuation.

Invariant 2 Receipts contributing to the aggregate decision are bound to the relevant act, phase, participant, and protected state.

Invariant 3 The aggregate rule is evaluated by protected logic not controlled solely by the proposing source.

Invariant 4 A later phase may be made technically dependent upon the accepted quorum/consensus confirmation or Commit Certificate.

Invariant 5 Stale, replayed, wrong-participant, wrong-phase, or otherwise invalid receipts do not silently satisfy the protected aggregate rule.

Invariant 6 A split-brain, conflicting, or indeterminate state blocks unauthorized broader progression unless a new protected decision resolves the state.

Invariant 7 A successful quorum cannot enlarge authority beyond the already authorized maximum envelope.

Invariant 8 Equivalent bypass paths are correspondingly controlled where required to preserve the replicated-confirmation property. Everything else in E34 may vary by implementation unless expressly required.

TION, AND RECOVERY RECEIPT-GATED EFFECTUATION

A.35. E35 — Negative, Indeterminate, Conflict, Reconciliation, and Recovery Receipt-Gated Effectuation

A.35.1. E35.1 Purpose

E35 defines a protected effectuation workflow for cases in which the system receives evidence that an effect did not occur, may not have occurred, occurred only partially, produced conflicting observations, or cannot yet be determined with sufficient confidence. The embodiment is important because absence of a positive success receipt is not equivalent to proof that no effect occurred. A consequential system must distinguish, where relevant, between at least:

  • PROVEN EFFECTED;

  • PROVEN NOT EFFECTED;

  • PARTIALLY EFFECTED;

  • ROLLED BACK / COMPENSATED;

  • REJECTED BEFORE EFFECT;

  • CONFLICTING EVIDENCE;

  • and INDETERMINATE.

The central relationship is:

Attempted Effect → P rotected Outcome Evidence → Outcome Classification → Reconciliation if Required → P rotected Retry/Continue/Stop Authority

The key safety property is:

N o P ositive Receipt ⇏ N o Effect

A.35.2. E35.2 Negative Receipt

A Negative Receipt is protected evidence affirmatively indicating that a specified effect did not become effective under the relevant technical definition. A negative receipt may be produced where, for example:

  • a sink rejected the operation before effect;

  • a destination proves no matching transaction was committed;

  • a storage engine proves the candidate object was not promoted;

  • a device proves the command was not actuated;

  • a payment rail proves the transaction identifier was not accepted;

  • a message destination proves the candidate message identifier was not delivered;

  • a database proves a transaction did not commit;

  • or another protected component can affirmatively establish non-effectuation. The negative receipt is stronger than a timeout or missing acknowledgement.

A.35.3. E35.3 Negative Receipt Representation

A protected negative receipt may be represented as:

Ri−

and may bind:

  • Candidate Act digest;

  • phase identifier;

  • attempted effect identifier;

  • sink/destination identity;

  • transaction/idempotency identifier;

  • protected time or sequence;

  • reason for non-effectuation;

  • protected state consulted;

  • policy epoch;

  • and cryptographic authenticator. The minus sign denotes negative/non-effect evidence only for this embodiment and is not arithmetic subtraction.

A.35.4. E35.4 Indeterminate Receipt

Where a protected component cannot establish either effectuation or non-effectuation, it may generate:

Ri?

representing an Indeterminate Receipt or protected indeterminate outcome artifact. Examples include:

  • crash after sending a command but before local completion state is durable;

  • network partition after destination acceptance but before acknowledgement returns;

  • payment request transmitted but settlement state unavailable;

  • hardware moved but sensor evidence lost;

  • message broker accepted a message but destination state cannot be queried;

  • database commit status unavailable after failover;

  • or two protected observers disagree.

A.35.5. E35.5 Conflict Receipt / Conflict Evidence

A protected conflict state may be represented by:

Ri×

where evidence exists that cannot be simultaneously reconciled with the required invariant. For example, one authoritative observer may report EFFECTED while another equally required observer reports NOT EFFECTED. The multiplication sign is merely a local conflict symbol and is not a mathematical product.

A.35.6. E35.6 Outcome State Set

For phase i, protected outcome classification may belong to:

ΣOUT i ∈ {EF F ECT ED, N OT _EF F ECT ED, P ART IAL, ROLLED_BACK, REJ ECT ED, IN DET ERM IN AT E, CON F LICT }

An implementation may define additional states. The important property is that the states are not collapsed into a single success/failure Boolean where doing so would make retry unsafe.

A.35.7. E35.7 Positive Evidence Versus Negative Evidence

A successful positive receipt may prove a defined effect occurred. A valid negative receipt may prove a defined effect did not occur. An indeterminate receipt proves neither. Thus:

Ri+ ≠ Ri− ≠ Ri?

as semantic outcome classes, even if all are authenticated using similar cryptographic structures. The Ri+ notation is used locally here only to distinguish a positive receipt from negative and indeterminate outcome artifacts.

A.35.8. E35.8 Missing Receipt Is Not Negative Receipt

If no receipt is received:

ReceiptAbsenti = T RU E

protected logic must not automatically infer:

N OT _EF F ECT ED

unless the system has an independently protected reason to do so. A missing receipt may result from:

  • network loss;

  • crash;

  • delayed processing;

  • dropped return path;

  • destination outage;

  • observer outage;

  • malicious suppression;

  • clock/timeout mismatch;

  • or actual non-effectuation.

A.35.9. E35.9 Negative Receipt Validation

Before a negative receipt authorizes retry, the protected verifier may check:

  • receipt authenticity;

  • correct act binding;

  • correct phase;

  • correct sink/destination;

  • correct transaction/idempotency identifier;

  • freshness;

  • authoritative non-effect source;

  • policy epoch;

  • revocation state;

  • and whether the negative evidence covers the entire relevant consequence domain. A negative receipt that proves “not settled” may not necessarily prove “not authorized” or “not reserved.” The receipt must be interpreted according to the state it actually proves.

A.35.10. E35.10 Effect-State Granularity

A consequential act may pass through multiple technical states. A payment may be:

  • requested;

  • accepted;

  • authorized;

  • reserved;

  • captured;

  • clearing;

  • settled;

  • reversed;

  • or refunded.

A message may be:

  • submitted;

  • queued;

  • transmitted;

  • accepted by destination domain;

  • delivered to endpoint;

  • rendered;

  • or acknowledged.

A hardware command may be:

  • accepted;

  • latched;

  • energized;

  • moving;

  • physically completed;

  • sensed;

  • or stabilized. A receipt must therefore identify the technical state actually evidenced.

A.35.11. E35.11 Protected Reconciliation State

When outcome is indeterminate or conflicting, the PED may enter:

State = RECON CILIN G

During this state, broader effectuation authority remains unavailable unless protected policy expressly permits a bounded recovery action.

A.35.12. E35.12 Reconciliation Evidence Set

Let:

ΓREC i

represent the protected reconciliation evidence set for phase i. It may contain:

  • sink logs;

  • destination query results;

  • transaction ledger entries;

  • idempotency records;

  • replicated-state versions;

  • message broker state;

  • storage metadata;

  • hardware counters;

  • sensor state;

  • secure logs;

  • trusted timestamps;

  • payment-rail query results;

  • remote attestations;

  • consensus certificates;

  • or another authoritative state source.

A.35.13. E35.13 Reconciliation Function

Protected reconciliation may be represented as:

Reci = Reconcile(DA , P hasei , ΓREC i , P olicyi )

where the result may be:

Reci ∈ {P ROV EN _EF F ECT ED, P ROV EN _N OT _EF F ECT ED, P ART IAL, CON F LICT , ST ILL_IN DET ERM IN AT E}

The named function is architectural and does not require a specific API or algorithm.

A.35.14. E35.14 PROVEN_EFFECTED Result

If reconciliation establishes that the effect already occurred, the system must not blindly repeat it. Protected logic may:

  • reconstruct or recover a valid completion receipt;

  • mark the authority consumed;

  • advance protected state if permitted;

  • issue a later-phase continuation authority;

  • or require human review before continuation. The recovery path preserves the fact that the real effect occurred even if the original receipt was lost.

A.35.15. E35.15 PROVEN_NOT_EFFECTED Result

If reconciliation establishes that the effect did not occur, protected policy may permit a retry. A new retry authority may be generated rather than reusing the original consumed/expired authority. The retry may bind:

  • the original act;

  • original phase;

  • negative/reconciliation evidence;

  • a new nonce;

  • a retry counter;

  • current policy;

  • current revocation state;

  • and a new idempotency identifier or safely reusable idempotency identifier depending on infrastructure semantics.

A.35.16. E35.16 Retry Authority

Let:

RET RY Ci,k

represent retry authority for retry attempt k of phase i. A protected derivation may include:

RET RY Ci,k = Derive(DA , H(Ri− ), P hasei , k, P olicyCurrent)

where a valid negative receipt is the technical prerequisite for retry. Alternatively the authority may depend on a protected reconciliation result rather than directly on Ri− .

A.35.17. E35.17 Retry Counter

Protected state may maintain:

kiRET RY

as the number of authorized retry attempts for phase i. Policy may enforce:

kiRET RY ≤ kMAX RET RY

where the maximum is protected policy. This prevents unbounded automatic repetition of a consequential act.

A.35.18. E35.18 Consequence-Safe Retry

A retry is consequence-safe where protected controls make duplicate or contradictory effect acceptably bounded under the applicable system semantics. Techniques may include:

  • idempotency identifier;

  • transaction uniqueness constraint;

  • destination-side duplicate suppression;

  • protected phase counter;

  • hardware monotonic counter;

  • conditional commit;

  • compare-and-swap state;

  • ledger uniqueness;

  • message deduplication;

  • or another effect-specific control. E35 does not assume that all infrastructure provides exactly-once semantics.

A.35.19. E35.19 Partial Effect Result

If only part of the requested effect occurred, the system may classify:

ΣOUT i = P ART IAL

The protected workflow then determines the actually effected subset or magnitude before deciding whether to:

  • complete only the remainder;

  • compensate;

  • rollback;

  • reduce scope;

  • re-plan;

  • require human approval;

  • or terminate. A retry of the entire original operation may be unsafe.

A.35.20. E35.20 Partial Effect Quantification

Where meaningful, let:

Eiactual

represent the proven actual effect and:

Eitarget

represent the intended phase effect. The protected remaining effect may be constrained by:

Eiremaining = Eitarget − Eiactual

where arithmetic subtraction is meaningful. For qualitative effects, a set-difference or state-specific reconciliation rule may be used instead.

A.35.21. E35.21 Compensation Receipt

Where rollback is impossible but a compensating action is performed, the system may generate:

RiCOMP

binding:

  • original effect;

  • compensation act;

  • compensation result;

  • affected resource;

  • transaction identifiers;

  • remaining residual consequence;

  • and protected status. A compensation receipt does not necessarily mean the original effect never occurred.

A.35.22. E35.22 Rollback Receipt

Where the original effect is technically reversible, a protected rollback receipt may establish that the system returned to an acceptable protected state. Rollback may be complete or partial. Continuation policy may distinguish:

  • original effect never occurred;

  • original effect occurred then was rolled back;

  • original effect occurred and was compensated;

  • and original effect remains active.

A.35.23. E35.23 Late Positive Receipt After Negative Receipt

A critical race condition occurs where a negative or timeout-related path is processed and a delayed positive receipt later arrives. Protected logic must determine whether:

  • the negative evidence was authoritative and the late positive receipt is stale/invalid;

  • the positive receipt proves the effect actually occurred and the earlier classification was wrong or incomplete;

  • the two receipts refer to different technical stages;

  • or a conflict state exists. No duplicate retry should be released merely because the system first saw a timeout.

A.35.24. E35.24 Late Receipt After Retry

Suppose: 1. original attempt A0 becomes indeterminate; 2. protected reconciliation authorizes retry A1 ; 3. a late receipt for A0 arrives. The system may compare:

  • idempotency identifiers;

  • effect identifiers;

  • destination state;

  • transaction IDs;

  • phase counters;

  • and actual effect state. If both attempts became effective, the system may enter duplicate-effect handling rather than falsely reporting one clean success.

A.35.25. E35.25 Duplicate-Effect Detection

A protected duplicate-effect detector may identify:

DuplicateEffecti = T RU E

where two or more effect instances correspond to one intended single-use consequence. Responses may include:

  • compensation;

  • reversal;

  • quarantine;

  • account reconciliation;

  • message suppression where still possible;

  • hardware safe-state transition;

  • human escalation;

  • or another effect-specific remediation.

A.35.26. E35.26 Conflicting Protected Evidence

If protected evidence conflicts, continuation may require:

ConflictResolvedi = T RU E

before broader authority is released. The system may rank sources according to protected authority, require quorum, invoke E34 replicated confirmation, or require human resolution. The proposing agent must not resolve the conflict solely by choosing the evidence that enables its preferred action.

A.35.27. E35.27 Evidence Authority Hierarchy

Protected policy may define an authority order among evidence sources. For example: 1. destination-side authoritative transaction state; 2. protected sink journal; 3. replicated commit certificate; 4. hardware counter; 5. signed observer receipt; 6. non-authoritative application log. The hierarchy is implementation-specific and may differ by domain. The important property is that evidence authority is protected policy, not arbitrary source selection by the proposing process.

A.35.28. E35.28 Human Reconciliation Approval

A protected human may review reconciliation evidence before retry or continuation. The review surface may show:

  • original candidate act;

  • attempted phase;

  • positive/negative/indeterminate receipts;

  • transaction identifiers;

  • actual destination state;

  • duplicate risk;

  • current protected policy;

  • proposed recovery action;

  • and maximum additional consequence. The human may approve, deny, reduce scope, compensate, or terminate.

A.35.29. E35.29 Automatic Reconciliation

Automatic recovery may be permitted where protected logic can establish a sufficiently authoritative state. For example:

Reci = P ROV EN _N OT _EF F ECT ED ∧ RetryP olicyP assi ∧ W ithinEnvelope(Pi )

may authorize a bounded retry. If:

Reci = ST ILL_IN DET ERM IN AT E

broader progression remains blocked.

A.35.30. E35.30 Hybrid Recovery

A hybrid policy may allow automatic reconciliation but require human approval for:

  • second retry;

  • irreversible effect;

  • high financial value;

  • physical-safety consequence;

  • cross-jurisdiction data release;

  • conflicting evidence;

  • or effect beyond a protected threshold.

A.35.31. E35.31 Time-Bounded Indeterminate State

An indeterminate state may persist for a bounded observation interval. Let:

TiREC

represent the protected reconciliation window. During this interval the system may perform safe read/query operations without authorizing duplicate effect. Expiry of the window need not convert indeterminate state into NOT_EFFECTED; it may instead trigger escalation.

A.35.32. E35.32 Protected Recovery Query

A recovery query is a protected operation intended to determine effect state without independently creating the disputed consequential effect. Examples include:

  • query payment transaction ID;

  • query message-delivery ID;

  • read database commit record;

  • query storage object generation;

  • read actuator encoder/counter;

  • query cloud deployment state;

  • query telecom policy generation;

  • query GPU job/output record;

  • or inspect a replicated commit certificate. Recovery queries may themselves require bounded credentials and protected rate limits.

A.35.33. E35.33 Query Result Receipt

A protected recovery query may produce:

RiQUERY

binding the queried object, authoritative source, returned state, query time/sequence, and integrity evidence. Multiple query receipts may contribute to ΓREC i .

A.35.34. E35.34 SEND Example - Missing Delivery Confirmation

A file/message is sent using a single-use communication authority. The sender loses the acknowledgement. The system must not immediately resend the full communication merely because no receipt arrived. It may query:

  • broker message ID;

  • destination-domain state;

  • recipient endpoint state;

  • or a protected delivery ledger.

Possible outcomes:

  • PROVEN_EFFECTED: do not resend; recover completion receipt;

  • PROVEN_NOT_EFFECTED: protected retry may be issued;

  • PARTIAL: send only the missing segment if technically possible;

  • INDETERMINATE: hold;

  • CONFLICT: reconcile or escalate.

A.35.35. E35.35 SEND Example - Wrong Recipient Rejection

If a protected destination proves that a candidate communication was rejected because recipient binding failed, a negative receipt may prove that semantic release did not occur at the required recipient. The system may then permit a newly authorized corrected-recipient attempt if current policy and human/automatic approval allow it. The rejected receipt cannot by itself authorize sending to an arbitrary new recipient.

A.35.36. E35.36 Payment Example - Timeout After Submission

A payment request is submitted and the sender times out before receiving status. The system queries the transaction identifier. If the payment rail or authoritative institution returns:

  • settled/accepted: mark effected and do not duplicate;

  • definitively rejected/not found under authoritative semantics: a protected retry may be considered;

  • pending: remain in a non-final state;

  • unknown: remain indeterminate;

  • conflicting: reconcile. This avoids treating network timeout as proof of non-payment.

A.35.37. E35.37 Payment Example - Partial Settlement

Where only part of an intended payment was settled, protected state may identify the settled amount and maximum remaining authorized amount. A continuation or corrective payment must be bounded so cumulative effect does not exceed the authorized maximum. The prior partial settlement remains part of cumulative consequence accounting.

A.35.38. E35.38 Database Example

A database transaction loses its client acknowledgement during failover. Protected recovery may query:

  • transaction ID;

  • commit log;

  • replicated commit index;

  • unique constraint state;

  • or authoritative row version. A new transaction is released only if protected evidence establishes that doing so will not create an unauthorized duplicate mutation.

A.35.39. E35.39 Storage Example

An object upload completes to some replicas but promotion state is uncertain. Reconciliation may determine:

  • object absent;

  • object provisional only;

  • object promoted;

  • object partially replicated;

  • or conflicting metadata state. Deletion of the source copy or release of a decryption key remains blocked until the required state is established.

A.35.40. E35.40 Hardware Actuation Example

A motor command is issued and controller power fails before the completion receipt returns. Protected recovery may inspect:

  • monotonic command counter;

  • encoder position;

  • current/energy record;

  • actuator-local journal;

  • safety controller state;

  • and command identifier. If the motor already moved, the system must not blindly issue the same full movement again.

A.35.41. E35.41 Vehicle / UAV Example

A vehicle or UAV reaches an intermediate waypoint but communication with the supervisory PED is lost. Local protected state may record the completed phase. After reconnection, reconciliation compares:

  • actual position;

  • protected route phase;

  • command counter;

  • local receipt;

  • remote receipt chain;

  • and current policy. Only the remaining authorized route/movement may be released.

A.35.42. E35.42 Industrial Example

A valve or process-control command is issued, then supervisory communication is lost. The recovery workflow may inspect:

  • valve position sensor;

  • PLC state;

  • process pressure/flow;

  • hardware command counter;

  • and protected event log. A duplicate open/close command is not issued until the real process state is established or a protected safe-state action is required.

A.35.43. E35.43 Telecom Example

A network policy update is sent to a network function but acknowledgement is lost. Protected recovery may inspect:

  • policy generation;

  • network-function state;

  • data-plane behavior;

  • controller journal;

  • and protected telemetry. Broader rollout remains blocked until the bounded phase is classified.

A.35.44. E35.44 GPU / Accelerator Example

A protected accelerator completes a job but the host loses the completion notification. Recovery may inspect:

  • protected job identifier;

  • accelerator queue state;

  • output digest;

  • device counter;

  • secure memory state;

  • and egress state. The architecture distinguishes recomputing an internal result from repeating an external consequence such as data release or network transmission.

A.35.45. E35.45 Model-State Example

A model-memory update may have been committed to one authoritative state store before a crash.

The recovery path queries the protected model-state version and digest before issuing another update. If the update already became authoritative, a duplicate memory entry or duplicated parameter update is prevented.

A.35.46. E35.46 Software/Firmware Update Example

An update activation request loses its acknowledgement during reboot. Recovery may inspect:

  • active slot;

  • boot measurement;

  • version counter;

  • firmware generation;

  • secure-boot state;

  • and update receipt journal. The system need not reinstall or reactivate the update blindly.

A.35.47. E35.47 Multi-Destination Recovery

For a multi-destination act, different destinations may have different outcome states. Let:

Zeff , Znot , Zind represent effected, proven-not-effected, and indeterminate destination subsets. A retry may be restricted to Znot while Zeff is excluded and Zind remains blocked pending reconciliation.

A.35.48. E35.48 Replicated Recovery with E34

Where outcome depends on replicated state, E35 may use E34 Commit Certificates or quorum evidence as authoritative reconciliation material. For example:

V alid(CCi ) ⇒ P ROV EN _EF F ECT ED under the protected semantics of the relevant replicated system. An insufficient replica set may instead leave the outcome indeterminate.

A.35.49. E35.49 Recovery Receipt

After reconciliation, a protected Recovery Receipt may be generated:

RiREC binding:

  • original act;

  • original phase;

  • initial outcome state;

  • reconciliation evidence commitment;

  • authoritative reconciliation result;

  • retry/continue/stop decision;

  • policy epoch;

  • and protected time/sequence.

A.35.50. E35.50 Recovery-Receipt-Derived Authority

A new continuation or retry authority may depend cryptographically on the recovery result. For example:

REC Ci+1 = Derive(DA , H(RiREC ), N extAction, Scope) Thus recovery is not merely informational; it may become part of the authority chain.

A.35.51. E35.51 Recovery Authority Consumption

A Recovery Receipt or retry authorization may be single-use. After the protected recovery transition:

Consumed(RiREC ) = T RU E

or equivalent protected state may be recorded. Replay must not create repeated retries or repeated continuation authority.

A.35.52. E35.52 Recovery Policy Change

If protected policy changes during reconciliation, a prior negative or recovery receipt need not automatically authorize retry under the new policy. The system may require:

  • revalidation;

  • reduced scope;

  • new human approval;

  • new automatic policy decision;

  • or termination.

A.35.53. E35.53 Revocation During Reconciliation

If the act, user, credential, destination, device, or policy authority is revoked while outcome is unresolved, recovery may remain limited to state determination and safe remediation. A valid negative receipt does not necessarily override current revocation.

A.35.54. E35.54 Safe-State Authority

Certain systems may permit a narrowly defined protected safe-state action even while the original effect remains indeterminate. Examples include:

  • stop motor;

  • apply brake;

  • close safety valve;

  • isolate network path;

  • revoke credential;

  • quarantine data;

  • or disable further release. Such authority should be bounded to hazard reduction and must not silently become a broader continuation authority.

A.35.55. E35.55 Audit and Evidence Preservation

Protected reconciliation may preserve:

  • original authority;

  • all received receipts;

  • missing-receipt condition;

  • query evidence;

  • state transitions;

  • retry decisions;

  • human approvals;

  • automatic decisions;

  • compensation actions;

  • and final recovery receipt. This supports later technical reconstruction of how the final consequence was determined.

A.35.56. E35.56 Privacy-Preserving Reconciliation

Recovery evidence need not disclose unnecessary payload or personal data.

The system may use:

  • digests;

  • commitments;

  • selective disclosure;

  • attestation claims;

  • zero-knowledge proofs;

  • destination-side yes/no proofs;

  • or protected enclaves; provided the evidence remains sufficient for the required protected decision.

A.35.57. E35.57 Anti-Bypass Requirement

An unresolved outcome must not be bypassed by using an alternate path to repeat or broaden the consequence. Relevant bypasses may include:

  • alternate API;

  • different credential;

  • administrator interface;

  • direct network socket;

  • different message broker;

  • raw database connection;

  • direct device command;

  • recovery console;

  • or another effect-equivalent path.

A.35.58. E35.58 Fail-Closed and Fail-Limited Recovery

For high-consequence operations, indeterminate state may fail closed. For systems requiring continued operation, protected policy may instead enter a fail-limited state that permits only bounded low-risk or hazard-reducing actions. The permissible fail-limited envelope remains protected and must not silently expand because a receipt is unavailable.

A.35.59. E35.59 Required Invariants

The minimum frozen conceptual invariants of E35 are:

Invariant 1 Absence of a positive receipt is not automatically treated as proof that no effect occurred.

Invariant 2 A negative receipt used to authorize retry is protected, act-bound, phase-bound, and sufficiently authoritative for the non-effect state it asserts.

Invariant 3 Indeterminate or conflicting effect state blocks unauthorized broader progression.

Invariant 4 Reconciliation uses protected evidence from one or more authoritative state sources.

Invariant 5 A proven already-effected operation is not blindly repeated.

Invariant 6 A retry, where permitted, is separately bounded and authorized under current protected state.

Invariant 7 Partial effect is accounted for so cumulative consequence does not exceed the authorized maximum.

Invariant 8 Recovery receipts, retry authorities, and continuation authorities may be consumed or otherwise replay-protected.

Invariant 9 Equivalent alternate paths do not silently bypass unresolved-effect controls.

Invariant 10 Safe-state or fail-limited actions remain bounded to their protected recovery purpose. Everything else in E35 may vary by implementation unless expressly required.

FROZEN RELATIONSHIP BETWEEN E34 AND E35 E34 addresses how multiple protected observations or replicas establish sufficient confirmation for continuation. E35 addresses what the protected system does when effect status is negative, partial, conflicting, missing, or indeterminate. The two workflows may operate together:

Replicated Effect → Replica Receipts → Quorum/Consensus Evaluation ⎧Confirmed → Continue { {N egative → P rotected Retry/Stop { → ⎨P artial → Reconcile Remaining {Conflict → Reconciliation { {Indeterminate → Hold/Reconcile ⎩

The final architectural principle remains:

Computational P roposal ≠ Authority to Create or Repeat Consequence

and, correspondingly:

M issing Evidence ≠ P roof of N on-Effect

Appendix B. Normalized Mathematical and State-Machine Summary

The following formulas restate recurring source relationships using one notation. They are not intended to require a particular cryptographic primitive or data representation.

Act binding:
  D_A = H(Canon(A))

Exact effect confirmation:
  O_i = X_i

Tolerance effect confirmation:
  d(O_i, X_i) <= epsilon_i

Envelope constraint:
  Scope(P_i) <= E_MAX

Receipt-gated continuation:
  Enable(P_(i+1)) = ReceiptValid_i AND CurrentConditions_i

Receipt chain example:
  R_i = Protect(D_A || i || O_i || H(R_(i-1)) || context_i)

Progressive chain:
  P_0 -> R_0 -> Gamma_1 -> P_1 -> R_1 -> Gamma_2 -> ... -> P_n

Threshold continuation:
  sum_j ValidShare_j >= m

Quorum continuation:
  sum_j Valid(R_i^j) >= m

Conflict rule:
  Authentic(R_a) AND Authentic(R_b) AND NOT Consistent(R_a,R_b)
      => no ordinary continuation

Indeterminate rule:
  UNKNOWN != SUCCESS

Anti-bypass rule:
  EffectCapable(q) => EquivalentFinalityControl(q) OR Disable(q)
Figure 34: Cross-workflow mathematical summary

Appendix C. Workflow Coverage Map

Table 2: Workflow families
Profiles Primary coverage
E01-E03 Baseline single-phase, demonstration-then-full, and progressive multi-phase effectuation.
E04-E06 Protected human, automatic, and hybrid continuation.
E07-E09 Software, hardware, and split software/hardware protected enforcement.
E10-E12 Receipt-conditioned key chains, threshold continuation, and SEND trailer/full release.
E13-E15 File transfer, payment demonstration, and escrow/conditional settlement.
E16-E18 Database promotion, cloud rollout, and AI model deployment/activation.
E19-E21 Tool invocation, progressive credential release, and progressive data export.
E22-E24 Storage release, robotic actuation, and sensor-confirmed hardware actuation.
E25-E27 Vehicle, UAV/mobile robot, and industrial/PLC/process control.
E28-E30 Telecom, radio/satellite/NTN, and GPU/accelerator/compute egress.
E31-E33 Model-state updates, software/firmware/configuration activation, and multi-destination effects.
E34-E35 Replicated/quorum/consensus confirmation and negative/indeterminate/conflict/recovery handling.

Author's Address

Sangam Das
Independent Researcher
Balasore
Odisha
India