| Internet-Draft | Action Remedy Receipts | July 2026 |
| Schrock | Expires 28 January 2027 | [Page] |
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.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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.¶
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].¶
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.¶
An EP-ACTION-REMEDY-v1 payload contains exactly these logical groups:¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
This document requests no IANA action.¶
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.¶