Abstract

“Payment sent.” “Stock reserved.” “Firmware updated.” “Door unlocked.” Multi-step AI agent workflows move to the next step when the previous one reports success. But none of the following means the real-world effect has happened: code finishing, an API returning 200 or 202, a job being queued, a signature verifying, or an action being authorised. Agents can hallucinate an acknowledgement, believe success after a timeout, accept a forged tool output or reuse a genuine result from a different operation. If the next step treats that claim as permission, the system ships goods that were never paid for, refunds twice, releases a batch that failed quality checks, or drives a device on stale state.

This disclosure makes each dependent step wait for verified proof that the required earlier effect actually occurred:

  1. A qualified observer produces a Protected Effect Receipt (PER) for the predecessor’s real outcome.
  2. An identity-authenticated Interim Effectuation Validator (IEV) checks the receipt against the correct predecessor operation and resource, the required effect predicate (for example a committed resource version or a confirmed reservation), freshness, revocation, and workflow phase lineage.
  3. Acceptance yields a Validator-Accepted Effect Receipt (VAER), which constitutes a single-use Causal Continuation Condition (CCC). The CCC can be realised as a key, capability, latch, state or gateway release, and is bound to the workflow, phase, designated sink and authority generation.
  4. The successor’s Finality Sink independently reconstructs the actual pending operation. It releases the operation only if its own current source grant, the CCC, scope, resource and sink state all match, and it consumes the condition atomically.

Further safeguards apply throughout:

  • A receipt never broadens the successor’s authority.
  • Dispatch or HTTP acceptance never counts as completion.
  • Where there are multiple predecessors, all must be qualified.
  • Branch substitution and cycles are rejected.
  • Timeouts become explicit indeterminate states that are reconciled before any retry.
  • Alternate interfaces cannot bypass the gate.

The disclosure includes key points for examiners with search terms, architecture and decision-gate drawings for each source unit, receipt structures and state machines, ten implementation variations, a ten-threat model, twenty-four proposed validation tests, and IETF and EU AI Act mappings.

Industry relevance (AI-generated): the patterns apply to publicly described environments, including:

  • Apple iOS, iPadOS, macOS, Siri, Shortcuts and App Intents
  • Google Android, Gemini, Intents, Binder, Keystore and Google Cloud
  • Samsung Bixby; Microsoft Windows, Azure and Copilot; Amazon Alexa
  • OpenAI Responses API, Agents SDK and Codex; Anthropic Claude, Claude Code and managed agents
  • Meta Muse/Sentinel; NVIDIA OpenShell, BlueField and Sentry; Qualcomm Snapdragon, Arm and Huawei device security
  • agentic commerce and digital wallets; logistics; healthcare ordering; insurance and lending; travel booking
  • Matter smart-home and physical access; Apple CarPlay and Android Auto; energy grid switching
  • the EU Digital Identity Wallet; App Store and Google Play staged rollouts

Names identify integration environments only. No vulnerability, deficiency, implementation or infringement is alleged, and no endorsement is implied. This material is AI-generated and must be cross-checked against the original PCT filings and primary sources before drawing any conclusion.

This technical disclosure is based on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026 (WO 2026/150382), which claims priority from PCT/IB2026/053385, filed 7 April 2026 and publicly disclosed 4 June 2026 (WO 2026/115520). The source text corresponds to the following units of the 3,567-page specification published on Zenodo (https://zenodo.org/records/23657985):

  • Common Workflow CW-2 and its implementation clarification;
  • Embodiment 2 and its supplementary disclosure;
  • combined Embodiments 1 and 2;
  • supporting Embodiment 4 material.

These units appear at pages 63–119, 179–196, 295–363, 378–406, 407–436 and 493–554. The page numbers refer to that specification, not to the PCT page count. This document expands Internet-Draft draft-das-causal-effect-receipts-00, dated 26 October 2026 (Part 6 of a 12-part series). Diagrams, schemas, implementation variations, threat classifications and proposed tests are newly authored explanations, not claimed as filed content or experimental results. Related family applications can be cross-checked on WIPO PATENTSCOPE. Licensed under CC BY-NC 4.0. The author is open to acquihire or strategic collaboration.

Keywords

AI agent workflow security; multi-step agent; effect receipt; proof of effect; causal continuation; receipt-gated execution; saga pattern; workflow orchestration; HTTP 202 accepted; asynchronous operation; idempotency; duplicate payment; double refund; replay attack; receipt replay; fabricated tool output; hallucinated success; prompt injection; validator; witness; attestation; time-of-check to time-of-use; indeterminate outcome; reconciliation; agentic commerce; supply chain; execution finality; Finality Sink; EU AI Act.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS