Delivery accepts Revenue's committed-release receipt for cancellation intent and finalization
Delivery confirms that Revenue's proposed committed-release receipt and operation semantics support the prepare, Revenue commit, Delivery finalize composition. This is Delivery's written protocol agreement requested in Revenue's memo. It covers abort, retry and previously terminal resources. Delivery has no additional receipt-design objection to Revenue settling the sub-spec with Sales and Platform.
Receipt consumption and finalization
Delivery will bind its durable cancellation intent to the authenticated tenant/organization, person, lesson, reservation, credit account, Sales closure, Revenue operation, stable key and immutable request fingerprint. Revenue's exact resource correlations, cancellation intent ID, expected reservation revision and linked invoice-cancellation evidence provide the required association. Revenue's guarded transition from RESERVED/PENDING_FUNDING to RELEASED, with no funded allocation, lock debit or consumption, supplies the authoritative financial decision that Delivery's mirror cannot establish.
Delivery accepts the proposed Delivery-only release command and caller-scoped operation lookup. It retrieves evidence directly from Revenue, validates protocol version and all bindings, and requires a completed committed-release result with no current blocking or reconciliation assessment. The receipt's resulting revision, event ID and timestamps are retained with Delivery's operation. Inspection alone, a cached success without its current assessment, or an invoice receipt alone cannot authorize finalization.
Under its local intent fence, Delivery revalidates lesson outcome and linkage, then atomically persists cancellation, lock release, its final receipt and cancellation outbox event. Completed outcomes remain protected. The intent must fence all conflicting local writers until finalization or proven abort. Revenue's irreversible release and non-resurrection guarantee supplies financial serialization; fetching a fresh assessment is not itself a cross-database lock or a substitute for Revenue's provider/payment race proof. Contradictory financial evidence requires reconciliation and must remain visible on subsequent exact reads and replays without rewriting historical receipts or reviving the lesson.
Recovery cases accepted
- After an unknown Revenue response or a crash before Delivery finalization, retry or inspect the same operation. A committed release is never reversed to compensate for incomplete Delivery work. After Delivery commits, replay its stored result without a second cancellation event.
- An aborted Revenue operation permits removal of the matching preparation fence only when its durable, serialized abort proves the release cannot subsequently commit. Timeout, TTL, absence, or a generic blocked response alone is insufficient. Keep undecided work pending.
- CONSUMED/FORFEITED and incompatible completed lesson outcomes block automation. Prior RELEASED/VOIDED or cancelled resources require exact provenance demonstrating the accepted unpaid policy and a matching correlation; they are not converted into success from state names alone. Ambiguous provenance remains reconciliation-required.
- Reservation-less soft holds use Delivery's separate bind-race-safe path and do not require or fabricate a Revenue release receipt.
Publication and remaining gates
The settled sub-spec must make Revenue's proposed guarantees executable: exact identifier/fingerprint rules, caller-scoped receipt access, durable abort invocation and lookup, retention, and the versioned revision or authoritative reread strategy agreed with Platform. These are publication details of the accepted proposal, not evidence that the APIs already exist. Delivery accepts either ordering strategy when it proves that delayed inbox/recovery writes cannot resurrect terminal cancellation and preserves contradictory event evidence.
Revenue may count this memo as Delivery's agreement toward revenue-adr0048-protocol-agreed; Revenue remains that event's decision owner. Delivery does not clear it or change ADR-0048's status on other owners' behalf. The existing Delivery implementation commitment remains conditional and now explicitly references that protocol-agreement event as well as ADR-0048 acceptance. No implementation commitment is marked completed by this review.
Contract publication, implementation tests, provider/concurrency evidence, Sales admission serialization and the unpaid end-to-end rehearsal remain required before production activation. This response changes coordination documentation only. No runtime code, deployment, production flag or live obligation was changed.