Revenue approves ADR-0056 manual late-cancel policy with retained cutover gates
Revenue approves ADR-0056's design. The manual choices use existing financial semantics; no new Revenue endpoint or event type is required. This is policy/design acknowledgment, not production readiness or activation approval. Existing release gates, historical financial records, scheduling protections and separately governed correction flows remain intact.
Financial choices
charge submits the existing reservation forfeiture operation with forfeiture_reason=late_cancel, the exact organization and lesson, the pinned reservation and original decision identity. runReservationForfeitPg requires a LOCKED reservation, a positive integral reserved quantity and one matching lock debit. It reverses that lock debit and writes CREDIT_FORFEIT for the full reserved quantity, with producer-transactional credit.forfeited@1. It does not accept a partial amount or reprice from a newly selected Lesson Type. A RESERVED, released or consumed reservation is not permission to synthesize a lock or a replacement charge.
do_not_charge submits release with initiator=admin, reason_code=customer_requested_exception and the original identity. This is an explicit operator exception, not an in-window cancellation and not a waiver-token spend. The existing release service permits release from RESERVED or LOCKED, preserves the original quantity, links the lock reversal where applicable and emits credit.released@2. Neither choice changes Delivery's true Canceled / Client Late-Cancel outcome. Client no-show policy and coach no-show service-recovery credits remain separate.
Exact evidence and retry requirements
The release route validates organization and any supplied lesson against the reservation. The forfeiture route also validates those relationships, but its response does not itself contain the complete lesson evidence. Delivery must always send the exact lesson and independently verify one authoritative row matching organization, lesson and reservation with the intended terminal state before atomic lesson/journal finalization. No missing, duplicate, mismatched or unverifiable row may be treated as success.
In particular, release can return HTTP 200 already_terminal with lifecycle_state=forfeited; that is not a successful no-charge decision. Its echoed request reason is not proof of the historic transition cause. The reviewed Delivery manual path checks the exact terminal state before and after submission. An opposite terminal outcome requires review, not another key or another operation.
Revenue's existing idempotency receipt keys operation, organization and idempotency key, hashes the payload, replays retained results and conflicts on changed payload. Receipts are recorded after the handler and have a 24-hour default retention horizon. They are not an atomic admission lock around two simultaneous handlers, and keys are scoped separately across release and forfeit. Therefore Delivery's durable original-choice journal and shared per-lesson serialization are load-bearing: retain choice, operator, original notes, outcome version and lock identity; serialize competing save/correction/reschedule paths; retry the same identity and payload after timeouts or local-finalization failure. Never rely on receipt retention alone to prevent switching from release to forfeiture. Expired/missing receipts require authoritative state verification, not invented success.
Historical waiver releases and corrections
Revenue retains waiver_token_applied compatibility. Existing-spend recovery uses initiator=customer, the original organization/lesson/reservation and original release key. Delivery's retained recovery service reads the existing spend and exact Revenue state; it does not mint a grant or spend. Released or already reversed history is preserved; pending or unverifiable state cannot be erased or repriced. Consumed/forfeited conflicts and payload mismatch require owner review rather than automatic conversion, new spending or forced release.
The older cancellation-waiver-token section 4.5 describes compensating spend-reversal grants. The coordinated retirement publication must explicitly preserve that historical meaning while making clear that post-cutover recovery does not create new grants/spends. An unfinished pre-cutover release must be resolved or explicitly owner-disposed before activation. Delivery's reported zero spends on a configured hosted target is not independent production clearance. Revenue has no exact unresolved production release IDs to dispose in this review and grants no blanket historical disposition. A production-identified, organization-scoped inventory with zero unresolved rows, or a per-row approved disposition, remains outstanding.
The reason-only correction classifier cannot distinguish a manually uncharged late-cancel from a forfeited one. Revenue endorses Delivery's guard requiring manager and Revenue review for that case until a separately approved interface exists. Do not bypass it by relabeling the cancellation or supplying a charged classification. Charged-outcome correction may clear the current-choice pointer while preserving the append-only decision journal and ordinary correction safeguards. Unused tokens are retired without credit conversion or retroactive recognition/ledger changes.
Financial cutover proof still required
Before release, provide exact reviewed deployment/source revisions, direct/session-pooled lock configuration and additive migration proof, plus isolated financial fixtures for both choices. Prove full reserved quantity, lock reversal lineage, stored-versus-ledger consistency, recognition treatment under existing provenance rules, one terminal event, exact organization/lesson/reservation evidence and no duplicate effects. Include same-choice replay, response-loss and Delivery-finalization recovery, changed-choice/payload rejection, simultaneous requests, opposite terminal states, missing/mismatched/duplicate authoritative rows, and correction/reschedule contention. Historical release recovery must retain the original key and emit no new token grant/spend. Do not infer these integration results from mocked UI tests or this design acknowledgment.
All existing deployment, cutover and read-only production verification gates remain. This review authorizes no production DDL, synthetic financial writes, deployment, activation, historical repricing or unused-token conversion.
Review basis
ADR and request reviewed at coordination publication pin 462a24efa49e3ff1cb277c77ee2648875d71f679. Revenue source basis: checkout fecab1cc63c5ef46aad551b3bb4a438ff3606a21; the four reviewed release/forfeit/idempotency files have no diff against retained cleanup revision 1409053. This is source comparison, not a current serving-deployment attestation. Delivery's prepared working-tree policy, settlement, decision-journal, waiver recovery and correction guard were read as implementation evidence, not declared deployed.
Relevant sources: Revenue modules/credit-reservation/service.release-api.ts, service.forfeit-pg.ts, routes/forfeit-api.routes.ts, lib/mutating-api-idempotency.ts; Delivery modules/lesson-settlement/service.ts, modules/lesson-late-cancel-decision/repo.ts, modules/waiver-token/service.ts, modules/lesson-outcome-correction/service.ts; credit-reservation-lock section 6 and reservation-release API; cancellation-waiver-token section 4.5. Verification was scoped source/contract review; no financial tests or production operations were rerun.