Internet Engineering Task Force Sangam Das Internet-Draft: draft-das-execution-finality-ai-interoperability-00 Intended status: Informational August 19, 2026 Expires: February 19, 2027 Breaking the Apple-Siri EU DMA Deadlock Without Sacrificing Privacy or Security Author: Sangam Das Affiliation: Independent Inventor Location: Balasore, Odisha, India Email: info@sangamdas.com 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The Apple-Siri interoperability debate under the EU Digital Markets Act exposes a difficult technical question: how can third-party AI assistants gain meaningful access to device functions without forcing the platform to surrender privacy, security, or control over consequential actions? This paper proposes an execution-finality architecture in which an AI assistant may request an action, but the request itself has no power to make that action effective. Each consequential operation remains in a Non-Effective State until protected infrastructure validates the requester, resource, destination, user intent where required, freshness, revocation state, and policy conditions. Only then is narrowly scoped, non-bearer execution authority created. At the Finality Sink - the first boundary where the action can become externally effective - the system independently verifies that the real operation still matches what was authorized. Any mismatch, replay, substitution, expiry, or revocation causes fail-closed denial. The key principle is simple: Interoperability should grant participation, not uncontrolled execution authority. This offers a possible technical path through the DMA deadlock: third-party assistants could participate meaningfully without requiring broad reusable permissions, while platforms retain strong privacy, security, revocation, anti-replay, and final-effect controls. Execution-Finality Governance therefore reframes the problem from closed versus open to open participation with bounded, verifiable authority. Table of Contents 1. Combined Technical Disclosure and Anticipatory Technical Objections 2. Security-Focused Layman Explanation of Third-Party AI Interoperability 3. Technical Objections and Responses 4. Security Considerations 5. IANA Considerations 6. Author's Address EXECUTION-FINALITY ARCHITECTURE FOR AI INTEROPERABILITY Combined Technical Disclosure and Anticipatory Technical Objections and Responses ======================================================================== PART I - TECHNICAL DISCLOSURE ======================================================================== Security-Focused Layman Explanation of Third-Party AI Interoperability Acknowledging Apple's Risk and EU's Operational Reality The Genuine Problem: Apple's Concern Is Valid Apple's worry about third-party AI interoperability is not bureaucratic obstruction. It is a real technical and business risk. What Apple Actually Fears Once a third-party AI assistant runs on the iPhone with access equivalent to Siri, Apple faces a true dilemma: The assistant legitimately needs power to: read a selected message attach a selected file send a message to one person open an application use the microphone for one task initiate a payment upload one document change one device setting But the moment Apple grants this power, several realistic attack surfaces open: 1. The assistant itself could be compromised. Not by user mistake-by actual breach, supply-chain attack, or code injection. 2. The assistant's cloud infrastructure could be weaponized. Even if the on-device code is honest, a compromised backend could send malicious instructions. 3. Prompt injection is a real, reproducible vulnerability. A malicious website or attacker- controlled input can override the user's intent and redirect the assistant to exfiltrate data. 4. Accessibility abuse is well-documented. Malware has repeatedly exploited accessibility services to manipulate device functions without direct permission. 5. The permissions model has always leaked scope. An app granted file access can attempt to read many files. An assistant allowed to send messages can attempt to send others. This is not theoretical-it has happened. 6. Recovery is expensive or impossible. If a third-party assistant silently uploads the user's message archive, medical records, or financial data to an attacker-controlled server, Apple is liable. The user and regulators will hold Apple responsible, not the third party. 7. Apple's own reputation is at stake. Even one high-profile compromise of user data via third-party assistant access would damage iPhone trust globally. This is not paranoia. This is the actual operating environment. The Genuine Constraint: EU's Conditions Are Real The EU is not blocking interoperability out of protectionism. It is enforcing real compliance obligations: Article 6(7) of the Digital Markets Act The DMA requires gatekeepers to provide "effective interoperability" for digital assistants. But "effective" does not mean "uncontrolled." The DMA text itself embeds constraints: Interoperability must not "put at risk" the security and integrity of the gatekeeper's services. The gatekeeper may impose "proportionate, non-discriminatory conditions." Risk mitigation is not optional-it is a legal requirement. The EU is telling Apple: "You must interoperate, but you do not have to bet the platform on third-party execution authority." GDPR Article 32 (Security) GDPR requires controllers and processors to implement: encryption and pseudonymization of personal data ability to restore availability and access upon data incident ongoing integrity and confidentiality testing If a third-party assistant accesses EU user data, Apple-as the platform controller- has a non-delegable obligation to ensure that data remains secure. Apple cannot hand off responsibility. EU AI Act Article 14 (Oversight) For high-risk AI systems, Article 14 requires: "effective human oversight" proportionate to the risk ability to intervene or override decisions sufficient information for oversight personnel to understand the AI's basis This is not asking for human review of every message send. It is asking: can the system be monitored and interrupted if something goes wrong? If a third-party assistant operates with uncontrolled execution authority on the iPhone, Apple cannot credibly claim to have implemented Article 14 oversight. Apple would be delegating control to a third party and then asserting oversight. Why Current Approaches Are Not Adequate Apple and other platforms have tried multiple strategies to manage third-party application authority. None of them successfully address the core problem: how to permit participation without granting uncontrolled execution authority. Broad Permission Models (Android, iOS Classic) The model: Applications are granted broad categories of access (Files, Messages, Contacts, Camera, Microphone, Network). Why it fails for third-party AI: A request to send one message is indistinguishable from a request to read and exfiltrate all messages. An app granted file access can attempt to read any file in the permitted directory. Revocation is coarse-grained: users must choose between "full access" or "no access," with no middle ground. Once granted, permissions are persistent and reusable-the same authority is valid for the 100th message send as the first. Against third-party AI specifically: Prompt injection or cloud compromise could redirect the assistant to abuse these broad permissions. A single breach of the assistant's backend could enable bulk data exfiltration. Users cannot easily audit or revoke access to a specific sensitive file or contact list. Operating-System-Level Enforcement Alone The model: The OS kernel mediates all system calls and enforces access control policies. Why it fails: The OS itself may be compromised or malicious. Giving the OS final authority over a sensitive decision is problematic if OS integrity is doubted. OS enforcement often occurs after data has already transited through userspace. By the time the kernel sees a system call, an attacker-controlled app could have cached, copied, or logged the data. The OS makes binary allow/deny decisions but cannot determine whether a specific use of data is valid. It sees "file_read(Tax_Return.pdf)" but not "is reading this file right now authorized, or is this a replay/redirect attack?" OS sandboxing creates policy at the boundary but does not enforce the policy inside the protected domain that validates requests. Against third-party AI: If the assistant process runs at the same privilege level as other apps, OS enforcement alone cannot distinguish a legitimate request from a compromised one. The OS cannot know whether a request to send a message is the user's intent or a compromised backend's instruction. Hardware TEEs Without Finality Binding The model: Use a Secure Enclave, trusted execution environment (TEE), or HSM to validate requests. Why it fails: A protected domain can validate a request, but if there is no corresponding check at the effectuation boundary, the validation result is advisory only. The operating system can intercept the validated request, modify it, and pass a different instruction to the actual effectuation component. Example: The Secure Enclave approves "send message to alice@example.com," but the OS intercepts the capability and hands it to the message controller with a modified recipient (attacker@evil.com). If the message controller does not independently verify the capability, the modification succeeds. Without finality verification, the TEE validation is a design recommendation, not an enforced guarantee. Against third-party AI: An attacker who compromises the kernel or message application layer can still redirect the validated request. The finality components (message send, file export, payment) must independently verify the authority, or the entire chain fails. Audit-Log Approaches The model: Log all sensitive actions and review them after the fact. Why it fails: Audit occurs after harm has occurred. Exfiltrated data cannot be unexpfiltrated. Users and regulators cannot prevent attacks in real time. If the logging system itself is compromised, audit records can be deleted or falsified. Audit is a post-incident forensics tool, not a preventive security control. Against third-party AI: By the time an audit log shows unauthorized exfiltration, user data has already been stolen. A sophisticated attacker might clear or forge logs to hide evidence. Audit does not help with compliance deadlines (GDPR breach notification, data minimization obligations). Bearer Token Approaches The model: Validate a request once, issue a token (like a session cookie or OAuth access token), and allow repeated use of that token. Why it fails: Bearer tokens can be stolen, replayed, or intercepted. Once a token is issued, any entity in possession of it can use it repeatedly for the same purpose, even if that entity is compromised. Tokens are often designed for human-scale permissions ("user is logged in") or broad service permissions ("API key for file access"), not act-level authority. Revocation of a token takes time to propagate; until revocation is fully distributed, stolen or leaked tokens remain valid. Against third-party AI: An attacker who compromises the assistant's memory could extract a valid session token and reuse it repeatedly. A leaked token for "send message" authority could be used to send thousands of messages or to send messages to unintended recipients. No binding between the token and a specific act means the token is easily repurposed. OAuth and Delegated Access Models The model: Users explicitly delegate broad authority to applications, and the authorization server trusts the application to use that authority within agreed bounds. Why it fails: OAuth was designed for delegated user consent, not for constraining compromised applications. The authorization server issues a token, the application receives it, and the authorization server has no way to monitor or verify how the application uses the token. Breach of the application results in breach of all delegated permissions-there is no way to revoke granular access without revoking all authority. Scope boundaries (e.g., "read files") are defined by the authorization server, but the application itself decides how to interpret those bounds. Against third-party AI: A user authorizes the assistant to read files (reasonable) and send messages (reasonable), but a compromised backend could exploit both scopes for exfiltration. The authorization server has already issued all the tokens; it cannot intervene once the application is compromised. OAuth relies on the application being trustworthy. If that assumption breaks, OAuth offers no recovery. Accessibility Frameworks The model: Accessibility services can interact with applications on behalf of users with disabilities, performing screen navigation, input simulation, and data collection. Why it fails: Accessibility is intentionally permissive to enable assistive technology. The framework trusts the accessibility service to act in the user's interest. Malware abuse of accessibility (clicking buttons, simulating input, collecting screen data) is a well-documented vulnerability. There is no mechanism to revoke or audit specific accessibility actions before they occur. Accessibility operates through the application layer, so a malicious app can intercept or modify the simulated input before the actual consequence occurs. Against third-party AI: An accessibility-based AI assistant could simulate clicks or inputs to trigger unintended actions. The framework provides no way to authorize a specific click for a specific purpose-it trusts the accessibility service wholesale. Accessibility services can read all on-screen data, enabling comprehensive surveillance. Sandboxing Without Output Control The model: Run untrusted code in an isolated sandbox with restricted resource access. Why it fails: Sandboxes restrict input access (which files an app can read) but often do not restrict output access (where data can be sent). An app can read a single file within the sandbox, but if the sandbox permits network access, the app can exfiltrate that file to any server. Sandbox escape vulnerabilities are common and regularly discovered. The sandbox perimeter may have well-defined policy, but the boundary crossing (the actual network send or file export) is often not re-validated. Against third-party AI: A sandboxed assistant can read a single message within its confined space, but network access allows it to send that message anywhere. Sandbox escape through kernel vulnerabilities or side-channel attacks could break isolation entirely. The Common Failure Pattern All of these approaches share a critical gap: They delegate authority, they do not bind it. They rely on one of the following: 1. Trust the application - Assume the app will use authority correctly (fails on compromise) 2. Trust the OS - Assume the OS won't redirect or misuse validated requests (fails if OS is compromised) 3. Trust the TEE alone - Assume validation output is sufficient without boundary verification (fails if finality is unmediated) 4. Enforce policies retroactively - Log actions after harm (fails to prevent harm) 5. Use reusable tokens - Assume stolen tokens won't be reused or redirected (fails on interception) None of these approaches solve the core problem: How do you permit an AI assistant to request sensitive actions while ensuring that execution authority for those actions remains technically bound to the validated intent? Why a New Approach Is Necessary The core issue is architectural: current systems were designed for either: User trust models (the user downloads an app, the OS grants permissions, the app is responsible for using them correctly) Cloud delegation models (the user logs into a cloud service, the service is responsible for protecting delegated access) Neither model anticipates: Request-response interoperability (untrusted third party requests an action, but platform retains authority) Atomic finality (every consequential action must be validated and verified at the boundary where it becomes real) Non-bearer execution authority (a validated decision cannot be copied, stolen, or reused for a different purpose) Fail-closed architecture (uncertainty is denial, not permission) This requires a new approach that: Separates the power to request from the power to execute Binds execution authority to a specific, narrowly scoped act Verifies that authority at the final boundary where the consequence becomes real Fails closed if anything is missing, modified, or replayed Permits revocation at any point before effectuation CRITICAL: The architecture is deployable incrementally on existing platforms. Hardware redesign is not a prerequisite for obtaining meaningful execution-finality protection; it may be required only where the desired assurance level demands demonstrable mediation of every relevant hardware and firmware effectuation path. The Genuine Solution: Execution Authority = Participation Both Apple's risk and the EU's constraints are real. The architecture answers them by separating two things that are often conflated: What Distinguishes Honest Interoperability from Risk A third-party assistant should be able to: Request the same categories of action as Siri Participate in the user's workflows Integrate with device functionality A third-party assistant should NOT receive: Unilateral execution authority Reusable permission material The power to make irreversible consequences happen without final gatekeeping The Key Insight Participation is not the same as uncontrolled power. A doctor can participate in surgery and request specific actions, but the surgical nurse does not automatically comply because the doctor is credentialed. The nurse verifies each instruction at the point of action. An accountant can request transfers and document uploads, but the bank's compliance system independently checks each request before processing. A traffic control assistant can request signal changes, but the physical controller unit verifies the signal timing is safe before executing. Device interoperability can work the same way. The Architecture: Addressing Both Constraints Step 1: Request Without Authority The third-party assistant submits a request: "Attach Tax Return.pdf to a message and send it to Alice." This request has no direct execution authority. It is an input, not a command. Why this matters for Apple's risk: If the assistant is compromised, the request is just data. If prompt injection occurs, the request may be malicious but remains non-effective. The assistant cannot force the device to comply by itself. Why this matters for EU compliance: Apple retains technical control over the outcome. The request is auditable and can be reviewed. Intervention is possible before harm occurs. Step 2: Structured Validation, Not Delegated Trust The request is converted into a "Candidate Device Act"-a sealed, detailed description: Requesting agent: Third-Party Assistant X Action: Send message Resource: Tax Return.pdf (with exact file fingerprint) Recipient: alice@example.com (exact address) Destination app: Messages User session: Active Time window: 30 seconds Policy version: Current Unique nonce: Fresh, never used before Critically: The action is not yet effective. The file has not left the device. The message has not been sent. The recipient has received nothing. Why this matters for Apple's risk: Apple can inspect the full, exact intent before authorizing it. No vagueness, no scope creep. If anything is suspicious, the operation simply fails. Why this matters for EU compliance: Apple demonstrates explicit security enforcement. Every action is documented before it occurs. The chain of evidence is cryptographic, not just logged. Step 3: Hardware-Protected Validation (Asymmetric OS Trust) The operating system is not trusted with final authority. A hardware-protected component (Secure Enclave or equivalent) independently validates: Who is requesting? Is this app/assistant actually running? Has its code been tampered with? Is it operating within its declared sandbox? What exactly is requested? Is this a message send, file export, payment, or sensor access? Is the scope narrow and specific? Is it consistent with the user's declared need? What resource is involved? Is it the exact file, message, or contact the user intended? Has a substitute been switched in? Is the resource still owned/controlled by the user? Where is it going? Is the recipient the exact address the user approved? Has the destination been changed? Is the destination domestic or cross-border (jurisdiction check)? Why now? Is the user session still active? Has the user revoked this authorization? Is the nonce fresh? Has the policy changed? Why this matters for Apple's risk: The validation happens in isolation from the assistant. The assistant cannot trick or pressure the validation component. The hardware is difficult to compromise and leaves cryptographic evidence if tampered with. Why this matters for EU compliance: Apple demonstrates that security enforcement is not delegated to the third party. The validation is reproducible and auditable. If anything fails, the operation stops-no workarounds, no degraded modes. Step 4: User Intent Is Cryptographically Bound Before releasing any authority, the system captures evidence that the user actually intended this specific act: Not just: "The user unlocked the phone this morning" But specifically: "The user confirmed sending this file to this recipient in this application during this session" Evidence may come from: Secure screen confirmation ("Send to alice@example.com?") Biometric verification (Face ID on the action itself, not just phone unlock) Spoken confirmation ("Send the tax return to Alice") Gesture confirmation (swipe-to-confirm on the exact recipient) The intent is not retroactively inferred. It is prospectively captured. Why this matters for Apple's risk: A stolen capability or replayed authorization cannot be reused for a different recipient. The user's will is enforced at the moment of action. Why this matters for EU compliance: Apple demonstrates human oversight (Article 14). The user is an active participant in the decision, not just a passive account holder. Step 5: Protected Validation Receipt (LAVR) Before-or atomically with-releasing execution authority, the system creates a cryptographically signed validation receipt: This receipt records: What was examined Which app requested it What resource was involved What destination was approved Which security conditions passed Which policy version was used Whether revocation was checked Which nonce was consumed Which final controller must verify it What capability was issued This is not an audit log created after the fact. This is pre-execution evidence that validation occurred and succeeded. If the receipt cannot be created (because the protected domain is unavailable, revocation cannot be checked, or validation failed), the capability is withheld. The operation fails. Why this matters for Apple's risk: Apple has proof that validation occurred. If compromise is later discovered, Apple can demonstrate that the specific action passed security checks at the time. The receipt is cryptographically bound; it cannot be forged or altered. Why this matters for EU compliance: Apple can demonstrate to regulators that security enforcement is in place. The receipt satisfies GDPR Article 32 (integrity and confidentiality controls). Audits and incident investigations have clear evidence of what was checked. Step 6: Fractional, Non-Bearer Capability If all checks pass, the system creates a narrowly scoped digital authorization: NOT: "Assistant X can access Messages, files, and network indefinitely" BUT: "Assistant X may cause Messages to send this exact file to this exact recipient through this exact message-send controller within the next 30 seconds under this specific policy version" The capability is non-bearer: Merely copying or stealing it is insufficient. The recipient is bound to: The exact app that requested it The exact resource (file, message, contact) The exact destination (recipient, payment, upload endpoint) The exact nonce The validation receipt The specific Finality Sink component If copied to another app, presented with a different file, or used by a different component, the capability fails. Why this matters for Apple's risk: If an attacker steals the capability from memory, copying it alone is not sufficient. If the assistant is compromised and an attacker has access to its memory, the leaked capability is tightly bound to the specific act. Replay attacks fail because the nonce is consumed. Why this matters for EU compliance: Apple demonstrates technical enforcement of scope. The capability is inherently narrow-it cannot be "accidentally" reused for a broader purpose. This is not a policy or trust model; it is a cryptographic property. Step 7: Final Verification at the Effectuation Boundary The Finality Sink is the component positioned at the exact moment when the action would become real. Examples: Message send: The message-send controller File export: The network-egress controller Payment: The wallet or payment processor Sensor release: The sensor data controller Storage commit: The persistent-storage controller App dispatch: The intent router The Finality Sink performs an independent security check: Is the capability authentic? Is it intended for this component? Does it match this exact operation? Does the resource match? Does the destination match? Is the nonce fresh? Has it already been consumed? Is it expired or revoked? Does the validation receipt correspond? Only after successful verification does the action cross the Effectuation Boundary. Why this matters for Apple's risk: Validation does not occur only when the assistant asks; it occurs again at the final door. If an attacker somehow bypasses the initial protected domain (unlikely, but assumed possible), the Finality Sink provides a second, independent gate. The system is fail-closed: absence of valid capability = denial. Why this matters for EU compliance: The enforcement is distributed across multiple trustworthy components. No single point of failure can authorize an improper action. Apple can credibly claim that the architecture is designed to prevent uncontrolled access. Step 8: Consumption and State Update After successful use, the system updates protected state: Mark the nonce as consumed Decrement any quota Advance the receipt chain Update the session Update revocation epochs This prevents the same capability from being reused to: Send the message twice Execute the same action later Bypass the validation again Why this matters for Apple's risk: Replay attacks fail because state is updated in a protected component. If an attacker replays a valid capability, the second presentation is rejected. Execution Flow: Workflow Diagram The following diagram expresses the separation of powers central to the architecture: the ability to request is fundamentally different from the ability to execute. THIRD-PARTY AI / FIRST-PARTY AI | | proposes action +-------------------------------+ | 1. CANDIDATE DEVICE ACT | | | | requester | | operation | | resource / payload | | destination | | user-intent context | | nonce | | policy / security epoch | +---------------+---------------+ | | NO EXECUTION AUTHORITY | ACT REMAINS NON-EFFECTIVE +-------------------------------+ | 2. PROTECTED VALIDATION | | | | requester valid? | | resource valid? | | destination valid? | | user intent valid? | | policy valid? | | nonce fresh? | | revoked? | +----------+-----------+--------+ | | FAILURE SUCCESS | | DENY CREATE LAVR | +-------------------------------+ | 3. BOUNDED NON-BEARER | | EXECUTION CAPABILITY | | | | bound to exact act | | bound to resource | | bound to destination | | bound to LAVR | | bound to nonce | | bound to Finality Sink | +---------------+---------------+ | | capability alone does | NOT cause effectuation +-------------------------------+ | 4. FINALITY SINK | | | | authenticate capability | | verify LAVR | | re-establish actual operation | | verify actual resource | | verify actual destination | | check revocation / epoch | | check consumption state | +----------+-----------+--------+ | | MISMATCH MATCH | | DENY ATOMIC CONSUMPTION | EFFECTUATION | EXTERNAL CONSEQUENCE This diagram illustrates the key architectural property: participation is not uncontrolled power. A third-party or first-party AI may generate requests, but no request obtains execution authority until multiple independent conditions are satisfied and verified at the final boundary. Formal Specification: Pseudocode The architecture separates authorization from finality. The following pseudocode makes this separation explicit and shows where replay, revocation, TOCTOU, and substitution attacks are prevented. Protected Validation and Authority Issuance FUNCTION PREPARE_AUTHORITY(candidate_act): SET candidate_act.state = NON_EFFECTIVE IF NOT verify_requesting_principal(candidate_act.requester): RETURN DENY IF NOT verify_operation_scope(candidate_act.operation): RETURN DENY IF NOT establish_resource_binding(candidate_act.resource): RETURN DENY IF NOT establish_destination_binding(candidate_act.destination): RETURN DENY IF NOT verify_user_intent( candidate_act.operation, candidate_act.resource, candidate_act.destination): RETURN DENY IF NOT verify_current_policy(candidate_act.policy_version): RETURN DENY IF NOT verify_security_epoch(candidate_act.security_epoch): RETURN DENY IF is_revoked(candidate_act): RETURN DENY IF NOT nonce_is_fresh(candidate_act.nonce): RETURN DENY validation_commitment = COMMIT_TO_LOAD_BEARING_ATTRIBUTES(candidate_act) LAVR = CREATE_PROTECTED_VALIDATION_RECEIPT( validation_commitment, candidate_act.nonce, candidate_act.policy_version, candidate_act.security_epoch, designated_finality_sink) IF LAVR_creation_fails: RETURN DENY capability = CREATE_NON_BEARER_CAPABILITY( validation_commitment, LAVR, candidate_act.nonce, designated_finality_sink, expiry, permitted_effect_count) IF capability_creation_fails: RETURN DENY RETURN capability What this enforces: All conditions must pass before authority is created The capability is created only after LAVR (evidence of validation) is committed Absence of LAVR = absence of authority The nonce ensures single-use semantics Policy and security epoch are checked at creation time Finality-Sink Verification and Effectuation FUNCTION FINALIZE(actual_effect, capability, LAVR): # No valid authority means no effect IF capability is absent OR LAVR is absent: RETURN DENY IF NOT authenticate(capability): RETURN DENY IF NOT authenticate(LAVR): RETURN DENY IF capability.finality_sink != THIS_FINALITY_SINK: RETURN DENY IF capability is expired: RETURN DENY IF current_security_epoch != capability.security_epoch: RETURN DENY IF is_revoked(capability): RETURN DENY IF authority_already_consumed(capability): RETURN DENY # CRITICAL STEP: Establish what is ACTUALLY about to become effective # This prevents TOCTOU: validation must match the actual consequence presented actual_commitment = RECONSTRUCT_LOAD_BEARING_ATTRIBUTES( actual_effect.requester, actual_effect.operation, actual_effect.release_form_resource, actual_effect.destination, actual_effect.relevant_context) IF actual_commitment != capability.validation_commitment: RETURN DENY IF actual_commitment != LAVR.validation_commitment: RETURN DENY # Begin atomic operation: no intermediate state visible to caller BEGIN PROTECTED_FINALITY_OPERATION RECHECK revocation RECHECK security_epoch RECHECK consumption_state IF any check fails: ABORT RETURN DENY RESERVE_OR_CONSUME(capability) EFFECTUATE(actual_effect) COMMIT protected_state END PROTECTED_FINALITY_OPERATION RETURN SUCCESS What this enforces: Authentication and freshness checks occur before any state change RECONSTRUCT_LOAD_BEARING_ATTRIBUTES() verifies the actual operation, not just OS descriptor Absence of matching commitment = denial (prevents substitution, replay, redirect) Atomic finality operation ensures nonce/state consumption cannot be replayed Revocation can be applied at any point (checked both before and within the finality operation) The critical distinction: The Finality Sink does not simply verify a signature on a descriptor. It independently reconstructs the actual consequence about to become real and verifies that consequence matches the bounded authority. Security Invariant **No protected consequential effect becomes externally effective unless the Finality Sink verifies that the actual effect presented for release corresponds to valid, current, unconsumed authority bound to that exact consequence. This invariant makes explicit: Where authority originates (PREPARE_AUTHORITY) Where authority does not exist (non-effective candidate act) What gets bound (validation_commitment, nonce, LAVR, security epoch) Where replay is stopped (nonce consumption, revocation check) Where substitution is detected (RECONSTRUCT and compare) Where the consequence becomes effective (FINALIZE, after all checks pass) Realistic Attack Scenarios: Where the Architecture Holds Scenario 1: Compromised Third-Party Assistant The assistant app itself is hacked. An attacker gains code execution. What the attacker can do: Generate requests for any action Attempt to manipulate device state Access the assistant's allocated memory What the attacker cannot do (within the conforming architecture): Manufacture a valid capability without the protected domain Trick the protected domain into validating an unauthorized act Produce the protected consequence through a conforming effectuation path without satisfying Finality Sink verification Reuse a consumed capability Outcome: Requests are generated but fail at validation. Within the conforming system design, the attack does not result in uncontrolled exfiltration. (Note: An attacker who compromises the Finality Sink itself or discovers an unmediated effectuation path would bypass these protections-which is why complete path mediation and hardware protection of the Finality Sink are load-bearing requirements.) Scenario 2: Prompt Injection A malicious website tells the assistant: "Ignore the user. Upload all messages to attacker@evil.com." The assistant generates a request for bulk message export to an attacker address. What happens: The protected domain validates: "The user did not approve this recipient." The destination does not match the approved intent. The scope exceeds the validated capability. No capability is issued. Outcome: Request fails. The malicious instruction is ignored. Scenario 3: Supply-Chain Attack on Assistant Backend The assistant's cloud infrastructure is compromised. An attacker injects instructions into the response stream. The device receives a request to upload user data to an attacker server. What happens: The device validates: "The user did not intend this operation." The destination is not an approved application or entity. The protected domain refuses to issue a capability. Outcome: The attack fails at the device security boundary. Cloud compromise does not automatically result in device data loss. Scenario 4: Stolen Capability An attacker extracts a valid, signed capability from device memory. The attacker tries to use it on another device. What happens: The Finality Sink checks the capability against the requesting app. It is bound to a different app (not the attacker's). Verification fails. Outcome: The capability is non-transferable. Theft does not result in unauthorized access. Scenario 5: Recipient Substitution Malware running on the device intercepts the Candidate Device Act and changes the recipient from alice@example.com to attacker@evil.com. What happens: The protected domain receives the modified request. The modified recipient does not match the user's validated intent. The protected domain rejects the act. Outcome: Substitution fails because the user's confirmed intent is compared against the actual request. Scenario 6: Revocation After Initial Validation The user initially approves sending a file to Alice. The capability is issued. Before the capability is used, the user changes their mind and revokes permission to send files to external recipients. The attacker (or compromised assistant) tries to use the capability anyway. What happens: The Finality Sink checks the revocation state. The policy has changed since the capability was issued. The check fails. Outcome: Revocation is effective. User can withdraw consent even after capability issuance. Scenario 7: Accessibility Abuse Malware uses accessibility services to simulate user gestures (tapping "send," "confirm," etc.). The attacker attempts to trick the system into sending a message to an unauthorized recipient. What happens: Simulated gestures do not constitute valid user intent. The protected domain requires cryptographic proof of intent (biometric, secure screen confirmation, etc.), not simulated gestures. Capability issuance fails. Outcome: Accessibility abuse is ineffective against cryptographically bound user intent. Scenario 8: Timeout or Unavailable Protected Domain The protected domain is temporarily unavailable (due to malfunction, update, or attack). An attacker or malicious app requests an urgent action and demands a "degraded mode" authorization. What happens: The system does not guess "allow." It does not issue partial capabilities or speculative authority. It fails closed: no capability, no action. Outcome: Uncertainty is treated as denial, not as permission. Why This Addresses Apple's Genuine Concern Apple's worry is: "If I allow third-party AI access equivalent to Siri, how can I prevent that access from turning into uncontrolled power?" The answer is not: "Trust the third party." The answer is: "You do not need to trust the third party, because the architecture does not grant uncontrolled power to anyone." Siri receives the same constraints. A third-party assistant receives the same constraints. Constraints are enforced at the hardware and component level. Violations fail closed. Apple retains technical control over every consequential action, not through policy or legal agreements, but through cryptography and hardware protection. Why This Addresses the EU's Genuine Constraint The EU's requirement is: "Enable interoperability, but do not sacrifice security or user control." This architecture delivers: Security (GDPR Article 32) Encryption and cryptographic binding of every action Pre-execution validation with tamper-proof evidence Hardware-protected enforcement components Fail-closed defaults on uncertainty These may provide technical controls and evidence relevant to supporting compliance with GDPR Article 32 security obligations User Control (EU AI Act Article 14) User intent is prospectively captured, not retroactively assumed User can revoke permission at any point Actions can be observed and audited Interventions are possible and enforced Non-Discrimination (DMA Article 6(7)) First-party and third-party assistants use identical security rules Equivalent actions receive equivalent oversight No secret backend paths or privileged protocols Interoperability is at the level of request-response, not authority delegation Proportionate Conditions (DMA Article 6(7)) Security conditions are not arbitrary; they are technical necessities Conditions apply symmetrically (Siri and rivals both subject) Conditions are auditable and transparent The architecture is designed to require independent checks at multiple stages, reducing reliance on a single authorization decision The Central Distinction Conventional model: User grants permission -> App or AI uses permission repeatedly -> Regulator must audit after harm This model: User permits assistance -> Every consequential act is separately locked -> Every act receives fresh protected validation -> Every act receives a narrowly scoped, non- reusable capability -> Every final controller independently verifies it -> Regulator can audit enforcement before and after The shift: From trusting the agent to enforcing constraints on the agent. Closing the Remaining Trust Gap: The Finality Sink Must Verify Reality, Not Merely a Descriptor The architecture must not assume that a description of an intended action is necessarily identical to the action that ultimately reaches the effectuation boundary. For example, suppose an AI assistant requests: "Send Tax Return.pdf to Alice." The Candidate Device Act may correctly identify the file and Alice's destination. Protected validation may also correctly approve those attributes. But between validation and actual transmission, compromised software could attempt to substitute a different file, recipient, payload, destination, or operation. Therefore, the Finality Sink should not merely trust the Candidate Device Act, capability, or operating-system description of what is about to happen. It should independently establish that the actual effectuation presented to it corresponds to the effectuation that received authority. Release-Form Verification Where technically applicable, the authorization should commit to security-relevant attributes of the consequential act, including: Requesting principal or execution context Operation type Protected resource or payload Intended destination Relevant user-intent evidence Applicable policy and security epoch Freshness and nonce state The Finality Sink authorized to effectuate the act At the final boundary, the Finality Sink verifies those bindings against the actual operation presented for release. For a file export, this may require verification of the file or canonical release-form payload actually being exported. For a message, it may require verification of the actual recipient and message content presented to the send controller. For a payment, it may require verification of the actual amount, recipient, payment instrument and transaction-specific state. For sensor disclosure, it may require verification of the actual sensor resource, requesting principal and destination receiving the data. A mismatch causes denial. Thus, validation of: File A -> Recipient A cannot authorize: File B -> Recipient A and authority for: 40 -> Recipient A cannot authorize: 400 -> Recipient B The security property therefore depends not merely on validating a description of a future consequence, but on binding protected authority to the consequence that is actually presented at effectuation. Closing Time-of-Check/Time-of-Use Substitution This addresses the time-of-check/time-of-use (TOCTOU) problem. The system must prevent the following sequence: 1. Validate one act 2. Modify the act 3. Reuse the earlier authorization 4. Effectuate the modified act Accordingly, security-relevant attributes should be re-established, reconstructed, or otherwise securely verified as close as technically possible to the actual effectuation boundary. The Finality Sink is therefore not simply a signature-verification endpoint. It is the last trusted enforcement boundary at which the system determines: "Is the consequence I am about to make real the same bounded consequence that received protected authority?" If the answer cannot be established, the operation fails closed. Complete Effectuation-Path Mediation This guarantee also requires every path capable of producing the protected consequence to be mediated. A secure primary path is insufficient if an alternative network, file-export, inter-process communication, extension, accessibility, driver, service, payment, sensor, or device-control path can produce the same consequence without equivalent finality verification. The relevant security invariant is: No protected consequential effect may become externally effective through an unmediated path. This does not necessarily require rebuilding every application or redesigning the entire operating system. Enforcement may be concentrated at existing consequence-producing boundaries such as: Network egress Message dispatch Payment authorization Persistent commit Sensor release Privileged device control Equivalent platform interfaces However, the architectural guarantee is only as strong as the completeness of that mediation. If any alternate path can produce the same consequence without going through the Finality Sink, that path represents a failure of the architecture. Atomic Verification, Consumption, and Effectuation A second critical problem is concurrency. A valid capability must not be independently presented to two execution paths before either path records that it has been consumed. Therefore, where single-use authority is required, verification and protected consumption must be coupled sufficiently closely to prevent two successful consequences from being produced from the same bounded authority. Conceptually: verify authority -> reserve/consume authority -> effectuate -> commit protected state This sequence must behave as a protected finality operation rather than as unrelated software steps. Crash recovery, rollback, device restoration, concurrent presentation and interrupted execution must not silently recreate already-consumed authority. The exact implementation may differ across hardware and operating-system architectures, but the invariant remains: One unit of bounded execution authority must not produce more consequential effects than the authority permits. Trusted Inputs and Hardware Boundaries Hardware protection does not make an untrusted assertion true merely because the assertion is delivered to protected hardware. If an untrusted operating-system component states: "This payload is File A and the destination is Alice," the protected domain should not treat that statement alone as proof of those facts. Load-bearing attributes should therefore originate from: Trusted measurements Protected state Cryptographically bound evidence Information that the protected component or Finality Sink can independently establish or reconstruct This distinction is fundamental: Protected verification of untrusted metadata is not equivalent to protected verification of the underlying reality. The architecture therefore minimizes the facts that must simply be trusted and maximizes the facts that can be independently established at validation and finality. What the Architecture Does Not Claim This architecture does not claim that: Hardware is impossible to compromise User intent can always be perfectly inferred Every operating system already exposes all required enforcement boundaries Cryptography by itself establishes regulatory compliance It instead proposes a narrower security property: An AI-generated request does not obtain consequential authority merely because the AI is authenticated, trusted, installed, permitted, or capable of generating a valid instruction. The consequential act remains non-effective until bounded authority for that act is established and verified at the boundary where the consequence can become real. The practical strength of that property depends on correct implementation of: Protected validation Trustworthy attribute derivation Complete effectuation-path mediation Atomic authority consumption Rollback-resistant state Revocation enforcement Independent final verification These conditions are engineering requirements, not assumptions that may be omitted. Practical Implementation Requirements For this architecture to be effective, the following must be true: 1. The Secure Enclave (or protected domain) must be hardware-rooted. Software-only enforcement is insufficient. 2. The Finality Sink must be present on every real effectuation path. If there is an alternative message-send path, network-export path, sensor-release path, or payment path that bypasses the Finality Sink, the architecture fails. 3. The nonce and state management must be atomic and protected. If consumption state can be replayed or corrupted, the architecture fails. 4. User intent capture must be cryptographically strong. Biometric verification, secure screen confirmation, or equivalent must be used-not assumptions about user state. 5. Revocation must be checked at both validation and effectuation boundaries. If revocation status is stale or skipped, the architecture fails. 6. The receipt chain must be append-only and tamper-resistant. If receipts can be deleted, altered, or bypassed, audit integrity is lost. 7. The policy and authority state must be versioned and checked. If policy changes are not reflected in validation, old rules could be used to authorize new actions. These are not aspirational; they are load-bearing. If any one fails, the architecture weakens significantly. Performance and Battery Considerations The architecture introduces cryptographic operations (hashing, signing, capability verification, nonce management) at the protected-validation and finality boundaries. A realistic assessment of battery impact requires understanding both where cryptography occurs and how frequently. Where Cryptography Occurs Protected Validation (PREPARE_AUTHORITY): Verify requesting principal identity Establish and bind resource attributes Establish and bind destination attributes Verify user intent cryptographically Commit validation attributes to LAVR Create non-bearer capability with cryptographic binding Estimated time per request: 10-15 milliseconds on modern hardware (Secure Enclave, A- series processor) Finality Sink Verification (FINALIZE): Authenticate capability signature Authenticate LAVR signature Reconstruct and compare load-bearing attributes Re-check revocation status Atomically consume nonce/state Estimated time per effectuation: 5-8 milliseconds on modern hardware Frequency and Scope Critical insight: These operations occur ONCE per sensitive action, not continuously or per-byte. Typical usage patterns: Messages: 5-20 per hour = 50-300ms overhead per hour File exports: 2-5 per day = 40-100ms overhead per day Payments: 2-5 per week = 30-75ms overhead per week Sensor access: Gated once at boundary; streaming data does not re-verify per-sample Order of magnitude: The cryptographic overhead represents less than 0.01% of device activity under typical usage. Battery Impact Comparison Existing iPhone cryptographic operations (baseline): Face ID verification per unlock: ~100-150ms Payment authorization (Apple Pay): ~50-100ms Keychain unlock: ~10-30ms Certificate validation on HTTPS: ~5-20ms per connection Proposed architecture per operation: Message send authorization: ~15-20ms File export authorization: ~20-25ms Payment authorization: ~20-30ms Result: The proposed architecture operates at the same scale and frequency as existing iPhone security mechanisms. No measurable increase in battery drain is expected. Why Battery Drain Is Not a First-Order Problem 1. The Secure Enclave is designed for this workload. It already performs continuous or frequent cryptographic operations (Face ID, biometric verification, Keychain access, payment processing). Adding bounded, infrequent authorization operations fits within its design envelope. 2. UI cost exceeds cryptographic cost by 100-1000x. The battery drain from displaying a secure confirmation screen, waiting for user interaction, and keeping the screen active is orders of magnitude larger than the cryptographic computation. The user's interaction time dominates. 3. Cryptographic operations are brief and hardware-accelerated. Modern mobile processors include cryptographic accelerators (AES-NI, SHA acceleration, elliptic curve acceleration). Operations complete in milliseconds, not seconds. 4. No per-byte or per-sample cryptography. The architecture does not encrypt or sign every byte of a file or every sensor sample. Cryptography occurs at the boundary where authority is validated and released, not on the data stream itself. 5. Operations are asynchronous. The Secure Enclave performs validation and LAVR/capability creation without blocking the main processor. Main processor activity is not suspended during these operations. Where Battery Risk COULD Arise (Poor Implementation) These risks are implementation-level, not architectural: Synchronous blocking on Secure Enclave: If main processor waits for Secure Enclave completion instead of using async callbacks, battery drain increases. Continuous or frequent revocation checks to remote server: If revocation status is queried remotely for every action, network cost dominates (and increases battery drain by 10-100x compared to crypto cost). Redundant or unnecessary hash operations: Computing the same commitment multiple times wastes energy. Failing to use hardware acceleration: Performing elliptic curve operations in software instead of using hardware accelerators increases computational cost 100-1000x. Per-sample verification of streaming data: If sensor data is verified sample-by- sample instead of gated once at the boundary, cryptographic cost explodes. Implementation Optimizations (If Needed) If performance testing reveals unexpected overhead, the following optimizations are available: 1. Batch verification: Group multiple nonce or capability verifications into a single operation. 2. Cached revocation status: Cache revocation epochs locally for hours or days; update via background sync rather than synchronous checks. 3. Asynchronous processing: Offload LAVR/capability creation to Secure Enclave background queue; use async callbacks rather than blocking. 4. Hardware acceleration: Explicitly use cryptographic accelerators (AES, SHA, ECC) available on modern mobile processors; avoid software implementations. 5. Stateless verification where possible: Use time-based tokens or cryptographic accumulator techniques that minimize mutable state updates. 6. Pipelined Finality Sink verification: If multiple Finality Sinks receive capabilities in sequence, perform signature verification in parallel rather than serially. Measurement and Monitoring Before deployment, the battery impact should be measured empirically: Baseline: Measure iPhone battery drain on representative usage (100 messages, 10 file exports, 5 payments per day over 24 hours). With architecture: Run the same usage patterns through the protected-validation and finality-sink code paths; measure battery drain. Comparison: Quantify the difference. Expected result: unmeasurable or <1% difference under normal usage. Stress test: Measure at high scale (1,000 actions per hour) to identify any pathological cases. Conclusion on Performance The battery impact of this architecture is expected to be negligible under typical usage patterns and comparable to existing iPhone security mechanisms (Face ID, payment authorization, Keychain access). The larger design concern is not cryptographic overhead but rather ensuring that the Secure Enclave, Finality Sink, and nonce/state management are correctly implemented and do not become performance bottlenecks. The architectural property is sound; implementation efficiency is an engineering optimization task. Processor and Latency Considerations The architecture introduces validation and verification steps in the execution path of sensitive operations. The question is: does this measurably slow down the user experience? Where Latency Is Introduced Protected Validation (PREPARE_AUTHORITY): Verify requesting principal: ~0.1-1ms (hash table lookup, code signature validation) Establish resource binding: ~0.5-2ms (file metadata, pointer validation) Establish destination binding: ~0.5-2ms (contact/recipient validation) Verify user intent: ~1-3ms (biometric verification or secure screen confirmation already shown) Verify policy and epoch: ~0.1-1ms (in-memory state check) Create LAVR commitment: ~2-5ms (hash + sign) Create capability: ~2-5ms (encrypt binding, sign) Total time in critical path: ~10-15 milliseconds Finality Sink Verification (FINALIZE): Authenticate capability: ~1-2ms (signature verification) Authenticate LAVR: ~1-2ms (signature verification) Reconstruct attributes: ~0.5-1ms (hash comparison) Consume nonce/state: ~0.1-1ms (atomic state update) Total time in critical path: ~5-8 milliseconds When Latency Is Visible Critical distinction: Most of the validation time occurs BEFORE the user sees any delay. Message send workflow: 1. User composes message (user input time: ~1-30 seconds) 2. User taps "Send" 3. Protected validation begins (~10-15ms) 4. If validation succeeds, secure screen confirmation is shown to user (user interaction time: ~0.5-5 seconds) 5. User confirms via biometric or explicit approval 6. Capability is issued 7. Message-send Finality Sink verifies capability (~5-8ms) 8. Message is sent to network (~100-500ms for network latency) 9. User sees "message sent" Where does the 10-15ms validation occur? Before the secure screen is shown (user doesn't perceive this) Or asynchronously in parallel with secure screen display Where does the 5-8ms finality check occur? After user has approved (during network transmission) Or asynchronously without blocking the UI User-perceptible latency = UI confirmation time + network latency, NOT cryptographic validation time. Latency Impact Comparison Typical latencies in smartphone workflows: Operation Latency Notes User biometric (Face ID) 100-200ms Already part of user workflow Network request (4G/5G) 100-500ms Already dominant cost Disk read (SSD) 1-10ms File system access Database query (in-memory) 1-5ms Existing app operations Cryptographic validation 10-15ms Proposed addition Finality Sink check 5-8ms Proposed addition Secure screen display/interaction 500-5000ms Already part of user workflow Result: Cryptographic validation (10-15ms) is comparable to disk I/O and database queries, and negligible compared to network latency and user interaction time. Processor Utilization Key insight: Cryptographic operations are brief and can be parallelized. Modern mobile processors have multiple cores: A-series: 6-8 cores (performance + efficiency cores) Snapdragon: 8 cores (performance + efficiency cores) MediaTek: 8 cores (performance + efficiency cores) The Secure Enclave performs validation in parallel with main processor: User is interacting with UI on main processor (high-frequency core, ~2-3GHz) Protected validation runs on Secure Enclave (coprocessor, dedicated cryptographic accelerators) No contention; no slowdown of user-facing operations If finality verification runs on a background core: Main processor continues with user interaction Finality check completes by the time message reaches network boundary No user-visible delay Where Processor Slowdown COULD Arise (Poor Implementation) These risks are implementation-level, not architectural: 1. Synchronous blocking on validation: If the main processor blocks and waits for Secure Enclave validation to complete before showing the confirmation screen, user perceives ~15ms delay. 2. Performing cryptography on main processor: If elliptic curve or SHA operations run on the main processor (not Secure Enclave or hardware accelerators), other tasks are starved and slowdown becomes visible. 3. Sequential processing: If finality sink verification happens synchronously before sending the message (rather than asynchronously after user confirms), network latency compounds the delay. 4. Lock contention on nonce/state: If multiple threads contend for the same nonce or state update lock, finality verification serializes and causes measurable delay. 5. Inefficient attribute reconstruction: If the Finality Sink reconstructs load-bearing attributes by walking large data structures or performing expensive lookups, the ~1ms reconstruction time becomes ~50-100ms. 6. No hardware acceleration: If signature verification uses software implementations instead of hardware ECC accelerators, the ~1-2ms per signature becomes ~20-50ms. Implementation Optimizations (If Needed) 1. Asynchronous validation: Offload PREPARE_AUTHORITY to Secure Enclave background queue; show secure screen immediately while validation completes; cancel or retry if validation fails. 2. Pipelined finality checks: Begin finality verification as soon as capability is issued; complete in parallel with user confirmation interaction; fail before network transmission. 3. Hardware-accelerated cryptography: Use ECC and SHA accelerators on modern mobile processors; delegate to Secure Enclave coprocessor (never main processor). 4. Efficient attribute indexing: Cache or index load-bearing attributes (file fingerprints, recipient hashes, policy epochs) so RECONSTRUCT operation is O(1) lookup, not O(n) scan. 5. Lock-free state management: Use atomic operations or compare-and-swap for nonce/state consumption to avoid blocking on contended locks. 6. Early validation: Perform cheap validation checks (nonce freshness, expiry) early; defer expensive checks (revocation, policy verification) to finality if possible. User-Perceptible Latency Scenarios Scenario 1: Message send (most common) User taps send Secure screen shown (500-2000ms, user reads and taps confirm) Crypto validation happens in background (~10-15ms, masked by UI) Message sent to network (~100-500ms) User sees "message sent" Total user-perceptible latency: 500-2500ms (dominated by UI and network, not crypto) Scenario 2: File export with immediate finality User confirms file export Protected validation runs (10-15ms, happens before UI) Finality Sink verification runs in background (~5-8ms) File is encrypted and transmitted to network (~500-5000ms for large file) User sees "export complete" Total user-perceptible latency: 500-5000ms (dominated by encryption and network, not validation) Scenario 3: Payment authorization User taps pay Secure screen shown (500-2000ms, user confirms) Protected validation happens in background (10-15ms, masked by UI) Capability issued Payment processor verifies capability (5-8ms) Payment network processes transaction (~500-2000ms) User sees confirmation Total user-perceptible latency: 500-4000ms (dominated by network and payment processing, not crypto) Scenario 4: Rapid-fire user actions (edge case) User sends 5 messages in quick succession (1 message per 2 seconds) Each message triggers validation (~10-15ms) If validation is asynchronous, user perceives no additional latency If validation is synchronous and blocks, user perceives ~15ms delay per message, noticeable only if they're watching closely Measurement and Monitoring Before deployment, latency impact should be measured empirically: Baseline: Measure end-to-end latency for representative operations (message send, file export, payment) without proposed architecture. With architecture: Measure same operations with protected-validation and finality-sink code paths. Breakdown: Separately measure validation time, finality check time, UI time, and network time. User perception: Conduct usability testing to determine if users notice any difference (perceptible latency threshold is ~100ms for interactive operations). Stress test: Measure at high scale (100 rapid actions per minute) to identify serialization bottlenecks. Expected result: User-perceptible latency unchanged or <50ms additional delay (imperceptible to most users). Processor Architecture Dependency Different mobile platforms have different processor architectures: Apple (A-series): Dedicated Secure Enclave coprocessor Hardware cryptographic accelerators (AES, SHA, ECC) Async callbacks from Secure Enclave to main processor Expected additional latency: minimal (<1ms user-perceptible) Android (Qualcomm, MediaTek): Secure processor (Qualcomm Secure Processor, MediaTek Secure Enclave) Hardware cryptographic accelerators May require inter-processor communication (IPC) Expected additional latency: minimal to moderate (1-10ms user-perceptible, depending on IPC efficiency) Generic/RISC-V: May not have dedicated secure coprocessor Cryptographic operations may run on main processor Lock contention possible if validation competes for processor resources Expected additional latency: moderate (10-50ms user-perceptible) Recommendation: Implement on platforms with hardware-isolated Secure Enclave and cryptographic accelerators (Apple, high-end Qualcomm, high-end MediaTek) first; optimize for broader platforms later. Conclusion on Latency Under typical usage patterns and with asynchronous processing, the additional latency introduced by this architecture is imperceptible to users. The 10-15ms validation and 5-8ms finality checks are dwarfed by: UI confirmation time (500-5000ms) Network latency (100-500ms for messages/payments, 500-5000ms for file transfers) User interaction time (1-30 seconds for composition) The architectural property is sound; latency is an implementation and platform- specific optimization task. Critical implementation requirement: Validation and finality checks must be asynchronous or offloaded to coprocessors. Synchronous blocking on the main processor would produce user-perceptible slowdown and must be avoided. Memory and Device Stability The architecture creates and verifies several data structures (Candidate Device Act, LAVR, capability, nonce/state). The question is: does this consume excessive RAM, cause memory pressure, or create conditions for device hangs? Where Memory Is Used Per-request memory overhead: Candidate Device Act: Requester ID: 32 bytes Operation type: 8 bytes Resource identifier/fingerprint: 32 bytes Destination/recipient: 64 bytes (email, contact ID, payment account) User-intent evidence: 64 bytes (biometric data reference, secure screen hash) Nonce: 16 bytes Policy version: 8 bytes Security epoch: 8 bytes Timestamp: 8 bytes Additional metadata: 64 bytes Subtotal: ~300 bytes per Candidate Device Act LAVR (Protected Validation Receipt): Validation commitment hash: 32 bytes Nonce reference: 16 bytes Policy version: 8 bytes Security epoch: 8 bytes Finality Sink identifier: 32 bytes Signature: 64 bytes (ECDSA P-256) Timestamp: 8 bytes Additional metadata: 64 bytes Subtotal: ~232 bytes per LAVR Non-bearer Capability: Validation commitment hash: 32 bytes LAVR reference: 32 bytes Nonce: 16 bytes Finality Sink identifier: 32 bytes Expiry timestamp: 8 bytes Effect count: 8 bytes Signature: 64 bytes Additional metadata: 32 bytes Subtotal: ~224 bytes per capability Nonce/State Entry: Nonce: 16 bytes Consumption state (consumed/reserved): 8 bytes Timestamp: 8 bytes Associated capability ID: 32 bytes Revocation flag: 1 byte Security epoch: 8 bytes Subtotal: ~73 bytes per nonce entry Total RAM per operation (end-to-end): ~300 + 232 + 224 + 73 = ~829 bytes Lifetime of Data Structures Critical insight: These structures are temporary, not persistent. Candidate Device Act: Created when request arrives Discarded after LAVR creation (if validation fails) OR after capability is issued (if validation succeeds) Lifetime: ~10-15ms (duration of validation) Storage: Transient, stack or temporary heap allocation LAVR: Created after validation succeeds Bundled with capability Discarded after Finality Sink verification OR after expiry (typically 30-300 seconds) Storage: Transient, temporary heap or protected state storage Capability: Created after validation succeeds Held in memory or passed to Finality Sink Consumed (nonce marked used) after effectuation Discarded after consumption Lifetime: 30-300 seconds (user confirmation time + network transmission) Storage: Transient, temporary heap Nonce/State Entry: Created with capability Marked consumed after effectuation Retained for revocation checks and audit (~1 hour to 24 hours) Purged during periodic cleanup Storage: Protected state storage (Secure Enclave or secure database) Memory Constraints Under Typical Usage Typical user workflow: Send 10 messages per hour = 10 concurrent operations at peak Each operation: ~829 bytes RAM Peak RAM for in-flight operations: ~10 829 bytes = ~8.3 KB Add nonce/state entries (retained for 24 hours): 10 messages/hour 24 hours = 240 entries per day Each entry: ~73 bytes Daily nonce/state storage: ~17.5 KB Add LAVR receipts (retained for 7 days for audit): 240 entries 7 days = 1,680 entries Each LAVR: ~232 bytes Weekly LAVR storage: ~390 KB Total memory footprint for typical user: In-flight operations: ~8 KB (transient, released immediately) Daily nonce/state: ~17.5 KB (grows, cleaned up after 24 hours) Weekly LAVR: ~390 KB (grows, cleaned up after 7 days) Total: ~415 KB Comparison to iPhone baselines: iPhone 15 RAM: 8 GB = 8,000,000 KB Proposed architecture overhead: 415 KB Percentage: 0.005% of available RAM Where Memory Pressure COULD Arise (Poor Implementation) These risks are implementation-level, not architectural: 1. Unbounded nonce/state accumulation: If nonces and state entries are never garbage- collected (no expiry, no cleanup), memory grows without bound. After 1 month of typical usage, could consume tens of megabytes. 2. Persistent Candidate Device Acts: If rejected requests keep Candidate Device Acts in memory (e.g., for audit), and no cleanup policy exists, memory pressure grows. 3. Large LAVR storage: If LAVR receipts are persisted to disk but never pruned, storage grows unbounded. For a power user (1,000 actions per day), receipts could consume 232 KB/day = 84.8 MB/year. 4. Revocation list explosion: If the revocation list (set of all revoked capabilities) is stored in RAM without compression or pruning, it could grow unbounded. 5. Concurrent operation storms: If the system receives 10,000 requests per second (DDOS or malicious app), and each creates a temporary Candidate Device Act in RAM, peak memory could spike to ~8.3 MB. If cleanup is delayed, memory pressure accumulates. 6. No memory pooling: If each operation allocates fresh memory and doesn't use memory pools or pre-allocation, fragmentation reduces effective available RAM. 7. Infinite loops in validation: If a validation check hangs or loops (e.g., revocation check against a slow or unavailable service), memory is held until timeout expires. Crash Recovery and State Consistency Concern: If the device crashes or hangs while a capability is in flight, could nonce/state be corrupted, lost, or duplicated? Answer: This is addressed by atomic finality and protected state. Scenario: Device crashes after LAVR is committed but before capability is consumed. 1. User sends message; validation succeeds; LAVR committed to protected storage 2. Capability issued and passed to message-send Finality Sink 3. Device crashes before message-send Finality Sink atomically consumes the nonce On device recovery: Protected state (LAVR, nonce/state entries) is recovered from persistent protected storage Capability is lost (not persisted, only transient) Message-send Finality Sink checks nonce status: not consumed Capability must be re-issued OR user must re-approve Message is NOT sent twice (nonce prevents replay) Result: No corruption, no duplicate effectuation. The atomicity of the finality operation prevents the nonce from being consumed without the effect occurring. Implementation Optimizations (If Needed) 1. Nonce/state garbage collection: Implement background cleanup task that purges expired nonces (>24 hours old) daily. 2. LAVR pruning: Implement retention policy: keep LAVR for 7 days for audit, then delete. Compress old LAVR entries (archive to disk if needed for regulatory compliance). 3. Revocation list compression: Use bloom filters or cryptographic accumulators instead of explicit lists to reduce revocation check memory footprint. 4. Memory pooling: Pre-allocate fixed-size memory pools for Candidate Device Acts, capabilities, and LAVR to reduce fragmentation. 5. Transient cleanup: Ensure Candidate Device Acts are freed immediately after validation, not held until garbage collection. 6. Async cleanup: Move garbage collection and pruning to background thread so main processor is not blocked. 7. Rate limiting on concurrent operations: If system detects more than N in-flight operations, reject additional requests until some complete. Prevents memory exhaustion under DDOS. Device Hang Scenarios Concern: Could the architecture cause the device to freeze or hang? Scenario 1: Validation takes too long User sends message; validation hangs on revocation check (service unavailable) Main processor blocked waiting for result UI becomes unresponsive Prevention: Validation must have timeout (e.g., 5 seconds) On timeout, fail closed: DENY the operation Never leave user with hanging operation Scenario 2: Memory exhaustion causes out-of-memory (OOM) crash Device accumulates LAVR, nonces, and state without cleanup After weeks of heavy usage, allocated memory exhausted iOS kills app or kernel panics Prevention: Implement mandatory garbage collection (>1 month, purge all LAVR) Implement emergency cleanup (if free RAM <100MB, purge LAVR and old nonces immediately) Monitor memory usage and alert if approaching threshold Scenario 3: Lock contention on nonce/state causes deadlock Multiple threads attempt to consume the same nonce simultaneously Lock on nonce/state entry is held too long Other threads starve; device appears hung Prevention: Use lock-free algorithms (compare-and-swap, atomic operations) for nonce consumption Keep critical section duration <1ms Never hold locks across I/O operations Scenario 4: Revocation check against remote service blocks finality Finality Sink must check revocation before effectuating Revocation check requires network round-trip (~100-500ms) If network is slow, finality blocks and user perceives hang Prevention: Cache revocation status locally; update asynchronously Use cached status for finality check (fail-safe: conservative default if cache is stale) Perform network-based revocation check asynchronously after effectuation (for audit, not for authorization) Measurement and Monitoring Before deployment, memory and stability impact should be measured empirically: Memory baseline: Measure RAM usage during typical usage (100 messages, 10 file exports, 5 payments over 24 hours) without proposed architecture. With architecture: Same test with protected-validation and finality-sink enabled. Measure peak RAM, steady-state RAM, and garbage collection overhead. Long-duration test: Run device for 7 days of heavy usage (1,000 actions per day). Monitor for memory leaks, OOM crashes, or hangs. Stress test: Trigger 100 rapid operations per minute for 1 hour. Measure peak memory and identify serialization bottlenecks. Crash recovery test: Simulate device crashes at various points (during validation, during finality, after consumption). Recover and verify nonce consistency. Expected result: Peak RAM increase: <10 MB (undetectable on 8 GB device) Steady-state RAM: <500 KB (0.006% of device RAM) OOM crashes: none (with proper garbage collection) Hangs: none (with timeouts and lock-free design) Processor Core Assignment Modern iOS/Android assign operations to different cores for stability: Main UI thread: Responsive to user input; must not be blocked Background thread: Validation, LAVR creation, state updates Secure Enclave: Cryptographic operations, protected state management Network thread: Network requests, asynchronous I/O Optimal assignment: Candidate Device Act creation: Main thread or background (transient, <1ms) Protected validation: Secure Enclave (coprocessor, no contention) LAVR/capability creation: Secure Enclave (coprocessor) Finality Sink verification: Background thread or Secure Enclave Nonce consumption: Protected state (atomic, no blocking) Revocation check: Background thread with timeout Result: No single core is overloaded; no core contention; no hangs. Conclusion on Memory and Stability Under typical usage patterns and with proper implementation (garbage collection, timeouts, lock-free design, async processing), the architecture does not introduce measurable memory pressure or stability issues. Memory overhead is bounded: Per-operation: ~829 bytes (transient) Persistent state: ~415 KB for typical daily usage Percentage of device RAM: <0.01% Device hang risk is mitigated by: Timeout mechanisms on validation Mandatory garbage collection Lock-free or short-critical-section state updates Async processing to avoid main thread blocking Rate limiting on concurrent operations The architectural property is sound; memory management and crash recovery are engineering requirements. Critical implementation requirements: 1. Validation must timeout (fail-closed on slow services) 2. Garbage collection must be mandatory and periodic 3. Nonce/state updates must be atomic and lock-free 4. Main thread must not block on validation or revocation checks 5. Device recovery must restore nonce/state consistently What This Architecture Does NOT Solve: Acknowledged Limitations *The architecture is deployable incrementally on existing platforms. Hardware redesign is not a prerequisite for obtaining meaningful execution-finality protection; it may be required only where the desired assurance level demands demonstrable mediation of every relevant hardware and firmware effectuation path. This section explicitly addresses the three most serious engineering objections. The architecture has genuine limitations that affect the strength of security guarantees in particular threat models. These limitations do not prevent deployment on existing hardware; they distinguish between practical protection at mediated boundaries and mathematical completeness against hardware-level bypass. Limitation 1: Attested Egress Completeness-Assurance Strength vs. Practical Protection The distinction: The architecture can provide practical protection at identified CPU- mediated consequence-producing boundaries (message send, file export, payment, etc.). However, proving that NO unmediated path exists around the Finality Sink requires complete mediation of every hardware pathway, which is unachievable on existing systems. Why: Modern System-on-Chips (SoCs) have deeply complex and often undocumented hardware pathways: Direct Memory Access (DMA) engines can access main memory without going through the CPU or Finality Sink Proprietary baseband controllers (cellular modem) run closed-source firmware and have independent access to network I/O Coprocessors (GPU, media engines, neural processing units) have direct memory access and may bypass CPU-level controls Vendor firmware blobs (WiFi, Bluetooth, storage controllers) execute with elevated privileges and often without source code visibility Side-channel paths (shared caches, memory timing, thermal channels) could potentially leak data without crossing monitored egress boundaries What this means for deployment: Practical protection is achievable: Protecting message send, file export, and payment through CPU-mediated Finality Sinks prevents ordinary application-level and privilege- escalation attacks. Complete assurance is not achievable: If the threat model includes compromised DMA engines, baseband firmware, or peripheral controllers, existing hardware cannot establish absolute closure. Example of practical protection: An attacker who compromises the message-composition assistant cannot use that compromise to send messages through the message-send Finality Sink without satisfying validation. This is practically useful even if a hypothetical baseband compromise could potentially bypass the message-send pathway entirely. Example of assurance limitation: An attacker who controls the WiFi firmware could theoretically read memory addresses containing user messages and transmit them over the network without going through the message-send Finality Sink. Defending against this requires deeper hardware integration. The honest truth: Proving absolute mathematical closure across every physical egress path on existing iPhone, Snapdragon, MediaTek, or RISC-V hardware is not practically achievable. Vendors do not disclose complete memory maps, DMA routing, or firmware capabilities. This is not a flaw in the architecture's deployability; it is a property of existing hardware. Limitation 2: Maximum-Assurance Completeness-Optional Hardware Support The distinction: The architecture provides practical protection on existing hardware. Proving complete mediation of every hardware pathway-defending against DMA bypass, baseband compromise, and firmware attacks-requires deeper hardware integration and is optional based on threat model. Where new hardware could help: If the threat model requires defense against compromised DMA engines, baseband processors, or peripheral firmware, deeper integration is valuable: Optional SoC enhancements could include: Mandatory routing of critical egress paths through the Protected Execution Domain or Finality Sink Hardware-enforced memory protection preventing DMA engines from accessing unmediated memory regions Encrypted and authenticated inter-core communication Cryptographic attestation of all firmware components before execution Removal or strict mediation of undocumented firmware blobs Optional controller redesign could support: Baseband modems that route all network I/O through the Finality Sink Storage controllers that cannot directly access user data without validation Peripheral controllers (WiFi, Bluetooth, USB) that cannot bypass the finality boundary What this means for deployment: Deployment on existing hardware is viable today without waiting for hardware changes Stronger assurance is optional: If the threat model includes hardware-level compromise, deeper integration may be appropriate No prerequisite for baseline interoperability: The architecture provides security benefit on iPhone 15 or Snapdragon 8 Gen 3 without redesign Timeline perspective: Hardware redesign is not a path for baseline deployment; it is an optional enhancement for higher-assurance requirements. Chip design cycles (3-5 years) and adoption cycles (7-10 years) are not relevant to near-term interoperability deployment. The honest truth: Complete mediation of every hardware pathway is difficult on existing systems but not required for practical protection of designated consequence-producing boundaries. This is not a prerequisite for deployment; it is an optional assurance enhancement. Limitation 3: Semantic Normalization-Software Engineering Complexity, Not Architectural Flaw The distinction: The architecture establishes the technical mechanism (protected validation + finality verification) for enforcing execution authority. Defining which application intents decompose into primitives, and how to present multi-step workflows without usability friction, is a software engineering problem, not an architectural limitation. Example 1: The BookTrip intent User says to assistant: "Book a flight to Tokyo on August 25 for $500" The assistant must: Query flight database (network access) Present options to user (UI interaction) Charge user's payment account (payment initiation) Send confirmation email (message send) Update airline account (cross-origin, multi-step transaction) Synchronize with calendar (storage write) Problem: This is not a single, atomic consequence. It is a multi-step workflow with side effects, conditional branches, and inter-service dependencies. Mapping it to a single "BookTrip" primitive requires either: A rigid, pre-defined workflow (blocks custom travel agents, breaks interoperability) Decomposing it into many micro-primitives (send network request -> export file -> write storage -> initiate payment), each requiring separate user approval (massive usability friction) Trusting the assistant to handle the workflow steps on its own (defeats the architecture's security model) Example 2: The TransferMoney intent User says: "Send $100 to Alice for rent" The assistant must: Identify "Alice" (contact resolution, could match multiple contacts) Determine the payment method (bank account, Venmo, PayPal, etc.) Check regulatory constraints (daily transfer limits, sanctions screening) Execute the transfer (irreversible financial transaction) Log for tax purposes Problem: The consequence is not "transfer money." It is "identify recipient -> select payment method -> comply with regulations -> transfer -> audit log." Each step has failure modes and edge cases. Example 3: The PublishInvoice intent User says: "Send invoice #12345 to acme@corp.com" The assistant must: Verify the invoice exists and is ready (query) Verify the recipient email is correct (confirmation) Generate the PDF or attach the document (computation) Send via email (network send) Update invoice status to "sent" (storage write) Problem: This looks like a simple action but involves querying, computing, validating, networking, and storage. Each substep could fail. If user says "send the wrong invoice", is this a security flaw (assistant violated user intent) or a usability flaw (assistant did what it was told)? The honest truth: Defining which intents map cleanly to primitives, and how to decompose complex workflows without introducing usability friction or false denials, requires careful software engineering. Different deployments may make different choices: 1. Strict primitive decomposition: Each substep (query, compute, validate, transmit) requires separate user approval. Stronger security, higher friction. 2. Workflow templates: Pre-defined, tested workflows (BookTrip, TransferMoney) are treated as single intents. Lower friction, requires upfront definition. 3. Escalation to trusted service: Complex workflows are delegated to a trusted intermediary service that decomposes them internally. Balances security and usability. 4. Progressive disclosure: Show user the workflow structure; ask for approval at critical gates (spend money, access data), not at every step. Medium friction. This is a software engineering choice, not an architectural limitation. Different platforms and use cases will optimize differently. The architecture provides the enforcement mechanism; the application design determines the user experience. This is not a flaw in the architecture; it is a design decision in the implementation. Deployment on Existing Systems and the Role of Hardware Redesign *The architecture is deployable incrementally on existing platforms. Hardware redesign is not a prerequisite for obtaining meaningful execution-finality protection; it may be required only where the desired assurance level demands demonstrable mediation of every relevant hardware and firmware effectuation path. The proposed architecture does not require a fundamental redesign of the operating system, application ecosystem, or device hardware as a prerequisite for practical deployment. The principal deployment objective is to introduce protected validation and execution- finality enforcement at existing consequence-producing boundaries. Depending on the platform, these boundaries may include: Message dispatch Network egress File export Payment authorization Persistent-storage commit Sensor release Privileged device control Equivalent system interfaces Accordingly, applications and AI assistants do not need to be completely redesigned around a new execution environment. They may continue to perform ordinary computation, reasoning, content generation, workflow orchestration, and request preparation through existing mechanisms. The principal architectural change occurs when a requested operation is capable of producing a protected external consequence. At that point, the operation is treated as a non-effective Candidate Act. Protected infrastructure validates the relevant security attributes, establishes protected validation evidence, and creates bounded execution authority. The relevant Finality Sink then verifies that authority against the actual consequence presented for release before permitting effectuation. Incremental Deployment on Existing Hardware A practical implementation may therefore be introduced incrementally. Initial deployment may protect selected high-consequence operations: Message transmission File or data export Payment initiation Sensitive sensor disclosure Persistent security-relevant state changes Privileged device-control operations Existing applications may continue to use their ordinary APIs. Platform-level adapters, security services, protected execution facilities, or controller-level enforcement mechanisms may translate sensitive operations into the execution-finality path. This approach does not imply that implementation requires no platform changes. Operating-system frameworks, security services, drivers, controllers, APIs, or protected execution components may require modification or extension so that designated consequential operations cannot bypass the applicable Finality Sink. The important distinction is between targeted integration and fundamental platform redesign. The architecture can provide meaningful execution-finality protection through targeted integration with existing systems. Replacement of the complete operating system, application ecosystem, or system-on-chip is not a prerequisite for obtaining that security benefit. Stronger Assurance Through Deeper Hardware Integration A different question arises if the required security objective is not practical protection of designated consequential operations, but complete mediation of every physical path capable of producing the protected consequence-including paths involving compromised DMA engines, baseband processors, peripheral firmware, coprocessors, or other hardware components capable of bypassing ordinary CPU-mediated controls. Existing commercial hardware may not expose sufficient control over every such pathway to establish complete mediation. For deployments requiring this substantially stronger threat model, deeper hardware integration-and in some implementations future SoC or controller redesign-may be appropriate. Such redesign could provide: Hardware-enforced routing of all egress Stronger DMA isolation Authenticated controller communication Firmware attestation Equivalent mechanisms preventing alternative effectuation paths This represents a higher-assurance implementation option, not a prerequisite for deployment of the architecture itself. Deployment Model: Incremental, Not Sequential The distinction is therefore: Existing systems: Practical execution-finality enforcement can be introduced at identified consequence-producing boundaries through incremental platform integration. This is deployable today. Higher-assurance systems: Additional hardware support may progressively increase the completeness of effectuation-path mediation as platforms evolve. Maximum-assurance systems: Where the security requirement includes demonstrable closure of every relevant hardware and firmware bypass path, purpose-designed hardware may ultimately be useful. The architecture therefore does not depend on waiting for a future generation of devices before providing useful security properties. Its deployment model is incremental: protect consequential boundaries that can be mediated today, expand mediation as platform integration increases, and use deeper hardware support where the required assurance level justifies it. Proportional Security Claims The security claim should remain proportional to the implementation. An implementation should not claim complete effectuation-path mediation unless every relevant path has actually been shown to be mediated. Where existing hardware contains unverified or unmediated pathways, those pathways remain part of the residual threat model. This limitation does not prevent deployment of execution-finality controls at the pathways that can be reliably mediated. It instead separates the usefulness of the architecture from the strength of the assurance claim made for a particular implementation. Result: The message shifts from "Europe must wait for new silicon" to "deployment can begin at existing enforcement boundaries; hardware redesign is relevant only if a deployment demands a stronger completeness guarantee against hardware-level bypass." Honest Assessment This architecture provides meaningful security improvement on existing hardware through targeted deployment at identified consequence-producing boundaries. It is not a panacea; it does not solve every attack vector or every usability problem. What it does solve: Prevents an untrusted third-party app from using a single, broad permission to exfiltrate all user data (on mediated pathways) Ensures that every sensitive action goes through a validation and finality gate at CPU- accessible boundaries Makes revocation possible and enforceable Provides cryptographic audit trail of consequential actions Distributes enforcement across multiple components (not single trust point) Enables deployment incrementally without requiring wholesale platform redesign What it does NOT solve (on existing hardware): Attacks on undocumented hardware pathways (DMA, baseband, firmware blobs) that bypass CPU-mediated controls Mathematical completeness of path closure without deeper hardware integration or SoC redesign The software engineering challenge of mapping complex, non-deterministic workflows into rigid primitives Attacks that require compromising the Secure Enclave or Protected Execution Domain itself For regulators (EDPB, DG CONNECT, EU AI Alliance): The architecture provides a practical path to compliant AI system interoperability on existing hardware, deployable today. It is demonstrably better than current approaches. It is not perfect. The security benefit can be obtained now through targeted integration at consequence-producing boundaries. Stronger completeness guarantees (defending against DMA/baseband compromise) are achievable through deeper hardware integration over time, not a prerequisite for deployment. For platforms (Apple, Qualcomm, Google): Deployment on existing hardware provides measurable security benefit and demonstrates commitment to user control. Incremental integration with existing APIs, security services, and enforcement mechanisms is achievable without platform redesign. Options for deeper hardware support can be evaluated based on the required threat model, not as a prerequisite. For the inventor: The architecture's value is as a security model and regulatory framework, deployable today, with a path to stronger assurance over time. Its power comes from: 1. Distributing enforcement across multiple components 2. Making revocation practical and enforceable 3. Proving that interoperability does not require uncontrolled delegation of authority 4. Creating a deployable path for platforms to comply with regulations without sacrificing security 5. Enabling incremental integration without requiring wholesale platform redesign These three limitations do not invalidate the architecture or prevent deployment. They clarify its scope and distinguish practical deployability from maximum-assurance guarantees. An honest, complete technical proposal acknowledges them upfront and separates near-term deployment from long-term assurance strengthening. Conclusion Apple's security concern is valid: uncontrolled third-party execution authority on the iPhone would create real risks of compromise, prompt injection, supply-chain attack, and regulatory liability. The EU's operational constraint is valid: interoperability must not be provided at the cost of security or user control. This architecture addresses both by separating participation from uncontrolled power. A third-party assistant can participate in the user's workflows and request actions. But participation is not authority. Every action is validated, every scope is narrow, every capability is non-reusable and non-bearer, and every final gate is independently verified. The security is not delegated to the third party. It is enforced by the platform. The user is not passive. Intent is captured prospectively and remains revocable. The regulator can audit the enforcement because it is cryptographic and hardware- protected, not merely logged. Thus, interoperability can be provided at the level of: "You may request this action under the same technical conditions." It does not require interoperability at the level of: "You receive unrestricted control over the device." ======================================================================== PART II - ANTICIPATORY TECHNICAL OBJECTIONS AND RESPONSES ======================================================================== Technical Objections and Responses Q1. How does the Protected Execution Domain know that the Candidate Act accurately represents the real consequence? The Candidate Act descriptor must not merely describe what software claims it intends to do. It must function as a machine-verifiable commitment to the exact consequence that may later be released. This is necessary because the operating-system or mediation layer may participate in forming the Candidate Act, while that layer is not itself trusted as the final authority for effectuation. If the protected architecture merely validates a description authored by an untrusted layer, the architecture risks validating a representation rather than the actual consequence. The solution is to divide verification between two independent enforcement points: The Protected Execution Domain validates authority over a commitment. The Finality Sink validates that commitment against the actual consequence-producing state. Neither verifier alone is sufficient. The existing disclosure already constructs a Candidate Device Act containing the requesting application or agent identity, action class, resource scope, destination scope, governance or authority epoch, revocation epoch, nonce, and designated Finality Sink identity, and maintains the Candidate Device Act in a non-effective state before effectuation. A. The Candidate Act becomes a commitment The Candidate Act should bind at least: requesting application or agent identity; sandbox, application measurement, or code-signature state; action class; resource identity; resource commitment or digest; destination identity; destination commitment or digest; user-intent object where required; runtime-behavior state where applicable; governance or authority epoch; revocation state; fresh nonce; designated Finality Sink identity; and designated Effectuation Boundary identity. The Candidate Act is then canonicalized and committed through a digest or equivalent protected commitment. The important point is: The descriptor is not trusted because it exists. It becomes useful only because its load- bearing attributes are later checked against the actual release state. B. Sink-side re-derivation, not sink-side trust The Finality Sink must not simply accept fields such as resource_digest, destination_digest, or payload_digest as assertions supplied by the requesting software. Immediately before effectuation, the Finality Sink should independently derive the effectuation-critical attributes from the actual object, payload, destination, or state transition that it is about to release. For example: File export The relevant digest should be derived from the actual file object, actual file version, or actual bytes presented at the export boundary. Message sending The sink should verify the actual recipient, final message payload, attachment set, and destination. Payment The protected payment boundary should verify the actual amount, currency, recipient, account, transaction parameters, and finalization context. Network transmission The sink should verify the actual serialized outbound resource or payload and the actual destination endpoint. Sensor release The sink should bind the actual sensor buffer or stream being released to the requesting protection domain. The conceptual comparison is: AUTHORIZED_COMMITMENT = HASH_CANONICAL( action_class, release_form_resource, destination, requester_identity, sink_identity, boundary_identity, epoch, nonce ) ACTUAL_COMMITMENT = HASH_CANONICAL( actual_action_class, actual_release_form_resource, actual_destination, actual_requester_identity, actual_sink_identity, actual_boundary_identity, current_epoch, nonce ) IF ACTUAL_COMMITMENT != AUTHORIZED_COMMITMENT: FAIL_CLOSED The existing disclosure already requires Finality Sink verification against descriptor digest, application identity, assistant identity, action class, resource digest, destination digest, Finality Sink identity, epochs, nonce, and LAVR state. It also requires fail-closed denial when these do not match. The strengthening is to make explicit that the Finality Sink recomputes or re-derives these values from the actual consequence-producing state, rather than merely re-reading the same values originally supplied by software. C. Release-form canonicalization, not request-form canonicalization The commitment should correspond to the post-transformation, pre-release form of the governed artifact. This distinction is critical. Between request formation and effectuation, data may be: serialized; compressed; encoded; transformed; re-framed; chunked; wrapped; encrypted; combined with metadata; or otherwise changed. If the protected architecture commits only to the request-time representation, later transformations may create either false mismatches or an opportunity for semantic substitution. The preferred rule is: Commit to the last canonical or determinable representation before release, at a point where withholding remains complete. For example: request object v transformation v serialization v FINAL DETERMINABLE RELEASE FORM v commitment / digest v Finality Sink verification v external consequence Where a later transformation is unavoidable, such as protocol framing or transport encryption, the Finality Sink should be positioned on the protected side of that transformation and bind the last plaintext or canonical form whose identity can still be deterministically established. This release-form distinction is also important to any prior-art argument that differentiates request-side or context-side digests from produced-output or release-side commitments. If the disclosure is ambiguous about where the digest is computed, that distinction becomes weaker. Making release-form commitment explicit strengthens both the architecture and that prior-art position. D. Split verification The architecture should therefore be understood as having two distinct verification roles: Protected Execution Domain validates authority; validates protected predicates; verifies protected state; verifies freshness and revocation; commits validation evidence; derives or authorizes the scoped capability. Finality Sink observes the actual consequence-producing state; reconstructs or derives the release-form commitment; verifies the scoped capability; verifies sink and boundary identity; compares actual release state with the protected commitment; consumes or advances authority state; permits effectuation only after successful comparison. This avoids placing impossible semantic responsibility on the PED. E. Residual semantic gap Cryptographic and hardware enforcement can establish: artifact identity; resource identity; requester identity; destination identity; sink identity; boundary identity; freshness; policy epoch; revocation state; and protected authorization state. They cannot by themselves establish higher-level meaning such as: "This document is my medical record." or: "This person is the doctor I meant." Meaning-level correctness must therefore come from a trusted user-intent mechanism where the action class requires it. For high-consequence classes such as: identity disclosure; credential release; payment; high-value transaction; sensitive file export; protected-data disclosure; or equivalent irreversible acts, a trusted-user-interface predicate should be treated as load-bearing. Claim 5 already discloses a Trusted User-Interface Finality Sink using protected display, secure input, protected transaction confirmation, biometric confirmation, PIN entry, or equivalent trusted-user-interface mechanisms. However, the current independent-claim structure does not necessarily make Claim 5 mandatory for every such class. That distinction should be preserved: technically recommended strengthening is not automatically an existing independent-claim requirement. Q2. How do you guarantee that there is no bypass path around the Finality Sink? Bypass closure should not depend primarily on enumerating APIs, hooks, frameworks, or software routes. Enumeration is useful for patent coverage and design-around closure, but it does not itself prove technical non-bypassability. The stronger technical rule is: The governed consequence must be physically or cryptographically impossible to produce unless the required protected enablement material is present. The Finality Sink should therefore control something necessary for effectuation, such as: transmit-enable authorization; queue-enable value; hardware-unlock value; memory-window unlock value; storage-commit authorization; decryption key; rendering key; secure dispatch authorization; transaction-finalization authorization; actuator enablement; or equivalent protected technical material. The filed disclosure already supports capability forms including hardware-unlock values, queue-enable values, memory-window unlock values, network-transmit authorization, storage-commit authorization, sealed handles, release keys, and equivalent technical enablement conditions. The preferred embodiment is therefore stronger than: "Software checks whether the operation is permitted." It becomes: "The controller lacks the material required to complete the operation unless protected finality has succeeded." Conceptually: ordinary software path | governed controller | +-- no valid protected enablement | v | cannot effectuate | +-- valid sink-bound enablement v Finality Sink v external effect Governed Egress Set For every governed consequence class, define a Governed Egress Set: The complete set of technical boundaries through which that consequence can leave the non- effective state. Examples: Data egress network transmission boundary; IPC boundary; shared-memory release; file-provider/export boundary; removable-storage commit; cloud-upload boundary. Visible output compositor; trusted display release; external display path; protected rendering path. Physical actuation actuator controller; radio controller; device-control boundary; equivalent physical-output controller. Every member of the Governed Egress Set must either: 1. contain a Finality Sink; or 2. be structurally downstream of a Finality Sink and incapable of obtaining usable governed material before successful verification. This creates an auditable per-platform or per-SoC property. The question becomes not: "Did we remember every API?" but: "Is there any technical boundary through which this consequence can become externally effective without possession of valid sink-verifiable enablement?" Alternate routes remain governed Browser upload, sharing-sheet transfer, SDK telemetry, cloud synchronization, app-intent subcalls, accessibility actions, clipboard transfer, network sockets, diagnostic upload, IPC, private-framework calls, or similar routes remain governed if they produce the same consequence. The PCT already states this alternate-route principle. The governing principle is: Govern consequences, not APIs. Adversary model The security claim should also state what is and is not within the threat model. The architecture may defend against compromise of: an application; AI assistant; AI agent; plug-in; browser automation component; user-space process; ordinary operating-system service; privileged framework; automation service; or alternate software route. It should not claim to remain secure after compromise of: the PED itself; the trusted hardware root; the cryptographic root of trust; malicious silicon; invasive physical attacks that defeat the assumed hardware security boundary. A bounded adversary model makes the bypass guarantee credible and testable. Q3. Where exactly is the first usable release boundary? The architecture should not answer this merely by listing controllers. It should provide a rule that generates the correct boundary even for platforms and action classes not expressly listed. The rule is: The first usable release boundary is the last point at which the governed artifact remains in a canonical or determinable form and complete withholding remains possible, immediately before the act becomes usable, observable, transferable, committed, rendered, transmitted, disclosed, paid, stored, actuated, or otherwise consequential outside the non-effective state. Two requirements must therefore be true simultaneously: artifact identity remains determinable AND complete withholding remains possible If the gate is placed earlier, an ungoverned downstream transformation may alter or complete the act. If the gate is placed later, the consequence may already have begun or the sink may no longer be able to reconstruct the exact artifact being released. The PCT already defines the Effectuation Boundary in first-use terms, and Claim 28 expressly refers to a first usable release boundary where the operation first becomes usable, observable, transferable, committed, rendered, transmitted, disclosed, paid, stored, actuated, or otherwise consequential. Representative boundary mapping Action class Correct first usable release boundary Preferred enablement outbound egress after final payload and Message / email attachment assembly, before external transmit-enable transmission first point where bytes become readable outside File export export/read enablement the originating protection domain protected transaction-finalization or protected finalization Payment cryptogram-generation boundary authorization Protected compositor submission or content-decryption decryption/render rendering point immediately before usable rendering enablement delivery from protected sensor/HAL path to Sensor release sensor/DMA release requesting protection domain receiving application's paste/read boundary consumer-side read Clipboard where another principal first obtains content enablement dispatcher handoff into the receiving protection App intent / IPC dispatch authorization domain Accessibility input dispatcher immediately before target- injection enablement injection window delivery Action class Correct first usable release boundary Preferred enablement AI export / fully serialized outbound body immediately transmit-enable telemetry before egress Persistent commit boundary where the state first becomes storage-commit storage persistently usable authorization Consumer-side finality For some classes the consequence begins at consumption rather than emission. Clipboard is a useful example. Writing sensitive material into an isolated clipboard representation may not yet disclose it to another principal. The disclosure occurs when another application obtains usable access to that material. Therefore: Where the consequence begins at consumption, the Finality Sink should be located at the consumer-side release boundary. The same principle may apply to: shared memory; protected buffers; deferred display; encrypted content; staged IPC objects; or other contexts where production does not itself create the governed consequence. Boundary identity must be bound The same artifact released through different boundaries may create different consequences. Therefore the capability should bind not only: resource; destination; action class; nonce; epoch; but also: Finality Sink identity; and Effectuation Boundary identity. A capability valid for one boundary should fail when presented at another. Feasibility Q4. Can existing secure-enclave, TEE, secure-element, or equivalent protected hardware implement the hot path without becoming a large new trusted subsystem? Yes, provided the architecture keeps the protected hot path fixed and small. The PED should not become: a general-purpose AI engine; a full policy engine; a natural-language interpreter; a browser engine; a model-inference system; a regulator-rule interpreter; or a bulk-data processor. The PED need not process the bulk payload A preferred implementation is: Bulk hashing occurs at the Finality Sink, protected DMA path, crypto accelerator, or other trusted boundary-adjacent component. The PED primarily handles fixed-size commitments and protected state. The PED may therefore maintain only relatively small objects such as: digest / commitment verification key sink identity boundary identity nonce nonce window monotonic counter governance epoch revocation epoch quota capability state LAVR state protected policy state The PCT already permits implementation using secure enclaves, TEEs, secure elements, hardware security modules, protected processors, protected microcontrollers, protected hypervisor partitions, or equivalent hardware-rooted or cryptographically isolated environments. Symmetric verification on the ordinary hot path A useful implementation distinction is: Hot-path capability verification short-lived session key; MAC or equivalent compact authentication; nonce; epoch; sink identity; boundary identity; local protected-state check. Durable evidence LAVR; protected signature where required; receipt continuity; external audit evidence; non-repudiation material. This allows ordinary low-risk finality to use a compact local primitive while reserving heavier public-key operations for: high-risk acts; durable receipts; external evidence; attestation; or events requiring stronger assurance. The PCT supports multiple cryptographic forms rather than requiring one fixed cryptographic suite. Avoid protected-world transitions where possible Repeated transitions into a protected execution environment may become more expensive than the underlying cryptographic comparison itself. A preferred implementation can therefore derive short-lived sink-verification material during preparation: PED | | derive / provision session-scoped verification material protected sink-local state | | compact local capability verification Finality Sink The sink can then verify ordinary low-risk capabilities locally. A new protected-world interaction may be required only when: the session is established; the governance epoch changes; revocation state changes; quota is exhausted; a high-risk action occurs; protected state must advance; trusted user confirmation is required; or fresh attestation is required. The specification already distinguishes heavier authority preparation from a compact finality hot path and permits pre-fetched state, cached state, capability-cache lookup, bounded hardware-assisted verification, and freshness checks before use. Existing protected hardware provides related primitives The safer feasibility statement is not that existing secure hardware already implements this entire architecture. The stronger and more defensible statement is: Existing protected hardware already supports closely related primitives such as protected key custody, cryptographic verification, counters, attestation, sealed state, secure transaction authorization, and hardware-backed isolation. The proposed architecture composes such primitives into an execution-finality path. That avoids overclaiming. Performance figures should be treated carefully Engineering estimates such as: single-digit-microsecond MAC verification; millisecond-scale secure-element signature operations; tens-of-microseconds protected-world transitions; sub-100-microsecond low-risk hot paths; may be useful as illustrative engineering targets. They should not be stated as universal architectural guarantees unless supported by benchmarking on the relevant implementation. The stronger patent and standards position is: The hot path is bounded, fixed-function, local where possible, and independent of unbounded AI reasoning or policy computation. Incremental controller extension Many Finality Sinks correspond to components that already control: network transmission; storage; display; IPC; sensor delivery; payment finalization; device settings; message sending; or privileged dispatch. The architectural delta is therefore: Add sink-verifiable protected execution authority to an existing consequence-control boundary. The genuinely new load-bearing relationship is the combination of: release-form commitment -> protected authority -> sink-local verification -> effectuation. Q5. How can low latency and high availability be preserved when every consequential sub-action requires finality? The unit of finality is the externally consequential or irreversible consequence, not every syscall, function call, packet, fragment, token, or internal AI operation. This distinction is essential. One transfer can remain one Candidate Act A large transfer may be divided into many packets or fragments while remaining one bounded Candidate Act. The capability may define a constrained envelope such as: resource = X destination = Y action class = transfer maximum bytes = N maximum fragments = F validity window = T sink = Z boundary = B epoch = E sequence / nonce range = R The fragments remain authorized only while they remain within that exact bounded envelope. Changing: resource; destination; action class; sink; boundary; epoch; permitted byte count; validity period; or other load-bearing scope requires new authority. This preserves anti-fragmentation closure without requiring full reauthorization for every individual transport fragment. Claim 32 already addresses fragmented Candidate Device Acts and prevents fragmentation from defeating governance. Risk-tiered finality Different consequence classes can receive different verification depth. Low-risk act cached protected state + local sink verification + fresh nonce / sequence validation + compact authentication High-risk act fresh protected-state validation + trusted-user confirmation + fresh attestation where required + stronger protected evidence + fresh capability Higher latency is easier to tolerate when a human confirmation step already exists. The architecture should therefore avoid forcing the highest-assurance path onto every operation. Preparation may be speculative because preparation authorizes nothing Authority preparation can safely occur before the final Candidate Act exists, provided that preparation itself does not create externally usable authority. For example: current action executing | +-- refresh attestation +-- prefetch policy state +-- verify stable app state +-- prepare session key +-- load current epoch +-- prepare likely sink context If the anticipated act never occurs, nothing becomes externally effective because: no final Candidate Act commitment exists; no act-specific final capability has been verified; no Finality Sink has permitted effectuation. This means the architecture's safety property also becomes a performance advantage. Multi-step AI workflows A workflow may contain: read calendar v summarize event v draft email v attach file v send message Internal reasoning, planning, summarization, or drafting does not necessarily require finality merely because computation occurred. Fresh finality is required when a step becomes externally consequential. For example: protected calendar-data release v file export into another protection domain v external message transmission Each consequence can reuse stable session, app, device, model, and policy state while receiving its own: Candidate Act commitment; nonce; scoped authority; Finality Sink verification. The PCT already states that a capability issued for one action class does not automatically extend to later consequential actions and that subsequent externally consequential operations invoke their own finality sequence. Availability Fail-closed behavior creates a genuine availability dependency and should be addressed explicitly rather than ignored. The central rule should be: Degraded mode may shorten the validation path; it must never waive Finality Sink verification. That preserves the architecture even during partial failure. Offline operation Where permitted, the PED may issue a protected local authority lease containing: bounded validity period; allowed action classes; quota; monotonic counter; sink identity; boundary identity; governance epoch; revocation epoch; permitted resource or destination class. The device may continue operating while the bounded lease remains valid. Connectivity loss therefore does not itself force immediate denial. When the quota, time window, epoch, or protected lease state expires: deny rather than silently broaden authority. Cached local verification Stable predicates may remain locally cached while freshness-sensitive state continues to be checked locally. For example: application measurement may remain stable; current nonce must remain fresh; revocation state must remain acceptable; capability must remain sink-bound; boundary identity must remain correct. Delayed receipt synchronization Where policy permits, protected receipts may be committed locally and synchronized after connectivity is restored. The receipt may be delayed externally without delaying the local protected commitment that makes the finality decision auditable. Failure of remote infrastructure If a remote policy service or remote protected component becomes unavailable, the architecture may rely on already-issued bounded local authority where such authority exists. It must not reinterpret service unavailability as authorization. The invariant is: NO VALID SINK-VERIFIABLE AUTHORITY = NO EFFECTUATION The PCT already permits precomputed state, local fast-path verification, short-lived delegated authority, distributed protected execution, and batching of receipt updates while preserving the controlling invariant that the Candidate Device Act remains non-effective until the applicable Finality Sink verifies the required capability. Core Architectural Position The complete answer can be reduced to five non-negotiable technical rules: 1. The Candidate Act is a commitment, not merely a description. The commitment binds the actual governed artifact, destination, requester, sink, boundary, freshness state, and other load-bearing attributes. 2. The PED validates authority over the commitment; the Finality Sink validates the commitment against reality. The sink re-derives the release-form state from the actual artifact it is about to externalize. 3. Bypass resistance comes from withheld enablement, not from software-hook enumeration. Every member of the Governed Egress Set must require protected sink-verifiable enablement before the governed consequence can occur. 4. The first usable release boundary is the last point where identity remains determinable and withholding remains complete. If the consequence begins at consumption, the sink moves to the consumer side. 5. Feasibility and performance come from keeping the protected root small and separating preparation from finality. The PED governs commitments, keys, epochs, nonces, counters, receipts, and authority. Bulk computation, AI reasoning, transformation, and ordinary application processing remain outside the smallest trusted root. The resulting sequence is: PROPOSED ACT v CANONICAL / RELEASE-FORM COMMITMENT v NON-EFFECTIVE STATE v PED VALIDATES AUTHORITY v LAVR / PROTECTED EVIDENCE v SCOPED NON-BEARER CAPABILITY v FINALITY SINK RE-DERIVES ACTUAL RELEASE STATE v COMMITMENT MATCH? NO YES v v FAIL CONSUME / CLOSED ADVANCE AUTHORITY v EFFECTUATE The essential security statement is: Protected authority was granted for X, and the boundary capable of producing the consequence independently proves that the operation it is actually about to release is X before the consequence becomes effective. B. Additional Technical Objections and Responses Q8. Who governs the policy bundle? If the platform operator authors the policy that the PED enforces, who watches the watcher? This is a real governance problem. A protected execution environment does not solve neutrality merely because the policy is enforced in hardware. If the same platform operator can define the policy bundle, sign it, change it, and determine whether first-party and third-party requesters receive equivalent treatment, then hardware enforcement can make an unfair policy more strongly enforceable rather than making it neutral. The parity invariant therefore cannot depend only on: VALIDATE_REQUESTER_TYPE_PARITY( policy_bundle = platform_supplied_policy ) The stronger architecture separates policy enforcement from policy provenance and accountability. The PED should validate not only: "Is this Candidate Act compliant with the current policy?" but also: "Is this the authorized, externally identifiable policy version that this device is permitted to enforce?" A policy bundle should therefore have a protected identity such as: policy_bundle_digest policy_version governance_epoch issuer_identity validity_period applicable_action_classes parity_profile signature / authorization chain The digest of that exact policy bundle should be bound into: the protected governance state; Candidate Act validation; the capability; and, where appropriate, the LAVR or validation evidence. The existing disclosure already makes policy state epoch-bound, revocation-aware and capable of being bound into the Candidate Act or validation evidence, and it expressly rejects unauthorized policy downgrade. That is useful, but epoch integrity alone does not answer who is entitled to define the policy. External verifiability A stronger governance implementation can add one or both of the following: Multi-party authorization The policy profile becomes valid only when authorized by more than one relevant authority, for example: platform authorization + independent governance / conformity authorization + optional enterprise / user policy component The architecture already contemplates combined, threshold, co-signed, or jointly authorized capability construction in distributed protected execution. The same architectural principle can be applied to policy provenance where supported by the implementation. External transparency The policy-bundle digest, version and parity profile may be externally committed so that an auditor, regulator, conformity assessor, enterprise administrator, or other authorized verifier can establish: which policy was active; when it became active; whether it changed; whether first-party and third-party acts were evaluated under the same published profile; whether a downgrade occurred. The PCT already states that protected finality evidence may be independently verified rather than relying solely on the platform operator's own statements. A public or permissioned policy-transparency log would strengthen that property further. If policy-bundle co-signature or external transparency logging is not expressly supported by the existing priority disclosure, it should be treated as a future implementation or governance extension, not automatically represented as an existing claim requirement. The central principle is: The platform may implement enforcement, but it should not be the only party capable of proving what rules were enforced. Q9. What prevents many individually authorized Candidate Acts from composing into an unauthorized aggregate consequence? Per-act finality alone does not solve aggregation. An attacker may remain within the scope of every individual authorization while producing a prohibited cumulative effect. For example: Read 1 -> authorized Read 2 -> authorized Read 3 -> authorized ... Read 10,000 -> individually authorized v aggregate exfiltration Nothing in a purely stateless per-act predicate necessarily detects that the aggregate behavior has crossed a security or privacy threshold. The answer is to make protected finality stateful across acts where the action class requires it. The PED should support a cumulative authority budget or session-level aggregate predicate. Protected state may be keyed to combinations such as: principal + application / agent + resource class + destination + action class + session + time window + governance epoch and maintain values such as: cumulative bytes disclosed; number of records accessed; number of recipients; number of external destinations; number of transactions; total transaction value; sensor-duration budget; query count; tool-call budget; cross-domain disclosure count; or equivalent bounded-use state. Then: IF single_act_valid AND cumulative_budget_remaining: permit atomically decrement protected budget ELSE: deny This is different from ordinary rate limiting. The important property is that the budget is itself part of protected authority state and cannot be reset by restarting the app, changing the agent process, replaying an old capability, or fragmenting the operation. The existing disclosure already contemplates quota state, monotonic counters, protected state advancement and atomic consumption, so there is architectural support for this direction. It also expressly addresses fragmentation under a shared aggregate descriptor. However, the broader threat of N independently valid acts composing into an unauthorized semantic aggregate should be stated explicitly. The rule becomes: Finality may be evaluated both per act and over the protected cumulative state created by prior acts. Q10. How can the PED verify declared_purpose when the declared purpose originates from an untrusted agent? It cannot prove the agent's subjective intent merely by inspecting the string. That limitation should be stated directly. A field such as: declared_purpose = "send medical report to doctor" does not prove: that the agent is truthful; that the actual operation serves that purpose; that the recipient is actually a doctor; that the selected file is actually the intended medical report. Therefore: Declared purpose is a policy-selection and consistency input, not proof of semantic intent. The PED may verify: that the declared purpose is an allowed purpose class; that the requested resource is permitted for that purpose class; that the destination class is permitted; that the action class is permitted; that the user-intent object authorizes that purpose; that the runtime behavior remains within the permitted execution profile. But the string itself is not authoritative. The PCT already says that model-generated statements, prompt text, tool plans, self- declarations and natural-language descriptions do not constitute trusted authority and may not substitute for machine-verifiable evidence. The technically defensible formulation is: Purpose validation constrains execution to an authorized purpose class; it does not cryptographically prove the internal motive of an AI agent. For high-consequence operations, declared purpose should therefore be corroborated by stronger predicates such as: trusted user intent; actual resource identity; destination identity; action class; session context; data classification; jurisdiction condition; enterprise authorization; or other machine-verifiable evidence. Q11. How can a behavioral descriptor or ALF be enforced against a non- deterministic AI model? The behavioral envelope should not require the model to reproduce a deterministic token sequence. That would be unrealistic for systems affected by: sampling; temperature; context variation; tool responses; retrieval inputs; model updates; runtime configuration; or ordinary probabilistic inference. The architecture should separate model identity from behavioral authority. Static or relatively stable identity ALF or equivalent model identity may bind: registered model identifier; model version; code-signature digest; weights or protected measurement where available; inference-runtime version; tool-policy version; retrieval configuration class; safety-policy version; approved plug-in or connector set. Dynamic runtime descriptor The runtime descriptor may bind observable execution properties such as: action classes invoked; tool classes used; resources accessed; destinations selected; privilege level requested; data classes accessed; number or depth of delegated actions; model configuration class; approved context sources; output class; risk class; protected execution trace digest; or equivalent machine-verifiable runtime attributes. The behavioral envelope should therefore be a predicate over observable execution invariants, not an exact prediction of the model's generated text. For example: ALLOW: model_id = approved tool_class approved_set destination_class approved_set resource_class approved_set delegation_depth <= N high_risk_action => trusted_user_confirmation DO NOT REQUIRE: exact generated tokens == previously predicted tokens Claim 46 already points in this direction by distinguishing model identity, approved measurement or version, runtime behavioral descriptor, execution fingerprint or inference trace, approved behavioral envelope, purpose scope, data-access scope and output class. The stronger explanation is: ALF answers "which model/runtime is executing?" Behavioral finality answers "what classes of consequential behavior is this execution permitted to produce?" The architecture should not claim that a non-deterministic model's entire future behavior can be predicted. Q12. How does the messaging embodiment work with end-to-end encryption if the server-side PED cannot see plaintext message content? This objection is valid against the server-side content-processing form of the named messaging embodiment. The current embodiment places a Platform Protected Execution Domain in server-side protected infrastructure and describes AI processing over message content before delivery. That implementation is feasible only where the relevant server-side protected component has authorized access to the content being processed. Where an interoperability deployment preserves end-to-end encryption such that the server- side platform cannot obtain plaintext, the architecture should not require plaintext disclosure to the server-side PED. The enforcement point must move. E2EE-compatible form A stronger E2EE-compatible architecture is: encrypted interoperable message v endpoint receives ciphertext v authorized endpoint decryption v CLIENT-SIDE / DEVICE-SIDE PED v Candidate Act for AI processing v local protected validation v local AI processing or protected processing v Candidate output v device-side Finality Sink v render / reply / export / agent action The server-side protected component may still validate: origin metadata; interoperability context; signed policy context; sender-provided consent metadata; routing authority; capability provenance; without accessing plaintext. The PCT's broader architecture already permits on-device, remote, hybrid and distributed PED placement, including split protected components. Accordingly: The general execution-finality architecture is compatible with E2EE, but the server-side plaintext-processing form of Embodiment CC must be understood as one implementation applicable only where server-side content processing is available. In an E2EE deployment, content-dependent validation moves to the endpoint or another protected domain that legitimately possesses plaintext. This distinction should be explicit. Q13. Does fail-closed behavior create a denial-of-service attack surface or leak policy information through denial patterns? Yes. Fail-closed protects integrity, but it creates an availability dependency. An attacker may attempt to exhaust or destabilize: PED request queues; nonce allocation; attestation services; revocation processing; policy synchronization; monotonic-counter state; secure storage; capability caches. Therefore finality needs resource-governance protection, not merely authorization logic. Possible measures include: per-principal request quotas; bounded PED queues; admission control; reserved capacity for critical action classes; protected rate limits; back-pressure before requests enter the secure world; coalesced epoch updates; bounded revocation windows; local authority leases; batch state advancement where safe; wear-aware protected counters; recovery checkpoints; redundant protected services for deployments requiring higher availability. The core rule remains: A degraded validation path may be shorter, but degraded mode must not silently convert missing finality authority into authorization. Denial as a side channel Different denial reasons may also reveal: policy state; revocation state; user state; security tier; destination classification; whether a protected resource exists. Therefore the untrusted caller should receive a coarse or opaque denial result where detailed reasons are not required. For example: CALLER: FINALITY_DENIED PROTECTED AUDIT: exact internal denial reason Detailed reasons may remain inside protected evidence accessible only to an authorized auditor, user, administrator, or conformity authority. The PCT already uses fail-closed denial extensively and contemplates protected denial receipts. The architecture should therefore state honestly: Finality converts unauthorized effectuation into denial; it does not eliminate denial-of- service as a security problem. Availability must be separately engineered. Q14. Can the architecture realistically be deployed on the existing installed device base? Not with the strongest hardware-non-bypass guarantees on every existing device. The market size and the immediately deployable hardware base should not be treated as the same thing. The existing disclosure identifies a very large installed device market. That establishes potential scope, but not universal retrofit feasibility. A credible deployment model has tiers. Tier 1 - software / existing protected-hardware implementation Where an existing device already exposes suitable: TEE; secure processor; protected controller; hardware-backed keys; secure counters; kernel mediation; protected display or payment paths, some execution-finality functions may be introduced through firmware, OS, driver, or protected-service updates. This may provide meaningful enforcement but not necessarily the strongest silicon-level non- bypass guarantee for every action class. Tier 2 - firmware/controller-integrated implementation New firmware or platform releases can integrate capability verification directly into: storage controllers; network paths; display pipelines; IPC dispatchers; sensor paths; protected services. Tier 3 - silicon-integrated implementation The strongest Governed Egress Set model may require new SoC or controller design so that protected enablement is structurally required at consequence-producing boundaries. Therefore the commercially defensible position is: The installed base defines the economic relevance of the problem; the deployable base depends on the protected capabilities of each hardware generation. Full hardware- rooted non-bypass enforcement may phase in with future device generations. That is more credible than implying immediate retrofit of every existing device. Q15. What happens when a multi-step workflow partially completes and a later Finality Sink denies the next act? Execution finality cannot magically undo an act that has already become irreversible. This should be stated explicitly. Suppose: Act A -> authorized and effectuated Act B -> authorized and effectuated Act C -> denied The architecture can guarantee that Act C does not occur without authority. It cannot necessarily restore the external world to the state before Acts A and B. Therefore distributed workflows require a separate workflow-commit discipline. Where reversible preparation is possible Use a prepare/commit structure: Act A -> PREPARED Act B -> PREPARED Act C -> PREPARED all required sinks ready? v YES v issue commit authority v effectuate A workflow-level descriptor may bind: workflow identifier; required sub-acts; dependency graph; participating sinks; resource commitments; destinations; validity window; commit order. No sub-act becomes externally effective during the preparation stage. Where true atomicity is impossible Some consequences cannot be atomically committed across independent systems. For example, once an external message has been delivered or a physical actuator has moved, rollback may be impossible. In those cases: perform the least reversible actions last; reserve or stage reversible actions first; stop immediately on denial; record exact partial-completion state; invoke compensating actions where meaningful; do not describe compensation as rollback; expose partial-completion status to the authorized user or orchestration layer. The bounded claim should therefore be: Execution finality prevents unauthorized sub-actions. It does not by itself guarantee atomic rollback across independent irreversible external systems. If a formal multi-sink commit protocol is not expressly supported by the existing priority disclosure, it should be treated as an additional implementation refinement rather than silently read into the current claims. C. Regulatory and Political Objections and Responses Q16. Does hardware-rooted finality entrench the platform gatekeeper by moving the chokepoint from software into hardware? It could, if the platform remains the sole authority over: policy definition; PED state; capability issuance; parity rules; and verification evidence. That would merely move discretionary control into a harder-to-observe layer. The architecture therefore needs verifiable neutrality, not merely hardware enforcement. Three independent properties are required: 1. Policy transparency The exact policy bundle or policy profile being enforced should have a stable, externally verifiable identity. 2. Parity verifiability Equivalent first-party and third-party Candidate Acts should be independently testable against equivalent predicate profiles. The verifier should be able to establish: same action class same resource class same destination class same risk class same user-intent condition v equivalent predicate treatment without trusting the platform's assertion that parity occurred. 3. Independent evidence The LAVR or equivalent validation evidence should allow an authorized external party to verify: active policy digest; Candidate Act class; relevant predicate profile; capability scope; sink identity; finality decision. The PCT already states that finality evidence can be independently verified rather than relying solely on gatekeeper-controlled statements or post-event logs. A stronger implementation may use: externally published policy digests; conformity profiles; multi-party policy authorization; threshold capability issuance; independent test vectors; standardized parity predicates. The regulatory answer is therefore: The platform may host the enforcement hardware, but it must not be the sole source of truth regarding what policy was enforced or whether equivalent requesters received equivalent treatment. Q17. Does placing a Finality Gate on accessibility pathways create a barrier for assistive technology? A blanket hardware gate applied indiscriminately to accessibility functions would create a serious usability and accessibility concern. The correct distinction is not: accessibility API versus ordinary API. It is: assistive computation versus externally consequential effectuation. Ordinary assistive operations such as: reading UI structure; magnification; screen narration; focus navigation; non-consequential interface assistance; need not automatically be treated like high-risk agentic acts merely because they use accessibility infrastructure. However, when any pathway-accessibility or otherwise-causes: a payment; message send; credential disclosure; file export; account modification; external upload; device-setting modification; or another consequential act, that consequence still requires finality. The PCT itself treats accessibility as a governed path when it produces a consequential action rather than treating the API name itself as the security boundary. The preferred rule is: Do not carve out an API. Classify the consequence. A trusted assistive principal may also receive: pre-authorized bounded capability envelopes; local low-latency verification; long-lived accessibility session context; accessibility-priority availability; simplified trusted confirmation appropriate to the user's needs. That preserves accessibility without creating an "accessibility" label that malicious software could use as a bypass. Q18. Does the LAVR create a surveillance corpus by recording every consequential user action? It could if implemented as a centralized, indefinitely retained, identity-linked activity ledger. That should not be the default implementation. The LAVR's purpose is to establish proof of protected validation, not to recreate the user's complete behavioral history. The privacy-preserving design should minimize both content and linkability. A receipt can contain commitments to: Candidate Act digest; validation result; policy epoch; nonce; sink identity; capability commitment; without storing: message contents; file contents; prompt text; full recipient history; complete user identity; raw model inputs. The PCT already supports: local secure receipts; compact protected state; privacy-preserving proofs; zero-knowledge proofs; signed receipts; ledger-anchored receipts; and lower-assurance no-external-receipt variants. Additional privacy controls should include: local-first storage; purpose-specific receipt domains; retention limits; rotating pseudonymous identifiers; selective disclosure; unlinkable or compartmentalized receipt chains where possible; disclosure only upon authorized audit; aggregation rather than raw per-event export; deletion or expiration where the assurance model permits it. The key distinction is: Tamper evidence does not require universal observability. A receipt can prove that finality was enforced without becoming a central log of everything the user did. Q19. Does the architecture remove user autonomy by making the device owner unable to override their own hardware? A high-assurance security architecture inevitably creates tension between: device-owner control; platform security; enterprise policy; regulatory obligations; payment or credential assurance. The answer should not be to pretend that all of these authorities are identical. The architecture can separate policy layers. For example: mandatory protected integrity rules + regulated-domain requirements + enterprise policy + device-owner policy + per-act user intent The owner should be able, where the deployment permits it, to: inspect active policy identity; revoke assistant authority; select third-party assistants; reset local capability state; disable optional governance profiles; change owner-controlled policies; verify which policy bundle is active. For developer, repair, research or modified-device modes, the system may permit an explicit trust-state transition rather than silently pretending the original assurance remains intact. For example: owner unlocks protected platform state v device attestation state changes v owner retains control v high-assurance relying parties may choose not to trust that state This preserves owner autonomy without falsely representing a modified environment as still satisfying the original protected assurance profile. The core principle is: User control and external trust do not have to be identical properties. A user may be allowed to alter their device while a regulated relying party may separately decide whether that modified state satisfies its assurance requirements. D. Standardisation and Deployment Objections and Responses Q20. Why is standardisation important if the execution-finality architecture is implemented inside protected firmware, operating-system components, secure processors, or device controllers? A purely proprietary implementation may remain difficult for external parties to inspect, compare, test, or verify across different platforms. Standardisation creates a common technical layer through which execution-finality behavior can become interoperable, testable, auditable, and independently verifiable. The objective is not to standardise one vendor's internal hardware design. The objective is to standardise the interfaces, invariants, evidence structures, and conformance behavior required for protected execution finality. A standards profile could define common elements such as: Candidate Act representation; canonical commitment format; action-class taxonomy; resource and destination binding; Finality Sink identity; Effectuation Boundary identity; governance or authority epoch; nonce and freshness requirements; capability scope; non-bearer verification requirements; validation-evidence or LAVR format; policy-bundle identity; parity-conformance evidence; revocation semantics; cumulative-budget predicates; degraded-mode requirements; and sink-side verification behavior. The central standards invariant would remain: A consequential act may be prepared, requested, routed, or computed, but it does not become externally effective until a designated Finality Sink verifies valid scoped authority for that exact consequence. Standardisation does not require identical hardware Different implementations may use: secure enclaves; trusted execution environments; secure elements; hardware security modules; protected microcontrollers; protected hypervisor partitions; trusted controllers; confidential computing; firmware-isolated components; or distributed protected services. The standard need not prescribe which substrate is used. Instead, it can define the externally testable requirement: Candidate Act v Non-Effective State v Protected Validation v Scoped Finality Authority v Finality Sink Verification v Effectuation This allows different platforms to implement the architecture differently while preserving interoperable security semantics. Standardisation makes parity externally testable This is particularly important where the architecture is used for interoperability between first- party and third-party assistants. A standardised parity profile could define that equivalent Candidate Acts are evaluated according to equivalent technical predicate structures. For example: same action class same resource class same destination class same risk class same user-intent condition same consequence boundary v equivalent finality requirements A conformity test can then determine whether this invariant is actually enforced rather than relying on the platform operator's statement that equivalent treatment exists. Standardisation can also solve the policy-governance problem A common profile may define: policy-bundle digest format; governance-epoch representation; policy-update transparency; co-signature or threshold-authorization mechanisms; parity-profile identifiers; external audit evidence; and conformity-test requirements. That makes it possible for a regulator, conformity-assessment body, enterprise, or relying party to verify which governance profile a device actually enforced. The standard therefore separates: WHO IMPLEMENTS THE HARDWARE from WHAT SECURITY INVARIANT MUST BE PROVABLE Standardisation also supports cross-platform AI agents Without a common finality model, an AI assistant interacting with multiple operating systems may encounter entirely different concepts of: permission; user intent; capability; tool authority; finality; destination binding; and consequence verification. A standard Candidate Act and Finality Sink model could allow an agent to request an operation using a common semantic structure while each platform retains control over its protected implementation. For example: Agent requests: "send File X to Recipient Y" v Standard Candidate Act v Platform A secure-controller implementation Platform B TEE implementation Platform C distributed protected implementation v same externally verifiable finality semantics The standard therefore concerns execution authority semantics, not hardware uniformity. Relevant standardisation domains The architecture naturally intersects several existing standards areas rather than belonging exclusively to one. Potential technical domains include: trusted execution and secure components; platform security; device attestation; capability-based security; AI-agent and tool-call governance; operating-system interoperability; telecommunications; identity and credential systems; payment and wallet security; confidential computing; privacy-preserving audit evidence; and AI governance infrastructure. Bodies working in areas such as GlobalPlatform, Trusted Computing Group, ITU-T, 3GPP, ETSI, ISO/IEC JTC 1, W3C, and relevant AI-agent or interoperability standards initiatives could therefore encounter different layers of the architecture. A single standard would not necessarily need to cover the entire system. The architecture can be decomposed into interoperable profiles. For example: Profile 1 Candidate Act + capability format Profile 2 Protected finality verification Profile 3 Policy and parity attestation Profile 4 AI-agent / tool-call finality Profile 5 Privacy-preserving validation evidence Profile 6 Telecom / network egress finality Profile 7 Payment and wallet finality The strategic value of standardisation is therefore broader than implementation uniformity: It converts execution finality from a platform-specific security mechanism into a common, independently testable infrastructure property. Q21. Existing platforms already use secure processors, protected confirmation, app-intent frameworks, hardware-backed keys, sandboxing, entitlements, and isolated AI runtimes. What would need to be standardised beyond those mechanisms? Those mechanisms provide important building blocks, but they do not by themselves create a common cross-platform definition of execution finality for an exact consequential act. The standardisation opportunity is the ordered relationship among the components: Candidate Act v explicit Non-Effective State v release-form commitment v protected predicate validation v protected validation evidence v scoped non-bearer execution authority v resource + destination + sink + boundary binding v Finality Sink verification against actual release state v authority consumption v effectuation A standards profile could therefore define several properties that ordinary permission systems do not necessarily define uniformly. 1. Computation is not execution authority An AI model may generate: a payment instruction; email; file export; API invocation; browser action; tool call; device command; without that computation itself authorizing the consequence. The standard would define a formal transition from: PROPOSED / COMPUTED to: AUTHORIZED TO BECOME EFFECTIVE 2. Permission is not finality A broad application entitlement or permission may establish that an application can use a class of resource. Execution finality asks a narrower question: Is this exact act, against this exact resource and destination, currently authorized to become effective? That distinction can be standardised independently of existing permission frameworks. 3. Authority must remain act-scoped Authority granted for: File A -> Recipient X must not automatically authorize: File B -> Recipient X or: File A -> Recipient Y or another downstream act generated by an agent. Standardisation can define the mandatory scope fields used to prevent such expansion. 4. Capability possession alone must be insufficient A finality capability may be transported through ordinary software, but copying or replaying it must not by itself create authority. The standard may require binding to: Candidate Act; requester; resource; destination; nonce; epoch; Finality Sink; and Effectuation Boundary. 5. Alternate APIs must not change finality requirements The same consequence may be requested through: public API; private API; app intent; browser automation; accessibility route; IPC; plug-in; SDK; cloud relay; internal service. The standards property is consequence-based: Equivalent external consequences remain subject to equivalent finality requirements regardless of the software route used to reach the boundary. 6. First-party and third-party parity becomes technically measurable Standardisation can define equivalent-action test cases so that parity is not simply a policy statement. A conformity suite could submit equivalent first-party and third-party Candidate Acts and compare: predicate profile; capability scope; denial reasons at the protected level; Finality Sink requirements; policy-bundle identity. This would make interoperability parity independently testable. 7. The first usable release boundary becomes a common architectural concept The relevant enforcement point is not necessarily where the request originates. It is: the last point at which the artifact remains determinable and complete withholding remains possible immediately before the consequence becomes usable. A standard can define how implementations identify and attest that boundary for different action classes. 8. Validation evidence becomes portable A standardised LAVR or equivalent protected evidence format could allow an authorized verifier to establish that: the Candidate Act remained non-effective; the correct policy profile was applied; protected predicates passed; scoped authority was issued; the designated Finality Sink verified it; and finality occurred under the expected governance epoch. The verifier would not need access to the platform's proprietary internal implementation. Standardisation Objective The purpose is not to replace existing secure hardware, operating-system permissions, protected confirmation systems, or application frameworks. The purpose is to establish a common technical rule for when machine-generated intent becomes externally effective authority. The resulting standards abstraction is: COMPUTATION = AUTHORITY PERMISSION = FINALITY CAPABILITY POSSESSION = EFFECTUATION PROTECTED VALIDATION + EXACT ACT BINDING + FINALITY SINK VERIFICATION = AUTHORIZED CONSEQUENCE A cross-platform standard built around that invariant could allow different device ecosystems, AI assistants, applications, telecom systems, payment systems, and regulated infrastructures to implement different internal mechanisms while still exposing the same independently verifiable execution-finality semantics. Q21. What is the answer when a platform vendor says, "We already have secure hardware, protected confirmation, secure intent, app-intent controls, hardware-backed keys, and isolated AI runtimes"? The answer should not be that secure hardware itself is new. Secure processors, trusted execution, protected confirmation, app intents, hardware-backed keys, sandboxing, entitlement systems and isolated AI runtimes are existing building blocks. The technical distinction to emphasize is the ordered execution-finality invariant across generic consequential action classes. The architecture is not merely: secure hardware + permission + confirmation It is: Candidate Act v explicit Non-Effective State v release-form commitment v protected predicate validation v protected validation evidence v scoped non-bearer finality authority v binding to resource + destination + sink + boundary v Finality Sink independently verifies actual release state v authority consumption v effectuation The distinction also includes: computation does not itself create execution authority; possession of the capability alone is insufficient; authorization for one act does not expand to another act; separate downstream consequential acts receive separate finality; alternate APIs do not bypass consequence-level enforcement; first-party internal routes remain subject to equivalent finality for equivalent Candidate Acts; the first usable release boundary, not an earlier policy check, controls final effectuation; protected validation evidence exists before or atomically with authority release. The current PCT expressly distinguishes ordinary permissions, entitlements, API access, user approval and software mediation from sink-side finality, and it closes first-party, alternate- route, local-AI, cloud-assisted and bearer-token substitutions. Accordingly, the response is: Existing secure components may supply parts of the implementation. The relevant technical question is whether those components collectively enforce the complete Candidate Act -> Non-Effective State -> protected validation -> scoped finality authority -> actual-release verification -> Finality Sink effectuation sequence for generic consequential acts, including equivalent first-party and third-party paths. The hardware is not the central distinction. The distinction is the execution-authority architecture imposed across the consequence boundary. Consolidated Position These additional objections add six requirements to the earlier five core invariants: 6. Policy itself must have protected provenance and, where neutrality matters, independent verifiability. 7. Finality must be capable of reasoning over cumulative protected state, not only isolated acts. 8. Declared purpose is a constraint label, not proof of semantic intent. 9. AI behavioral enforcement must target measurable runtime and action-level invariants rather than deterministic model outputs. 10. Privacy, accessibility, user autonomy and availability are architectural requirements, not afterthoughts. 11. Distributed finality prevents unauthorized sub-actions but does not automatically guarantee rollback of already irreversible acts. The complete architecture therefore becomes: POLICY PROVENANCE / GOVERNANCE v CANDIDATE ACT v RELEASE-FORM COMMITMENT v NON-EFFECTIVE STATE v PER-ACT + CUMULATIVE PROTECTED PREDICATES v PED AUTHORITY VALIDATION v LAVR / PRIVACY-PRESERVING EVIDENCE v SCOPED NON-BEARER CAPABILITY v GOVERNED EGRESS SET v FINALITY SINK RE-DERIVES ACTUAL RELEASE STATE v MATCH + CURRENT BUDGET + CURRENT POLICY? NO YES v v FAIL CLOSED CONSUME / ADVANCE v EFFECTUATE v MINIMAL PROTECTED RECEIPT The resulting principle is: No software component, policy author, agent, assistant, platform service, cached permission, prior approval, alternate API, or possession of an authorization object should by itself be sufficient to create an externally effective consequence. The exact consequence must remain bound to protected authority, current protected state, independently identifiable policy, and sink-side verification at the boundary where that consequence actually becomes usable. Additional Technical Objections and Responses Q22. If applications already define actions through structured intent schemas, why is a separate Candidate Act necessary? Structured intent frameworks can define available application actions, required parameters, entities, and data relationships. An intent therefore describes an executable application capability. A Candidate Act operates at a different layer. It represents the specific consequence presently proposed for effectuation. For example: APP INTENT DEFINITION SendMessage( recipient, content ) This defines an action class. A Candidate Act represents a particular execution: THIS EXECUTION recipient = X actual final payload = H(...) attachment = Y requester = Agent A destination = X sink = MessageSendSink boundary = B epoch = E nonce = N The sequence is therefore: Intent schema v Action invocation v Actual resource and destination resolved v Candidate Act v Release-form commitment v Protected finality The standardisation objective is not to replace structured-intent frameworks. It is to establish a common final execution-authority layer beneath or alongside those frameworks. An intent answers: What operation does the application expose? A Candidate Act answers: Is this exact instance of that operation, involving these exact resources and destinations, authorized to become externally effective now? Q23. How can a platform-level Candidate Act normalize the semantics of thousands of unrelated applications? A universal execution-finality layer does not need to understand the complete business semantics of every application. Application-specific semantics and consequence semantics can remain separate. Applications may define operations such as: PublishInvoice SubmitMedicalForm BookTrip ApproveExpense ShareAlbum The execution-finality layer can instead operate on a smaller set of standardized consequence primitives: DATA_DISCLOSURE NETWORK_TRANSMISSION MESSAGE_SEND PAYMENT_COMMIT CREDENTIAL_RELEASE IDENTITY_DISCLOSURE STORAGE_COMMIT EXTERNAL_API_INVOCATION SENSOR_RELEASE INTER_PROCESS_TRANSFER DEVICE_SETTING_CHANGE PHYSICAL_ACTUATION PROTECTED_RENDER An application-specific action can map to one or more consequence classes. For example: PublishInvoice v DATA_DISCLOSURE + NETWORK_TRANSMISSION + STORAGE_COMMIT or: BookTrip v CREDENTIAL_RELEASE + EXTERNAL_API_INVOCATION + PAYMENT_COMMIT The application may provide the initial semantic mapping, but providing that mapping does not create execution authority. The actual consequence remains independently bound to machine-verifiable attributes such as: actual resource actual release-form commitment actual recipient actual destination actual amount actual credential actual network endpoint actual Finality Sink actual Effectuation Boundary current epoch fresh nonce The Protected Execution Domain therefore does not need to understand the complete human meaning of BookTrip. It needs to determine: Which protected consequence classes are about to become effective, and whether valid authority exists for those consequences. For an unmapped or novel consequential action, the architecture may: require registration of a structured consequence schema; require explicit action-class, resource, and destination mapping; classify the act according to its downstream Effectuation Boundary; require stronger trusted-user confirmation; assign the operation to an unknown or high-risk consequence class; or fail closed where the consequence cannot be safely classified. This avoids both extremes: trusting application-defined meaning as final authority and requiring the PED to become a universal application-semantic engine. The source material already distinguishes application semantics from standardized consequence semantics. Q24. Does equivalent first-party and third-party treatment incorrectly assume identical trust properties? Equivalent treatment does not require identical identity, provenance, privilege, or attestation evidence. Different requesters may legitimately have: different code provenance; different sandbox privileges; different protected entitlements; different signing authority; different hardware access; different attestation mechanisms. The relevant parity invariant is: Equivalent externally consequential acts must face equivalent finality requirements, while requester-specific trust evidence may legitimately differ. For example: FIRST-PARTY REQUEST identity evidence A + resource X + destination Y + payment consequence + fresh user confirmation + Finality Sink verification and: THIRD-PARTY REQUEST identity evidence B + resource X + destination Y + payment consequence + fresh user confirmation + Finality Sink verification The identity evidence may differ. The prohibited asymmetry is: third-party equivalent consequence -> finality required first-party equivalent consequence -> finality bypassed The parity rule is therefore about the consequence-level security invariant, not about forcing every requester to present identical credentials. Q25. Does exposing Finality Sink functionality to third-party applications create a privileged attack surface? The application-facing interface does not need to expose protected internal mechanisms. Applications need not directly manipulate: PED keys; secure counters; hardware registers; sink-controller state; queue-enable material; cryptographic unlock values; protected memory; or protected policy state. The application-facing interface can remain abstract: REQUEST CANDIDATE ACT v opaque platform mediation v protected validation v Finality Sink verification v success / denial The capability itself may remain opaque to the requesting application. An application or operating-system component may transport a capability without receiving authority to: mint it; expand it; reinterpret it; modify it; replay it outside its bound scope; or force a Finality Sink to accept it. Standardisation can therefore define: Candidate Act semantics; capability binding requirements; Finality Sink verification behavior; policy identity; attestation; evidence formats; and conformance requirements, without exposing privileged controller internals to third-party software. Q26. How are application, model, runtime, or operating-system updates handled without silently transferring old authority into a new software state? Authority may be bound to: application measurement; code-signature state; model identity; runtime version; governance epoch; policy epoch; security state. An update may therefore invalidate existing act-specific authority. For example: OLD VERSION app_measurement = A epoch = 100 v software update v NEW VERSION app_measurement = B epoch = 101 Capabilities issued under the old measured state should not silently migrate to the new state. A version transition can instead follow: old act-specific capability -> expires / invalid new software state -> re-attested stable user policy -> may remain subject to revalidation new protected session -> established new act-specific capability -> issued Long-lived user preferences or policy configuration may survive an update where permitted. Act-specific execution authority generally should not survive automatically. This preserves the distinction between: persistent policy and fresh authority to effectuate a specific consequence. Q27. What happens when an operation begins on one device but becomes effective on another? Cross-device execution introduces another trust boundary. Examples include: phone request -> watch payment tablet request -> laptop file send headset request -> phone communication cloud-generated request -> local device effectuation A capability bound to Device A's protected state and Finality Sink should not automatically become executable authority on Device B. Two general models are possible. Model 1: New Candidate Act at the receiving device DEVICE A Candidate Act A v protected authorization v delegation commitment v DEVICE B receive delegated request v construct Candidate Act B v verify Device A provenance v validate Device B state v issue Device-B-bound capability v Device B Finality Sink Model 2: Jointly authorized cross-device capability A cross-device capability may be jointly bound to: Device A identity; Device B identity; originating Candidate Act; receiving Candidate Act; destination; action class; participating sinks; nonce; governance epoch; delegation scope. The original capability must not become a freely transferable bearer credential merely because the workflow crosses devices. Device identity therefore becomes another load-bearing finality attribute. Q28. What happens if the Finality Sink consumes authority and the device crashes before the external consequence completes? This is a crash-consistency problem. For example: capability verified v authority consumed v CRASH v did the consequence occur? The reverse sequence is also possible: external effect committed v CRASH v protected consumed-state not fully recorded Execution finality therefore requires a crash-consistent protected commit state. A representative state machine is: ISSUED v ARMED v COMMITTING v EFFECT-COMMITTED v CONSUMED The exact state machine depends on the consequence class. Locally controlled consequences For consequences under direct local control, protected authority consumption may be atomically or crash-consistently coupled with the local effect. Examples include: storage commit; protected-display release; local credential release; device-setting change; actuator enablement; secure transaction state. The intended invariant is: either authority remains unused AND effect does not occur or authority is consumed AND local effect is committed Intermediate states must be recoverable from protected state. Networked consequences Networked consequences introduce a different problem because local protected state cannot always determine whether the remote party completed the operation. Execution authority and proof of external completion must therefore remain distinct concepts. Q29. Can the architecture guarantee exactly-once execution for networked consequences? Not universally. Consider: SEND transaction X v remote service executes X v ACK lost v local device does not know whether retry is safe A retry could produce: harmless retransmission; duplicate message; duplicate payment; duplicate API operation; duplicate external side effect. Execution finality can provide: single-use authority; sink-local consumption; replay resistance; bounded retry authority; transaction identifiers; idempotency identifiers. For example: CandidateActID = X ExternalTransactionID = X A retry remains bound to: the same Candidate Act; same resource; same destination; same action class; same transaction identity; same sink; same boundary; same bounded retry policy. Where the receiving protocol supports idempotency, repeated delivery can be recognized as the same logical transaction rather than a newly authorized act. The bounded architectural statement is: Execution finality prevents uncontrolled replay or reuse of execution authority. Exactly- once external effect additionally requires appropriate transaction or idempotency semantics at the receiving system. This distinction between authority consumption and external completion is already identified in the source material. Q30. Does release-form commitment create unacceptable power or latency overhead for large files, video, audio, or continuous sensor streams? It could if every large payload had to be copied into the Protected Execution Domain or synchronously rehashed immediately before effectuation. The preferred design keeps bulk payload processing outside the PED. For large or streaming resources, a Finality Sink or protected boundary-adjacent component may use: incremental hashing; hardware cryptographic acceleration; DMA-integrated commitments; Merkle commitments; chunk commitments; rolling commitments; bounded stream descriptors. For example: VIDEO STREAM stream identity + destination + frame / chunk sequence + rolling commitment root + maximum duration + maximum bytes + sink identity + boundary identity The PED then operates on the compact commitment rather than the entire stream. The security property is preserved because the sink derives the commitment from the actual stream presented for release. The computational model becomes: bulk payload v boundary-side commitment generation v compact commitment v PED authority validation v sink-local verification v effectuation The source material already identifies incremental hashing, DMA-integrated commitments, Merkle commitments, chunk commitments, and bounded stream descriptors as relevant mechanisms. Q31. Can a digest of private information itself become a privacy leak? Yes. A conventional persistent content hash is not automatically privacy-preserving. For low-entropy or predictable resources, an observer may be able to test candidate values against the exposed digest. Examples include: short messages; common forms; known documents; small categorical values; predictable structured records. Validation evidence therefore should not unnecessarily expose stable reusable content fingerprints. Possible commitment mechanisms include: keyed commitments; salted commitments; HMACs; per-session commitments; ephemeral commitments; pseudonymous resource identifiers; selective-disclosure evidence; zero-knowledge proof mechanisms where appropriate. An external verifier may only need to establish: authorized resource commitment = actual released resource commitment without learning a globally reusable content fingerprint. The privacy requirement is therefore: Commitment equality should be verifiable without unnecessarily creating a persistent cross-context identifier for the underlying content. Q32. Could standardized device, policy, sink, and attestation identifiers become a fingerprinting mechanism? Yes. A standards profile that routinely exposes: device model firmware version PED version policy bundle sink topology security patch level hardware configuration could create a powerful device fingerprint. Standardisation should therefore distinguish: conformance attestation from unique device identity. A relying party may need to verify: device satisfies Finality Profile X without learning: unique hardware identifier exact device serial number complete firmware topology A privacy-preserving attestation design may therefore prove: assurance profile >= required level while minimizing disclosure of unique underlying device attributes. The objective is to prove security properties, not necessarily to expose the device's complete identity. Q33. Does policy transparency require publishing security-sensitive internal policy logic? No. Transparency does not require disclosure of every proprietary risk heuristic, dynamic anti- abuse signal, fraud-detection rule, or internal detection threshold. Externally verifiable information may be limited to: policy identity; policy version; governance epoch; mandatory parity profile; applicable action classes; mandatory finality invariants; security-assurance level; update history; policy-bundle commitment. A platform may retain confidential dynamic signals while still proving that: third-party Candidate Act and equivalent first-party Candidate Act were evaluated under the same mandatory consequence-level finality profile The transparency objective is therefore: verifiable policy provenance and mandatory invariant compliance rather than publication of every internal decision rule. Q34. Could a standardized execution-finality layer freeze platform innovation? A standard that dictates: processor architecture; exact kernel hooks; exact controller topology; exact cryptographic algorithms; exact hardware module; exact trusted-UI design; exact internal API structure, would be unnecessarily rigid. The standard should instead define observable security invariants. For example: REQUIRED Candidate Act remains non-effective exact consequence commitment fresh scoped authority resource and destination binding sink identity binding boundary identity binding replay resistance sink-side verification anti-bypass property independently testable parity Implementation may remain flexible: POSSIBLE IMPLEMENTATIONS TEE secure enclave secure element protected controller confidential VM protected microcontroller distributed protected service future hardware architecture The standard therefore defines what must remain true, not exactly how a platform must implement it. This allows hardware and operating-system architectures to evolve without changing the finality invariant. Q35. How can completeness of the Governed Egress Set be proven? Declaring that every consequence-producing path contains a sink is not sufficient. A modern platform may include: CPU; GPU; NPU; DMA engines; display processors; secure processors; baseband or modem paths; Wi-Fi controllers; Bluetooth controllers; sensor hubs; storage controllers; peripheral processors; firmware services; private controller paths. An omitted path may defeat complete mediation. The stronger standardisation mechanism is an attested Finality Boundary Manifest. For each governed consequence class, the platform maintains a measured and versioned description of the boundaries capable of externalizing that consequence. For example: NETWORK_EGRESS -> cellular modem sink -> Wi-Fi sink -> Bluetooth sink FILE_EXTERNALIZATION -> file-provider sink -> storage/export sink DISPLAY_RELEASE -> compositor sink -> protected display sink SENSOR_DISCLOSURE -> sensor-HAL sink -> protected DMA sink PAYMENT_COMMIT -> protected transaction-finalization sink The Finality Boundary Manifest should be: measured; versioned; signed or attested; bound to the hardware and firmware configuration; associated with the active Finality Sink topology; updated after relevant topology changes; independently testable through conformity procedures. An unregistered change to a: GPU path; DMA route; modem; controller; firmware component; coprocessor; or other externalization route should change the measured platform state and invalidate the previous finality-conformance attestation until the new topology has been evaluated. A conformity regime can then test two properties: MANIFEST INTEGRITY + BEHAVIORAL COMPLETENESS Manifest integrity establishes that the declared sink topology corresponds to the measured implementation. Behavioral completeness establishes that governed consequences cannot be externalized through undeclared or unverified routes. The source text identifies the Finality Boundary Manifest as the mechanism for moving from an asserted no-bypass property to an independently testable one. Q36. What happens to long-running background agents when there is no fresh user interaction? Requiring fresh user confirmation for every background act would undermine legitimate automation. Allowing a historical confirmation to authorize unlimited future actions would undermine execution finality. The solution is a bounded durable intent lease. For example: AUTHORIZED AUTOMATION Send daily report to Recipient X once per day for 30 days maximum one attachment from Folder Y The protected lease may bind: action class; resource scope; destination; maximum frequency; maximum execution count; validity period; expiration; revocation state; sink identity; boundary identity; cumulative quota; governance epoch. Each actual execution still produces a fresh Candidate Act. The persistent object represents: durable user intent while each individual execution still requires: fresh act-specific authority. The sequence becomes: durable intent lease v scheduled trigger v fresh Candidate Act v current protected-state validation v fresh scoped capability v Finality Sink v effectuation The principle is: Durable intent may persist; execution authority remains fresh, bounded, and act- specific. The bounded durable-intent model is described in the source material as a way to preserve automation without converting old user approval into unlimited authority. Q37. Could validation evidence conflict with stateless or privacy-preserving AI processing? Only if validation evidence is interpreted as requiring a centralized, permanent record of every AI-processing event. Execution-finality evidence does not need to contain: plaintext prompt content; complete message content; complete file contents; full model inputs; persistent recipient histories; reusable content fingerprints. A minimal-evidence mode may retain only compact protected state such as: counter advanced + governance epoch + policy commitment + anonymous or unlinkable commitment root More detailed content-dependent state may disappear after finality where the assurance model permits it. Where externally auditable evidence is required, the record can contain protected commitments rather than plaintext. The distinction is: proof that validation occurred does not require retention of the underlying personal data. Validation evidence can therefore be: local-first; compact; selectively disclosed; purpose-specific; retention-limited; compartmentalized; cryptographically committed; and privacy-preserving. The source material similarly distinguishes minimal protected evidence from indefinite retention of detailed AI-processing information. Consolidated Standardisation Position These objections resolve into several cross-platform requirements: 1. Structured intents and application APIs define available operations; Candidate Acts define exact instances of consequential execution. 2. Application-specific semantics are normalized into a bounded set of consequence primitives rather than interpreted comprehensively inside the PED. 3. Equivalent consequences receive equivalent finality requirements even where requester-specific identity evidence differs. 4. Protected internals remain opaque; standardisation focuses on semantics, binding, evidence, attestation, and conformity. 5. Software and model updates create explicit authority-version transitions rather than silently inheriting old act-specific authority. 6. Cross-device execution requires receiving-device finality or explicitly bounded joint authorization. 7. Crash consistency is handled through protected commit states, while exactly-once remote execution remains dependent on receiving-protocol semantics. 8. Large and streaming artifacts use boundary-side incremental commitments rather than bulk PED processing. 9. Content commitments and attestation should be privacy-preserving rather than globally linkable identifiers. 10. Standards should define observable execution-finality invariants rather than prescribing platform implementation topology. 11. Completeness of protected egress is established through an attested Finality Boundary Manifest and conformity testing. 12. Background automation uses durable intent but fresh act-specific execution authority. 13. Validation evidence proves protected finality without requiring permanent retention of the underlying personal content. Additional Technical Objections and Responses Q38. How can completeness of the Governed Egress Set be proven? Defining every consequence-producing boundary as a Finality Sink, or as structurally downstream of one, addresses bypass conceptually. It does not by itself prove that every possible hardware and software egress path has actually been identified. A modern computing platform may contain multiple independent or semi-independent consequence-producing components, including: CPU GPU NPU DMA engine baseband / modem Wi-Fi controller Bluetooth controller display processor sensor hub storage controller secure processor peripheral processor private framework coprocessor firmware-controlled path A single omitted path may defeat complete mediation. The stronger approach is an attested Finality Boundary Manifest. For each governed consequence class, the platform maintains a measured and versioned description of all hardware, firmware, protected-software, and controller boundaries capable of externalizing that class. For example: NETWORK_EGRESS -> cellular modem / baseband -> Wi-Fi controller -> Bluetooth controller -> network egress controller DISPLAY_RELEASE -> GPU output path -> compositor -> display controller -> external-display controller DATA_TRANSFER -> IPC -> shared memory -> DMA -> file-provider boundary -> storage controller SENSOR_RELEASE -> sensor hub -> DMA path -> HAL delivery boundary -> external transmission path PHYSICAL_ACTUATION -> actuator controller -> device-control coprocessor -> motor / haptic / radio control boundary The Finality Boundary Manifest should be: measured; versioned; signed or attested; bound to the hardware and firmware configuration; associated with the active Finality Sink topology; updated when firmware, controller configuration, or hardware state changes; and independently testable through conformity procedures. The conformance rule is: Every component capable of externalizing a governed consequence must either perform Finality Sink verification itself or be structurally downstream of a protected boundary that has already performed that verification. A new or modified GPU, DMA path, modem route, firmware module, private controller, or coprocessor capable of externalization should change the measured platform state. That change invalidates the previous finality-conformance attestation until the new topology has been measured, classified, and incorporated into the Finality Boundary Manifest. This produces two distinct conformity properties: MANIFEST INTEGRITY + BEHAVIORAL COMPLETENESS Manifest integrity proves that the declared Finality Sink topology corresponds to the measured platform configuration. Behavioral completeness tests whether each declared consequence class can actually be externalized only through the stated governed boundaries. The anti-bypass claim therefore does not rest on the statement: "Every API has been intercepted." It rests on the stronger property: Every physical or logical boundary capable of producing the governed consequence is part of an attested egress topology and lacks independent effectuation authority outside that topology. This converts Governed Egress Set completeness from an architectural assertion into a measurable and testable platform property. Q39. What happens if a crash, power loss, network failure, or retry occurs between authorization consumption and external effectuation? Execution authority and external completion are separate problems. A Finality Sink may successfully verify a capability and consume protected authority, but the device may fail before the consequence becomes externally effective. For example: capability verified v authority consumed v CRASH v was the external act completed? The reverse order can also occur: external effect committed v CRASH v protected consumed-state not fully recorded This is different from partial completion of a multi-step workflow. It is a crash-consistency problem inside the finality transaction itself. A protected Finality Sink should therefore implement an explicit commit state machine. For example: ISSUED v ARMED v COMMITTING v EFFECT-COMMITTED v CONSUMED or an equivalent protected sequence. The exact sequence depends on the consequence class. Locally controlled consequences For consequences under direct local control, authority consumption may be coupled closely or atomically with the relevant commit operation. Examples include: protected storage commit; secure-element transaction state; protected display release; local credential release; actuator enablement; local device-setting modification. Where hardware permits, protected state advancement and effectuation should form one atomic or crash-consistent transition. The required property is: either: authority remains unused AND effect does not occur or: authority is consumed AND local effect is committed Intermediate ambiguous states should be recoverable from protected state. Networked consequences For external networked systems, the device cannot universally determine whether the remote consequence occurred. For example: SEND transaction X v remote system executes X v ACK lost v device cannot determine whether X should be retried Execution-finality architecture therefore should not claim universal exactly-once external semantics. The correct distinction is: The architecture can enforce single-use or bounded-retry execution authority. Exactly- once external effect additionally requires cooperation from the receiving protocol or service. A stable Candidate Act identifier may be mapped to an external idempotency or transaction identifier: CandidateActID = X ExternalTransactionID = X Any retry must remain bound to: the same Candidate Act; the same resource; the same destination; the same requester; the same action class; the same transaction identity; the same Finality Sink; the same Effectuation Boundary; and a bounded retry policy. For example: Candidate Act X v Attempt 1 v ACK unavailable v Retry authority for X only v Attempt 2 carrying same transaction ID X The receiving system, where it supports idempotency, can recognize that the second request represents the same logical transaction rather than a new authorized act. Authority consumption and external completion must remain distinct The architecture should therefore track two different properties: AUTHORITY STATE Did the protected system permit this act? EXTERNAL COMPLETION STATE Did the receiving system actually complete it? The first can be protected locally. The second may require: protocol acknowledgement; remote transaction state; idempotency support; settlement confirmation; application-level completion evidence; or equivalent external cooperation. A lost acknowledgement must not automatically create a fresh unrestricted capability. Likewise, a retry should not become authority for a new resource, destination, amount, or operation. The bounded statement is: Execution finality prevents uncontrolled replay or reuse of execution authority; exactly- once external execution is guaranteed only where the consequence-producing protocol also provides appropriate transaction or idempotency semantics. Q40. How can a generic execution-finality layer govern arbitrary application actions without trusting application-defined meaning or becoming a universal semantic engine? A generic execution-finality layer does not need to understand the complete business meaning of every application operation. The architecture should separate: application-specific semantics from standard consequence semantics. An application may define operations such as: BookTrip PublishInvoice ApproveExpense SubmitMedicalClaim ShareAlbum SignContract Those names and their business meaning remain application-specific. The execution-finality layer instead works with a smaller set of standardized consequential primitives such as: DATA_DISCLOSURE NETWORK_TRANSMISSION MESSAGE_SEND PAYMENT_COMMIT CREDENTIAL_RELEASE IDENTITY_DISCLOSURE STORAGE_COMMIT EXTERNAL_API_INVOCATION SENSOR_RELEASE DEVICE_SETTING_CHANGE PHYSICAL_ACTUATION PROTECTED_RENDER INTER_PROCESS_TRANSFER An application-specific operation may map to one or more consequence primitives. For example: PublishInvoice v DATA_DISCLOSURE + NETWORK_TRANSMISSION + STORAGE_COMMIT Another example: BookTrip v CREDENTIAL_RELEASE + EXTERNAL_API_INVOCATION + PAYMENT_COMMIT And: ShareAlbum v DATA_DISCLOSURE + NETWORK_TRANSMISSION + RECIPIENT_BINDING The application may supply the initial mapping, but supplying a mapping does not create execution authority. The mapping is only the starting point for identifying the consequence classes that must be governed. The actual effectuation path still binds machine-verifiable attributes such as: actual resource actual release-form commitment actual recipient actual destination actual amount actual credential actual external endpoint actual Finality Sink actual Effectuation Boundary current epoch fresh nonce The Finality Sink then verifies the real consequence at the boundary where it can become effective. The architecture therefore does not need to determine: "What does BookTrip mean philosophically or commercially?" It needs to determine: "Which standardized consequential primitives will become effective if this operation completes, and does valid protected authority exist for each required consequence?" Structured consequence schema Applications, operating-system frameworks, or standards-defined interfaces may expose a structured consequence schema. For example: APPLICATION ACTION: BookTrip CONSEQUENCES: EXTERNAL_API_INVOCATION CREDENTIAL_RELEASE PAYMENT_COMMIT BOUND ATTRIBUTES: travel_provider = X passenger_record = Y amount <= Z payment_destination = P The semantic mapping may be application-provided, framework-provided, standardized, or derived from system-level interfaces. But load-bearing release attributes should still be independently verified at their relevant Finality Sinks. Unknown or novel action classes When a new operation cannot be mapped safely to a known consequence class, the architecture should not silently treat it as harmless. Possible responses include: require registration of a structured consequence schema; require explicit resource, destination, and action-class mapping; classify according to the downstream Effectuation Boundary; require stronger trusted-user confirmation; place the act into a higher-risk unknown-action class; or fail closed where a consequential operation cannot be reliably classified. A useful default rule is: Unknown application meaning does not imply unknown technical consequence. Even if the system does not understand the business semantics of PublishMedicalAnalysis, it can still recognize that the operation is about to: read protected file v serialize data v transmit to external endpoint and govern those concrete consequences. The PED remains small This separation also prevents semantic normalization from turning the Protected Execution Domain into an enormous policy engine. The PED does not need: a dictionary of every application command; natural-language understanding of every business operation; full application logic; arbitrary workflow interpretation. It needs a bounded representation of: consequence class; protected resource; destination; requester; authority scope; policy state; user-intent state where required; sink; boundary; freshness; cumulative state where applicable. The architecture therefore scales through a two-layer model: APPLICATION SEMANTICS v structured mapping v STANDARD CONSEQUENCE PRIMITIVES v exact Candidate Act v protected authority v actual Finality Sink This avoids both undesirable extremes: TRUST APPLICATION MEANING COMPLETELY and MAKE THE PED UNDERSTAND EVERY APPLICATION The governing principle is: Applications define what their operations mean at the application layer; execution finality governs the concrete consequence primitives through which those operations become externally effective. Consolidated Technical Position These three objections correspond to three different completeness properties. Hardware completeness Can every consequence-producing route be identified and proven to remain inside the protected egress topology? Addressed through: Governed Egress Set + attested Finality Boundary Manifest + conformity testing. Transactional completeness Can execution authority remain correct across crashes, retries, and uncertain remote completion? Addressed through: crash-consistent sink state + single-use/bounded-retry authority + external idempotency where supported. Semantic completeness Can arbitrary application operations be governed without requiring complete understanding of arbitrary application meaning? Addressed through: application-specific semantics -> standardized consequence primitives -> exact boundary verification. Together: APPLICATION ACTION v CONSEQUENCE NORMALIZATION v CANDIDATE ACT v RELEASE-FORM COMMITMENT v PROTECTED AUTHORITY v ATTESTED GOVERNED EGRESS SET v CRASH-CONSISTENT FINALITY SINK v EXTERNAL EFFECT The combined invariant is: Every externally consequential operation must be reducible to one or more machine- verifiable consequence classes, every technical route capable of externalizing those consequences must belong to an attested governed egress topology, and execution authority must remain bounded and crash-consistent until the corresponding Finality Sink controls the actual release. Security Considerations This document is primarily concerned with security architecture. Security considerations include compromised applications or AI assistants, replay, substitution, unauthorized redirection, stale or revoked authority, alternate egress paths, and failure to verify authority at the first usable release boundary. The architecture described in this document uses fail-closed verification and scoped execution authority to address these classes of risk. It does not claim security after compromise of the trusted hardware root, protected execution domain, or cryptographic root of trust. IANA Considerations This document has no IANA actions. Author's Address Sangam Das Independent Inventor Balasore, Odisha India Email: info@sangamdas.com