Network Working Group I. Schrock Internet-Draft EMILIA Protocol, Inc. Intended status: Informational 27 July 2026 Expires: 28 January 2027 Action Remedy Receipts for Consequential Agent Effects draft-schrock-action-remedy-receipts-00 Abstract Revocation cannot undo an effect that already occurred. A dispute does not authorize a refund, return, reversal, or other remedy. This document defines Action Remedy Receipts for recording a bounded dispute decision and a fresh compensating action without rewriting the original action or effect. Every remedy has its own operation identifier, CAID, action digest, authority, consequence owner, and execution result. Indeterminate outcomes remain fenced until authenticated reconciliation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Schrock Expires 28 January 2027 [Page 1] Internet-Draft Action Remedy Receipts July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Lifecycle Invariants . . . . . . . . . . . . . . . . . . . . 3 3. The Remedy Receipt . . . . . . . . . . . . . . . . . . . . . 3 4. Processing Model . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Open a Case . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Decide Separately . . . . . . . . . . . . . . . . . . . . 4 4.3. Execute a Fresh Compensating Action . . . . . . . . . . . 4 4.4. Reconcile Uncertainty . . . . . . . . . . . . . . . . . . 4 5. Claim Boundary . . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Implementation Status . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Consequential systems need a lifecycle after execution: late revocation, dispute intake, decision, remedy authorization, remedy execution, and reconciliation. Collapsing these steps creates two unsafe fictions: that revocation rewrites history, or that opening a dispute authorizes a compensating effect. This document defines a signed record family that preserves the original effect and binds each later step. It does not define legal entitlement, adjudication, insurance coverage, payment finality, or a universal remedy policy. It uses CAID [CAID] for exact compensating- action identity, composes with the AEB lifecycle [AEB], and preserves the separate revocation semantics in [REVOCATION]. Schrock Expires 28 January 2027 [Page 2] Internet-Draft Action Remedy Receipts July 2026 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. 2. Lifecycle Invariants 1. A revocation withdraws future authority for its exact target. It MUST NOT relabel or delete an earlier provider result. 2. A dispute is a bounded challenge and evidence set. It MUST NOT be treated as a decision or remedy authorization. 3. A decision is separately authorized and bound to one dispute. It MAY authorize no remedy or one or more bounded remedy legs. 4. Every remedy leg is a fresh compensating action. It MUST use a new operation identifier and a different action digest from the original. 5. An uncertain original or remedy effect remains INDETERMINATE. It MUST NOT be blindly retried or called reversed. 3. The Remedy Receipt An EP-ACTION-REMEDY-v1 payload contains exactly these logical groups: case case_id, tenant or reliance domain, opened_at, and the pinned remedy-profile digest. original original operation_id, CAID, action_digest, consequence owner, owner-profile digest, terminal evidence digest, and observed owner result. dispute dispute_id, challenger, evidence digests, requested remedy units and unit, and opening time. decision decision artifact digest, verifier profile, decision authority, decision time, and result of no_remedy or remedy_authorized. remedy new operation_id, CAID, action_digest, destination binding, units, unit, selected consequence owner, owner-profile digest, and authority evidence digests. result authorized, claimed, executed, refused, indeterminate, or Schrock Expires 28 January 2027 [Page 3] Internet-Draft Action Remedy Receipts July 2026 reconciled, plus authenticated owner evidence and observation time. The signed payload MUST bind all groups that apply to its state and a monotonic revision. Unknown members are refused unless a negotiated extension profile defines their signing and processing semantics. 4. Processing Model 4.1. Open a Case The relying party MUST verify that the original operation, action digest, CAID, owner result, and terminal evidence refer to the same protected effect. If the original result is INDETERMINATE, the case can accept petition evidence but MUST NOT authorize an effectful remedy until authenticated reconciliation establishes EXECUTED. 4.2. Decide Separately The decision verifier, trust roots, policy, and decision authority are relying-party inputs. A valid dispute signature does not grant decision authority. A decision of no_remedy closes the case without inventing a compensating action. A remedy authorization MUST bind the exact remedy leg and a limit no greater than the remaining case amount. 4.3. Execute a Fresh Compensating Action The remedy operation_id, action_digest, and CAID MUST differ from the original. The compensating action then traverses the same evidence, authorization, durable claim, provider invocation, and reconciliation controls as any other consequential action. The original record remains immutable. An implementation MUST represent rollback as false: the protocol records compensation, not time reversal. A physical return, monetary refund, fee reversal, inventory change, and entitlement revocation are different material effects. Each MUST be a separately bound leg. A shared decision can authorize multiple legs, but evidence for one leg MUST NOT be replayed as another. 4.4. Reconcile Uncertainty An indeterminate remedy remains claimed and fenced. Authenticated evidence for the same operation MAY establish executed or proved_no_effect. The latter returns the case to its prior disputed state without consuming remedy units. Conflicting or mismatched evidence leaves the operation indeterminate. Schrock Expires 28 January 2027 [Page 4] Internet-Draft Action Remedy Receipts July 2026 5. Claim Boundary A valid receipt can show that named parties signed the bounded case, decision, remedy, and owner evidence and that the technical bindings are internally consistent. It does not prove legal liability, consumer entitlement, adjudicator correctness, availability of funds, delivery of goods, or reversal of an external effect beyond the accepted owner evidence. 6. Security Considerations Implementations MUST refuse original/remedy action equality, operation replay, authority substitution, decision/dispute role substitution, evidence reuse across remedy legs, limit overflow, stale status, wrong tenant, wrong consequence owner, and unauthenticated reconciliation. Durable compare-and-swap state is required when multiple workers can claim a remedy. Store ambiguity fails closed. 7. IANA Considerations This document requests no IANA action. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [AEB] Schrock, I., "The Action Evidence Boundary for Consequential Agent Effects", Work in Progress, Internet- Draft, draft-schrock-action-evidence-boundary-01, July 2026, . Schrock Expires 28 January 2027 [Page 5] Internet-Draft Action Remedy Receipts July 2026 [CAID] Schrock, I., "The Canonical Action Identifier (CAID)", Work in Progress, Internet-Draft, draft-schrock-canonical- action-identifier-01, July 2026, . [REVOCATION] Schrock, I., "Revocation Statements for Agent-Action Authorization Evidence", Work in Progress, Internet-Draft, draft-schrock-ep-revocation-statement-01, July 2026, . Appendix A. Implementation Status An Apache-2.0 TypeScript reference kernel is published in the EMILIA Protocol repository. It includes durable remedy cases, bounded units, distinct original and remedy CAIDs and action digests, claim fencing, multi-leg case sets, authenticated owner results, indeterminate reconciliation, tests, and a TLA+ lifecycle model. It is same-team implementation evidence, not an independent implementation, legal remedy system, or operated deployment. Author's Address Iman Schrock EMILIA Protocol, Inc. United States of America Email: team@emiliaprotocol.ai Schrock Expires 28 January 2027 [Page 6]