Platform approves manual late-cancel decisions and historical token retention
Position
Platform acknowledges ADR-0056. Delivery owns the operator choice, durable intent, lesson outcome, and token-store retirement. Revenue retains financial settlement authority. The existing reservation-release contract accepts initiator=admin and reason_code=customer_requested_exception; the explicit-operator subset already represents an approved out-of-window exception. This design needs no new Platform endpoint, event type, payload version, or service-auth capability. Revenue's owner review remains necessary to confirm implementation semantics and exact terminal evidence.
Platform retains waiver_token.granted and waiver_token.spent schema version 1 in the canonical event registry and SDK mirror, together with their payload schemas. Stopping producer activity does not remove historical event validity or warehouse ingestion and replay compatibility. Retain waiver_token_applied in the reservation-release API and credit.released schemas for historical financial facts and existing-spend recovery. Preserve the separate coach_no_show, coach_late_cancel, and service-recovery-credit behavior outside token grants. Existing records are neither repriced nor converted into new credits.
Publication and cutover
Delivery, as ADR and token-contract owner, collects explicit Revenue, Finance, and Platform acknowledgments before recording ADR-0056 acceptance. ADR-0020 remains Accepted during proposal review. After acceptance, publish a linked supersession notice for ADR-0020's active grant and spend policy, retaining its historical body and making the coordinated cutover condition explicit. Delivery publishes the cancellation-waiver-token contract's retirement notice and change-log entry, identifying the retained historical specification and existing-spend recovery boundary. Preserve semantic version metadata; active behavior retirement is not a payload schema deletion.
Platform's gated commitment covers the corresponding credit-reservation-lock documentation and event-registry retirement notes. The documentation must distinguish accepted policy from runtime activation, preserve historical enum values and event registrations, and identify the retained recovery path. No wire-interface version change is proposed. Indexed header and memo edits require the coordination indexer and freshness check, and any registry edit requires registry validation and a matching SDK mirror. Owners publish through their own coordination clones.
Acceptance and documentation publication do not authorize production migration or deployment. Delivery retains the reviewed direct or session-pooled lock connection, additive migration proof, isolated exact-state financial fixture proof, zero unresolved historical token releases or explicit owner disposition, and read-only verification of the independently identified production target as release gates. The configured-target zero-spend observation alone does not clear that final production gate. Preserve original release identities, do not create grants or spends during retained historical recovery, and keep manually uncharged late-cancels outside the reason-only correction classifier until a separately approved interface exists.
References
Publication completed on 2026-10-09 following Delivery's acceptance and token-contract retirement publication 86536f013d3d47c8cdb74d1f55f05e0eb2ce2f21. The credit-reservation-lock policy notice and canonical event-registry notes retain all historical schemas and reason codes; the two token entries are mirrored into Platform's local SDK registry. This documentation completes Platform's declared publication commitment. Delivery source, migration, financial fixture, historical disposition and runtime activation gates remain separate.