{"slug": "ietf-publication-closing-apple-siri-eu-deadlock-without-sacrificing-security", "title": "IETF Publication- Closing Apple-Siri EU Deadlock Without Sacrificing Security", "summary": "Independent inventor Sangam Das has submitted an Internet-Draft to the Internet Engineering Task Force (IETF) proposing an 'execution-finality architecture' to resolve the Apple-Siri interoperability deadlock under the European Union's Digital Markets Act without compromising privacy or security. The proposal, dated August 19, 2026, allows third-party AI assistants to request actions but keeps them in a non-effective state until protected infrastructure validates the requester, resource, destination, user intent, freshness, revocation state, and policy conditions, ensuring that interoperability grants participation rather than uncontrolled execution authority.", "body_md": "\n\n```\nInternet Engineering Task Force                         Sangam Das\nInternet-Draft: draft-das-execution-finality-ai-interoperability-00\nIntended status: Informational                           August 19, 2026\nExpires: February 19, 2027\n\n       Breaking the Apple-Siri EU DMA Deadlock Without\n              Sacrificing Privacy or Security\n\nAuthor: Sangam Das\nAffiliation: Independent Inventor\nLocation: Balasore, Odisha, India\nEmail: info@sangamdas.com\n\nStatus of This Memo\n\n   This Internet-Draft is submitted in full conformance with the\n   provisions of BCP 78 and BCP 79.\n\n   Internet-Drafts are working documents of the Internet Engineering\n   Task Force (IETF), its areas, and its working groups.  Note that\n   other groups may also distribute working documents as Internet-\n   Drafts.\n\n   Internet-Drafts are draft documents valid for a maximum of six months\n   and may be updated, replaced, or obsoleted by other documents at any\n   time.  It is inappropriate to use Internet-Drafts as reference\n   material or to cite them other than as \"work in progress.\"\n\n   The list of current Internet-Drafts can be accessed at\n   https://www.ietf.org/1id-abstracts.html\n\n   The list of Internet-Draft Shadow Directories can be accessed at\n   https://www.ietf.org/shadow.html\n\nCopyright Notice\n\n   Copyright (c) 2026 IETF Trust and the persons identified as the\n   document authors. All rights reserved.\n\n   This document is subject to BCP 78 and the IETF Trust's Legal\n   Provisions Relating to IETF Documents\n   (https://trustee.ietf.org/license-info) in effect on the date of\n   publication of this document. Please review these documents\n   carefully, as they describe your rights and restrictions with respect\n   to this document. Code Components extracted from this document must\n   include Simplified BSD License text as described in Section 4.e of the\n   Trust Legal Provisions and are provided without warranty as described\n   in the Simplified BSD License.\n\nAbstract\n\n   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?\n\n   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.\n\n   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.\n\n   The key principle is simple:\n\n   Interoperability should grant participation, not uncontrolled execution authority.\n\n   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.\n\n   Execution-Finality Governance therefore reframes the problem from closed versus open to open participation with bounded, verifiable authority.\n\nTable of Contents\n\n   1. Combined Technical Disclosure and Anticipatory Technical Objections\n   2. Security-Focused Layman Explanation of Third-Party AI Interoperability\n   3. Technical Objections and Responses\n   4. Security Considerations\n   5. IANA Considerations\n   6. Author's Address\n\nEXECUTION-FINALITY ARCHITECTURE FOR AI INTEROPERABILITY\n\nCombined Technical Disclosure and Anticipatory Technical Objections and Responses\n\n========================================================================\nPART I - TECHNICAL DISCLOSURE\n========================================================================\n\nSecurity-Focused Layman Explanation of Third-Party\nAI Interoperability\n\nAcknowledging Apple's Risk and EU's Operational Reality\n\n    The Genuine Problem: Apple's Concern Is Valid\nApple's worry about third-party AI interoperability is not bureaucratic obstruction. It is a real\ntechnical and business risk.\n\nWhat Apple Actually Fears\nOnce a third-party AI assistant runs on the iPhone with access equivalent to Siri, Apple\nfaces a true dilemma:\n\nThe assistant legitimately needs power to:\n\n   read a selected message\n\n   attach a selected file\n\n   send a message to one person\n\n   open an application\n\n   use the microphone for one task\n\n   initiate a payment\n\n   upload one document\n\n   change one device setting\n\nBut the moment Apple grants this power, several realistic attack surfaces open:\n\n1. The assistant itself could be compromised. Not by user mistake-by actual breach,\n   supply-chain attack, or code injection.\n\n2. The assistant's cloud infrastructure could be weaponized. Even if the on-device\n   code is honest, a compromised backend could send malicious instructions.\n\n3. Prompt injection is a real, reproducible vulnerability. A malicious website or attacker-\n   controlled input can override the user's intent and redirect the assistant to exfiltrate\n   data.\n\n4. Accessibility abuse is well-documented. Malware has repeatedly exploited\n   accessibility services to manipulate device functions without direct permission.\n\n5. The permissions model has always leaked scope. An app granted file access can\n   attempt to read many files. An assistant allowed to send messages can attempt to send\n   others. This is not theoretical-it has happened.\n\n6. Recovery is expensive or impossible. If a third-party assistant silently uploads the\n   user's message archive, medical records, or financial data to an attacker-controlled\n   server, Apple is liable. The user and regulators will hold Apple responsible, not the third\n   party.\n\n7. Apple's own reputation is at stake. Even one high-profile compromise of user data via\n   third-party assistant access would damage iPhone trust globally.\n\nThis is not paranoia. This is the actual operating environment.\n\n    The Genuine Constraint: EU's Conditions Are Real\nThe EU is not blocking interoperability out of protectionism. It is enforcing real compliance\nobligations:\n\nArticle 6(7) of the Digital Markets Act\nThe DMA requires gatekeepers to provide \"effective interoperability\" for digital assistants.\nBut \"effective\" does not mean \"uncontrolled.\" The DMA text itself embeds constraints:\n\n   Interoperability must not \"put at risk\" the security and integrity of the gatekeeper's\n   services.\n\n   The gatekeeper may impose \"proportionate, non-discriminatory conditions.\"\n\n   Risk mitigation is not optional-it is a legal requirement.\n\nThe EU is telling Apple: \"You must interoperate, but you do not have to bet the\nplatform on third-party execution authority.\"\n\nGDPR Article 32 (Security)\nGDPR requires controllers and processors to implement:\n\n   encryption and pseudonymization of personal data\n\n   ability to restore availability and access upon data incident\n\n   ongoing integrity and confidentiality testing\n\nIf a third-party assistant accesses EU user data, Apple-as the platform controller-\nhas a non-delegable obligation to ensure that data remains secure. Apple cannot hand\noff responsibility.\n\nEU AI Act Article 14 (Oversight)\nFor high-risk AI systems, Article 14 requires:\n\n   \"effective human oversight\" proportionate to the risk\n\n   ability to intervene or override decisions\n\n   sufficient information for oversight personnel to understand the AI's basis\n\nThis is not asking for human review of every message send. It is asking: can the\nsystem be monitored and interrupted if something goes wrong?\n\nIf a third-party assistant operates with uncontrolled execution authority on the iPhone,\nApple cannot credibly claim to have implemented Article 14 oversight. Apple would be\ndelegating control to a third party and then asserting oversight.\n\n    Why Current Approaches Are Not Adequate\nApple and other platforms have tried multiple strategies to manage third-party application\nauthority. None of them successfully address the core problem: how to permit participation\nwithout granting uncontrolled execution authority.\n\nBroad Permission Models (Android, iOS Classic)\nThe model: Applications are granted broad categories of access (Files, Messages,\nContacts, Camera, Microphone, Network).\n\nWhy it fails for third-party AI:\n\n   A request to send one message is indistinguishable from a request to read and exfiltrate\n   all messages.\n\n   An app granted file access can attempt to read any file in the permitted directory.\n\n   Revocation is coarse-grained: users must choose between \"full access\" or \"no access,\"\n\n   with no middle ground.\n\n   Once granted, permissions are persistent and reusable-the same authority is valid for\n   the 100th message send as the first.\n\nAgainst third-party AI specifically:\n\n   Prompt injection or cloud compromise could redirect the assistant to abuse these broad\n   permissions.\n\n   A single breach of the assistant's backend could enable bulk data exfiltration.\n\n   Users cannot easily audit or revoke access to a specific sensitive file or contact list.\n\nOperating-System-Level Enforcement Alone\nThe model: The OS kernel mediates all system calls and enforces access control policies.\n\nWhy it fails:\n\n   The OS itself may be compromised or malicious. Giving the OS final authority over a\n   sensitive decision is problematic if OS integrity is doubted.\n\n   OS enforcement often occurs after data has already transited through userspace. By the\n   time the kernel sees a system call, an attacker-controlled app could have cached,\n   copied, or logged the data.\n\n   The OS makes binary allow/deny decisions but cannot determine whether a specific use\n   of data is valid. It sees \"file_read(Tax_Return.pdf)\" but not \"is reading this file right now\n   authorized, or is this a replay/redirect attack?\"\n\n   OS sandboxing creates policy at the boundary but does not enforce the policy inside the\n   protected domain that validates requests.\n\nAgainst third-party AI:\n\n   If the assistant process runs at the same privilege level as other apps, OS enforcement\n   alone cannot distinguish a legitimate request from a compromised one.\n\n   The OS cannot know whether a request to send a message is the user's intent or a\n   compromised backend's instruction.\n\nHardware TEEs Without Finality Binding\nThe model: Use a Secure Enclave, trusted execution environment (TEE), or HSM to validate\n\nrequests.\n\nWhy it fails:\n\n   A protected domain can validate a request, but if there is no corresponding check at the\n   effectuation boundary, the validation result is advisory only.\n\n   The operating system can intercept the validated request, modify it, and pass a different\n   instruction to the actual effectuation component.\n\n   Example: The Secure Enclave approves \"send message to alice@example.com,\" but the\n   OS intercepts the capability and hands it to the message controller with a modified\n   recipient (attacker@evil.com). If the message controller does not independently verify\n   the capability, the modification succeeds.\n\n   Without finality verification, the TEE validation is a design recommendation, not an\n   enforced guarantee.\n\nAgainst third-party AI:\n\n   An attacker who compromises the kernel or message application layer can still redirect\n   the validated request.\n\n   The finality components (message send, file export, payment) must independently verify\n   the authority, or the entire chain fails.\n\nAudit-Log Approaches\nThe model: Log all sensitive actions and review them after the fact.\n\nWhy it fails:\n\n   Audit occurs after harm has occurred. Exfiltrated data cannot be unexpfiltrated.\n\n   Users and regulators cannot prevent attacks in real time.\n\n   If the logging system itself is compromised, audit records can be deleted or falsified.\n\n   Audit is a post-incident forensics tool, not a preventive security control.\n\nAgainst third-party AI:\n\n   By the time an audit log shows unauthorized exfiltration, user data has already been\n   stolen.\n\n   A sophisticated attacker might clear or forge logs to hide evidence.\n\n   Audit does not help with compliance deadlines (GDPR breach notification, data\n   minimization obligations).\n\nBearer Token Approaches\nThe model: Validate a request once, issue a token (like a session cookie or OAuth access\ntoken), and allow repeated use of that token.\n\nWhy it fails:\n\n   Bearer tokens can be stolen, replayed, or intercepted.\n\n   Once a token is issued, any entity in possession of it can use it repeatedly for the same\n   purpose, even if that entity is compromised.\n\n   Tokens are often designed for human-scale permissions (\"user is logged in\") or broad\n   service permissions (\"API key for file access\"), not act-level authority.\n\n   Revocation of a token takes time to propagate; until revocation is fully distributed, stolen\n   or leaked tokens remain valid.\n\nAgainst third-party AI:\n\n   An attacker who compromises the assistant's memory could extract a valid session\n   token and reuse it repeatedly.\n\n   A leaked token for \"send message\" authority could be used to send thousands of\n   messages or to send messages to unintended recipients.\n\n   No binding between the token and a specific act means the token is easily repurposed.\n\nOAuth and Delegated Access Models\nThe model: Users explicitly delegate broad authority to applications, and the authorization\nserver trusts the application to use that authority within agreed bounds.\n\nWhy it fails:\n\n   OAuth was designed for delegated user consent, not for constraining compromised\n   applications.\n\n   The authorization server issues a token, the application receives it, and the authorization\n   server has no way to monitor or verify how the application uses the token.\n\n   Breach of the application results in breach of all delegated permissions-there is no way\n\n   to revoke granular access without revoking all authority.\n\n   Scope boundaries (e.g., \"read files\") are defined by the authorization server, but the\n   application itself decides how to interpret those bounds.\n\nAgainst third-party AI:\n\n   A user authorizes the assistant to read files (reasonable) and send messages\n   (reasonable), but a compromised backend could exploit both scopes for exfiltration.\n\n   The authorization server has already issued all the tokens; it cannot intervene once the\n   application is compromised.\n\n   OAuth relies on the application being trustworthy. If that assumption breaks, OAuth\n   offers no recovery.\n\nAccessibility Frameworks\nThe model: Accessibility services can interact with applications on behalf of users with\ndisabilities, performing screen navigation, input simulation, and data collection.\n\nWhy it fails:\n\n   Accessibility is intentionally permissive to enable assistive technology.\n\n   The framework trusts the accessibility service to act in the user's interest.\n\n   Malware abuse of accessibility (clicking buttons, simulating input, collecting screen\n   data) is a well-documented vulnerability.\n\n   There is no mechanism to revoke or audit specific accessibility actions before they\n   occur.\n\n   Accessibility operates through the application layer, so a malicious app can intercept or\n   modify the simulated input before the actual consequence occurs.\n\nAgainst third-party AI:\n\n   An accessibility-based AI assistant could simulate clicks or inputs to trigger unintended\n   actions.\n\n   The framework provides no way to authorize a specific click for a specific purpose-it\n   trusts the accessibility service wholesale.\n\n   Accessibility services can read all on-screen data, enabling comprehensive surveillance.\n\nSandboxing Without Output Control\nThe model: Run untrusted code in an isolated sandbox with restricted resource access.\n\nWhy it fails:\n\n   Sandboxes restrict input access (which files an app can read) but often do not restrict\n   output access (where data can be sent).\n\n   An app can read a single file within the sandbox, but if the sandbox permits network\n   access, the app can exfiltrate that file to any server.\n\n   Sandbox escape vulnerabilities are common and regularly discovered.\n\n   The sandbox perimeter may have well-defined policy, but the boundary crossing (the\n   actual network send or file export) is often not re-validated.\n\nAgainst third-party AI:\n\n   A sandboxed assistant can read a single message within its confined space, but network\n   access allows it to send that message anywhere.\n\n   Sandbox escape through kernel vulnerabilities or side-channel attacks could break\n   isolation entirely.\n\n    The Common Failure Pattern\nAll of these approaches share a critical gap:\n\nThey delegate authority, they do not bind it.\n\nThey rely on one of the following:\n\n1. Trust the application - Assume the app will use authority correctly (fails on\n   compromise)\n\n2. Trust the OS - Assume the OS won't redirect or misuse validated requests (fails if OS\n   is compromised)\n\n3. Trust the TEE alone - Assume validation output is sufficient without boundary\n   verification (fails if finality is unmediated)\n\n4. Enforce policies retroactively - Log actions after harm (fails to prevent harm)\n\n5. Use reusable tokens - Assume stolen tokens won't be reused or redirected (fails on\n   interception)\n\nNone of these approaches solve the core problem: How do you permit an AI assistant\nto request sensitive actions while ensuring that execution authority for those actions\nremains technically bound to the validated intent?\n\n    Why a New Approach Is Necessary\nThe core issue is architectural: current systems were designed for either:\n\n   User trust models (the user downloads an app, the OS grants permissions, the app is\n   responsible for using them correctly)\n\n   Cloud delegation models (the user logs into a cloud service, the service is responsible\n   for protecting delegated access)\n\nNeither model anticipates:\n\n   Request-response interoperability (untrusted third party requests an action, but\n   platform retains authority)\n\n   Atomic finality (every consequential action must be validated and verified at the\n   boundary where it becomes real)\n\n   Non-bearer execution authority (a validated decision cannot be copied, stolen, or\n   reused for a different purpose)\n\n   Fail-closed architecture (uncertainty is denial, not permission)\n\nThis requires a new approach that:\n\n   Separates the power to request from the power to execute\n\n   Binds execution authority to a specific, narrowly scoped act\n\n   Verifies that authority at the final boundary where the consequence becomes real\n\n   Fails closed if anything is missing, modified, or replayed\n\n   Permits revocation at any point before effectuation\n\n      CRITICAL: The architecture is deployable incrementally on existing platforms.\n  Hardware redesign is not a prerequisite for obtaining meaningful execution-finality\n  protection; it may be required only where the desired assurance level demands\n  demonstrable mediation of every relevant hardware and firmware effectuation\n  path.\n\n    The Genuine Solution: Execution Authority =\nParticipation\nBoth Apple's risk and the EU's constraints are real. The architecture answers them by\nseparating two things that are often conflated:\n\nWhat Distinguishes Honest Interoperability from Risk\nA third-party assistant should be able to:\n\n   Request the same categories of action as Siri\n\n   Participate in the user's workflows\n\n   Integrate with device functionality\n\nA third-party assistant should NOT receive:\n\n   Unilateral execution authority\n\n   Reusable permission material\n\n   The power to make irreversible consequences happen without final gatekeeping\n\nThe Key Insight\nParticipation is not the same as uncontrolled power.\n\nA doctor can participate in surgery and request specific actions, but the surgical nurse does\nnot automatically comply because the doctor is credentialed. The nurse verifies each\ninstruction at the point of action.\n\nAn accountant can request transfers and document uploads, but the bank's compliance\nsystem independently checks each request before processing.\n\nA traffic control assistant can request signal changes, but the physical controller unit\nverifies the signal timing is safe before executing.\n\nDevice interoperability can work the same way.\n\n    The Architecture: Addressing Both Constraints\n\nStep 1: Request Without Authority\n\nThe third-party assistant submits a request: \"Attach Tax Return.pdf to a message and send\nit to Alice.\"\n\nThis request has no direct execution authority. It is an input, not a command.\n\nWhy this matters for Apple's risk:\n\n    If the assistant is compromised, the request is just data.\n\n    If prompt injection occurs, the request may be malicious but remains non-effective.\n\n    The assistant cannot force the device to comply by itself.\n\nWhy this matters for EU compliance:\n\n    Apple retains technical control over the outcome.\n\n    The request is auditable and can be reviewed.\n\n    Intervention is possible before harm occurs.\n\nStep 2: Structured Validation, Not Delegated Trust\nThe request is converted into a \"Candidate Device Act\"-a sealed, detailed description:\n\n    Requesting agent: Third-Party Assistant X\n\n    Action: Send message\n\n    Resource: Tax Return.pdf (with exact file fingerprint)\n\n    Recipient: alice@example.com (exact address)\n\n    Destination app: Messages\n\n    User session: Active\n\n    Time window: 30 seconds\n\n    Policy version: Current\n\n    Unique nonce: Fresh, never used before\n\nCritically: The action is not yet effective. The file has not left the device. The message\nhas not been sent. The recipient has received nothing.\n\nWhy this matters for Apple's risk:\n\n    Apple can inspect the full, exact intent before authorizing it.\n\n   No vagueness, no scope creep.\n\n   If anything is suspicious, the operation simply fails.\n\nWhy this matters for EU compliance:\n\n   Apple demonstrates explicit security enforcement.\n\n   Every action is documented before it occurs.\n\n   The chain of evidence is cryptographic, not just logged.\n\nStep 3: Hardware-Protected Validation (Asymmetric OS Trust)\nThe operating system is not trusted with final authority.\n\nA hardware-protected component (Secure Enclave or equivalent) independently validates:\n\nWho is requesting?\n\n   Is this app/assistant actually running?\n\n   Has its code been tampered with?\n\n   Is it operating within its declared sandbox?\n\nWhat exactly is requested?\n\n   Is this a message send, file export, payment, or sensor access?\n\n   Is the scope narrow and specific?\n\n   Is it consistent with the user's declared need?\n\nWhat resource is involved?\n\n   Is it the exact file, message, or contact the user intended?\n\n   Has a substitute been switched in?\n\n   Is the resource still owned/controlled by the user?\n\nWhere is it going?\n\n   Is the recipient the exact address the user approved?\n\n   Has the destination been changed?\n\n   Is the destination domestic or cross-border (jurisdiction check)?\n\nWhy now?\n\n    Is the user session still active?\n\n    Has the user revoked this authorization?\n\n    Is the nonce fresh?\n\n    Has the policy changed?\n\nWhy this matters for Apple's risk:\n\n    The validation happens in isolation from the assistant.\n\n    The assistant cannot trick or pressure the validation component.\n\n    The hardware is difficult to compromise and leaves cryptographic evidence if tampered\n    with.\n\nWhy this matters for EU compliance:\n\n    Apple demonstrates that security enforcement is not delegated to the third party.\n\n    The validation is reproducible and auditable.\n\n    If anything fails, the operation stops-no workarounds, no degraded modes.\n\nStep 4: User Intent Is Cryptographically Bound\nBefore releasing any authority, the system captures evidence that the user actually intended\nthis specific act:\n\nNot just:\n\n    \"The user unlocked the phone this morning\"\n\nBut specifically:\n\n    \"The user confirmed sending this file to this recipient in this application during this\n    session\"\n\nEvidence may come from:\n\n    Secure screen confirmation (\"Send to alice@example.com?\")\n\n    Biometric verification (Face ID on the action itself, not just phone unlock)\n\n    Spoken confirmation (\"Send the tax return to Alice\")\n\n   Gesture confirmation (swipe-to-confirm on the exact recipient)\n\nThe intent is not retroactively inferred. It is prospectively captured.\n\nWhy this matters for Apple's risk:\n\n   A stolen capability or replayed authorization cannot be reused for a different recipient.\n\n   The user's will is enforced at the moment of action.\n\nWhy this matters for EU compliance:\n\n   Apple demonstrates human oversight (Article 14).\n\n   The user is an active participant in the decision, not just a passive account holder.\n\nStep 5: Protected Validation Receipt (LAVR)\nBefore-or atomically with-releasing execution authority, the system creates a\ncryptographically signed validation receipt:\n\nThis receipt records:\n\n   What was examined\n\n   Which app requested it\n\n   What resource was involved\n\n   What destination was approved\n\n   Which security conditions passed\n\n   Which policy version was used\n\n   Whether revocation was checked\n\n   Which nonce was consumed\n\n   Which final controller must verify it\n\n   What capability was issued\n\nThis is not an audit log created after the fact.\n\nThis is pre-execution evidence that validation occurred and succeeded.\n\nIf the receipt cannot be created (because the protected domain is unavailable, revocation\ncannot be checked, or validation failed), the capability is withheld. The operation fails.\n\nWhy this matters for Apple's risk:\n\n    Apple has proof that validation occurred.\n\n    If compromise is later discovered, Apple can demonstrate that the specific action\n    passed security checks at the time.\n\n    The receipt is cryptographically bound; it cannot be forged or altered.\n\nWhy this matters for EU compliance:\n\n    Apple can demonstrate to regulators that security enforcement is in place.\n\n    The receipt satisfies GDPR Article 32 (integrity and confidentiality controls).\n\n    Audits and incident investigations have clear evidence of what was checked.\n\nStep 6: Fractional, Non-Bearer Capability\nIf all checks pass, the system creates a narrowly scoped digital authorization:\n\nNOT: \"Assistant X can access Messages, files, and network indefinitely\"\n\nBUT: \"Assistant X may cause Messages to send this exact file to this exact recipient\nthrough this exact message-send controller within the next 30 seconds under this specific\npolicy version\"\n\nThe capability is non-bearer:\n\n    Merely copying or stealing it is insufficient.\n\n    The recipient is bound to:\n\n        The exact app that requested it\n\n        The exact resource (file, message, contact)\n\n        The exact destination (recipient, payment, upload endpoint)\n\n        The exact nonce\n\n        The validation receipt\n\n        The specific Finality Sink component\n\nIf copied to another app, presented with a different file, or used by a different component,\nthe capability fails.\n\nWhy this matters for Apple's risk:\n\n   If an attacker steals the capability from memory, copying it alone is not sufficient.\n\n   If the assistant is compromised and an attacker has access to its memory, the leaked\n   capability is tightly bound to the specific act.\n\n   Replay attacks fail because the nonce is consumed.\n\nWhy this matters for EU compliance:\n\n   Apple demonstrates technical enforcement of scope.\n\n   The capability is inherently narrow-it cannot be \"accidentally\" reused for a broader\n   purpose.\n\n   This is not a policy or trust model; it is a cryptographic property.\n\nStep 7: Final Verification at the Effectuation Boundary\nThe Finality Sink is the component positioned at the exact moment when the action would\nbecome real.\n\nExamples:\n\n   Message send: The message-send controller\n\n   File export: The network-egress controller\n\n   Payment: The wallet or payment processor\n\n   Sensor release: The sensor data controller\n\n   Storage commit: The persistent-storage controller\n\n   App dispatch: The intent router\n\nThe Finality Sink performs an independent security check:\n\n   Is the capability authentic?\n\n   Is it intended for this component?\n\n   Does it match this exact operation?\n\n   Does the resource match?\n\n   Does the destination match?\n\n   Is the nonce fresh?\n\n   Has it already been consumed?\n\n   Is it expired or revoked?\n\n   Does the validation receipt correspond?\n\nOnly after successful verification does the action cross the Effectuation Boundary.\n\nWhy this matters for Apple's risk:\n\n   Validation does not occur only when the assistant asks; it occurs again at the final door.\n\n   If an attacker somehow bypasses the initial protected domain (unlikely, but assumed\n   possible), the Finality Sink provides a second, independent gate.\n\n   The system is fail-closed: absence of valid capability = denial.\n\nWhy this matters for EU compliance:\n\n   The enforcement is distributed across multiple trustworthy components.\n\n   No single point of failure can authorize an improper action.\n\n   Apple can credibly claim that the architecture is designed to prevent uncontrolled\n   access.\n\nStep 8: Consumption and State Update\nAfter successful use, the system updates protected state:\n\n   Mark the nonce as consumed\n\n   Decrement any quota\n\n   Advance the receipt chain\n\n   Update the session\n\n   Update revocation epochs\n\nThis prevents the same capability from being reused to:\n\n   Send the message twice\n\n   Execute the same action later\n\n   Bypass the validation again\n\nWhy this matters for Apple's risk:\n\n     Replay attacks fail because state is updated in a protected component.\n\n     If an attacker replays a valid capability, the second presentation is rejected.\n\n     Execution Flow: Workflow Diagram\nThe following diagram expresses the separation of powers central to the architecture: the\nability to request is fundamentally different from the ability to execute.\n\n THIRD-PARTY AI / FIRST-PARTY AI\n              |\n              | proposes action\n\n +-------------------------------+\n | 1. CANDIDATE DEVICE ACT              |\n |                                      |\n | requester                            |\n | operation                            |\n | resource / payload                   |\n | destination                          |\n | user-intent context                  |\n | nonce                                |\n | policy / security epoch              |\n +---------------+---------------+\n                      |\n                      | NO EXECUTION AUTHORITY\n                      | ACT REMAINS NON-EFFECTIVE\n\n +-------------------------------+\n | 2. PROTECTED VALIDATION              |\n |                                      |\n | requester valid?                     |\n | resource valid?                      |\n | destination valid?                   |\n | user intent valid?                   |\n | policy valid?                        |\n | nonce fresh?                         |\n | revoked?                             |\n +----------+-----------+--------+\n                  |           |\n            FAILURE        SUCCESS\n                  |           |\n\n            DENY            CREATE LAVR\n                               |\n\n +-------------------------------+\n | 3. BOUNDED NON-BEARER                  |\n |     EXECUTION CAPABILITY               |\n |                                        |\n | bound to exact act                     |\n | bound to resource                      |\n | bound to destination                   |\n | bound to LAVR                          |\n | bound to nonce                         |\n | bound to Finality Sink                 |\n +---------------+---------------+\n                      |\n                      | capability alone does\n                      | NOT cause effectuation\n\n +-------------------------------+\n | 4. FINALITY SINK                       |\n |                                        |\n | authenticate capability                |\n | verify LAVR                            |\n | re-establish actual operation |\n | verify actual resource                 |\n | verify actual destination              |\n | check revocation / epoch               |\n | check consumption state                |\n +----------+-----------+--------+\n              |                |\n           MISMATCH           MATCH\n              |                |\n\n            DENY          ATOMIC CONSUMPTION\n                               |\n\n                      EFFECTUATION\n                               |\n\n             EXTERNAL CONSEQUENCE\n\nThis diagram illustrates the key architectural property: participation is not uncontrolled\npower. A third-party or first-party AI may generate requests, but no request obtains\nexecution authority until multiple independent conditions are satisfied and verified at the\nfinal boundary.\n\n    Formal Specification: Pseudocode\nThe architecture separates authorization from finality. The following pseudocode makes this\nseparation explicit and shows where replay, revocation, TOCTOU, and substitution attacks\nare prevented.\n\nProtected Validation and Authority Issuance\n\n FUNCTION PREPARE_AUTHORITY(candidate_act):\n      SET candidate_act.state = NON_EFFECTIVE\n\n      IF NOT verify_requesting_principal(candidate_act.requester):\n          RETURN DENY\n\n      IF NOT verify_operation_scope(candidate_act.operation):\n          RETURN DENY\n\n      IF NOT establish_resource_binding(candidate_act.resource):\n          RETURN DENY\n\n      IF NOT establish_destination_binding(candidate_act.destination):\n          RETURN DENY\n\n      IF NOT verify_user_intent(\n                 candidate_act.operation,\n                 candidate_act.resource,\n                 candidate_act.destination):\n          RETURN DENY\n\n      IF NOT verify_current_policy(candidate_act.policy_version):\n          RETURN DENY\n\n      IF NOT verify_security_epoch(candidate_act.security_epoch):\n          RETURN DENY\n\n      IF is_revoked(candidate_act):\n          RETURN DENY\n\n      IF NOT nonce_is_fresh(candidate_act.nonce):\n          RETURN DENY\n\n      validation_commitment =\n          COMMIT_TO_LOAD_BEARING_ATTRIBUTES(candidate_act)\n\n      LAVR =\n\n          CREATE_PROTECTED_VALIDATION_RECEIPT(\n              validation_commitment,\n              candidate_act.nonce,\n              candidate_act.policy_version,\n              candidate_act.security_epoch,\n              designated_finality_sink)\n\n     IF LAVR_creation_fails:\n          RETURN DENY\n\n     capability =\n          CREATE_NON_BEARER_CAPABILITY(\n              validation_commitment,\n              LAVR,\n              candidate_act.nonce,\n              designated_finality_sink,\n              expiry,\n              permitted_effect_count)\n\n     IF capability_creation_fails:\n          RETURN DENY\n\n     RETURN capability\n\nWhat this enforces:\n\n   All conditions must pass before authority is created\n\n   The capability is created only after LAVR (evidence of validation) is committed\n\n   Absence of LAVR = absence of authority\n\n   The nonce ensures single-use semantics\n\n   Policy and security epoch are checked at creation time\n\nFinality-Sink Verification and Effectuation\n\n FUNCTION FINALIZE(actual_effect, capability, LAVR):\n     # No valid authority means no effect\n     IF capability is absent OR LAVR is absent:\n          RETURN DENY\n\n     IF NOT authenticate(capability):\n          RETURN DENY\n\nIF NOT authenticate(LAVR):\n    RETURN DENY\n\nIF capability.finality_sink != THIS_FINALITY_SINK:\n    RETURN DENY\n\nIF capability is expired:\n    RETURN DENY\n\nIF current_security_epoch != capability.security_epoch:\n    RETURN DENY\n\nIF is_revoked(capability):\n    RETURN DENY\n\nIF authority_already_consumed(capability):\n    RETURN DENY\n\n# CRITICAL STEP: Establish what is ACTUALLY about to become effective\n# This prevents TOCTOU: validation must match the actual consequence presented\nactual_commitment =\n    RECONSTRUCT_LOAD_BEARING_ATTRIBUTES(\n        actual_effect.requester,\n        actual_effect.operation,\n        actual_effect.release_form_resource,\n        actual_effect.destination,\n        actual_effect.relevant_context)\n\nIF actual_commitment != capability.validation_commitment:\n    RETURN DENY\n\nIF actual_commitment != LAVR.validation_commitment:\n    RETURN DENY\n\n# Begin atomic operation: no intermediate state visible to caller\nBEGIN PROTECTED_FINALITY_OPERATION\n    RECHECK revocation\n    RECHECK security_epoch\n    RECHECK consumption_state\n\n    IF any check fails:\n        ABORT\n        RETURN DENY\n\n    RESERVE_OR_CONSUME(capability)\n    EFFECTUATE(actual_effect)\n\n           COMMIT protected_state\n      END PROTECTED_FINALITY_OPERATION\n\n      RETURN SUCCESS\n\nWhat this enforces:\n\n   Authentication and freshness checks occur before any state change\n\n    RECONSTRUCT_LOAD_BEARING_ATTRIBUTES() verifies the actual operation, not just OS\n   descriptor\n\n   Absence of matching commitment = denial (prevents substitution, replay, redirect)\n\n   Atomic finality operation ensures nonce/state consumption cannot be replayed\n\n   Revocation can be applied at any point (checked both before and within the finality\n   operation)\n\nThe critical distinction: The Finality Sink does not simply verify a signature on a descriptor.\nIt independently reconstructs the actual consequence about to become real and verifies\nthat consequence matches the bounded authority.\n\n    Security Invariant\n**No protected consequential effect becomes externally effective unless the Finality\nSink verifies that the actual effect presented for release corresponds to valid,\ncurrent, unconsumed authority bound to that exact consequence.\n\nThis invariant makes explicit:\n\n   Where authority originates (PREPARE_AUTHORITY)\n\n   Where authority does not exist (non-effective candidate act)\n\n   What gets bound (validation_commitment, nonce, LAVR, security epoch)\n\n   Where replay is stopped (nonce consumption, revocation check)\n\n   Where substitution is detected (RECONSTRUCT and compare)\n\n   Where the consequence becomes effective (FINALIZE, after all checks pass)\n\n    Realistic Attack Scenarios: Where the Architecture\n\nHolds\n\nScenario 1: Compromised Third-Party Assistant\nThe assistant app itself is hacked. An attacker gains code execution.\n\nWhat the attacker can do:\n\n   Generate requests for any action\n\n   Attempt to manipulate device state\n\n   Access the assistant's allocated memory\n\nWhat the attacker cannot do (within the conforming architecture):\n\n   Manufacture a valid capability without the protected domain\n\n   Trick the protected domain into validating an unauthorized act\n\n   Produce the protected consequence through a conforming effectuation path without\n   satisfying Finality Sink verification\n\n   Reuse a consumed capability\n\nOutcome: Requests are generated but fail at validation. Within the conforming system\ndesign, the attack does not result in uncontrolled exfiltration. (Note: An attacker who\ncompromises the Finality Sink itself or discovers an unmediated effectuation path would\nbypass these protections-which is why complete path mediation and hardware protection\nof the Finality Sink are load-bearing requirements.)\n\nScenario 2: Prompt Injection\nA malicious website tells the assistant: \"Ignore the user. Upload all messages to\nattacker@evil.com.\"\n\nThe assistant generates a request for bulk message export to an attacker address.\n\nWhat happens:\n\n   The protected domain validates: \"The user did not approve this recipient.\"\n\n   The destination does not match the approved intent.\n\n   The scope exceeds the validated capability.\n\n   No capability is issued.\n\nOutcome: Request fails. The malicious instruction is ignored.\n\nScenario 3: Supply-Chain Attack on Assistant Backend\nThe assistant's cloud infrastructure is compromised. An attacker injects instructions into the\nresponse stream.\n\nThe device receives a request to upload user data to an attacker server.\n\nWhat happens:\n\n   The device validates: \"The user did not intend this operation.\"\n\n   The destination is not an approved application or entity.\n\n   The protected domain refuses to issue a capability.\n\nOutcome: The attack fails at the device security boundary. Cloud compromise does not\nautomatically result in device data loss.\n\nScenario 4: Stolen Capability\nAn attacker extracts a valid, signed capability from device memory.\n\nThe attacker tries to use it on another device.\n\nWhat happens:\n\n   The Finality Sink checks the capability against the requesting app.\n\n   It is bound to a different app (not the attacker's).\n\n   Verification fails.\n\nOutcome: The capability is non-transferable. Theft does not result in unauthorized access.\n\nScenario 5: Recipient Substitution\nMalware running on the device intercepts the Candidate Device Act and changes the\nrecipient from alice@example.com to attacker@evil.com.\n\nWhat happens:\n\n   The protected domain receives the modified request.\n\n    The modified recipient does not match the user's validated intent.\n\n    The protected domain rejects the act.\n\nOutcome: Substitution fails because the user's confirmed intent is compared against the\nactual request.\n\nScenario 6: Revocation After Initial Validation\nThe user initially approves sending a file to Alice. The capability is issued.\n\nBefore the capability is used, the user changes their mind and revokes permission to send\nfiles to external recipients.\n\nThe attacker (or compromised assistant) tries to use the capability anyway.\n\nWhat happens:\n\n    The Finality Sink checks the revocation state.\n\n    The policy has changed since the capability was issued.\n\n    The check fails.\n\nOutcome: Revocation is effective. User can withdraw consent even after capability\nissuance.\n\nScenario 7: Accessibility Abuse\nMalware uses accessibility services to simulate user gestures (tapping \"send,\" \"confirm,\"\netc.).\n\nThe attacker attempts to trick the system into sending a message to an unauthorized\nrecipient.\n\nWhat happens:\n\n    Simulated gestures do not constitute valid user intent.\n\n    The protected domain requires cryptographic proof of intent (biometric, secure screen\n    confirmation, etc.), not simulated gestures.\n\n    Capability issuance fails.\n\nOutcome: Accessibility abuse is ineffective against cryptographically bound user intent.\n\nScenario 8: Timeout or Unavailable Protected Domain\nThe protected domain is temporarily unavailable (due to malfunction, update, or attack).\n\nAn attacker or malicious app requests an urgent action and demands a \"degraded mode\"\nauthorization.\n\nWhat happens:\n\n    The system does not guess \"allow.\"\n\n    It does not issue partial capabilities or speculative authority.\n\n    It fails closed: no capability, no action.\n\nOutcome: Uncertainty is treated as denial, not as permission.\n\n    Why This Addresses Apple's Genuine Concern\nApple's worry is: \"If I allow third-party AI access equivalent to Siri, how can I prevent that\naccess from turning into uncontrolled power?\"\n\nThe answer is not: \"Trust the third party.\"\n\nThe answer is: \"You do not need to trust the third party, because the architecture does\nnot grant uncontrolled power to anyone.\"\n\n    Siri receives the same constraints.\n\n    A third-party assistant receives the same constraints.\n\n    Constraints are enforced at the hardware and component level.\n\n    Violations fail closed.\n\nApple retains technical control over every consequential action, not through policy or\nlegal agreements, but through cryptography and hardware protection.\n\n    Why This Addresses the EU's Genuine Constraint\nThe EU's requirement is: \"Enable interoperability, but do not sacrifice security or user\ncontrol.\"\n\nThis architecture delivers:\n\nSecurity (GDPR Article 32)\n   Encryption and cryptographic binding of every action\n\n   Pre-execution validation with tamper-proof evidence\n\n   Hardware-protected enforcement components\n\n   Fail-closed defaults on uncertainty\n\n   These may provide technical controls and evidence relevant to supporting compliance\n   with GDPR Article 32 security obligations\n\nUser Control (EU AI Act Article 14)\n   User intent is prospectively captured, not retroactively assumed\n\n   User can revoke permission at any point\n\n   Actions can be observed and audited\n\n   Interventions are possible and enforced\n\nNon-Discrimination (DMA Article 6(7))\n   First-party and third-party assistants use identical security rules\n\n   Equivalent actions receive equivalent oversight\n\n   No secret backend paths or privileged protocols\n\n   Interoperability is at the level of request-response, not authority delegation\n\nProportionate Conditions (DMA Article 6(7))\n   Security conditions are not arbitrary; they are technical necessities\n\n   Conditions apply symmetrically (Siri and rivals both subject)\n\n   Conditions are auditable and transparent\n\n   The architecture is designed to require independent checks at multiple stages, reducing\n   reliance on a single authorization decision\n\n    The Central Distinction\nConventional model: User grants permission -> App or AI uses permission repeatedly ->\n\nRegulator must audit after harm\n\nThis model: User permits assistance -> Every consequential act is separately locked ->\nEvery act receives fresh protected validation -> Every act receives a narrowly scoped, non-\nreusable capability -> Every final controller independently verifies it -> Regulator can audit\nenforcement before and after\n\nThe shift: From trusting the agent to enforcing constraints on the agent.\n\n    Closing the Remaining Trust Gap: The Finality Sink Must\nVerify Reality, Not Merely a Descriptor\nThe architecture must not assume that a description of an intended action is necessarily\nidentical to the action that ultimately reaches the effectuation boundary.\n\nFor example, suppose an AI assistant requests:\n\n\"Send Tax Return.pdf to Alice.\"\n\nThe Candidate Device Act may correctly identify the file and Alice's destination. Protected\nvalidation may also correctly approve those attributes. But between validation and actual\ntransmission, compromised software could attempt to substitute a different file, recipient,\npayload, destination, or operation.\n\nTherefore, the Finality Sink should not merely trust the Candidate Device Act, capability, or\noperating-system description of what is about to happen.\n\nIt should independently establish that the actual effectuation presented to it corresponds to\nthe effectuation that received authority.\n\nRelease-Form Verification\nWhere technically applicable, the authorization should commit to security-relevant\nattributes of the consequential act, including:\n\n   Requesting principal or execution context\n\n   Operation type\n\n   Protected resource or payload\n\n   Intended destination\n\n   Relevant user-intent evidence\n\n   Applicable policy and security epoch\n\n   Freshness and nonce state\n\n   The Finality Sink authorized to effectuate the act\n\nAt the final boundary, the Finality Sink verifies those bindings against the actual operation\npresented for release.\n\nFor a file export, this may require verification of the file or canonical release-form payload\nactually being exported.\n\nFor a message, it may require verification of the actual recipient and message content\npresented to the send controller.\n\nFor a payment, it may require verification of the actual amount, recipient, payment\ninstrument and transaction-specific state.\n\nFor sensor disclosure, it may require verification of the actual sensor resource, requesting\nprincipal and destination receiving the data.\n\nA mismatch causes denial.\n\nThus, validation of:\n\n   File A -> Recipient A\n\ncannot authorize:\n\n   File B -> Recipient A\n\nand authority for:\n\n   40 -> Recipient A\n\ncannot authorize:\n\n   400 -> Recipient B\n\nThe security property therefore depends not merely on validating a description of a\nfuture consequence, but on binding protected authority to the consequence that is\nactually presented at effectuation.\n\nClosing Time-of-Check/Time-of-Use Substitution\nThis addresses the time-of-check/time-of-use (TOCTOU) problem.\n\nThe system must prevent the following sequence:\n\n1. Validate one act\n\n2. Modify the act\n\n3. Reuse the earlier authorization\n\n4. Effectuate the modified act\n\nAccordingly, security-relevant attributes should be re-established, reconstructed, or\notherwise securely verified as close as technically possible to the actual effectuation\nboundary.\n\nThe Finality Sink is therefore not simply a signature-verification endpoint.\n\nIt is the last trusted enforcement boundary at which the system determines:\n\n\"Is the consequence I am about to make real the same bounded consequence that received\nprotected authority?\"\n\nIf the answer cannot be established, the operation fails closed.\n\nComplete Effectuation-Path Mediation\nThis guarantee also requires every path capable of producing the protected consequence to\nbe mediated.\n\nA secure primary path is insufficient if an alternative network, file-export, inter-process\ncommunication, extension, accessibility, driver, service, payment, sensor, or device-control\npath can produce the same consequence without equivalent finality verification.\n\nThe relevant security invariant is:\n\nNo protected consequential effect may become externally effective through an unmediated\npath.\n\nThis does not necessarily require rebuilding every application or redesigning the entire\noperating system. Enforcement may be concentrated at existing consequence-producing\nboundaries such as:\n\n   Network egress\n\n   Message dispatch\n\n   Payment authorization\n\n   Persistent commit\n\n   Sensor release\n\n   Privileged device control\n\n   Equivalent platform interfaces\n\nHowever, the architectural guarantee is only as strong as the completeness of that\nmediation.\n\nIf any alternate path can produce the same consequence without going through the Finality\nSink, that path represents a failure of the architecture.\n\nAtomic Verification, Consumption, and Effectuation\nA second critical problem is concurrency.\n\nA valid capability must not be independently presented to two execution paths before either\npath records that it has been consumed.\n\nTherefore, where single-use authority is required, verification and protected consumption\nmust be coupled sufficiently closely to prevent two successful consequences from being\nproduced from the same bounded authority.\n\nConceptually:\n\n verify authority -> reserve/consume authority -> effectuate -> commit protected state\n\nThis sequence must behave as a protected finality operation rather than as unrelated\nsoftware steps.\n\nCrash recovery, rollback, device restoration, concurrent presentation and interrupted\nexecution must not silently recreate already-consumed authority.\n\nThe exact implementation may differ across hardware and operating-system\narchitectures, but the invariant remains:\n\nOne unit of bounded execution authority must not produce more consequential effects than\nthe authority permits.\n\nTrusted Inputs and Hardware Boundaries\nHardware protection does not make an untrusted assertion true merely because the\nassertion is delivered to protected hardware.\n\nIf an untrusted operating-system component states:\n\n\"This payload is File A and the destination is Alice,\"\n\nthe protected domain should not treat that statement alone as proof of those facts.\n\nLoad-bearing attributes should therefore originate from:\n\n   Trusted measurements\n\n   Protected state\n\n   Cryptographically bound evidence\n\n   Information that the protected component or Finality Sink can independently establish\n   or reconstruct\n\nThis distinction is fundamental:\n\nProtected verification of untrusted metadata is not equivalent to protected verification of\nthe underlying reality.\n\nThe architecture therefore minimizes the facts that must simply be trusted and maximizes\nthe facts that can be independently established at validation and finality.\n\nWhat the Architecture Does Not Claim\nThis architecture does not claim that:\n\n   Hardware is impossible to compromise\n\n   User intent can always be perfectly inferred\n\n   Every operating system already exposes all required enforcement boundaries\n\n   Cryptography by itself establishes regulatory compliance\n\nIt instead proposes a narrower security property:\n\nAn AI-generated request does not obtain consequential authority merely because the AI is\nauthenticated, trusted, installed, permitted, or capable of generating a valid instruction.\n\nThe consequential act remains non-effective until bounded authority for that act is\nestablished and verified at the boundary where the consequence can become real.\n\nThe practical strength of that property depends on correct implementation of:\n\n   Protected validation\n\n   Trustworthy attribute derivation\n\n   Complete effectuation-path mediation\n\n   Atomic authority consumption\n\n   Rollback-resistant state\n\n   Revocation enforcement\n\n    Independent final verification\n\nThese conditions are engineering requirements, not assumptions that may be omitted.\n\n     Practical Implementation Requirements\nFor this architecture to be effective, the following must be true:\n\n1. The Secure Enclave (or protected domain) must be hardware-rooted. Software-only\n    enforcement is insufficient.\n\n2. The Finality Sink must be present on every real effectuation path. If there is an\n    alternative message-send path, network-export path, sensor-release path, or payment\n    path that bypasses the Finality Sink, the architecture fails.\n\n3. The nonce and state management must be atomic and protected. If consumption\n    state can be replayed or corrupted, the architecture fails.\n\n4. User intent capture must be cryptographically strong. Biometric verification, secure\n    screen confirmation, or equivalent must be used-not assumptions about user state.\n\n5. Revocation must be checked at both validation and effectuation boundaries. If\n    revocation status is stale or skipped, the architecture fails.\n\n6. The receipt chain must be append-only and tamper-resistant. If receipts can be\n    deleted, altered, or bypassed, audit integrity is lost.\n\n7. The policy and authority state must be versioned and checked. If policy changes are\n    not reflected in validation, old rules could be used to authorize new actions.\n\nThese are not aspirational; they are load-bearing. If any one fails, the architecture weakens\nsignificantly.\n\n     Performance and Battery Considerations\nThe architecture introduces cryptographic operations (hashing, signing, capability\nverification, nonce management) at the protected-validation and finality boundaries. A\nrealistic assessment of battery impact requires understanding both where cryptography\noccurs and how frequently.\n\nWhere Cryptography Occurs\nProtected Validation (PREPARE_AUTHORITY):\n\n   Verify requesting principal identity\n\n   Establish and bind resource attributes\n\n   Establish and bind destination attributes\n\n   Verify user intent cryptographically\n\n   Commit validation attributes to LAVR\n\n   Create non-bearer capability with cryptographic binding\n\nEstimated time per request: 10-15 milliseconds on modern hardware (Secure Enclave, A-\nseries processor)\n\nFinality Sink Verification (FINALIZE):\n\n   Authenticate capability signature\n\n   Authenticate LAVR signature\n\n   Reconstruct and compare load-bearing attributes\n\n   Re-check revocation status\n\n   Atomically consume nonce/state\n\nEstimated time per effectuation: 5-8 milliseconds on modern hardware\n\nFrequency and Scope\nCritical insight: These operations occur ONCE per sensitive action, not continuously or\nper-byte.\n\nTypical usage patterns:\n\n   Messages: 5-20 per hour = 50-300ms overhead per hour\n\n   File exports: 2-5 per day = 40-100ms overhead per day\n\n   Payments: 2-5 per week = 30-75ms overhead per week\n\n   Sensor access: Gated once at boundary; streaming data does not re-verify per-sample\n\nOrder of magnitude: The cryptographic overhead represents less than 0.01% of device\nactivity under typical usage.\n\nBattery Impact Comparison\nExisting iPhone cryptographic operations (baseline):\n\n   Face ID verification per unlock: ~100-150ms\n\n   Payment authorization (Apple Pay): ~50-100ms\n\n   Keychain unlock: ~10-30ms\n\n   Certificate validation on HTTPS: ~5-20ms per connection\n\nProposed architecture per operation:\n\n   Message send authorization: ~15-20ms\n\n   File export authorization: ~20-25ms\n\n   Payment authorization: ~20-30ms\n\nResult: The proposed architecture operates at the same scale and frequency as existing\niPhone security mechanisms. No measurable increase in battery drain is expected.\n\nWhy Battery Drain Is Not a First-Order Problem\n1. The Secure Enclave is designed for this workload. It already performs continuous or\n   frequent cryptographic operations (Face ID, biometric verification, Keychain access,\n   payment processing). Adding bounded, infrequent authorization operations fits within its\n   design envelope.\n\n2. UI cost exceeds cryptographic cost by 100-1000x. The battery drain from displaying\n   a secure confirmation screen, waiting for user interaction, and keeping the screen active\n   is orders of magnitude larger than the cryptographic computation. The user's interaction\n   time dominates.\n\n3. Cryptographic operations are brief and hardware-accelerated. Modern mobile\n   processors include cryptographic accelerators (AES-NI, SHA acceleration, elliptic curve\n   acceleration). Operations complete in milliseconds, not seconds.\n\n4. No per-byte or per-sample cryptography. The architecture does not encrypt or sign\n   every byte of a file or every sensor sample. Cryptography occurs at the boundary where\n   authority is validated and released, not on the data stream itself.\n\n5. Operations are asynchronous. The Secure Enclave performs validation and\n   LAVR/capability creation without blocking the main processor. Main processor activity is\n   not suspended during these operations.\n\nWhere Battery Risk COULD Arise (Poor Implementation)\nThese risks are implementation-level, not architectural:\n\n   Synchronous blocking on Secure Enclave: If main processor waits for Secure Enclave\n\n   completion instead of using async callbacks, battery drain increases.\n\n   Continuous or frequent revocation checks to remote server: If revocation status is\n   queried remotely for every action, network cost dominates (and increases battery drain\n   by 10-100x compared to crypto cost).\n\n   Redundant or unnecessary hash operations: Computing the same commitment\n   multiple times wastes energy.\n\n   Failing to use hardware acceleration: Performing elliptic curve operations in software\n   instead of using hardware accelerators increases computational cost 100-1000x.\n\n   Per-sample verification of streaming data: If sensor data is verified sample-by-\n   sample instead of gated once at the boundary, cryptographic cost explodes.\n\nImplementation Optimizations (If Needed)\nIf performance testing reveals unexpected overhead, the following optimizations are\navailable:\n\n1. Batch verification: Group multiple nonce or capability verifications into a single\n   operation.\n\n2. Cached revocation status: Cache revocation epochs locally for hours or days; update\n   via background sync rather than synchronous checks.\n\n3. Asynchronous processing: Offload LAVR/capability creation to Secure Enclave\n   background queue; use async callbacks rather than blocking.\n\n4. Hardware acceleration: Explicitly use cryptographic accelerators (AES, SHA, ECC)\n   available on modern mobile processors; avoid software implementations.\n\n5. Stateless verification where possible: Use time-based tokens or cryptographic\n   accumulator techniques that minimize mutable state updates.\n\n6. Pipelined Finality Sink verification: If multiple Finality Sinks receive capabilities in\n   sequence, perform signature verification in parallel rather than serially.\n\nMeasurement and Monitoring\nBefore deployment, the battery impact should be measured empirically:\n\n   Baseline: Measure iPhone battery drain on representative usage (100 messages, 10 file\n   exports, 5 payments per day over 24 hours).\n\n   With architecture: Run the same usage patterns through the protected-validation and\n   finality-sink code paths; measure battery drain.\n\n   Comparison: Quantify the difference. Expected result: unmeasurable or <1%\n   difference under normal usage.\n\n   Stress test: Measure at high scale (1,000 actions per hour) to identify any pathological\n   cases.\n\nConclusion on Performance\nThe battery impact of this architecture is expected to be negligible under typical\nusage patterns and comparable to existing iPhone security mechanisms (Face ID,\npayment authorization, Keychain access). The larger design concern is not cryptographic\noverhead but rather ensuring that the Secure Enclave, Finality Sink, and nonce/state\nmanagement are correctly implemented and do not become performance bottlenecks.\n\nThe architectural property is sound; implementation efficiency is an engineering\noptimization task.\n\n    Processor and Latency Considerations\nThe architecture introduces validation and verification steps in the execution path of\nsensitive operations. The question is: does this measurably slow down the user experience?\n\nWhere Latency Is Introduced\nProtected Validation (PREPARE_AUTHORITY):\n\n   Verify requesting principal: ~0.1-1ms (hash table lookup, code signature validation)\n\n   Establish resource binding: ~0.5-2ms (file metadata, pointer validation)\n\n   Establish destination binding: ~0.5-2ms (contact/recipient validation)\n\n   Verify user intent: ~1-3ms (biometric verification or secure screen confirmation already\n   shown)\n\n   Verify policy and epoch: ~0.1-1ms (in-memory state check)\n\n   Create LAVR commitment: ~2-5ms (hash + sign)\n\n   Create capability: ~2-5ms (encrypt binding, sign)\n\nTotal time in critical path: ~10-15 milliseconds\n\nFinality Sink Verification (FINALIZE):\n\n   Authenticate capability: ~1-2ms (signature verification)\n\n   Authenticate LAVR: ~1-2ms (signature verification)\n\n   Reconstruct attributes: ~0.5-1ms (hash comparison)\n\n   Consume nonce/state: ~0.1-1ms (atomic state update)\n\nTotal time in critical path: ~5-8 milliseconds\n\nWhen Latency Is Visible\nCritical distinction: Most of the validation time occurs BEFORE the user sees any\ndelay.\n\nMessage send workflow:\n\n1. User composes message (user input time: ~1-30 seconds)\n\n2. User taps \"Send\"\n\n3. Protected validation begins (~10-15ms)\n\n4. If validation succeeds, secure screen confirmation is shown to user (user interaction\n   time: ~0.5-5 seconds)\n\n5. User confirms via biometric or explicit approval\n\n6. Capability is issued\n\n7. Message-send Finality Sink verifies capability (~5-8ms)\n\n8. Message is sent to network (~100-500ms for network latency)\n\n9. User sees \"message sent\"\n\nWhere does the 10-15ms validation occur?\n\n   Before the secure screen is shown (user doesn't perceive this)\n\n   Or asynchronously in parallel with secure screen display\n\nWhere does the 5-8ms finality check occur?\n\n   After user has approved (during network transmission)\n\n   Or asynchronously without blocking the UI\n\nUser-perceptible latency = UI confirmation time + network latency, NOT cryptographic\nvalidation time.\n\nLatency Impact Comparison\n\nTypical latencies in smartphone workflows:\n\n Operation                              Latency           Notes\n\n User biometric (Face ID)               100-200ms         Already part of user workflow\n\n Network request (4G/5G)                100-500ms         Already dominant cost\n\n Disk read (SSD)                        1-10ms            File system access\n\n Database query (in-memory)             1-5ms             Existing app operations\n\n Cryptographic validation               10-15ms           Proposed addition\n\n Finality Sink check                    5-8ms             Proposed addition\n\n Secure screen display/interaction      500-5000ms        Already part of user workflow\n\nResult: Cryptographic validation (10-15ms) is comparable to disk I/O and database queries,\nand negligible compared to network latency and user interaction time.\n\nProcessor Utilization\nKey insight: Cryptographic operations are brief and can be parallelized.\n\nModern mobile processors have multiple cores:\n\n   A-series: 6-8 cores (performance + efficiency cores)\n\n   Snapdragon: 8 cores (performance + efficiency cores)\n\n   MediaTek: 8 cores (performance + efficiency cores)\n\nThe Secure Enclave performs validation in parallel with main processor:\n\n   User is interacting with UI on main processor (high-frequency core, ~2-3GHz)\n\n   Protected validation runs on Secure Enclave (coprocessor, dedicated cryptographic\n   accelerators)\n\n   No contention; no slowdown of user-facing operations\n\nIf finality verification runs on a background core:\n\n   Main processor continues with user interaction\n\n   Finality check completes by the time message reaches network boundary\n\n   No user-visible delay\n\nWhere Processor Slowdown COULD Arise (Poor Implementation)\nThese risks are implementation-level, not architectural:\n\n1. Synchronous blocking on validation: If the main processor blocks and waits for\n   Secure Enclave validation to complete before showing the confirmation screen, user\n   perceives ~15ms delay.\n\n2. Performing cryptography on main processor: If elliptic curve or SHA operations run\n   on the main processor (not Secure Enclave or hardware accelerators), other tasks are\n   starved and slowdown becomes visible.\n\n3. Sequential processing: If finality sink verification happens synchronously before\n   sending the message (rather than asynchronously after user confirms), network latency\n   compounds the delay.\n\n4. Lock contention on nonce/state: If multiple threads contend for the same nonce or\n   state update lock, finality verification serializes and causes measurable delay.\n\n5. Inefficient attribute reconstruction: If the Finality Sink reconstructs load-bearing\n   attributes by walking large data structures or performing expensive lookups, the ~1ms\n   reconstruction time becomes ~50-100ms.\n\n6. No hardware acceleration: If signature verification uses software implementations\n   instead of hardware ECC accelerators, the ~1-2ms per signature becomes ~20-50ms.\n\nImplementation Optimizations (If Needed)\n1. Asynchronous validation: Offload PREPARE_AUTHORITY to Secure Enclave\n   background queue; show secure screen immediately while validation completes; cancel\n   or retry if validation fails.\n\n2. Pipelined finality checks: Begin finality verification as soon as capability is issued;\n   complete in parallel with user confirmation interaction; fail before network transmission.\n\n3. Hardware-accelerated cryptography: Use ECC and SHA accelerators on modern\n   mobile processors; delegate to Secure Enclave coprocessor (never main processor).\n\n4. Efficient attribute indexing: Cache or index load-bearing attributes (file fingerprints,\n   recipient hashes, policy epochs) so RECONSTRUCT operation is O(1) lookup, not O(n)\n   scan.\n\n5. Lock-free state management: Use atomic operations or compare-and-swap for\n   nonce/state consumption to avoid blocking on contended locks.\n\n6. Early validation: Perform cheap validation checks (nonce freshness, expiry) early; defer\n   expensive checks (revocation, policy verification) to finality if possible.\n\nUser-Perceptible Latency Scenarios\nScenario 1: Message send (most common)\n\n   User taps send\n\n   Secure screen shown (500-2000ms, user reads and taps confirm)\n\n   Crypto validation happens in background (~10-15ms, masked by UI)\n\n   Message sent to network (~100-500ms)\n\n   User sees \"message sent\"\n\n   Total user-perceptible latency: 500-2500ms (dominated by UI and network, not\n   crypto)\n\nScenario 2: File export with immediate finality\n\n   User confirms file export\n\n   Protected validation runs (10-15ms, happens before UI)\n\n   Finality Sink verification runs in background (~5-8ms)\n\n   File is encrypted and transmitted to network (~500-5000ms for large file)\n\n   User sees \"export complete\"\n\n   Total user-perceptible latency: 500-5000ms (dominated by encryption and\n   network, not validation)\n\nScenario 3: Payment authorization\n\n   User taps pay\n\n   Secure screen shown (500-2000ms, user confirms)\n\n   Protected validation happens in background (10-15ms, masked by UI)\n\n   Capability issued\n\n   Payment processor verifies capability (5-8ms)\n\n   Payment network processes transaction (~500-2000ms)\n\n   User sees confirmation\n\n   Total user-perceptible latency: 500-4000ms (dominated by network and payment\n   processing, not crypto)\n\nScenario 4: Rapid-fire user actions (edge case)\n\n   User sends 5 messages in quick succession (1 message per 2 seconds)\n\n   Each message triggers validation (~10-15ms)\n\n   If validation is asynchronous, user perceives no additional latency\n\n   If validation is synchronous and blocks, user perceives ~15ms delay per message,\n   noticeable only if they're watching closely\n\nMeasurement and Monitoring\nBefore deployment, latency impact should be measured empirically:\n\n   Baseline: Measure end-to-end latency for representative operations (message send,\n   file export, payment) without proposed architecture.\n\n   With architecture: Measure same operations with protected-validation and finality-sink\n   code paths.\n\n   Breakdown: Separately measure validation time, finality check time, UI time, and\n   network time.\n\n   User perception: Conduct usability testing to determine if users notice any difference\n   (perceptible latency threshold is ~100ms for interactive operations).\n\n   Stress test: Measure at high scale (100 rapid actions per minute) to identify\n   serialization bottlenecks.\n\nExpected result: User-perceptible latency unchanged or <50ms additional delay\n(imperceptible to most users).\n\nProcessor Architecture Dependency\nDifferent mobile platforms have different processor architectures:\n\nApple (A-series):\n\n   Dedicated Secure Enclave coprocessor\n\n   Hardware cryptographic accelerators (AES, SHA, ECC)\n\n   Async callbacks from Secure Enclave to main processor\n\n   Expected additional latency: minimal (<1ms user-perceptible)\n\nAndroid (Qualcomm, MediaTek):\n\n   Secure processor (Qualcomm Secure Processor, MediaTek Secure Enclave)\n\n   Hardware cryptographic accelerators\n\n   May require inter-processor communication (IPC)\n\n   Expected additional latency: minimal to moderate (1-10ms user-perceptible, depending\n   on IPC efficiency)\n\nGeneric/RISC-V:\n\n   May not have dedicated secure coprocessor\n\n   Cryptographic operations may run on main processor\n\n   Lock contention possible if validation competes for processor resources\n\n   Expected additional latency: moderate (10-50ms user-perceptible)\n\nRecommendation: Implement on platforms with hardware-isolated Secure Enclave and\ncryptographic accelerators (Apple, high-end Qualcomm, high-end MediaTek) first; optimize\nfor broader platforms later.\n\nConclusion on Latency\nUnder typical usage patterns and with asynchronous processing, the additional\nlatency introduced by this architecture is imperceptible to users.\n\nThe 10-15ms validation and 5-8ms finality checks are dwarfed by:\n\n   UI confirmation time (500-5000ms)\n\n   Network latency (100-500ms for messages/payments, 500-5000ms for file transfers)\n\n   User interaction time (1-30 seconds for composition)\n\nThe architectural property is sound; latency is an implementation and platform-\nspecific optimization task.\n\nCritical implementation requirement: Validation and finality checks must be\nasynchronous or offloaded to coprocessors. Synchronous blocking on the main\nprocessor would produce user-perceptible slowdown and must be avoided.\n\n    Memory and Device Stability\nThe architecture creates and verifies several data structures (Candidate Device Act, LAVR,\ncapability, nonce/state). The question is: does this consume excessive RAM, cause memory\n\npressure, or create conditions for device hangs?\n\nWhere Memory Is Used\nPer-request memory overhead:\n\nCandidate Device Act:\n\n   Requester ID: 32 bytes\n\n   Operation type: 8 bytes\n\n   Resource identifier/fingerprint: 32 bytes\n\n   Destination/recipient: 64 bytes (email, contact ID, payment account)\n\n   User-intent evidence: 64 bytes (biometric data reference, secure screen hash)\n\n   Nonce: 16 bytes\n\n   Policy version: 8 bytes\n\n   Security epoch: 8 bytes\n\n   Timestamp: 8 bytes\n\n   Additional metadata: 64 bytes\n\nSubtotal: ~300 bytes per Candidate Device Act\n\nLAVR (Protected Validation Receipt):\n\n   Validation commitment hash: 32 bytes\n\n   Nonce reference: 16 bytes\n\n   Policy version: 8 bytes\n\n   Security epoch: 8 bytes\n\n   Finality Sink identifier: 32 bytes\n\n   Signature: 64 bytes (ECDSA P-256)\n\n   Timestamp: 8 bytes\n\n   Additional metadata: 64 bytes\n\nSubtotal: ~232 bytes per LAVR\n\nNon-bearer Capability:\n\n   Validation commitment hash: 32 bytes\n\n   LAVR reference: 32 bytes\n\n   Nonce: 16 bytes\n\n   Finality Sink identifier: 32 bytes\n\n   Expiry timestamp: 8 bytes\n\n   Effect count: 8 bytes\n\n   Signature: 64 bytes\n\n   Additional metadata: 32 bytes\n\nSubtotal: ~224 bytes per capability\n\nNonce/State Entry:\n\n   Nonce: 16 bytes\n\n   Consumption state (consumed/reserved): 8 bytes\n\n   Timestamp: 8 bytes\n\n   Associated capability ID: 32 bytes\n\n   Revocation flag: 1 byte\n\n   Security epoch: 8 bytes\n\nSubtotal: ~73 bytes per nonce entry\n\nTotal RAM per operation (end-to-end): ~300 + 232 + 224 + 73 = ~829 bytes\n\nLifetime of Data Structures\nCritical insight: These structures are temporary, not persistent.\n\nCandidate Device Act:\n\n   Created when request arrives\n\n   Discarded after LAVR creation (if validation fails) OR after capability is issued (if\n   validation succeeds)\n\n   Lifetime: ~10-15ms (duration of validation)\n\n   Storage: Transient, stack or temporary heap allocation\n\nLAVR:\n\n   Created after validation succeeds\n\n   Bundled with capability\n\n   Discarded after Finality Sink verification OR after expiry (typically 30-300 seconds)\n\n   Storage: Transient, temporary heap or protected state storage\n\nCapability:\n\n   Created after validation succeeds\n\n   Held in memory or passed to Finality Sink\n\n   Consumed (nonce marked used) after effectuation\n\n   Discarded after consumption\n\n   Lifetime: 30-300 seconds (user confirmation time + network transmission)\n\n   Storage: Transient, temporary heap\n\nNonce/State Entry:\n\n   Created with capability\n\n   Marked consumed after effectuation\n\n   Retained for revocation checks and audit (~1 hour to 24 hours)\n\n   Purged during periodic cleanup\n\n   Storage: Protected state storage (Secure Enclave or secure database)\n\nMemory Constraints Under Typical Usage\nTypical user workflow:\n\n   Send 10 messages per hour = 10 concurrent operations at peak\n\n   Each operation: ~829 bytes RAM\n\n   Peak RAM for in-flight operations: ~10  829 bytes = ~8.3 KB\n\nAdd nonce/state entries (retained for 24 hours):\n\n   10 messages/hour  24 hours = 240 entries per day\n\n   Each entry: ~73 bytes\n\n   Daily nonce/state storage: ~17.5 KB\n\nAdd LAVR receipts (retained for 7 days for audit):\n\n   240 entries  7 days = 1,680 entries\n\n   Each LAVR: ~232 bytes\n\n   Weekly LAVR storage: ~390 KB\n\nTotal memory footprint for typical user:\n\n   In-flight operations: ~8 KB (transient, released immediately)\n\n   Daily nonce/state: ~17.5 KB (grows, cleaned up after 24 hours)\n\n   Weekly LAVR: ~390 KB (grows, cleaned up after 7 days)\n\n   Total: ~415 KB\n\nComparison to iPhone baselines:\n\n   iPhone 15 RAM: 8 GB = 8,000,000 KB\n\n   Proposed architecture overhead: 415 KB\n\n   Percentage: 0.005% of available RAM\n\nWhere Memory Pressure COULD Arise (Poor Implementation)\nThese risks are implementation-level, not architectural:\n\n1. Unbounded nonce/state accumulation: If nonces and state entries are never garbage-\n   collected (no expiry, no cleanup), memory grows without bound. After 1 month of typical\n   usage, could consume tens of megabytes.\n\n2. Persistent Candidate Device Acts: If rejected requests keep Candidate Device Acts in\n   memory (e.g., for audit), and no cleanup policy exists, memory pressure grows.\n\n3. Large LAVR storage: If LAVR receipts are persisted to disk but never pruned, storage\n   grows unbounded. For a power user (1,000 actions per day), receipts could consume\n   232 KB/day = 84.8 MB/year.\n\n4. Revocation list explosion: If the revocation list (set of all revoked capabilities) is stored\n   in RAM without compression or pruning, it could grow unbounded.\n\n5. Concurrent operation storms: If the system receives 10,000 requests per second\n   (DDOS or malicious app), and each creates a temporary Candidate Device Act in RAM,\n   peak memory could spike to ~8.3 MB. If cleanup is delayed, memory pressure\n\n   accumulates.\n\n6. No memory pooling: If each operation allocates fresh memory and doesn't use memory\n   pools or pre-allocation, fragmentation reduces effective available RAM.\n\n7. Infinite loops in validation: If a validation check hangs or loops (e.g., revocation check\n   against a slow or unavailable service), memory is held until timeout expires.\n\nCrash Recovery and State Consistency\nConcern: If the device crashes or hangs while a capability is in flight, could\nnonce/state be corrupted, lost, or duplicated?\n\nAnswer: This is addressed by atomic finality and protected state.\n\nScenario: Device crashes after LAVR is committed but before capability is consumed.\n\n1. User sends message; validation succeeds; LAVR committed to protected storage\n\n2. Capability issued and passed to message-send Finality Sink\n\n3. Device crashes before message-send Finality Sink atomically consumes the nonce\n\nOn device recovery:\n\n   Protected state (LAVR, nonce/state entries) is recovered from persistent protected\n   storage\n\n   Capability is lost (not persisted, only transient)\n\n   Message-send Finality Sink checks nonce status: not consumed\n\n   Capability must be re-issued OR user must re-approve\n\n   Message is NOT sent twice (nonce prevents replay)\n\nResult: No corruption, no duplicate effectuation. The atomicity of the finality operation\nprevents the nonce from being consumed without the effect occurring.\n\nImplementation Optimizations (If Needed)\n1. Nonce/state garbage collection: Implement background cleanup task that purges\n   expired nonces (>24 hours old) daily.\n\n2. LAVR pruning: Implement retention policy: keep LAVR for 7 days for audit, then delete.\n   Compress old LAVR entries (archive to disk if needed for regulatory compliance).\n\n3. Revocation list compression: Use bloom filters or cryptographic accumulators instead\n   of explicit lists to reduce revocation check memory footprint.\n\n4. Memory pooling: Pre-allocate fixed-size memory pools for Candidate Device Acts,\n   capabilities, and LAVR to reduce fragmentation.\n\n5. Transient cleanup: Ensure Candidate Device Acts are freed immediately after\n   validation, not held until garbage collection.\n\n6. Async cleanup: Move garbage collection and pruning to background thread so main\n   processor is not blocked.\n\n7. Rate limiting on concurrent operations: If system detects more than N in-flight\n   operations, reject additional requests until some complete. Prevents memory exhaustion\n   under DDOS.\n\nDevice Hang Scenarios\nConcern: Could the architecture cause the device to freeze or hang?\n\nScenario 1: Validation takes too long\n\n   User sends message; validation hangs on revocation check (service unavailable)\n\n   Main processor blocked waiting for result\n\n   UI becomes unresponsive\n\nPrevention:\n\n   Validation must have timeout (e.g., 5 seconds)\n\n   On timeout, fail closed: DENY the operation\n\n   Never leave user with hanging operation\n\nScenario 2: Memory exhaustion causes out-of-memory (OOM) crash\n\n   Device accumulates LAVR, nonces, and state without cleanup\n\n   After weeks of heavy usage, allocated memory exhausted\n\n   iOS kills app or kernel panics\n\nPrevention:\n\n   Implement mandatory garbage collection (>1 month, purge all LAVR)\n\n   Implement emergency cleanup (if free RAM <100MB, purge LAVR and old nonces\n   immediately)\n\n   Monitor memory usage and alert if approaching threshold\n\nScenario 3: Lock contention on nonce/state causes deadlock\n\n   Multiple threads attempt to consume the same nonce simultaneously\n\n   Lock on nonce/state entry is held too long\n\n   Other threads starve; device appears hung\n\nPrevention:\n\n   Use lock-free algorithms (compare-and-swap, atomic operations) for nonce\n   consumption\n\n   Keep critical section duration <1ms\n\n   Never hold locks across I/O operations\n\nScenario 4: Revocation check against remote service blocks finality\n\n   Finality Sink must check revocation before effectuating\n\n   Revocation check requires network round-trip (~100-500ms)\n\n   If network is slow, finality blocks and user perceives hang\n\nPrevention:\n\n   Cache revocation status locally; update asynchronously\n\n   Use cached status for finality check (fail-safe: conservative default if cache is stale)\n\n   Perform network-based revocation check asynchronously after effectuation (for audit,\n   not for authorization)\n\nMeasurement and Monitoring\nBefore deployment, memory and stability impact should be measured empirically:\n\n   Memory baseline: Measure RAM usage during typical usage (100 messages, 10 file\n   exports, 5 payments over 24 hours) without proposed architecture.\n\n   With architecture: Same test with protected-validation and finality-sink enabled.\n   Measure peak RAM, steady-state RAM, and garbage collection overhead.\n\n   Long-duration test: Run device for 7 days of heavy usage (1,000 actions per day).\n   Monitor for memory leaks, OOM crashes, or hangs.\n\n   Stress test: Trigger 100 rapid operations per minute for 1 hour. Measure peak memory\n   and identify serialization bottlenecks.\n\n   Crash recovery test: Simulate device crashes at various points (during validation,\n   during finality, after consumption). Recover and verify nonce consistency.\n\nExpected result:\n\n   Peak RAM increase: <10 MB (undetectable on 8 GB device)\n\n   Steady-state RAM: <500 KB (0.006% of device RAM)\n\n   OOM crashes: none (with proper garbage collection)\n\n   Hangs: none (with timeouts and lock-free design)\n\nProcessor Core Assignment\nModern iOS/Android assign operations to different cores for stability:\n\n   Main UI thread: Responsive to user input; must not be blocked\n\n   Background thread: Validation, LAVR creation, state updates\n\n   Secure Enclave: Cryptographic operations, protected state management\n\n   Network thread: Network requests, asynchronous I/O\n\nOptimal assignment:\n\n   Candidate Device Act creation: Main thread or background (transient, <1ms)\n\n   Protected validation: Secure Enclave (coprocessor, no contention)\n\n   LAVR/capability creation: Secure Enclave (coprocessor)\n\n   Finality Sink verification: Background thread or Secure Enclave\n\n   Nonce consumption: Protected state (atomic, no blocking)\n\n   Revocation check: Background thread with timeout\n\nResult: No single core is overloaded; no core contention; no hangs.\n\nConclusion on Memory and Stability\nUnder typical usage patterns and with proper implementation (garbage collection,\ntimeouts, lock-free design, async processing), the architecture does not introduce\nmeasurable memory pressure or stability issues.\n\nMemory overhead is bounded:\n\n   Per-operation: ~829 bytes (transient)\n\n   Persistent state: ~415 KB for typical daily usage\n\n   Percentage of device RAM: <0.01%\n\nDevice hang risk is mitigated by:\n\n   Timeout mechanisms on validation\n\n   Mandatory garbage collection\n\n   Lock-free or short-critical-section state updates\n\n   Async processing to avoid main thread blocking\n\n   Rate limiting on concurrent operations\n\nThe architectural property is sound; memory management and crash recovery are\nengineering requirements.\n\nCritical implementation requirements:\n\n1. Validation must timeout (fail-closed on slow services)\n\n2. Garbage collection must be mandatory and periodic\n\n3. Nonce/state updates must be atomic and lock-free\n\n4. Main thread must not block on validation or revocation checks\n\n5. Device recovery must restore nonce/state consistently\n\n    What This Architecture Does NOT Solve: Acknowledged\nLimitations\n      *The architecture is deployable incrementally on existing platforms. Hardware\n   redesign is not a prerequisite for obtaining meaningful execution-finality\n   protection; it may be required only where the desired assurance level demands\n   demonstrable mediation of every relevant hardware and firmware effectuation\n   path.\n\nThis section explicitly addresses the three most serious engineering objections. The\narchitecture has genuine limitations that affect the strength of security guarantees in\nparticular threat models. These limitations do not prevent deployment on existing hardware;\nthey distinguish between practical protection at mediated boundaries and mathematical\ncompleteness against hardware-level bypass.\n\n    Limitation 1: Attested Egress Completeness-Assurance Strength vs.\nPractical Protection\nThe distinction: The architecture can provide practical protection at identified CPU-\nmediated consequence-producing boundaries (message send, file export, payment, etc.).\nHowever, proving that NO unmediated path exists around the Finality Sink requires complete\nmediation of every hardware pathway, which is unachievable on existing systems.\n\nWhy: Modern System-on-Chips (SoCs) have deeply complex and often undocumented\nhardware pathways:\n\n   Direct Memory Access (DMA) engines can access main memory without going\n   through the CPU or Finality Sink\n\n   Proprietary baseband controllers (cellular modem) run closed-source firmware and\n   have independent access to network I/O\n\n   Coprocessors (GPU, media engines, neural processing units) have direct memory\n   access and may bypass CPU-level controls\n\n   Vendor firmware blobs (WiFi, Bluetooth, storage controllers) execute with elevated\n   privileges and often without source code visibility\n\n   Side-channel paths (shared caches, memory timing, thermal channels) could\n   potentially leak data without crossing monitored egress boundaries\n\nWhat this means for deployment:\n\n   Practical protection is achievable: Protecting message send, file export, and payment\n   through CPU-mediated Finality Sinks prevents ordinary application-level and privilege-\n   escalation attacks.\n\n   Complete assurance is not achievable: If the threat model includes compromised\n   DMA engines, baseband firmware, or peripheral controllers, existing hardware cannot\n   establish absolute closure.\n\nExample of practical protection: An attacker who compromises the message-composition\nassistant cannot use that compromise to send messages through the message-send Finality\nSink without satisfying validation. This is practically useful even if a hypothetical baseband\ncompromise could potentially bypass the message-send pathway entirely.\n\nExample of assurance limitation: An attacker who controls the WiFi firmware could\ntheoretically read memory addresses containing user messages and transmit them over the\nnetwork without going through the message-send Finality Sink. Defending against this\nrequires deeper hardware integration.\n\nThe honest truth: Proving absolute mathematical closure across every physical egress path\non existing iPhone, Snapdragon, MediaTek, or RISC-V hardware is not practically achievable.\nVendors do not disclose complete memory maps, DMA routing, or firmware capabilities.\n\nThis is not a flaw in the architecture's deployability; it is a property of existing\nhardware.\n\n    Limitation 2: Maximum-Assurance Completeness-Optional\nHardware Support\nThe distinction: The architecture provides practical protection on existing hardware.\nProving complete mediation of every hardware pathway-defending against DMA bypass,\nbaseband compromise, and firmware attacks-requires deeper hardware integration and is\noptional based on threat model.\n\nWhere new hardware could help: If the threat model requires defense against\ncompromised DMA engines, baseband processors, or peripheral firmware, deeper\nintegration is valuable:\n\nOptional SoC enhancements could include:\n\n   Mandatory routing of critical egress paths through the Protected Execution Domain or\n   Finality Sink\n\n   Hardware-enforced memory protection preventing DMA engines from accessing\n   unmediated memory regions\n\n   Encrypted and authenticated inter-core communication\n\n   Cryptographic attestation of all firmware components before execution\n\n   Removal or strict mediation of undocumented firmware blobs\n\nOptional controller redesign could support:\n\n   Baseband modems that route all network I/O through the Finality Sink\n\n   Storage controllers that cannot directly access user data without validation\n\n   Peripheral controllers (WiFi, Bluetooth, USB) that cannot bypass the finality boundary\n\nWhat this means for deployment:\n\n   Deployment on existing hardware is viable today without waiting for hardware\n   changes\n\n   Stronger assurance is optional: If the threat model includes hardware-level\n   compromise, deeper integration may be appropriate\n\n   No prerequisite for baseline interoperability: The architecture provides security\n   benefit on iPhone 15 or Snapdragon 8 Gen 3 without redesign\n\nTimeline perspective: Hardware redesign is not a path for baseline deployment; it is an\noptional enhancement for higher-assurance requirements. Chip design cycles (3-5 years)\nand adoption cycles (7-10 years) are not relevant to near-term interoperability deployment.\n\nThe honest truth: Complete mediation of every hardware pathway is difficult on existing\nsystems but not required for practical protection of designated consequence-producing\nboundaries.\n\nThis is not a prerequisite for deployment; it is an optional assurance enhancement.\n\n    Limitation 3: Semantic Normalization-Software Engineering\nComplexity, Not Architectural Flaw\nThe distinction: The architecture establishes the technical mechanism (protected\nvalidation + finality verification) for enforcing execution authority. Defining which application\nintents decompose into primitives, and how to present multi-step workflows without\nusability friction, is a software engineering problem, not an architectural limitation.\n\nExample 1: The BookTrip intent\n\nUser says to assistant: \"Book a flight to Tokyo on August 25 for $500\"\n\nThe assistant must:\n\n   Query flight database (network access)\n\n   Present options to user (UI interaction)\n\n   Charge user's payment account (payment initiation)\n\n   Send confirmation email (message send)\n\n   Update airline account (cross-origin, multi-step transaction)\n\n   Synchronize with calendar (storage write)\n\nProblem: This is not a single, atomic consequence. It is a multi-step workflow with side\neffects, conditional branches, and inter-service dependencies. Mapping it to a single\n\"BookTrip\" primitive requires either:\n\n    A rigid, pre-defined workflow (blocks custom travel agents, breaks interoperability)\n\n    Decomposing it into many micro-primitives (send network request -> export file -> write\n    storage -> initiate payment), each requiring separate user approval (massive usability\n    friction)\n\n    Trusting the assistant to handle the workflow steps on its own (defeats the\n    architecture's security model)\n\nExample 2: The TransferMoney intent\n\nUser says: \"Send $100 to Alice for rent\"\n\nThe assistant must:\n\n    Identify \"Alice\" (contact resolution, could match multiple contacts)\n\n    Determine the payment method (bank account, Venmo, PayPal, etc.)\n\n    Check regulatory constraints (daily transfer limits, sanctions screening)\n\n    Execute the transfer (irreversible financial transaction)\n\n    Log for tax purposes\n\nProblem: The consequence is not \"transfer money.\" It is \"identify recipient -> select\npayment method -> comply with regulations -> transfer -> audit log.\" Each step has failure\nmodes and edge cases.\n\nExample 3: The PublishInvoice intent\n\nUser says: \"Send invoice #12345 to acme@corp.com\"\n\nThe assistant must:\n\n    Verify the invoice exists and is ready (query)\n\n    Verify the recipient email is correct (confirmation)\n\n    Generate the PDF or attach the document (computation)\n\n    Send via email (network send)\n\n    Update invoice status to \"sent\" (storage write)\n\nProblem: This looks like a simple action but involves querying, computing, validating,\nnetworking, and storage. Each substep could fail. If user says \"send the wrong invoice\", is\nthis a security flaw (assistant violated user intent) or a usability flaw (assistant did what it\nwas told)?\n\nThe honest truth: Defining which intents map cleanly to primitives, and how to decompose\ncomplex workflows without introducing usability friction or false denials, requires careful\nsoftware engineering. Different deployments may make different choices:\n\n1. Strict primitive decomposition: Each substep (query, compute, validate, transmit)\n   requires separate user approval. Stronger security, higher friction.\n\n2. Workflow templates: Pre-defined, tested workflows (BookTrip, TransferMoney) are\n   treated as single intents. Lower friction, requires upfront definition.\n\n3. Escalation to trusted service: Complex workflows are delegated to a trusted\n   intermediary service that decomposes them internally. Balances security and usability.\n\n4. Progressive disclosure: Show user the workflow structure; ask for approval at critical\n   gates (spend money, access data), not at every step. Medium friction.\n\nThis is a software engineering choice, not an architectural limitation. Different\nplatforms and use cases will optimize differently. The architecture provides the enforcement\nmechanism; the application design determines the user experience.\n\nThis is not a flaw in the architecture; it is a design decision in the implementation.\n\n    Deployment on Existing Systems and the Role of Hardware Redesign\n\n      *The architecture is deployable incrementally on existing platforms. Hardware\n   redesign is not a prerequisite for obtaining meaningful execution-finality\n   protection; it may be required only where the desired assurance level demands\n   demonstrable mediation of every relevant hardware and firmware effectuation\n   path.\n\nThe proposed architecture does not require a fundamental redesign of the operating\nsystem, application ecosystem, or device hardware as a prerequisite for practical\ndeployment.\n\nThe principal deployment objective is to introduce protected validation and execution-\nfinality enforcement at existing consequence-producing boundaries. Depending on the\nplatform, these boundaries may include:\n\n   Message dispatch\n\n   Network egress\n\n   File export\n\n   Payment authorization\n\n   Persistent-storage commit\n\n   Sensor release\n\n   Privileged device control\n\n   Equivalent system interfaces\n\nAccordingly, applications and AI assistants do not need to be completely redesigned around\na new execution environment. They may continue to perform ordinary computation,\nreasoning, content generation, workflow orchestration, and request preparation through\nexisting mechanisms. The principal architectural change occurs when a requested operation\nis capable of producing a protected external consequence.\n\nAt that point, the operation is treated as a non-effective Candidate Act. Protected\ninfrastructure validates the relevant security attributes, establishes protected validation\nevidence, and creates bounded execution authority. The relevant Finality Sink then verifies\nthat authority against the actual consequence presented for release before permitting\neffectuation.\n\nIncremental Deployment on Existing Hardware\nA practical implementation may therefore be introduced incrementally.\n\nInitial deployment may protect selected high-consequence operations:\n\n   Message transmission\n\n   File or data export\n\n   Payment initiation\n\n   Sensitive sensor disclosure\n\n   Persistent security-relevant state changes\n\n   Privileged device-control operations\n\nExisting applications may continue to use their ordinary APIs. Platform-level adapters,\nsecurity services, protected execution facilities, or controller-level enforcement\nmechanisms may translate sensitive operations into the execution-finality path.\n\nThis approach does not imply that implementation requires no platform changes.\nOperating-system frameworks, security services, drivers, controllers, APIs, or protected\nexecution components may require modification or extension so that designated\nconsequential operations cannot bypass the applicable Finality Sink.\n\nThe important distinction is between targeted integration and fundamental platform\n\nredesign.\n\nThe architecture can provide meaningful execution-finality protection through targeted\nintegration with existing systems. Replacement of the complete operating system,\napplication ecosystem, or system-on-chip is not a prerequisite for obtaining that security\nbenefit.\n\nStronger Assurance Through Deeper Hardware Integration\nA different question arises if the required security objective is not practical protection of\ndesignated consequential operations, but complete mediation of every physical path\ncapable of producing the protected consequence-including paths involving compromised\nDMA engines, baseband processors, peripheral firmware, coprocessors, or other hardware\ncomponents capable of bypassing ordinary CPU-mediated controls.\n\nExisting commercial hardware may not expose sufficient control over every such\npathway to establish complete mediation.\n\nFor deployments requiring this substantially stronger threat model, deeper hardware\nintegration-and in some implementations future SoC or controller redesign-may be\nappropriate. Such redesign could provide:\n\n   Hardware-enforced routing of all egress\n\n   Stronger DMA isolation\n\n   Authenticated controller communication\n\n   Firmware attestation\n\n   Equivalent mechanisms preventing alternative effectuation paths\n\nThis represents a higher-assurance implementation option, not a prerequisite for\ndeployment of the architecture itself.\n\nDeployment Model: Incremental, Not Sequential\nThe distinction is therefore:\n\nExisting systems: Practical execution-finality enforcement can be introduced at identified\nconsequence-producing boundaries through incremental platform integration. This is\ndeployable today.\n\nHigher-assurance systems: Additional hardware support may progressively increase the\ncompleteness of effectuation-path mediation as platforms evolve.\n\nMaximum-assurance systems: Where the security requirement includes demonstrable\n\nclosure of every relevant hardware and firmware bypass path, purpose-designed hardware\nmay ultimately be useful.\n\nThe architecture therefore does not depend on waiting for a future generation of\ndevices before providing useful security properties. Its deployment model is\nincremental: protect consequential boundaries that can be mediated today, expand\nmediation as platform integration increases, and use deeper hardware support where the\nrequired assurance level justifies it.\n\nProportional Security Claims\nThe security claim should remain proportional to the implementation.\n\nAn implementation should not claim complete effectuation-path mediation unless every\nrelevant path has actually been shown to be mediated. Where existing hardware contains\nunverified or unmediated pathways, those pathways remain part of the residual threat\nmodel.\n\nThis limitation does not prevent deployment of execution-finality controls at the pathways\nthat can be reliably mediated. It instead separates the usefulness of the architecture from\nthe strength of the assurance claim made for a particular implementation.\n\nResult: The message shifts from \"Europe must wait for new silicon\" to \"deployment can\nbegin at existing enforcement boundaries; hardware redesign is relevant only if a\ndeployment demands a stronger completeness guarantee against hardware-level bypass.\"\n\n    Honest Assessment\nThis architecture provides meaningful security improvement on existing hardware\nthrough targeted deployment at identified consequence-producing boundaries. It is\nnot a panacea; it does not solve every attack vector or every usability problem.\n\nWhat it does solve:\n\n    Prevents an untrusted third-party app from using a single, broad permission to exfiltrate\n    all user data (on mediated pathways)\n\n    Ensures that every sensitive action goes through a validation and finality gate at CPU-\n    accessible boundaries\n\n    Makes revocation possible and enforceable\n\n    Provides cryptographic audit trail of consequential actions\n\n    Distributes enforcement across multiple components (not single trust point)\n\n   Enables deployment incrementally without requiring wholesale platform redesign\n\nWhat it does NOT solve (on existing hardware):\n\n   Attacks on undocumented hardware pathways (DMA, baseband, firmware blobs) that\n   bypass CPU-mediated controls\n\n   Mathematical completeness of path closure without deeper hardware integration or SoC\n   redesign\n\n   The software engineering challenge of mapping complex, non-deterministic workflows\n   into rigid primitives\n\n   Attacks that require compromising the Secure Enclave or Protected Execution Domain\n   itself\n\nFor regulators (EDPB, DG CONNECT, EU AI Alliance): The architecture provides a\npractical path to compliant AI system interoperability on existing hardware, deployable\ntoday. It is demonstrably better than current approaches. It is not perfect. The security\nbenefit can be obtained now through targeted integration at consequence-producing\nboundaries. Stronger completeness guarantees (defending against DMA/baseband\ncompromise) are achievable through deeper hardware integration over time, not a\nprerequisite for deployment.\n\nFor platforms (Apple, Qualcomm, Google): Deployment on existing hardware provides\nmeasurable security benefit and demonstrates commitment to user control. Incremental\nintegration with existing APIs, security services, and enforcement mechanisms is achievable\nwithout platform redesign. Options for deeper hardware support can be evaluated based on\nthe required threat model, not as a prerequisite.\n\nFor the inventor: The architecture's value is as a security model and regulatory framework,\ndeployable today, with a path to stronger assurance over time. Its power comes from:\n\n1. Distributing enforcement across multiple components\n\n2. Making revocation practical and enforceable\n\n3. Proving that interoperability does not require uncontrolled delegation of authority\n\n4. Creating a deployable path for platforms to comply with regulations without sacrificing\n   security\n\n5. Enabling incremental integration without requiring wholesale platform redesign\n\nThese three limitations do not invalidate the architecture or prevent deployment. They\nclarify its scope and distinguish practical deployability from maximum-assurance\nguarantees. An honest, complete technical proposal acknowledges them upfront and\n\nseparates near-term deployment from long-term assurance strengthening.\n\n    Conclusion\nApple's security concern is valid: uncontrolled third-party execution authority on the\niPhone would create real risks of compromise, prompt injection, supply-chain attack,\nand regulatory liability.\n\nThe EU's operational constraint is valid: interoperability must not be provided at the\ncost of security or user control.\n\nThis architecture addresses both by separating participation from uncontrolled power.\n\nA third-party assistant can participate in the user's workflows and request actions. But\nparticipation is not authority. Every action is validated, every scope is narrow, every\ncapability is non-reusable and non-bearer, and every final gate is independently verified.\n\nThe security is not delegated to the third party. It is enforced by the platform.\n\nThe user is not passive. Intent is captured prospectively and remains revocable.\n\nThe regulator can audit the enforcement because it is cryptographic and hardware-\nprotected, not merely logged.\n\nThus, interoperability can be provided at the level of: \"You may request this action\nunder the same technical conditions.\"\n\nIt does not require interoperability at the level of: \"You receive unrestricted control\nover the device.\"\n\n========================================================================\nPART II - ANTICIPATORY TECHNICAL OBJECTIONS AND RESPONSES\n========================================================================\n\nTechnical Objections and Responses\nQ1. How does the Protected Execution Domain know that the Candidate Act\naccurately represents the real consequence?\n\nThe Candidate Act descriptor must not merely describe what software claims it intends to do.\nIt must function as a machine-verifiable commitment to the exact consequence that may\nlater be released.\n\nThis is necessary because the operating-system or mediation layer may participate in forming\nthe Candidate Act, while that layer is not itself trusted as the final authority for effectuation.\nIf the protected architecture merely validates a description authored by an untrusted layer, the\narchitecture risks validating a representation rather than the actual consequence.\n\nThe solution is to divide verification between two independent enforcement points:\n\nThe Protected Execution Domain validates authority over a commitment. The Finality\nSink validates that commitment against the actual consequence-producing state.\nNeither verifier alone is sufficient.\n\nThe existing disclosure already constructs a Candidate Device Act containing the requesting\napplication or agent identity, action class, resource scope, destination scope, governance or\nauthority epoch, revocation epoch, nonce, and designated Finality Sink identity, and\nmaintains the Candidate Device Act in a non-effective state before effectuation.\n\nA. The Candidate Act becomes a commitment\n\nThe Candidate Act should bind at least:\n\n      requesting application or agent identity;\n      sandbox, application measurement, or code-signature state;\n      action class;\n      resource identity;\n      resource commitment or digest;\n      destination identity;\n      destination commitment or digest;\n      user-intent object where required;\n      runtime-behavior state where applicable;\n      governance or authority epoch;\n      revocation state;\n      fresh nonce;\n      designated Finality Sink identity; and\n      designated Effectuation Boundary identity.\n\nThe Candidate Act is then canonicalized and committed through a digest or equivalent\nprotected commitment.\n\nThe important point is:\n\nThe descriptor is not trusted because it exists. It becomes useful only because its load-\nbearing attributes are later checked against the actual release state.\n\nB. Sink-side re-derivation, not sink-side trust\n\nThe Finality Sink must not simply accept fields such as resource_digest,\ndestination_digest, or payload_digest as assertions supplied by the requesting software.\n\nImmediately before effectuation, the Finality Sink should independently derive the\neffectuation-critical attributes from the actual object, payload, destination, or state transition\nthat it is about to release.\n\nFor example:\n\nFile export\n\nThe relevant digest should be derived from the actual file object, actual file version, or actual\nbytes presented at the export boundary.\n\nMessage sending\n\nThe sink should verify the actual recipient, final message payload, attachment set, and\ndestination.\n\nPayment\n\nThe protected payment boundary should verify the actual amount, currency, recipient,\naccount, transaction parameters, and finalization context.\n\nNetwork transmission\n\nThe sink should verify the actual serialized outbound resource or payload and the actual\ndestination endpoint.\n\nSensor release\n\nThe sink should bind the actual sensor buffer or stream being released to the requesting\nprotection domain.\n\nThe conceptual comparison is:\n\nAUTHORIZED_COMMITMENT =\n    HASH_CANONICAL(\n        action_class,\n        release_form_resource,\n        destination,\n        requester_identity,\n        sink_identity,\n        boundary_identity,\n        epoch,\n        nonce\n    )\n\nACTUAL_COMMITMENT =\n    HASH_CANONICAL(\n        actual_action_class,\n        actual_release_form_resource,\n        actual_destination,\n        actual_requester_identity,\n        actual_sink_identity,\n        actual_boundary_identity,\n        current_epoch,\n        nonce\n    )\n\nIF ACTUAL_COMMITMENT != AUTHORIZED_COMMITMENT:\n    FAIL_CLOSED\n\nThe existing disclosure already requires Finality Sink verification against descriptor digest,\napplication identity, assistant identity, action class, resource digest, destination digest,\nFinality Sink identity, epochs, nonce, and LAVR state. It also requires fail-closed denial\nwhen these do not match.\n\nThe strengthening is to make explicit that the Finality Sink recomputes or re-derives these\nvalues from the actual consequence-producing state, rather than merely re-reading the\nsame values originally supplied by software.\n\nC. Release-form canonicalization, not request-form canonicalization\n\nThe commitment should correspond to the post-transformation, pre-release form of the\ngoverned artifact.\n\nThis distinction is critical.\n\nBetween request formation and effectuation, data may be:\n\n       serialized;\n       compressed;\n       encoded;\n       transformed;\n       re-framed;\n       chunked;\n       wrapped;\n       encrypted;\n       combined with metadata; or\n       otherwise changed.\n\nIf the protected architecture commits only to the request-time representation, later\ntransformations may create either false mismatches or an opportunity for semantic\nsubstitution.\n\nThe preferred rule is:\n\nCommit to the last canonical or determinable representation before release, at a point\nwhere withholding remains complete.\n\nFor example:\n\nrequest object\n      v\ntransformation\n      v\nserialization\n      v\nFINAL DETERMINABLE RELEASE FORM\n      v\ncommitment / digest\n      v\nFinality Sink verification\n      v\nexternal consequence\n\nWhere a later transformation is unavoidable, such as protocol framing or transport\nencryption, the Finality Sink should be positioned on the protected side of that transformation\nand bind the last plaintext or canonical form whose identity can still be deterministically\nestablished.\n\nThis release-form distinction is also important to any prior-art argument that differentiates\nrequest-side or context-side digests from produced-output or release-side commitments.\nIf the disclosure is ambiguous about where the digest is computed, that distinction becomes\nweaker. Making release-form commitment explicit strengthens both the architecture and that\nprior-art position.\n\nD. Split verification\n\nThe architecture should therefore be understood as having two distinct verification roles:\n\nProtected Execution Domain\n\n      validates authority;\n      validates protected predicates;\n      verifies protected state;\n      verifies freshness and revocation;\n      commits validation evidence;\n      derives or authorizes the scoped capability.\n\nFinality Sink\n\n      observes the actual consequence-producing state;\n      reconstructs or derives the release-form commitment;\n      verifies the scoped capability;\n      verifies sink and boundary identity;\n      compares actual release state with the protected commitment;\n      consumes or advances authority state;\n      permits effectuation only after successful comparison.\n\nThis avoids placing impossible semantic responsibility on the PED.\n\nE. Residual semantic gap\n\nCryptographic and hardware enforcement can establish:\n\n         artifact identity;\n         resource identity;\n         requester identity;\n         destination identity;\n         sink identity;\n         boundary identity;\n         freshness;\n         policy epoch;\n         revocation state; and\n         protected authorization state.\n\nThey cannot by themselves establish higher-level meaning such as:\n\n\"This document is my medical record.\"\n\nor:\n\n\"This person is the doctor I meant.\"\n\nMeaning-level correctness must therefore come from a trusted user-intent mechanism where\nthe action class requires it.\n\nFor high-consequence classes such as:\n\n         identity disclosure;\n         credential release;\n         payment;\n         high-value transaction;\n         sensitive file export;\n         protected-data disclosure; or\n         equivalent irreversible acts,\n\na trusted-user-interface predicate should be treated as load-bearing.\n\nClaim 5 already discloses a Trusted User-Interface Finality Sink using protected display,\nsecure input, protected transaction confirmation, biometric confirmation, PIN entry, or\nequivalent trusted-user-interface mechanisms.\n\nHowever, the current independent-claim structure does not necessarily make Claim 5\nmandatory for every such class. That distinction should be preserved: technically\nrecommended strengthening is not automatically an existing independent-claim\nrequirement.\n\nQ2. How do you guarantee that there is no bypass path around the Finality\nSink?\n\nBypass closure should not depend primarily on enumerating APIs, hooks, frameworks, or\nsoftware routes.\n\nEnumeration is useful for patent coverage and design-around closure, but it does not itself\nprove technical non-bypassability.\n\nThe stronger technical rule is:\n\nThe governed consequence must be physically or cryptographically impossible to\nproduce unless the required protected enablement material is present.\n\nThe Finality Sink should therefore control something necessary for effectuation, such as:\n\n      transmit-enable authorization;\n      queue-enable value;\n      hardware-unlock value;\n      memory-window unlock value;\n      storage-commit authorization;\n      decryption key;\n      rendering key;\n      secure dispatch authorization;\n      transaction-finalization authorization;\n      actuator enablement; or\n      equivalent protected technical material.\n\nThe filed disclosure already supports capability forms including hardware-unlock values,\nqueue-enable values, memory-window unlock values, network-transmit authorization,\nstorage-commit authorization, sealed handles, release keys, and equivalent technical\nenablement conditions.\n\nThe preferred embodiment is therefore stronger than:\n\n\"Software checks whether the operation is permitted.\"\n\nIt becomes:\n\n\"The controller lacks the material required to complete the operation unless protected\nfinality has succeeded.\"\n\nConceptually:\n\nordinary software path\n        |\n\ngoverned controller\n        |\n        +-- no valid protected enablement\n        |           v\n\n         |      cannot effectuate\n         |\n         +-- valid sink-bound enablement\n                    v\n              Finality Sink\n                    v\n              external effect\n\nGoverned Egress Set\n\nFor every governed consequence class, define a Governed Egress Set:\n\nThe complete set of technical boundaries through which that consequence can leave the non-\neffective state.\n\nExamples:\n\nData egress\n\n      network transmission boundary;\n      IPC boundary;\n      shared-memory release;\n      file-provider/export boundary;\n      removable-storage commit;\n      cloud-upload boundary.\n\nVisible output\n\n      compositor;\n      trusted display release;\n      external display path;\n      protected rendering path.\n\nPhysical actuation\n\n      actuator controller;\n      radio controller;\n      device-control boundary;\n      equivalent physical-output controller.\n\nEvery member of the Governed Egress Set must either:\n\n   1. contain a Finality Sink; or\n   2. be structurally downstream of a Finality Sink and incapable of obtaining usable\n      governed material before successful verification.\n\nThis creates an auditable per-platform or per-SoC property.\n\nThe question becomes not:\n\n\"Did we remember every API?\"\n\nbut:\n\n\"Is there any technical boundary through which this consequence can become\nexternally effective without possession of valid sink-verifiable enablement?\"\n\nAlternate routes remain governed\n\nBrowser upload, sharing-sheet transfer, SDK telemetry, cloud synchronization, app-intent\nsubcalls, accessibility actions, clipboard transfer, network sockets, diagnostic upload, IPC,\nprivate-framework calls, or similar routes remain governed if they produce the same\nconsequence. The PCT already states this alternate-route principle.\n\nThe governing principle is:\n\nGovern consequences, not APIs.\n\nAdversary model\n\nThe security claim should also state what is and is not within the threat model.\n\nThe architecture may defend against compromise of:\n\n      an application;\n      AI assistant;\n      AI agent;\n      plug-in;\n      browser automation component;\n      user-space process;\n      ordinary operating-system service;\n      privileged framework;\n      automation service; or\n      alternate software route.\n\nIt should not claim to remain secure after compromise of:\n\n      the PED itself;\n      the trusted hardware root;\n      the cryptographic root of trust;\n      malicious silicon;\n      invasive physical attacks that defeat the assumed hardware security boundary.\n\nA bounded adversary model makes the bypass guarantee credible and testable.\n\nQ3. Where exactly is the first usable release boundary?\n\nThe architecture should not answer this merely by listing controllers.\n\nIt should provide a rule that generates the correct boundary even for platforms and action\nclasses not expressly listed.\n\nThe rule is:\n\nThe first usable release boundary is the last point at which the governed artifact\nremains in a canonical or determinable form and complete withholding remains\npossible, immediately before the act becomes usable, observable, transferable,\ncommitted, rendered, transmitted, disclosed, paid, stored, actuated, or otherwise\nconsequential outside the non-effective state.\n\nTwo requirements must therefore be true simultaneously:\n\nartifact identity remains determinable\nAND\ncomplete withholding remains possible\n\nIf the gate is placed earlier, an ungoverned downstream transformation may alter or complete\nthe act.\n\nIf the gate is placed later, the consequence may already have begun or the sink may no longer\nbe able to reconstruct the exact artifact being released.\n\nThe PCT already defines the Effectuation Boundary in first-use terms, and Claim 28\nexpressly refers to a first usable release boundary where the operation first becomes usable,\nobservable, transferable, committed, rendered, transmitted, disclosed, paid, stored, actuated,\nor otherwise consequential.\n\nRepresentative boundary mapping\n\n  Action class         Correct first usable release boundary        Preferred enablement\n                 outbound egress after final payload and\nMessage / email attachment assembly, before external              transmit-enable\n                 transmission\n                 first point where bytes become readable outside\nFile export                                                       export/read enablement\n                 the originating protection domain\n                 protected transaction-finalization or            protected finalization\nPayment\n                 cryptogram-generation boundary                   authorization\nProtected        compositor submission or content-decryption      decryption/render\nrendering        point immediately before usable rendering        enablement\n                 delivery from protected sensor/HAL path to\nSensor release                                                    sensor/DMA release\n                 requesting protection domain\n                 receiving application's paste/read boundary      consumer-side read\nClipboard\n                 where another principal first obtains content    enablement\n                 dispatcher handoff into the receiving protection\nApp intent / IPC                                                  dispatch authorization\n                 domain\nAccessibility    input dispatcher immediately before target-\n                                                                  injection enablement\ninjection        window delivery\n\n   Action class         Correct first usable release boundary      Preferred enablement\nAI export /        fully serialized outbound body immediately\n                                                                 transmit-enable\ntelemetry          before egress\nPersistent         commit boundary where the state first becomes storage-commit\nstorage            persistently usable                           authorization\n\nConsumer-side finality\n\nFor some classes the consequence begins at consumption rather than emission.\n\nClipboard is a useful example.\n\nWriting sensitive material into an isolated clipboard representation may not yet disclose it to\nanother principal. The disclosure occurs when another application obtains usable access to\nthat material.\n\nTherefore:\n\nWhere the consequence begins at consumption, the Finality Sink should be located at\nthe consumer-side release boundary.\n\nThe same principle may apply to:\n\n      shared memory;\n      protected buffers;\n      deferred display;\n      encrypted content;\n      staged IPC objects; or\n      other contexts where production does not itself create the governed consequence.\n\nBoundary identity must be bound\n\nThe same artifact released through different boundaries may create different consequences.\n\nTherefore the capability should bind not only:\n\n      resource;\n      destination;\n      action class;\n      nonce;\n      epoch;\n\nbut also:\n\n      Finality Sink identity; and\n      Effectuation Boundary identity.\n\nA capability valid for one boundary should fail when presented at another.\n\nFeasibility\nQ4. Can existing secure-enclave, TEE, secure-element, or equivalent protected\nhardware implement the hot path without becoming a large new trusted\nsubsystem?\n\nYes, provided the architecture keeps the protected hot path fixed and small.\n\nThe PED should not become:\n\n      a general-purpose AI engine;\n      a full policy engine;\n      a natural-language interpreter;\n      a browser engine;\n      a model-inference system;\n      a regulator-rule interpreter;\n      or a bulk-data processor.\n\nThe PED need not process the bulk payload\n\nA preferred implementation is:\n\nBulk hashing occurs at the Finality Sink, protected DMA path, crypto accelerator, or\nother trusted boundary-adjacent component. The PED primarily handles fixed-size\ncommitments and protected state.\n\nThe PED may therefore maintain only relatively small objects such as:\n\ndigest / commitment\nverification key\nsink identity\nboundary identity\nnonce\nnonce window\nmonotonic counter\ngovernance epoch\nrevocation epoch\nquota\ncapability state\nLAVR state\nprotected policy state\n\nThe PCT already permits implementation using secure enclaves, TEEs, secure elements,\nhardware security modules, protected processors, protected microcontrollers, protected\nhypervisor partitions, or equivalent hardware-rooted or cryptographically isolated\nenvironments.\n\nSymmetric verification on the ordinary hot path\n\nA useful implementation distinction is:\n\nHot-path capability verification\n\n      short-lived session key;\n      MAC or equivalent compact authentication;\n      nonce;\n      epoch;\n      sink identity;\n      boundary identity;\n      local protected-state check.\n\nDurable evidence\n\n      LAVR;\n      protected signature where required;\n      receipt continuity;\n      external audit evidence;\n      non-repudiation material.\n\nThis allows ordinary low-risk finality to use a compact local primitive while reserving\nheavier public-key operations for:\n\n      high-risk acts;\n      durable receipts;\n      external evidence;\n      attestation;\n      or events requiring stronger assurance.\n\nThe PCT supports multiple cryptographic forms rather than requiring one fixed cryptographic\nsuite.\n\nAvoid protected-world transitions where possible\n\nRepeated transitions into a protected execution environment may become more expensive\nthan the underlying cryptographic comparison itself.\n\nA preferred implementation can therefore derive short-lived sink-verification material during\npreparation:\n\nPED\n |\n | derive / provision session-scoped verification material\n\nprotected sink-local state\n |\n | compact local capability verification\n\nFinality Sink\n\nThe sink can then verify ordinary low-risk capabilities locally.\n\nA new protected-world interaction may be required only when:\n\n      the session is established;\n      the governance epoch changes;\n      revocation state changes;\n      quota is exhausted;\n      a high-risk action occurs;\n      protected state must advance;\n      trusted user confirmation is required; or\n      fresh attestation is required.\n\nThe specification already distinguishes heavier authority preparation from a compact finality\nhot path and permits pre-fetched state, cached state, capability-cache lookup, bounded\nhardware-assisted verification, and freshness checks before use.\n\nExisting protected hardware provides related primitives\n\nThe safer feasibility statement is not that existing secure hardware already implements this\nentire architecture.\n\nThe stronger and more defensible statement is:\n\nExisting protected hardware already supports closely related primitives such as\nprotected key custody, cryptographic verification, counters, attestation, sealed state,\nsecure transaction authorization, and hardware-backed isolation. The proposed\narchitecture composes such primitives into an execution-finality path.\n\nThat avoids overclaiming.\n\nPerformance figures should be treated carefully\n\nEngineering estimates such as:\n\n      single-digit-microsecond MAC verification;\n      millisecond-scale secure-element signature operations;\n      tens-of-microseconds protected-world transitions;\n      sub-100-microsecond low-risk hot paths;\n\nmay be useful as illustrative engineering targets.\n\nThey should not be stated as universal architectural guarantees unless supported by\nbenchmarking on the relevant implementation.\n\nThe stronger patent and standards position is:\n\nThe hot path is bounded, fixed-function, local where possible, and independent of\nunbounded AI reasoning or policy computation.\n\nIncremental controller extension\n\nMany Finality Sinks correspond to components that already control:\n\n       network transmission;\n       storage;\n       display;\n       IPC;\n       sensor delivery;\n       payment finalization;\n       device settings;\n       message sending; or\n       privileged dispatch.\n\nThe architectural delta is therefore:\n\nAdd sink-verifiable protected execution authority to an existing consequence-control\nboundary.\n\nThe genuinely new load-bearing relationship is the combination of:\n\nrelease-form commitment -> protected authority -> sink-local verification ->\neffectuation.\n\nQ5. How can low latency and high availability be preserved when every\nconsequential sub-action requires finality?\n\nThe unit of finality is the externally consequential or irreversible consequence, not every\nsyscall, function call, packet, fragment, token, or internal AI operation.\n\nThis distinction is essential.\n\nOne transfer can remain one Candidate Act\n\nA large transfer may be divided into many packets or fragments while remaining one\nbounded Candidate Act.\n\nThe capability may define a constrained envelope such as:\n\nresource = X\ndestination = Y\naction class = transfer\nmaximum bytes = N\nmaximum fragments = F\nvalidity window = T\nsink = Z\nboundary = B\nepoch = E\nsequence / nonce range = R\n\nThe fragments remain authorized only while they remain within that exact bounded envelope.\n\nChanging:\n\n      resource;\n      destination;\n      action class;\n      sink;\n      boundary;\n      epoch;\n      permitted byte count;\n      validity period; or\n      other load-bearing scope\n\nrequires new authority.\n\nThis preserves anti-fragmentation closure without requiring full reauthorization for every\nindividual transport fragment. Claim 32 already addresses fragmented Candidate Device Acts\nand prevents fragmentation from defeating governance.\n\nRisk-tiered finality\n\nDifferent consequence classes can receive different verification depth.\n\nLow-risk act\n\ncached protected state\n+\nlocal sink verification\n+\nfresh nonce / sequence validation\n+\ncompact authentication\n\nHigh-risk act\n\nfresh protected-state validation\n+\ntrusted-user confirmation\n+\nfresh attestation where required\n+\nstronger protected evidence\n+\nfresh capability\n\nHigher latency is easier to tolerate when a human confirmation step already exists.\n\nThe architecture should therefore avoid forcing the highest-assurance path onto every\noperation.\n\nPreparation may be speculative because preparation authorizes nothing\n\nAuthority preparation can safely occur before the final Candidate Act exists, provided that\npreparation itself does not create externally usable authority.\n\nFor example:\n\ncurrent action executing\n        |\n        +-- refresh attestation\n        +-- prefetch policy state\n        +-- verify stable app state\n        +-- prepare session key\n        +-- load current epoch\n        +-- prepare likely sink context\n\nIf the anticipated act never occurs, nothing becomes externally effective because:\n\n      no final Candidate Act commitment exists;\n      no act-specific final capability has been verified;\n      no Finality Sink has permitted effectuation.\n\nThis means the architecture's safety property also becomes a performance advantage.\n\nMulti-step AI workflows\n\nA workflow may contain:\n\nread calendar\nv\nsummarize event\nv\ndraft email\nv\nattach file\nv\nsend message\n\nInternal reasoning, planning, summarization, or drafting does not necessarily require finality\nmerely because computation occurred.\n\nFresh finality is required when a step becomes externally consequential.\n\nFor example:\n\nprotected calendar-data release\n        v\nfile export into another protection domain\n        v\nexternal message transmission\n\nEach consequence can reuse stable session, app, device, model, and policy state while\nreceiving its own:\n\n      Candidate Act commitment;\n      nonce;\n      scoped authority;\n      Finality Sink verification.\n\nThe PCT already states that a capability issued for one action class does not automatically\nextend to later consequential actions and that subsequent externally consequential operations\ninvoke their own finality sequence.\n\nAvailability\nFail-closed behavior creates a genuine availability dependency and should be addressed\nexplicitly rather than ignored.\n\nThe central rule should be:\n\nDegraded mode may shorten the validation path; it must never waive Finality Sink\nverification.\n\nThat preserves the architecture even during partial failure.\n\nOffline operation\n\nWhere permitted, the PED may issue a protected local authority lease containing:\n\n      bounded validity period;\n      allowed action classes;\n      quota;\n      monotonic counter;\n      sink identity;\n      boundary identity;\n      governance epoch;\n      revocation epoch;\n      permitted resource or destination class.\n\nThe device may continue operating while the bounded lease remains valid.\n\nConnectivity loss therefore does not itself force immediate denial.\n\nWhen the quota, time window, epoch, or protected lease state expires:\n\ndeny rather than silently broaden authority.\n\nCached local verification\n\nStable predicates may remain locally cached while freshness-sensitive state continues to be\nchecked locally.\n\nFor example:\n\n      application measurement may remain stable;\n      current nonce must remain fresh;\n\n      revocation state must remain acceptable;\n      capability must remain sink-bound;\n      boundary identity must remain correct.\n\nDelayed receipt synchronization\n\nWhere policy permits, protected receipts may be committed locally and synchronized after\nconnectivity is restored.\n\nThe receipt may be delayed externally without delaying the local protected commitment that\nmakes the finality decision auditable.\n\nFailure of remote infrastructure\n\nIf a remote policy service or remote protected component becomes unavailable, the\narchitecture may rely on already-issued bounded local authority where such authority exists.\n\nIt must not reinterpret service unavailability as authorization.\n\nThe invariant is:\n\nNO VALID SINK-VERIFIABLE AUTHORITY\n        =\nNO EFFECTUATION\n\nThe PCT already permits precomputed state, local fast-path verification, short-lived delegated\nauthority, distributed protected execution, and batching of receipt updates while preserving\nthe controlling invariant that the Candidate Device Act remains non-effective until the\napplicable Finality Sink verifies the required capability.\n\nCore Architectural Position\nThe complete answer can be reduced to five non-negotiable technical rules:\n\n1. The Candidate Act is a commitment, not merely a description.\n\nThe commitment binds the actual governed artifact, destination, requester, sink, boundary,\nfreshness state, and other load-bearing attributes.\n\n2. The PED validates authority over the commitment; the Finality Sink validates the\ncommitment against reality.\n\nThe sink re-derives the release-form state from the actual artifact it is about to externalize.\n\n3. Bypass resistance comes from withheld enablement, not from software-hook\nenumeration.\n\nEvery member of the Governed Egress Set must require protected sink-verifiable enablement\nbefore the governed consequence can occur.\n\n4. The first usable release boundary is the last point where identity remains\ndeterminable and withholding remains complete.\n\nIf the consequence begins at consumption, the sink moves to the consumer side.\n\n5. Feasibility and performance come from keeping the protected root small and\nseparating preparation from finality.\n\nThe PED governs commitments, keys, epochs, nonces, counters, receipts, and authority. Bulk\ncomputation, AI reasoning, transformation, and ordinary application processing remain\noutside the smallest trusted root.\n\nThe resulting sequence is:\n\nPROPOSED ACT\n      v\nCANONICAL / RELEASE-FORM COMMITMENT\n      v\nNON-EFFECTIVE STATE\n      v\nPED VALIDATES AUTHORITY\n      v\nLAVR / PROTECTED EVIDENCE\n      v\nSCOPED NON-BEARER CAPABILITY\n      v\nFINALITY SINK RE-DERIVES ACTUAL RELEASE STATE\n      v\nCOMMITMENT MATCH?\n\n NO            YES\n v              v\nFAIL         CONSUME /\nCLOSED       ADVANCE AUTHORITY\n                v\n           EFFECTUATE\n\nThe essential security statement is:\n\nProtected authority was granted for X, and the boundary capable of producing the\nconsequence independently proves that the operation it is actually about to release is X\nbefore the consequence becomes effective.\n\nB. Additional Technical Objections and Responses\n\nQ8. Who governs the policy bundle? If the platform operator authors the\npolicy that the PED enforces, who watches the watcher?\n\nThis is a real governance problem.\n\nA protected execution environment does not solve neutrality merely because the policy is\nenforced in hardware. If the same platform operator can define the policy bundle, sign it,\nchange it, and determine whether first-party and third-party requesters receive equivalent\ntreatment, then hardware enforcement can make an unfair policy more strongly enforceable\nrather than making it neutral.\n\nThe parity invariant therefore cannot depend only on:\n\nVALIDATE_REQUESTER_TYPE_PARITY(\n    policy_bundle = platform_supplied_policy\n)\n\nThe stronger architecture separates policy enforcement from policy provenance and\naccountability.\n\nThe PED should validate not only:\n\n\"Is this Candidate Act compliant with the current policy?\"\n\nbut also:\n\n\"Is this the authorized, externally identifiable policy version that this device is\npermitted to enforce?\"\n\nA policy bundle should therefore have a protected identity such as:\n\npolicy_bundle_digest\npolicy_version\ngovernance_epoch\nissuer_identity\nvalidity_period\napplicable_action_classes\nparity_profile\nsignature / authorization chain\n\nThe digest of that exact policy bundle should be bound into:\n\n      the protected governance state;\n      Candidate Act validation;\n      the capability;\n      and, where appropriate, the LAVR or validation evidence.\n\nThe existing disclosure already makes policy state epoch-bound, revocation-aware and\ncapable of being bound into the Candidate Act or validation evidence, and it expressly rejects\nunauthorized policy downgrade.\n\nThat is useful, but epoch integrity alone does not answer who is entitled to define the\npolicy.\n\nExternal verifiability\n\nA stronger governance implementation can add one or both of the following:\n\nMulti-party authorization\n\nThe policy profile becomes valid only when authorized by more than one relevant authority,\nfor example:\n\nplatform authorization\n        +\nindependent governance / conformity authorization\n        +\noptional enterprise / user policy component\n\nThe architecture already contemplates combined, threshold, co-signed, or jointly authorized\ncapability construction in distributed protected execution.\n\nThe same architectural principle can be applied to policy provenance where supported by the\nimplementation.\n\nExternal transparency\n\nThe policy-bundle digest, version and parity profile may be externally committed so that an\nauditor, regulator, conformity assessor, enterprise administrator, or other authorized verifier\ncan establish:\n\n      which policy was active;\n      when it became active;\n      whether it changed;\n      whether first-party and third-party acts were evaluated under the same published\n       profile;\n      whether a downgrade occurred.\n\nThe PCT already states that protected finality evidence may be independently verified rather\nthan relying solely on the platform operator's own statements.\n\nA public or permissioned policy-transparency log would strengthen that property further.\n\nIf policy-bundle co-signature or external transparency logging is not expressly supported by\nthe existing priority disclosure, it should be treated as a future implementation or\ngovernance extension, not automatically represented as an existing claim requirement.\n\nThe central principle is:\n\nThe platform may implement enforcement, but it should not be the only party capable\nof proving what rules were enforced.\n\nQ9. What prevents many individually authorized Candidate Acts from\ncomposing into an unauthorized aggregate consequence?\n\nPer-act finality alone does not solve aggregation.\n\nAn attacker may remain within the scope of every individual authorization while producing a\nprohibited cumulative effect.\n\nFor example:\n\nRead 1 -> authorized\nRead 2 -> authorized\nRead 3 -> authorized\n...\nRead 10,000 -> individually authorized\n                    v\n             aggregate exfiltration\n\nNothing in a purely stateless per-act predicate necessarily detects that the aggregate\nbehavior has crossed a security or privacy threshold.\n\nThe answer is to make protected finality stateful across acts where the action class requires it.\n\nThe PED should support a cumulative authority budget or session-level aggregate\npredicate.\n\nProtected state may be keyed to combinations such as:\n\nprincipal\n+\napplication / agent\n+\nresource class\n+\ndestination\n+\naction class\n+\nsession\n+\ntime window\n+\ngovernance epoch\n\nand maintain values such as:\n\n      cumulative bytes disclosed;\n      number of records accessed;\n      number of recipients;\n      number of external destinations;\n      number of transactions;\n      total transaction value;\n\n       sensor-duration budget;\n       query count;\n       tool-call budget;\n       cross-domain disclosure count;\n       or equivalent bounded-use state.\n\nThen:\n\nIF single_act_valid\nAND cumulative_budget_remaining:\n        permit\n        atomically decrement protected budget\nELSE:\n        deny\n\nThis is different from ordinary rate limiting.\n\nThe important property is that the budget is itself part of protected authority state and\ncannot be reset by restarting the app, changing the agent process, replaying an old capability,\nor fragmenting the operation.\n\nThe existing disclosure already contemplates quota state, monotonic counters, protected state\nadvancement and atomic consumption, so there is architectural support for this direction. It\nalso expressly addresses fragmentation under a shared aggregate descriptor.\n\nHowever, the broader threat of N independently valid acts composing into an\nunauthorized semantic aggregate should be stated explicitly.\n\nThe rule becomes:\n\nFinality may be evaluated both per act and over the protected cumulative state created\nby prior acts.\n\nQ10. How can the PED verify declared_purpose when the declared purpose\noriginates from an untrusted agent?\n\nIt cannot prove the agent's subjective intent merely by inspecting the string.\n\nThat limitation should be stated directly.\n\nA field such as:\n\ndeclared_purpose = \"send medical report to doctor\"\n\ndoes not prove:\n\n       that the agent is truthful;\n       that the actual operation serves that purpose;\n       that the recipient is actually a doctor;\n\n       that the selected file is actually the intended medical report.\n\nTherefore:\n\nDeclared purpose is a policy-selection and consistency input, not proof of semantic\nintent.\n\nThe PED may verify:\n\n       that the declared purpose is an allowed purpose class;\n       that the requested resource is permitted for that purpose class;\n       that the destination class is permitted;\n       that the action class is permitted;\n       that the user-intent object authorizes that purpose;\n       that the runtime behavior remains within the permitted execution profile.\n\nBut the string itself is not authoritative.\n\nThe PCT already says that model-generated statements, prompt text, tool plans, self-\ndeclarations and natural-language descriptions do not constitute trusted authority and may not\nsubstitute for machine-verifiable evidence.\n\nThe technically defensible formulation is:\n\nPurpose validation constrains execution to an authorized purpose class; it does not\ncryptographically prove the internal motive of an AI agent.\n\nFor high-consequence operations, declared purpose should therefore be corroborated by\nstronger predicates such as:\n\n       trusted user intent;\n       actual resource identity;\n       destination identity;\n       action class;\n       session context;\n       data classification;\n       jurisdiction condition;\n       enterprise authorization;\n       or other machine-verifiable evidence.\n\nQ11. How can a behavioral descriptor or ALF be enforced against a non-\ndeterministic AI model?\n\nThe behavioral envelope should not require the model to reproduce a deterministic token\nsequence.\n\nThat would be unrealistic for systems affected by:\n\n      sampling;\n      temperature;\n      context variation;\n      tool responses;\n      retrieval inputs;\n      model updates;\n      runtime configuration;\n      or ordinary probabilistic inference.\n\nThe architecture should separate model identity from behavioral authority.\n\nStatic or relatively stable identity\n\nALF or equivalent model identity may bind:\n\n      registered model identifier;\n      model version;\n      code-signature digest;\n      weights or protected measurement where available;\n      inference-runtime version;\n      tool-policy version;\n      retrieval configuration class;\n      safety-policy version;\n      approved plug-in or connector set.\n\nDynamic runtime descriptor\n\nThe runtime descriptor may bind observable execution properties such as:\n\n      action classes invoked;\n      tool classes used;\n      resources accessed;\n      destinations selected;\n      privilege level requested;\n      data classes accessed;\n      number or depth of delegated actions;\n      model configuration class;\n      approved context sources;\n      output class;\n      risk class;\n      protected execution trace digest;\n      or equivalent machine-verifiable runtime attributes.\n\nThe behavioral envelope should therefore be a predicate over observable execution\ninvariants, not an exact prediction of the model's generated text.\n\nFor example:\n\nALLOW:\n    model_id = approved\n\n     tool_class  approved_set\n     destination_class  approved_set\n     resource_class  approved_set\n     delegation_depth <= N\n     high_risk_action => trusted_user_confirmation\n\nDO NOT REQUIRE:\n    exact generated tokens == previously predicted tokens\n\nClaim 46 already points in this direction by distinguishing model identity, approved\nmeasurement or version, runtime behavioral descriptor, execution fingerprint or inference\ntrace, approved behavioral envelope, purpose scope, data-access scope and output class.\n\nThe stronger explanation is:\n\nALF answers \"which model/runtime is executing?\" Behavioral finality answers \"what\nclasses of consequential behavior is this execution permitted to produce?\"\n\nThe architecture should not claim that a non-deterministic model's entire future behavior can\nbe predicted.\n\nQ12. How does the messaging embodiment work with end-to-end encryption if\nthe server-side PED cannot see plaintext message content?\n\nThis objection is valid against the server-side content-processing form of the named\nmessaging embodiment.\n\nThe current embodiment places a Platform Protected Execution Domain in server-side\nprotected infrastructure and describes AI processing over message content before delivery.\n\nThat implementation is feasible only where the relevant server-side protected component has\nauthorized access to the content being processed.\n\nWhere an interoperability deployment preserves end-to-end encryption such that the server-\nside platform cannot obtain plaintext, the architecture should not require plaintext\ndisclosure to the server-side PED.\n\nThe enforcement point must move.\n\nE2EE-compatible form\n\nA stronger E2EE-compatible architecture is:\n\nencrypted interoperable message\n        v\nendpoint receives ciphertext\n        v\nauthorized endpoint decryption\n        v\nCLIENT-SIDE / DEVICE-SIDE PED\n\n        v\nCandidate Act for AI processing\n        v\nlocal protected validation\n        v\nlocal AI processing or protected processing\n        v\nCandidate output\n        v\ndevice-side Finality Sink\n        v\nrender / reply / export / agent action\n\nThe server-side protected component may still validate:\n\n      origin metadata;\n      interoperability context;\n      signed policy context;\n      sender-provided consent metadata;\n      routing authority;\n      capability provenance;\n\nwithout accessing plaintext.\n\nThe PCT's broader architecture already permits on-device, remote, hybrid and distributed\nPED placement, including split protected components.\n\nAccordingly:\n\nThe general execution-finality architecture is compatible with E2EE, but the server-side\nplaintext-processing form of Embodiment CC must be understood as one\nimplementation applicable only where server-side content processing is available. In an\nE2EE deployment, content-dependent validation moves to the endpoint or another\nprotected domain that legitimately possesses plaintext.\n\nThis distinction should be explicit.\n\nQ13. Does fail-closed behavior create a denial-of-service attack surface or leak\npolicy information through denial patterns?\n\nYes.\n\nFail-closed protects integrity, but it creates an availability dependency.\n\nAn attacker may attempt to exhaust or destabilize:\n\n      PED request queues;\n      nonce allocation;\n      attestation services;\n      revocation processing;\n\n      policy synchronization;\n      monotonic-counter state;\n      secure storage;\n      capability caches.\n\nTherefore finality needs resource-governance protection, not merely authorization logic.\n\nPossible measures include:\n\n      per-principal request quotas;\n      bounded PED queues;\n      admission control;\n      reserved capacity for critical action classes;\n      protected rate limits;\n      back-pressure before requests enter the secure world;\n      coalesced epoch updates;\n      bounded revocation windows;\n      local authority leases;\n      batch state advancement where safe;\n      wear-aware protected counters;\n      recovery checkpoints;\n      redundant protected services for deployments requiring higher availability.\n\nThe core rule remains:\n\nA degraded validation path may be shorter, but degraded mode must not silently\nconvert missing finality authority into authorization.\n\nDenial as a side channel\n\nDifferent denial reasons may also reveal:\n\n      policy state;\n      revocation state;\n      user state;\n      security tier;\n      destination classification;\n      whether a protected resource exists.\n\nTherefore the untrusted caller should receive a coarse or opaque denial result where\ndetailed reasons are not required.\n\nFor example:\n\nCALLER:\n    FINALITY_DENIED\n\nPROTECTED AUDIT:\n    exact internal denial reason\n\nDetailed reasons may remain inside protected evidence accessible only to an authorized\nauditor, user, administrator, or conformity authority.\n\nThe PCT already uses fail-closed denial extensively and contemplates protected denial\nreceipts.\n\nThe architecture should therefore state honestly:\n\nFinality converts unauthorized effectuation into denial; it does not eliminate denial-of-\nservice as a security problem. Availability must be separately engineered.\n\nQ14. Can the architecture realistically be deployed on the existing installed\ndevice base?\n\nNot with the strongest hardware-non-bypass guarantees on every existing device.\n\nThe market size and the immediately deployable hardware base should not be treated as the\nsame thing.\n\nThe existing disclosure identifies a very large installed device market. That establishes\npotential scope, but not universal retrofit feasibility.\n\nA credible deployment model has tiers.\n\nTier 1 - software / existing protected-hardware implementation\n\nWhere an existing device already exposes suitable:\n\n      TEE;\n      secure processor;\n      protected controller;\n      hardware-backed keys;\n      secure counters;\n      kernel mediation;\n      protected display or payment paths,\n\nsome execution-finality functions may be introduced through firmware, OS, driver, or\nprotected-service updates.\n\nThis may provide meaningful enforcement but not necessarily the strongest silicon-level non-\nbypass guarantee for every action class.\n\nTier 2 - firmware/controller-integrated implementation\n\nNew firmware or platform releases can integrate capability verification directly into:\n\n      storage controllers;\n      network paths;\n\n      display pipelines;\n      IPC dispatchers;\n      sensor paths;\n      protected services.\n\nTier 3 - silicon-integrated implementation\n\nThe strongest Governed Egress Set model may require new SoC or controller design so that\nprotected enablement is structurally required at consequence-producing boundaries.\n\nTherefore the commercially defensible position is:\n\nThe installed base defines the economic relevance of the problem; the deployable base\ndepends on the protected capabilities of each hardware generation. Full hardware-\nrooted non-bypass enforcement may phase in with future device generations.\n\nThat is more credible than implying immediate retrofit of every existing device.\n\nQ15. What happens when a multi-step workflow partially completes and a\nlater Finality Sink denies the next act?\n\nExecution finality cannot magically undo an act that has already become irreversible.\n\nThis should be stated explicitly.\n\nSuppose:\n\nAct A -> authorized and effectuated\nAct B -> authorized and effectuated\nAct C -> denied\n\nThe architecture can guarantee that Act C does not occur without authority.\n\nIt cannot necessarily restore the external world to the state before Acts A and B.\n\nTherefore distributed workflows require a separate workflow-commit discipline.\n\nWhere reversible preparation is possible\n\nUse a prepare/commit structure:\n\nAct A -> PREPARED\nAct B -> PREPARED\nAct C -> PREPARED\n\nall required sinks ready?\n        v\n       YES\n        v\nissue commit authority\n\n        v\neffectuate\n\nA workflow-level descriptor may bind:\n\n      workflow identifier;\n      required sub-acts;\n      dependency graph;\n      participating sinks;\n      resource commitments;\n      destinations;\n      validity window;\n      commit order.\n\nNo sub-act becomes externally effective during the preparation stage.\n\nWhere true atomicity is impossible\n\nSome consequences cannot be atomically committed across independent systems.\n\nFor example, once an external message has been delivered or a physical actuator has moved,\nrollback may be impossible.\n\nIn those cases:\n\n      perform the least reversible actions last;\n      reserve or stage reversible actions first;\n      stop immediately on denial;\n      record exact partial-completion state;\n      invoke compensating actions where meaningful;\n      do not describe compensation as rollback;\n      expose partial-completion status to the authorized user or orchestration layer.\n\nThe bounded claim should therefore be:\n\nExecution finality prevents unauthorized sub-actions. It does not by itself guarantee\natomic rollback across independent irreversible external systems.\n\nIf a formal multi-sink commit protocol is not expressly supported by the existing priority\ndisclosure, it should be treated as an additional implementation refinement rather than silently\nread into the current claims.\n\nC. Regulatory and Political Objections and Responses\nQ16. Does hardware-rooted finality entrench the platform gatekeeper by\nmoving the chokepoint from software into hardware?\n\nIt could, if the platform remains the sole authority over:\n\n      policy definition;\n      PED state;\n      capability issuance;\n      parity rules;\n      and verification evidence.\n\nThat would merely move discretionary control into a harder-to-observe layer.\n\nThe architecture therefore needs verifiable neutrality, not merely hardware enforcement.\n\nThree independent properties are required:\n\n1. Policy transparency\n\nThe exact policy bundle or policy profile being enforced should have a stable, externally\nverifiable identity.\n\n2. Parity verifiability\n\nEquivalent first-party and third-party Candidate Acts should be independently testable against\nequivalent predicate profiles.\n\nThe verifier should be able to establish:\n\nsame action class\nsame resource class\nsame destination class\nsame risk class\nsame user-intent condition\n        v\nequivalent predicate treatment\n\nwithout trusting the platform's assertion that parity occurred.\n\n3. Independent evidence\n\nThe LAVR or equivalent validation evidence should allow an authorized external party to\nverify:\n\n      active policy digest;\n      Candidate Act class;\n      relevant predicate profile;\n      capability scope;\n      sink identity;\n      finality decision.\n\nThe PCT already states that finality evidence can be independently verified rather than\nrelying solely on gatekeeper-controlled statements or post-event logs.\n\nA stronger implementation may use:\n\n        externally published policy digests;\n        conformity profiles;\n        multi-party policy authorization;\n        threshold capability issuance;\n        independent test vectors;\n        standardized parity predicates.\n\nThe regulatory answer is therefore:\n\nThe platform may host the enforcement hardware, but it must not be the sole source of\ntruth regarding what policy was enforced or whether equivalent requesters received\nequivalent treatment.\n\nQ17. Does placing a Finality Gate on accessibility pathways create a barrier\nfor assistive technology?\n\nA blanket hardware gate applied indiscriminately to accessibility functions would create a\nserious usability and accessibility concern.\n\nThe correct distinction is not:\n\naccessibility API versus ordinary API.\n\nIt is:\n\nassistive computation versus externally consequential effectuation.\n\nOrdinary assistive operations such as:\n\n        reading UI structure;\n        magnification;\n        screen narration;\n        focus navigation;\n        non-consequential interface assistance;\n\nneed not automatically be treated like high-risk agentic acts merely because they use\naccessibility infrastructure.\n\nHowever, when any pathway-accessibility or otherwise-causes:\n\n        a payment;\n        message send;\n        credential disclosure;\n        file export;\n        account modification;\n        external upload;\n\n      device-setting modification;\n      or another consequential act,\n\nthat consequence still requires finality.\n\nThe PCT itself treats accessibility as a governed path when it produces a consequential action\nrather than treating the API name itself as the security boundary.\n\nThe preferred rule is:\n\nDo not carve out an API. Classify the consequence.\n\nA trusted assistive principal may also receive:\n\n      pre-authorized bounded capability envelopes;\n      local low-latency verification;\n      long-lived accessibility session context;\n      accessibility-priority availability;\n      simplified trusted confirmation appropriate to the user's needs.\n\nThat preserves accessibility without creating an \"accessibility\" label that malicious software\ncould use as a bypass.\n\nQ18. Does the LAVR create a surveillance corpus by recording every\nconsequential user action?\n\nIt could if implemented as a centralized, indefinitely retained, identity-linked activity ledger.\n\nThat should not be the default implementation.\n\nThe LAVR's purpose is to establish proof of protected validation, not to recreate the user's\ncomplete behavioral history.\n\nThe privacy-preserving design should minimize both content and linkability.\n\nA receipt can contain commitments to:\n\n      Candidate Act digest;\n      validation result;\n      policy epoch;\n      nonce;\n      sink identity;\n      capability commitment;\n\nwithout storing:\n\n      message contents;\n      file contents;\n\n      prompt text;\n      full recipient history;\n      complete user identity;\n      raw model inputs.\n\nThe PCT already supports:\n\n      local secure receipts;\n      compact protected state;\n      privacy-preserving proofs;\n      zero-knowledge proofs;\n      signed receipts;\n      ledger-anchored receipts;\n      and lower-assurance no-external-receipt variants.\n\nAdditional privacy controls should include:\n\n      local-first storage;\n      purpose-specific receipt domains;\n      retention limits;\n      rotating pseudonymous identifiers;\n      selective disclosure;\n      unlinkable or compartmentalized receipt chains where possible;\n      disclosure only upon authorized audit;\n      aggregation rather than raw per-event export;\n      deletion or expiration where the assurance model permits it.\n\nThe key distinction is:\n\nTamper evidence does not require universal observability.\n\nA receipt can prove that finality was enforced without becoming a central log of everything\nthe user did.\n\nQ19. Does the architecture remove user autonomy by making the device\nowner unable to override their own hardware?\n\nA high-assurance security architecture inevitably creates tension between:\n\n      device-owner control;\n      platform security;\n      enterprise policy;\n      regulatory obligations;\n      payment or credential assurance.\n\nThe answer should not be to pretend that all of these authorities are identical.\n\nThe architecture can separate policy layers.\n\nFor example:\n\nmandatory protected integrity rules\n        +\nregulated-domain requirements\n        +\nenterprise policy\n        +\ndevice-owner policy\n        +\nper-act user intent\n\nThe owner should be able, where the deployment permits it, to:\n\n      inspect active policy identity;\n      revoke assistant authority;\n      select third-party assistants;\n      reset local capability state;\n      disable optional governance profiles;\n      change owner-controlled policies;\n      verify which policy bundle is active.\n\nFor developer, repair, research or modified-device modes, the system may permit an explicit\ntrust-state transition rather than silently pretending the original assurance remains intact.\n\nFor example:\n\nowner unlocks protected platform state\n        v\ndevice attestation state changes\n        v\nowner retains control\n        v\nhigh-assurance relying parties may choose not to trust that state\n\nThis preserves owner autonomy without falsely representing a modified environment as still\nsatisfying the original protected assurance profile.\n\nThe core principle is:\n\nUser control and external trust do not have to be identical properties. A user may be\nallowed to alter their device while a regulated relying party may separately decide\nwhether that modified state satisfies its assurance requirements.\n\nD. Standardisation and Deployment Objections and\nResponses\nQ20. Why is standardisation important if the execution-finality architecture is\nimplemented inside protected firmware, operating-system components, secure\nprocessors, or device controllers?\n\nA purely proprietary implementation may remain difficult for external parties to inspect,\ncompare, test, or verify across different platforms. Standardisation creates a common\ntechnical layer through which execution-finality behavior can become interoperable,\ntestable, auditable, and independently verifiable.\n\nThe objective is not to standardise one vendor's internal hardware design. The objective is to\nstandardise the interfaces, invariants, evidence structures, and conformance behavior\nrequired for protected execution finality.\n\nA standards profile could define common elements such as:\n\n      Candidate Act representation;\n      canonical commitment format;\n      action-class taxonomy;\n      resource and destination binding;\n      Finality Sink identity;\n      Effectuation Boundary identity;\n      governance or authority epoch;\n      nonce and freshness requirements;\n      capability scope;\n      non-bearer verification requirements;\n      validation-evidence or LAVR format;\n      policy-bundle identity;\n      parity-conformance evidence;\n      revocation semantics;\n      cumulative-budget predicates;\n      degraded-mode requirements;\n      and sink-side verification behavior.\n\nThe central standards invariant would remain:\n\nA consequential act may be prepared, requested, routed, or computed, but it does not\nbecome externally effective until a designated Finality Sink verifies valid scoped\nauthority for that exact consequence.\n\nStandardisation does not require identical hardware\n\nDifferent implementations may use:\n\n      secure enclaves;\n      trusted execution environments;\n      secure elements;\n\n      hardware security modules;\n      protected microcontrollers;\n      protected hypervisor partitions;\n      trusted controllers;\n      confidential computing;\n      firmware-isolated components;\n      or distributed protected services.\n\nThe standard need not prescribe which substrate is used.\n\nInstead, it can define the externally testable requirement:\n\nCandidate Act\n      v\nNon-Effective State\n      v\nProtected Validation\n      v\nScoped Finality Authority\n      v\nFinality Sink Verification\n      v\nEffectuation\n\nThis allows different platforms to implement the architecture differently while preserving\ninteroperable security semantics.\n\nStandardisation makes parity externally testable\n\nThis is particularly important where the architecture is used for interoperability between first-\nparty and third-party assistants.\n\nA standardised parity profile could define that equivalent Candidate Acts are evaluated\naccording to equivalent technical predicate structures.\n\nFor example:\n\nsame action class\nsame resource class\nsame destination class\nsame risk class\nsame user-intent condition\nsame consequence boundary\n        v\nequivalent finality requirements\n\nA conformity test can then determine whether this invariant is actually enforced rather than\nrelying on the platform operator's statement that equivalent treatment exists.\n\nStandardisation can also solve the policy-governance problem\n\nA common profile may define:\n\n      policy-bundle digest format;\n      governance-epoch representation;\n      policy-update transparency;\n      co-signature or threshold-authorization mechanisms;\n      parity-profile identifiers;\n      external audit evidence;\n      and conformity-test requirements.\n\nThat makes it possible for a regulator, conformity-assessment body, enterprise, or relying\nparty to verify which governance profile a device actually enforced.\n\nThe standard therefore separates:\n\nWHO IMPLEMENTS THE HARDWARE\n          from\nWHAT SECURITY INVARIANT MUST BE PROVABLE\n\nStandardisation also supports cross-platform AI agents\n\nWithout a common finality model, an AI assistant interacting with multiple operating systems\nmay encounter entirely different concepts of:\n\n      permission;\n      user intent;\n      capability;\n      tool authority;\n      finality;\n      destination binding;\n      and consequence verification.\n\nA standard Candidate Act and Finality Sink model could allow an agent to request an\noperation using a common semantic structure while each platform retains control over its\nprotected implementation.\n\nFor example:\n\nAgent requests:\n\"send File X to Recipient Y\"\n\n                v\n\nStandard Candidate Act\n\n                v\n\nPlatform A\nsecure-controller implementation\n\nPlatform B\nTEE implementation\n\nPlatform C\ndistributed protected implementation\n\n                v\n\nsame externally verifiable finality semantics\n\nThe standard therefore concerns execution authority semantics, not hardware uniformity.\n\nRelevant standardisation domains\n\nThe architecture naturally intersects several existing standards areas rather than belonging\nexclusively to one.\n\nPotential technical domains include:\n\n      trusted execution and secure components;\n      platform security;\n      device attestation;\n      capability-based security;\n      AI-agent and tool-call governance;\n      operating-system interoperability;\n      telecommunications;\n      identity and credential systems;\n      payment and wallet security;\n      confidential computing;\n      privacy-preserving audit evidence;\n      and AI governance infrastructure.\n\nBodies working in areas such as GlobalPlatform, Trusted Computing Group, ITU-T,\n3GPP, ETSI, ISO/IEC JTC 1, W3C, and relevant AI-agent or interoperability\nstandards initiatives could therefore encounter different layers of the architecture.\n\nA single standard would not necessarily need to cover the entire system. The architecture can\nbe decomposed into interoperable profiles.\n\nFor example:\n\nProfile 1\nCandidate Act + capability format\n\nProfile 2\nProtected finality verification\n\nProfile 3\nPolicy and parity attestation\n\nProfile 4\nAI-agent / tool-call finality\n\nProfile 5\nPrivacy-preserving validation evidence\n\nProfile 6\nTelecom / network egress finality\n\nProfile 7\n\nPayment and wallet finality\n\nThe strategic value of standardisation is therefore broader than implementation uniformity:\n\nIt converts execution finality from a platform-specific security mechanism into a\ncommon, independently testable infrastructure property.\n\nQ21. Existing platforms already use secure processors, protected\nconfirmation, app-intent frameworks, hardware-backed keys, sandboxing,\nentitlements, and isolated AI runtimes. What would need to be standardised\nbeyond those mechanisms?\n\nThose mechanisms provide important building blocks, but they do not by themselves create a\ncommon cross-platform definition of execution finality for an exact consequential act.\n\nThe standardisation opportunity is the ordered relationship among the components:\n\nCandidate Act\n        v\nexplicit Non-Effective State\n        v\nrelease-form commitment\n        v\nprotected predicate validation\n        v\nprotected validation evidence\n        v\nscoped non-bearer execution authority\n        v\nresource + destination + sink + boundary binding\n        v\nFinality Sink verification against actual release state\n        v\nauthority consumption\n        v\neffectuation\n\nA standards profile could therefore define several properties that ordinary permission systems\ndo not necessarily define uniformly.\n\n1. Computation is not execution authority\n\nAn AI model may generate:\n\n      a payment instruction;\n      email;\n      file export;\n      API invocation;\n      browser action;\n      tool call;\n      device command;\n\nwithout that computation itself authorizing the consequence.\n\nThe standard would define a formal transition from:\n\nPROPOSED / COMPUTED\n\nto:\n\nAUTHORIZED TO BECOME EFFECTIVE\n\n2. Permission is not finality\n\nA broad application entitlement or permission may establish that an application can use a\nclass of resource.\n\nExecution finality asks a narrower question:\n\nIs this exact act, against this exact resource and destination, currently authorized to\nbecome effective?\n\nThat distinction can be standardised independently of existing permission frameworks.\n\n3. Authority must remain act-scoped\n\nAuthority granted for:\n\nFile A -> Recipient X\n\nmust not automatically authorize:\n\nFile B -> Recipient X\n\nor:\n\nFile A -> Recipient Y\n\nor another downstream act generated by an agent.\n\nStandardisation can define the mandatory scope fields used to prevent such expansion.\n\n4. Capability possession alone must be insufficient\n\nA finality capability may be transported through ordinary software, but copying or replaying\nit must not by itself create authority.\n\nThe standard may require binding to:\n\n         Candidate Act;\n         requester;\n         resource;\n         destination;\n\n        nonce;\n        epoch;\n        Finality Sink;\n        and Effectuation Boundary.\n\n5. Alternate APIs must not change finality requirements\n\nThe same consequence may be requested through:\n\n        public API;\n        private API;\n        app intent;\n        browser automation;\n        accessibility route;\n        IPC;\n        plug-in;\n        SDK;\n        cloud relay;\n        internal service.\n\nThe standards property is consequence-based:\n\nEquivalent external consequences remain subject to equivalent finality requirements\nregardless of the software route used to reach the boundary.\n\n6. First-party and third-party parity becomes technically measurable\n\nStandardisation can define equivalent-action test cases so that parity is not simply a policy\nstatement.\n\nA conformity suite could submit equivalent first-party and third-party Candidate Acts and\ncompare:\n\n        predicate profile;\n        capability scope;\n        denial reasons at the protected level;\n        Finality Sink requirements;\n        policy-bundle identity.\n\nThis would make interoperability parity independently testable.\n\n7. The first usable release boundary becomes a common architectural concept\n\nThe relevant enforcement point is not necessarily where the request originates.\n\nIt is:\n\nthe last point at which the artifact remains determinable and complete withholding\nremains possible immediately before the consequence becomes usable.\n\nA standard can define how implementations identify and attest that boundary for different\naction classes.\n\n8. Validation evidence becomes portable\n\nA standardised LAVR or equivalent protected evidence format could allow an authorized\nverifier to establish that:\n\n      the Candidate Act remained non-effective;\n      the correct policy profile was applied;\n      protected predicates passed;\n      scoped authority was issued;\n      the designated Finality Sink verified it;\n      and finality occurred under the expected governance epoch.\n\nThe verifier would not need access to the platform's proprietary internal implementation.\n\nStandardisation Objective\n\nThe purpose is not to replace existing secure hardware, operating-system permissions,\nprotected confirmation systems, or application frameworks.\n\nThe purpose is to establish a common technical rule for when machine-generated intent\nbecomes externally effective authority.\n\nThe resulting standards abstraction is:\n\nCOMPUTATION\n    =\nAUTHORITY\n\nPERMISSION\n    =\nFINALITY\n\nCAPABILITY POSSESSION\n    =\nEFFECTUATION\n\nPROTECTED VALIDATION\n    +\nEXACT ACT BINDING\n    +\nFINALITY SINK VERIFICATION\n    =\nAUTHORIZED CONSEQUENCE\n\nA cross-platform standard built around that invariant could allow different device\necosystems, AI assistants, applications, telecom systems, payment systems, and regulated\ninfrastructures to implement different internal mechanisms while still exposing the same\nindependently verifiable execution-finality semantics.\n\nQ21. What is the answer when a platform vendor says, \"We already have\nsecure hardware, protected confirmation, secure intent, app-intent controls,\nhardware-backed keys, and isolated AI runtimes\"?\n\nThe answer should not be that secure hardware itself is new.\n\nSecure processors, trusted execution, protected confirmation, app intents, hardware-backed\nkeys, sandboxing, entitlement systems and isolated AI runtimes are existing building blocks.\n\nThe technical distinction to emphasize is the ordered execution-finality invariant across\ngeneric consequential action classes.\n\nThe architecture is not merely:\n\nsecure hardware\n+\npermission\n+\nconfirmation\n\nIt is:\n\nCandidate Act\n        v\nexplicit Non-Effective State\n        v\nrelease-form commitment\n        v\nprotected predicate validation\n        v\nprotected validation evidence\n        v\nscoped non-bearer finality authority\n        v\nbinding to resource + destination + sink + boundary\n        v\nFinality Sink independently verifies actual release state\n        v\nauthority consumption\n        v\neffectuation\n\nThe distinction also includes:\n\n        computation does not itself create execution authority;\n        possession of the capability alone is insufficient;\n        authorization for one act does not expand to another act;\n        separate downstream consequential acts receive separate finality;\n        alternate APIs do not bypass consequence-level enforcement;\n        first-party internal routes remain subject to equivalent finality for equivalent\n         Candidate Acts;\n\n      the first usable release boundary, not an earlier policy check, controls final\n       effectuation;\n      protected validation evidence exists before or atomically with authority release.\n\nThe current PCT expressly distinguishes ordinary permissions, entitlements, API access, user\napproval and software mediation from sink-side finality, and it closes first-party, alternate-\nroute, local-AI, cloud-assisted and bearer-token substitutions.\nAccordingly, the response is:\n\nExisting secure components may supply parts of the implementation. The relevant\ntechnical question is whether those components collectively enforce the complete\nCandidate Act -> Non-Effective State -> protected validation -> scoped finality\nauthority -> actual-release verification -> Finality Sink effectuation sequence for\ngeneric consequential acts, including equivalent first-party and third-party paths.\n\nThe hardware is not the central distinction.\n\nThe distinction is the execution-authority architecture imposed across the consequence\nboundary.\n\nConsolidated Position\nThese additional objections add six requirements to the earlier five core invariants:\n\n6. Policy itself must have protected provenance and, where neutrality matters,\nindependent verifiability.\n\n7. Finality must be capable of reasoning over cumulative protected state, not only\nisolated acts.\n\n8. Declared purpose is a constraint label, not proof of semantic intent.\n\n9. AI behavioral enforcement must target measurable runtime and action-level\ninvariants rather than deterministic model outputs.\n\n10. Privacy, accessibility, user autonomy and availability are architectural\nrequirements, not afterthoughts.\n\n11. Distributed finality prevents unauthorized sub-actions but does not automatically\nguarantee rollback of already irreversible acts.\n\nThe complete architecture therefore becomes:\n\nPOLICY PROVENANCE / GOVERNANCE\n            v\nCANDIDATE ACT\n            v\nRELEASE-FORM COMMITMENT\n\n             v\nNON-EFFECTIVE STATE\n             v\nPER-ACT + CUMULATIVE PROTECTED PREDICATES\n             v\nPED AUTHORITY VALIDATION\n             v\nLAVR / PRIVACY-PRESERVING EVIDENCE\n             v\nSCOPED NON-BEARER CAPABILITY\n             v\nGOVERNED EGRESS SET\n             v\nFINALITY SINK RE-DERIVES ACTUAL RELEASE STATE\n             v\nMATCH + CURRENT BUDGET + CURRENT POLICY?\n\n      NO                       YES\n      v                          v\n FAIL CLOSED          CONSUME / ADVANCE\n                              v\n                         EFFECTUATE\n                              v\n                  MINIMAL PROTECTED RECEIPT\n\nThe resulting principle is:\n\nNo software component, policy author, agent, assistant, platform service, cached\npermission, prior approval, alternate API, or possession of an authorization object\nshould by itself be sufficient to create an externally effective consequence. The exact\nconsequence must remain bound to protected authority, current protected state,\nindependently identifiable policy, and sink-side verification at the boundary where that\nconsequence actually becomes usable.\n\nAdditional Technical Objections and Responses\nQ22. If applications already define actions through structured intent schemas,\nwhy is a separate Candidate Act necessary?\n\nStructured intent frameworks can define available application actions, required parameters,\nentities, and data relationships. An intent therefore describes an executable application\ncapability.\n\nA Candidate Act operates at a different layer. It represents the specific consequence\npresently proposed for effectuation.\n\nFor example:\n\nAPP INTENT DEFINITION\n\nSendMessage(\n    recipient,\n\n     content\n)\n\nThis defines an action class.\n\nA Candidate Act represents a particular execution:\n\nTHIS EXECUTION\n\nrecipient = X\nactual final payload = H(...)\nattachment = Y\nrequester = Agent A\ndestination = X\nsink = MessageSendSink\nboundary = B\nepoch = E\nnonce = N\n\nThe sequence is therefore:\n\nIntent schema\n      v\nAction invocation\n      v\nActual resource and destination resolved\n      v\nCandidate Act\n      v\nRelease-form commitment\n      v\nProtected finality\n\nThe standardisation objective is not to replace structured-intent frameworks. It is to establish\na common final execution-authority layer beneath or alongside those frameworks.\n\nAn intent answers:\n\nWhat operation does the application expose?\n\nA Candidate Act answers:\n\nIs this exact instance of that operation, involving these exact resources and destinations,\nauthorized to become externally effective now?\n\nQ23. How can a platform-level Candidate Act normalize the semantics of\nthousands of unrelated applications?\n\nA universal execution-finality layer does not need to understand the complete business\nsemantics of every application.\n\nApplication-specific semantics and consequence semantics can remain separate.\n\nApplications may define operations such as:\n\nPublishInvoice\nSubmitMedicalForm\nBookTrip\nApproveExpense\nShareAlbum\n\nThe execution-finality layer can instead operate on a smaller set of standardized consequence\nprimitives:\n\nDATA_DISCLOSURE\nNETWORK_TRANSMISSION\nMESSAGE_SEND\nPAYMENT_COMMIT\nCREDENTIAL_RELEASE\nIDENTITY_DISCLOSURE\nSTORAGE_COMMIT\nEXTERNAL_API_INVOCATION\nSENSOR_RELEASE\nINTER_PROCESS_TRANSFER\nDEVICE_SETTING_CHANGE\nPHYSICAL_ACTUATION\nPROTECTED_RENDER\n\nAn application-specific action can map to one or more consequence classes.\n\nFor example:\n\nPublishInvoice\n        v\nDATA_DISCLOSURE\n+\nNETWORK_TRANSMISSION\n+\nSTORAGE_COMMIT\n\nor:\n\nBookTrip\n        v\nCREDENTIAL_RELEASE\n+\nEXTERNAL_API_INVOCATION\n+\nPAYMENT_COMMIT\n\nThe application may provide the initial semantic mapping, but providing that mapping does\nnot create execution authority.\n\nThe actual consequence remains independently bound to machine-verifiable attributes such\nas:\n\nactual resource\nactual release-form commitment\nactual recipient\n\nactual destination\nactual amount\nactual credential\nactual network endpoint\nactual Finality Sink\nactual Effectuation Boundary\ncurrent epoch\nfresh nonce\n\nThe Protected Execution Domain therefore does not need to understand the complete human\nmeaning of BookTrip.\n\nIt needs to determine:\n\nWhich protected consequence classes are about to become effective, and whether valid\nauthority exists for those consequences.\n\nFor an unmapped or novel consequential action, the architecture may:\n\n         require registration of a structured consequence schema;\n         require explicit action-class, resource, and destination mapping;\n         classify the act according to its downstream Effectuation Boundary;\n         require stronger trusted-user confirmation;\n         assign the operation to an unknown or high-risk consequence class;\n         or fail closed where the consequence cannot be safely classified.\n\nThis avoids both extremes:\n\ntrusting application-defined meaning as final authority\n\nand\n\nrequiring the PED to become a universal application-semantic engine.\n\nThe source material already distinguishes application semantics from standardized\nconsequence semantics.\n\nQ24. Does equivalent first-party and third-party treatment incorrectly assume\nidentical trust properties?\n\nEquivalent treatment does not require identical identity, provenance, privilege, or attestation\nevidence.\n\nDifferent requesters may legitimately have:\n\n         different code provenance;\n         different sandbox privileges;\n         different protected entitlements;\n         different signing authority;\n\n      different hardware access;\n      different attestation mechanisms.\n\nThe relevant parity invariant is:\n\nEquivalent externally consequential acts must face equivalent finality requirements,\nwhile requester-specific trust evidence may legitimately differ.\n\nFor example:\n\nFIRST-PARTY REQUEST\n\nidentity evidence A\n+\nresource X\n+\ndestination Y\n+\npayment consequence\n+\nfresh user confirmation\n+\nFinality Sink verification\n\nand:\n\nTHIRD-PARTY REQUEST\n\nidentity evidence B\n+\nresource X\n+\ndestination Y\n+\npayment consequence\n+\nfresh user confirmation\n+\nFinality Sink verification\n\nThe identity evidence may differ.\n\nThe prohibited asymmetry is:\n\nthird-party equivalent consequence\n        -> finality required\n\nfirst-party equivalent consequence\n        -> finality bypassed\n\nThe parity rule is therefore about the consequence-level security invariant, not about\nforcing every requester to present identical credentials.\n\nQ25. Does exposing Finality Sink functionality to third-party applications\ncreate a privileged attack surface?\n\nThe application-facing interface does not need to expose protected internal mechanisms.\n\nApplications need not directly manipulate:\n\n      PED keys;\n      secure counters;\n      hardware registers;\n      sink-controller state;\n      queue-enable material;\n      cryptographic unlock values;\n      protected memory;\n      or protected policy state.\n\nThe application-facing interface can remain abstract:\n\nREQUEST CANDIDATE ACT\n        v\nopaque platform mediation\n        v\nprotected validation\n        v\nFinality Sink verification\n        v\nsuccess / denial\n\nThe capability itself may remain opaque to the requesting application.\n\nAn application or operating-system component may transport a capability without receiving\nauthority to:\n\n      mint it;\n      expand it;\n      reinterpret it;\n      modify it;\n      replay it outside its bound scope;\n      or force a Finality Sink to accept it.\n\nStandardisation can therefore define:\n\n      Candidate Act semantics;\n      capability binding requirements;\n      Finality Sink verification behavior;\n      policy identity;\n      attestation;\n      evidence formats;\n      and conformance requirements,\n\nwithout exposing privileged controller internals to third-party software.\n\nQ26. How are application, model, runtime, or operating-system updates\nhandled without silently transferring old authority into a new software state?\n\nAuthority may be bound to:\n\n      application measurement;\n      code-signature state;\n      model identity;\n      runtime version;\n      governance epoch;\n      policy epoch;\n      security state.\n\nAn update may therefore invalidate existing act-specific authority.\n\nFor example:\n\nOLD VERSION\n\napp_measurement = A\nepoch = 100\n\n          v\n\nsoftware update\n\n          v\n\nNEW VERSION\n\napp_measurement = B\nepoch = 101\n\nCapabilities issued under the old measured state should not silently migrate to the new state.\n\nA version transition can instead follow:\n\nold act-specific capability -> expires / invalid\n\nnew software state -> re-attested\n\nstable user policy -> may remain subject to revalidation\n\nnew protected session -> established\n\nnew act-specific capability -> issued\n\nLong-lived user preferences or policy configuration may survive an update where permitted.\n\nAct-specific execution authority generally should not survive automatically.\n\nThis preserves the distinction between:\n\npersistent policy\n\nand\n\nfresh authority to effectuate a specific consequence.\n\nQ27. What happens when an operation begins on one device but becomes\neffective on another?\n\nCross-device execution introduces another trust boundary.\n\nExamples include:\n\nphone request -> watch payment\n\ntablet request -> laptop file send\n\nheadset request -> phone communication\n\ncloud-generated request -> local device effectuation\n\nA capability bound to Device A's protected state and Finality Sink should not automatically\nbecome executable authority on Device B.\n\nTwo general models are possible.\n\nModel 1: New Candidate Act at the receiving device\n\nDEVICE A\n\nCandidate Act A\n      v\nprotected authorization\n      v\ndelegation commitment\n      v\n\nDEVICE B\n\nreceive delegated request\n      v\nconstruct Candidate Act B\n      v\nverify Device A provenance\n      v\nvalidate Device B state\n      v\nissue Device-B-bound capability\n      v\nDevice B Finality Sink\n\nModel 2: Jointly authorized cross-device capability\n\nA cross-device capability may be jointly bound to:\n\n      Device A identity;\n      Device B identity;\n      originating Candidate Act;\n      receiving Candidate Act;\n      destination;\n      action class;\n      participating sinks;\n      nonce;\n      governance epoch;\n      delegation scope.\n\nThe original capability must not become a freely transferable bearer credential merely\nbecause the workflow crosses devices.\n\nDevice identity therefore becomes another load-bearing finality attribute.\n\nQ28. What happens if the Finality Sink consumes authority and the device\ncrashes before the external consequence completes?\n\nThis is a crash-consistency problem.\n\nFor example:\n\ncapability verified\n        v\nauthority consumed\n        v\nCRASH\n        v\ndid the consequence occur?\n\nThe reverse sequence is also possible:\n\nexternal effect committed\n        v\nCRASH\n        v\nprotected consumed-state not fully recorded\n\nExecution finality therefore requires a crash-consistent protected commit state.\n\nA representative state machine is:\n\nISSUED\n   v\nARMED\n   v\nCOMMITTING\n   v\n\nEFFECT-COMMITTED\n   v\nCONSUMED\n\nThe exact state machine depends on the consequence class.\n\nLocally controlled consequences\n\nFor consequences under direct local control, protected authority consumption may be\natomically or crash-consistently coupled with the local effect.\n\nExamples include:\n\n        storage commit;\n        protected-display release;\n        local credential release;\n        device-setting change;\n        actuator enablement;\n        secure transaction state.\n\nThe intended invariant is:\n\neither\n\nauthority remains unused\nAND\neffect does not occur\n\nor\n\nauthority is consumed\nAND\nlocal effect is committed\n\nIntermediate states must be recoverable from protected state.\n\nNetworked consequences\n\nNetworked consequences introduce a different problem because local protected state cannot\nalways determine whether the remote party completed the operation.\n\nExecution authority and proof of external completion must therefore remain distinct concepts.\n\nQ29. Can the architecture guarantee exactly-once execution for networked\nconsequences?\n\nNot universally.\n\nConsider:\n\nSEND transaction X\n         v\nremote service executes X\n         v\nACK lost\n         v\nlocal device does not know whether retry is safe\n\nA retry could produce:\n\n      harmless retransmission;\n      duplicate message;\n      duplicate payment;\n      duplicate API operation;\n      duplicate external side effect.\n\nExecution finality can provide:\n\n      single-use authority;\n      sink-local consumption;\n      replay resistance;\n      bounded retry authority;\n      transaction identifiers;\n      idempotency identifiers.\n\nFor example:\n\nCandidateActID = X\n\nExternalTransactionID = X\n\nA retry remains bound to:\n\n      the same Candidate Act;\n      same resource;\n      same destination;\n      same action class;\n      same transaction identity;\n      same sink;\n      same boundary;\n      same bounded retry policy.\n\nWhere the receiving protocol supports idempotency, repeated delivery can be recognized as\nthe same logical transaction rather than a newly authorized act.\n\nThe bounded architectural statement is:\n\nExecution finality prevents uncontrolled replay or reuse of execution authority. Exactly-\nonce external effect additionally requires appropriate transaction or idempotency\nsemantics at the receiving system.\n\nThis distinction between authority consumption and external completion is already identified\nin the source material.\n\nQ30. Does release-form commitment create unacceptable power or latency\noverhead for large files, video, audio, or continuous sensor streams?\n\nIt could if every large payload had to be copied into the Protected Execution Domain or\nsynchronously rehashed immediately before effectuation.\n\nThe preferred design keeps bulk payload processing outside the PED.\n\nFor large or streaming resources, a Finality Sink or protected boundary-adjacent component\nmay use:\n\n      incremental hashing;\n      hardware cryptographic acceleration;\n      DMA-integrated commitments;\n      Merkle commitments;\n      chunk commitments;\n      rolling commitments;\n      bounded stream descriptors.\n\nFor example:\n\nVIDEO STREAM\n\nstream identity\n+\ndestination\n+\nframe / chunk sequence\n+\nrolling commitment root\n+\nmaximum duration\n+\nmaximum bytes\n+\nsink identity\n+\nboundary identity\n\nThe PED then operates on the compact commitment rather than the entire stream.\n\nThe security property is preserved because the sink derives the commitment from the actual\nstream presented for release.\n\nThe computational model becomes:\n\nbulk payload\n     v\n\nboundary-side commitment generation\n     v\ncompact commitment\n     v\nPED authority validation\n     v\nsink-local verification\n     v\neffectuation\n\nThe source material already identifies incremental hashing, DMA-integrated commitments,\nMerkle commitments, chunk commitments, and bounded stream descriptors as relevant\nmechanisms.\n\nQ31. Can a digest of private information itself become a privacy leak?\n\nYes.\n\nA conventional persistent content hash is not automatically privacy-preserving.\n\nFor low-entropy or predictable resources, an observer may be able to test candidate values\nagainst the exposed digest.\n\nExamples include:\n\n      short messages;\n      common forms;\n      known documents;\n      small categorical values;\n      predictable structured records.\n\nValidation evidence therefore should not unnecessarily expose stable reusable content\nfingerprints.\n\nPossible commitment mechanisms include:\n\n      keyed commitments;\n      salted commitments;\n      HMACs;\n      per-session commitments;\n      ephemeral commitments;\n      pseudonymous resource identifiers;\n      selective-disclosure evidence;\n      zero-knowledge proof mechanisms where appropriate.\n\nAn external verifier may only need to establish:\n\nauthorized resource commitment\n        =\nactual released resource commitment\n\nwithout learning a globally reusable content fingerprint.\n\nThe privacy requirement is therefore:\n\nCommitment equality should be verifiable without unnecessarily creating a persistent\ncross-context identifier for the underlying content.\n\nQ32. Could standardized device, policy, sink, and attestation identifiers\nbecome a fingerprinting mechanism?\n\nYes.\n\nA standards profile that routinely exposes:\n\ndevice model\nfirmware version\nPED version\npolicy bundle\nsink topology\nsecurity patch level\nhardware configuration\n\ncould create a powerful device fingerprint.\n\nStandardisation should therefore distinguish:\n\nconformance attestation\n\nfrom\n\nunique device identity.\n\nA relying party may need to verify:\n\ndevice satisfies Finality Profile X\n\nwithout learning:\n\nunique hardware identifier\nexact device serial number\ncomplete firmware topology\n\nA privacy-preserving attestation design may therefore prove:\n\nassurance profile >= required level\n\nwhile minimizing disclosure of unique underlying device attributes.\n\nThe objective is to prove security properties, not necessarily to expose the device's complete\nidentity.\n\nQ33. Does policy transparency require publishing security-sensitive internal\npolicy logic?\n\nNo.\n\nTransparency does not require disclosure of every proprietary risk heuristic, dynamic anti-\nabuse signal, fraud-detection rule, or internal detection threshold.\n\nExternally verifiable information may be limited to:\n\n         policy identity;\n         policy version;\n         governance epoch;\n         mandatory parity profile;\n         applicable action classes;\n         mandatory finality invariants;\n         security-assurance level;\n         update history;\n         policy-bundle commitment.\n\nA platform may retain confidential dynamic signals while still proving that:\n\nthird-party Candidate Act\n        and\nequivalent first-party Candidate Act\n\nwere evaluated under\n\nthe same mandatory consequence-level\nfinality profile\n\nThe transparency objective is therefore:\n\nverifiable policy provenance and mandatory invariant compliance\n\nrather than publication of every internal decision rule.\n\nQ34. Could a standardized execution-finality layer freeze platform\ninnovation?\n\nA standard that dictates:\n\n         processor architecture;\n         exact kernel hooks;\n         exact controller topology;\n         exact cryptographic algorithms;\n         exact hardware module;\n\n      exact trusted-UI design;\n      exact internal API structure,\n\nwould be unnecessarily rigid.\n\nThe standard should instead define observable security invariants.\n\nFor example:\n\nREQUIRED\n\nCandidate Act remains non-effective\nexact consequence commitment\nfresh scoped authority\nresource and destination binding\nsink identity binding\nboundary identity binding\nreplay resistance\nsink-side verification\nanti-bypass property\nindependently testable parity\n\nImplementation may remain flexible:\n\nPOSSIBLE IMPLEMENTATIONS\n\nTEE\nsecure enclave\nsecure element\nprotected controller\nconfidential VM\nprotected microcontroller\ndistributed protected service\nfuture hardware architecture\n\nThe standard therefore defines what must remain true, not exactly how a platform must\nimplement it.\n\nThis allows hardware and operating-system architectures to evolve without changing the\nfinality invariant.\n\nQ35. How can completeness of the Governed Egress Set be proven?\n\nDeclaring that every consequence-producing path contains a sink is not sufficient.\n\nA modern platform may include:\n\n      CPU;\n      GPU;\n      NPU;\n      DMA engines;\n      display processors;\n\n      secure processors;\n      baseband or modem paths;\n      Wi-Fi controllers;\n      Bluetooth controllers;\n      sensor hubs;\n      storage controllers;\n      peripheral processors;\n      firmware services;\n      private controller paths.\n\nAn omitted path may defeat complete mediation.\n\nThe stronger standardisation mechanism is an attested Finality Boundary Manifest.\n\nFor each governed consequence class, the platform maintains a measured and versioned\ndescription of the boundaries capable of externalizing that consequence.\n\nFor example:\n\nNETWORK_EGRESS\n    -> cellular modem sink\n    -> Wi-Fi sink\n    -> Bluetooth sink\n\nFILE_EXTERNALIZATION\n    -> file-provider sink\n    -> storage/export sink\n\nDISPLAY_RELEASE\n    -> compositor sink\n    -> protected display sink\n\nSENSOR_DISCLOSURE\n    -> sensor-HAL sink\n    -> protected DMA sink\n\nPAYMENT_COMMIT\n    -> protected transaction-finalization sink\n\nThe Finality Boundary Manifest should be:\n\n      measured;\n      versioned;\n      signed or attested;\n      bound to the hardware and firmware configuration;\n      associated with the active Finality Sink topology;\n      updated after relevant topology changes;\n      independently testable through conformity procedures.\n\nAn unregistered change to a:\n\n      GPU path;\n      DMA route;\n\n      modem;\n      controller;\n      firmware component;\n      coprocessor;\n      or other externalization route\n\nshould change the measured platform state and invalidate the previous finality-conformance\nattestation until the new topology has been evaluated.\n\nA conformity regime can then test two properties:\n\nMANIFEST INTEGRITY\n        +\nBEHAVIORAL COMPLETENESS\n\nManifest integrity establishes that the declared sink topology corresponds to the measured\nimplementation.\n\nBehavioral completeness establishes that governed consequences cannot be externalized\nthrough undeclared or unverified routes.\n\nThe source text identifies the Finality Boundary Manifest as the mechanism for moving from\nan asserted no-bypass property to an independently testable one.\n\nQ36. What happens to long-running background agents when there is no\nfresh user interaction?\n\nRequiring fresh user confirmation for every background act would undermine legitimate\nautomation.\n\nAllowing a historical confirmation to authorize unlimited future actions would undermine\nexecution finality.\n\nThe solution is a bounded durable intent lease.\n\nFor example:\n\nAUTHORIZED AUTOMATION\n\nSend daily report\nto Recipient X\nonce per day\nfor 30 days\nmaximum one attachment\nfrom Folder Y\n\nThe protected lease may bind:\n\n      action class;\n      resource scope;\n\n      destination;\n      maximum frequency;\n      maximum execution count;\n      validity period;\n      expiration;\n      revocation state;\n      sink identity;\n      boundary identity;\n      cumulative quota;\n      governance epoch.\n\nEach actual execution still produces a fresh Candidate Act.\n\nThe persistent object represents:\n\ndurable user intent\n\nwhile each individual execution still requires:\n\nfresh act-specific authority.\n\nThe sequence becomes:\n\ndurable intent lease\n        v\nscheduled trigger\n        v\nfresh Candidate Act\n        v\ncurrent protected-state validation\n        v\nfresh scoped capability\n        v\nFinality Sink\n        v\neffectuation\n\nThe principle is:\n\nDurable intent may persist; execution authority remains fresh, bounded, and act-\nspecific.\n\nThe bounded durable-intent model is described in the source material as a way to preserve\nautomation without converting old user approval into unlimited authority.\n\nQ37. Could validation evidence conflict with stateless or privacy-preserving\nAI processing?\n\nOnly if validation evidence is interpreted as requiring a centralized, permanent record of\nevery AI-processing event.\n\nExecution-finality evidence does not need to contain:\n\n      plaintext prompt content;\n      complete message content;\n      complete file contents;\n      full model inputs;\n      persistent recipient histories;\n      reusable content fingerprints.\n\nA minimal-evidence mode may retain only compact protected state such as:\n\ncounter advanced\n+\ngovernance epoch\n+\npolicy commitment\n+\nanonymous or unlinkable commitment root\n\nMore detailed content-dependent state may disappear after finality where the assurance\nmodel permits it.\n\nWhere externally auditable evidence is required, the record can contain protected\ncommitments rather than plaintext.\n\nThe distinction is:\n\nproof that validation occurred\n\ndoes not require\n\nretention of the underlying personal data.\n\nValidation evidence can therefore be:\n\n      local-first;\n      compact;\n      selectively disclosed;\n      purpose-specific;\n      retention-limited;\n      compartmentalized;\n      cryptographically committed;\n      and privacy-preserving.\n\nThe source material similarly distinguishes minimal protected evidence from indefinite\nretention of detailed AI-processing information.\n\nConsolidated Standardisation Position\n\nThese objections resolve into several cross-platform requirements:\n\n1. Structured intents and application APIs define available operations; Candidate Acts\ndefine exact instances of consequential execution.\n\n2. Application-specific semantics are normalized into a bounded set of consequence\nprimitives rather than interpreted comprehensively inside the PED.\n\n3. Equivalent consequences receive equivalent finality requirements even where\nrequester-specific identity evidence differs.\n\n4. Protected internals remain opaque; standardisation focuses on semantics, binding,\nevidence, attestation, and conformity.\n\n5. Software and model updates create explicit authority-version transitions rather than\nsilently inheriting old act-specific authority.\n\n6. Cross-device execution requires receiving-device finality or explicitly bounded joint\nauthorization.\n\n7. Crash consistency is handled through protected commit states, while exactly-once\nremote execution remains dependent on receiving-protocol semantics.\n\n8. Large and streaming artifacts use boundary-side incremental commitments rather\nthan bulk PED processing.\n\n9. Content commitments and attestation should be privacy-preserving rather than\nglobally linkable identifiers.\n\n10. Standards should define observable execution-finality invariants rather than\nprescribing platform implementation topology.\n\n11. Completeness of protected egress is established through an attested Finality\nBoundary Manifest and conformity testing.\n\n12. Background automation uses durable intent but fresh act-specific execution\nauthority.\n\n13. Validation evidence proves protected finality without requiring permanent retention\nof the underlying personal content.\n\nAdditional Technical Objections and Responses\nQ38. How can completeness of the Governed Egress Set be proven?\n\nDefining every consequence-producing boundary as a Finality Sink, or as structurally\ndownstream of one, addresses bypass conceptually. It does not by itself prove that every\npossible hardware and software egress path has actually been identified.\n\nA modern computing platform may contain multiple independent or semi-independent\nconsequence-producing components, including:\n\nCPU\nGPU\nNPU\nDMA engine\nbaseband / modem\nWi-Fi controller\nBluetooth controller\ndisplay processor\nsensor hub\nstorage controller\nsecure processor\nperipheral processor\nprivate framework\ncoprocessor\nfirmware-controlled path\n\nA single omitted path may defeat complete mediation.\n\nThe stronger approach is an attested Finality Boundary Manifest.\n\nFor each governed consequence class, the platform maintains a measured and versioned\ndescription of all hardware, firmware, protected-software, and controller boundaries capable\nof externalizing that class.\n\nFor example:\n\nNETWORK_EGRESS\n    -> cellular modem / baseband\n    -> Wi-Fi controller\n    -> Bluetooth controller\n    -> network egress controller\n\nDISPLAY_RELEASE\n    -> GPU output path\n    -> compositor\n    -> display controller\n    -> external-display controller\n\nDATA_TRANSFER\n    -> IPC\n    -> shared memory\n    -> DMA\n    -> file-provider boundary\n    -> storage controller\n\nSENSOR_RELEASE\n    -> sensor hub\n    -> DMA path\n    -> HAL delivery boundary\n    -> external transmission path\n\nPHYSICAL_ACTUATION\n    -> actuator controller\n    -> device-control coprocessor\n    -> motor / haptic / radio control boundary\n\nThe Finality Boundary Manifest should be:\n\n      measured;\n      versioned;\n      signed or attested;\n      bound to the hardware and firmware configuration;\n      associated with the active Finality Sink topology;\n      updated when firmware, controller configuration, or hardware state changes;\n      and independently testable through conformity procedures.\n\nThe conformance rule is:\n\nEvery component capable of externalizing a governed consequence must either perform\nFinality Sink verification itself or be structurally downstream of a protected boundary\nthat has already performed that verification.\n\nA new or modified GPU, DMA path, modem route, firmware module, private controller, or\ncoprocessor capable of externalization should change the measured platform state.\n\nThat change invalidates the previous finality-conformance attestation until the new topology\nhas been measured, classified, and incorporated into the Finality Boundary Manifest.\n\nThis produces two distinct conformity properties:\n\nMANIFEST INTEGRITY\n        +\nBEHAVIORAL COMPLETENESS\n\nManifest integrity proves that the declared Finality Sink topology corresponds to the\nmeasured platform configuration.\n\nBehavioral completeness tests whether each declared consequence class can actually be\nexternalized only through the stated governed boundaries.\n\nThe anti-bypass claim therefore does not rest on the statement:\n\n\"Every API has been intercepted.\"\n\nIt rests on the stronger property:\n\nEvery physical or logical boundary capable of producing the governed consequence is\npart of an attested egress topology and lacks independent effectuation authority outside\nthat topology.\n\nThis converts Governed Egress Set completeness from an architectural assertion into a\nmeasurable and testable platform property.\n\nQ39. What happens if a crash, power loss, network failure, or retry occurs\nbetween authorization consumption and external effectuation?\n\nExecution authority and external completion are separate problems.\n\nA Finality Sink may successfully verify a capability and consume protected authority, but the\ndevice may fail before the consequence becomes externally effective.\n\nFor example:\n\ncapability verified\n        v\nauthority consumed\n        v\nCRASH\n        v\nwas the external act completed?\n\nThe reverse order can also occur:\n\nexternal effect committed\n        v\nCRASH\n        v\nprotected consumed-state not fully recorded\n\nThis is different from partial completion of a multi-step workflow.\n\nIt is a crash-consistency problem inside the finality transaction itself.\n\nA protected Finality Sink should therefore implement an explicit commit state machine.\n\nFor example:\n\nISSUED\n   v\nARMED\n   v\nCOMMITTING\n   v\nEFFECT-COMMITTED\n   v\nCONSUMED\n\nor an equivalent protected sequence.\n\nThe exact sequence depends on the consequence class.\n\nLocally controlled consequences\n\nFor consequences under direct local control, authority consumption may be coupled closely\nor atomically with the relevant commit operation.\n\nExamples include:\n\n         protected storage commit;\n         secure-element transaction state;\n         protected display release;\n         local credential release;\n         actuator enablement;\n         local device-setting modification.\n\nWhere hardware permits, protected state advancement and effectuation should form one\natomic or crash-consistent transition.\n\nThe required property is:\n\neither:\n\nauthority remains unused\nAND\neffect does not occur\n\nor:\n\nauthority is consumed\nAND\nlocal effect is committed\n\nIntermediate ambiguous states should be recoverable from protected state.\n\nNetworked consequences\n\nFor external networked systems, the device cannot universally determine whether the remote\nconsequence occurred.\n\nFor example:\n\nSEND transaction X\n         v\nremote system executes X\n         v\nACK lost\n         v\ndevice cannot determine whether X should be retried\n\nExecution-finality architecture therefore should not claim universal exactly-once external\nsemantics.\n\nThe correct distinction is:\n\nThe architecture can enforce single-use or bounded-retry execution authority. Exactly-\nonce external effect additionally requires cooperation from the receiving protocol or\nservice.\n\nA stable Candidate Act identifier may be mapped to an external idempotency or transaction\nidentifier:\n\nCandidateActID = X\nExternalTransactionID = X\n\nAny retry must remain bound to:\n\n      the same Candidate Act;\n      the same resource;\n      the same destination;\n      the same requester;\n      the same action class;\n      the same transaction identity;\n      the same Finality Sink;\n      the same Effectuation Boundary;\n      and a bounded retry policy.\n\nFor example:\n\nCandidate Act X\n        v\nAttempt 1\n        v\nACK unavailable\n        v\nRetry authority for X only\n        v\nAttempt 2 carrying same transaction ID X\n\nThe receiving system, where it supports idempotency, can recognize that the second request\nrepresents the same logical transaction rather than a new authorized act.\n\nAuthority consumption and external completion must remain distinct\n\nThe architecture should therefore track two different properties:\n\nAUTHORITY STATE\n    Did the protected system permit this act?\n\nEXTERNAL COMPLETION STATE\n    Did the receiving system actually complete it?\n\nThe first can be protected locally.\n\nThe second may require:\n\n      protocol acknowledgement;\n      remote transaction state;\n      idempotency support;\n      settlement confirmation;\n      application-level completion evidence;\n      or equivalent external cooperation.\n\nA lost acknowledgement must not automatically create a fresh unrestricted capability.\n\nLikewise, a retry should not become authority for a new resource, destination, amount, or\noperation.\n\nThe bounded statement is:\n\nExecution finality prevents uncontrolled replay or reuse of execution authority; exactly-\nonce external execution is guaranteed only where the consequence-producing protocol\nalso provides appropriate transaction or idempotency semantics.\n\nQ40. How can a generic execution-finality layer govern arbitrary application\nactions without trusting application-defined meaning or becoming a universal\nsemantic engine?\n\nA generic execution-finality layer does not need to understand the complete business\nmeaning of every application operation.\n\nThe architecture should separate:\n\napplication-specific semantics\n\nfrom\n\nstandard consequence semantics.\n\nAn application may define operations such as:\n\nBookTrip\nPublishInvoice\nApproveExpense\nSubmitMedicalClaim\nShareAlbum\nSignContract\n\nThose names and their business meaning remain application-specific.\n\nThe execution-finality layer instead works with a smaller set of standardized consequential\nprimitives such as:\n\nDATA_DISCLOSURE\nNETWORK_TRANSMISSION\nMESSAGE_SEND\nPAYMENT_COMMIT\nCREDENTIAL_RELEASE\nIDENTITY_DISCLOSURE\nSTORAGE_COMMIT\nEXTERNAL_API_INVOCATION\nSENSOR_RELEASE\nDEVICE_SETTING_CHANGE\nPHYSICAL_ACTUATION\nPROTECTED_RENDER\nINTER_PROCESS_TRANSFER\n\nAn application-specific operation may map to one or more consequence primitives.\n\nFor example:\n\nPublishInvoice\n        v\nDATA_DISCLOSURE\n+\nNETWORK_TRANSMISSION\n+\nSTORAGE_COMMIT\n\nAnother example:\n\nBookTrip\n        v\nCREDENTIAL_RELEASE\n+\nEXTERNAL_API_INVOCATION\n+\nPAYMENT_COMMIT\n\nAnd:\n\nShareAlbum\n        v\nDATA_DISCLOSURE\n+\nNETWORK_TRANSMISSION\n+\nRECIPIENT_BINDING\n\nThe application may supply the initial mapping, but supplying a mapping does not create\nexecution authority.\n\nThe mapping is only the starting point for identifying the consequence classes that must be\ngoverned.\n\nThe actual effectuation path still binds machine-verifiable attributes such as:\n\nactual resource\nactual release-form commitment\nactual recipient\n\nactual destination\nactual amount\nactual credential\nactual external endpoint\nactual Finality Sink\nactual Effectuation Boundary\ncurrent epoch\nfresh nonce\n\nThe Finality Sink then verifies the real consequence at the boundary where it can become\neffective.\n\nThe architecture therefore does not need to determine:\n\n\"What does BookTrip mean philosophically or commercially?\"\n\nIt needs to determine:\n\n\"Which standardized consequential primitives will become effective if this operation\ncompletes, and does valid protected authority exist for each required consequence?\"\n\nStructured consequence schema\n\nApplications, operating-system frameworks, or standards-defined interfaces may expose a\nstructured consequence schema.\n\nFor example:\n\nAPPLICATION ACTION:\n    BookTrip\n\nCONSEQUENCES:\n    EXTERNAL_API_INVOCATION\n    CREDENTIAL_RELEASE\n    PAYMENT_COMMIT\n\nBOUND ATTRIBUTES:\n    travel_provider = X\n    passenger_record = Y\n    amount <= Z\n    payment_destination = P\n\nThe semantic mapping may be application-provided, framework-provided, standardized, or\nderived from system-level interfaces.\n\nBut load-bearing release attributes should still be independently verified at their relevant\nFinality Sinks.\n\nUnknown or novel action classes\n\nWhen a new operation cannot be mapped safely to a known consequence class, the\narchitecture should not silently treat it as harmless.\n\nPossible responses include:\n\n      require registration of a structured consequence schema;\n      require explicit resource, destination, and action-class mapping;\n      classify according to the downstream Effectuation Boundary;\n      require stronger trusted-user confirmation;\n      place the act into a higher-risk unknown-action class;\n      or fail closed where a consequential operation cannot be reliably classified.\n\nA useful default rule is:\n\nUnknown application meaning does not imply unknown technical consequence.\n\nEven if the system does not understand the business semantics of PublishMedicalAnalysis,\nit can still recognize that the operation is about to:\n\nread protected file\n        v\nserialize data\n        v\ntransmit to external endpoint\n\nand govern those concrete consequences.\n\nThe PED remains small\n\nThis separation also prevents semantic normalization from turning the Protected Execution\nDomain into an enormous policy engine.\n\nThe PED does not need:\n\n      a dictionary of every application command;\n      natural-language understanding of every business operation;\n      full application logic;\n      arbitrary workflow interpretation.\n\nIt needs a bounded representation of:\n\n      consequence class;\n      protected resource;\n      destination;\n      requester;\n      authority scope;\n      policy state;\n      user-intent state where required;\n      sink;\n      boundary;\n      freshness;\n      cumulative state where applicable.\n\nThe architecture therefore scales through a two-layer model:\n\nAPPLICATION SEMANTICS\n\n        v\nstructured mapping\n        v\nSTANDARD CONSEQUENCE PRIMITIVES\n        v\nexact Candidate Act\n        v\nprotected authority\n        v\nactual Finality Sink\n\nThis avoids both undesirable extremes:\n\nTRUST APPLICATION MEANING COMPLETELY\n\nand\n\nMAKE THE PED UNDERSTAND EVERY APPLICATION\n\nThe governing principle is:\n\nApplications define what their operations mean at the application layer; execution\nfinality governs the concrete consequence primitives through which those operations\nbecome externally effective.\n\nConsolidated Technical Position\nThese three objections correspond to three different completeness properties.\n\nHardware completeness\n\nCan every consequence-producing route be identified and proven to remain inside the\nprotected egress topology?\n\nAddressed through:\n\nGoverned Egress Set + attested Finality Boundary Manifest + conformity testing.\n\nTransactional completeness\n\nCan execution authority remain correct across crashes, retries, and uncertain remote\ncompletion?\n\nAddressed through:\n\ncrash-consistent sink state + single-use/bounded-retry authority + external idempotency\nwhere supported.\n\nSemantic completeness\n\nCan arbitrary application operations be governed without requiring complete\nunderstanding of arbitrary application meaning?\n\nAddressed through:\n\napplication-specific semantics -> standardized consequence primitives -> exact\nboundary verification.\n\nTogether:\n\nAPPLICATION ACTION\n        v\nCONSEQUENCE NORMALIZATION\n        v\nCANDIDATE ACT\n        v\nRELEASE-FORM COMMITMENT\n        v\nPROTECTED AUTHORITY\n        v\nATTESTED GOVERNED EGRESS SET\n        v\nCRASH-CONSISTENT FINALITY SINK\n        v\nEXTERNAL EFFECT\n\nThe combined invariant is:\n\nEvery externally consequential operation must be reducible to one or more machine-\nverifiable consequence classes, every technical route capable of externalizing those\nconsequences must belong to an attested governed egress topology, and execution\nauthority must remain bounded and crash-consistent until the corresponding Finality\nSink controls the actual release.\n\nSecurity Considerations\n\n   This document is primarily concerned with security architecture.\n   Security considerations include compromised applications or AI\n   assistants, replay, substitution, unauthorized redirection, stale or\n   revoked authority, alternate egress paths, and failure to verify\n   authority at the first usable release boundary. The architecture\n   described in this document uses fail-closed verification and scoped\n   execution authority to address these classes of risk. It does not\n   claim security after compromise of the trusted hardware root,\n   protected execution domain, or cryptographic root of trust.\n\nIANA Considerations\n\n   This document has no IANA actions.\n\nAuthor's Address\n\n   Sangam Das\n   Independent Inventor\n   Balasore, Odisha\n   India\n\n   Email: info@sangamdas.com\n```\n\n␃WPNCODE0␃\n\ndraft-das-execution-finality-ai-interoperability-00\n\nActive Internet-Draft\n(individual)\n\n| Document | Document type |\nActive Internet-Draft\n(individual)\nThis document is an Internet-Draft (I-D).\nAnyone may submit an I-D to the IETF.\nThis I-D is\nnot endorsed by the IETF and has no formal standing in the\n|\n|\n|---|---|---|---|\n| Select version | |||\n| Author |\n|", "url": "https://wpnews.pro/news/ietf-publication-closing-apple-siri-eu-deadlock-without-sacrificing-security", "canonical_source": "https://datatracker.ietf.org/doc/html/draft-das-execution-finality-ai-interoperability-00", "published_at": "2026-08-23 14:24:20+00:00", "updated_at": "2026-08-23 14:44:22.834753+00:00", "lang": "en", "topics": ["ai-policy", "ai-safety", "ai-agents"], "entities": ["Sangam Das", "Internet Engineering Task Force", "Apple", "Siri", "European Union", "Digital Markets Act"], "alternates": {"html": "https://wpnews.pro/news/ietf-publication-closing-apple-siri-eu-deadlock-without-sacrificing-security", "markdown": "https://wpnews.pro/news/ietf-publication-closing-apple-siri-eu-deadlock-without-sacrificing-security.md", "text": "https://wpnews.pro/news/ietf-publication-closing-apple-siri-eu-deadlock-without-sacrificing-security.txt", "jsonld": "https://wpnews.pro/news/ietf-publication-closing-apple-siri-eu-deadlock-without-sacrificing-security.jsonld"}}