Revenue acknowledges ADR-0038 with durable correction, balance, and service-recovery guardrails
Revenue acknowledges ADR-0038 and accepts Option A. Delivery should own the guarded operator workflow and effective lesson outcome. Revenue should own the compensating financial write and classification. The original lesson lifecycle events, terminal reservation state, ledger entries, and recognition rows remain immutable. Corrections add linked facts instead of rewriting history.
The proposed preview and apply boundary is the right cross-domain seam. Revenue can resolve the reservation and account, calculate the customer-credit effect, inspect the original ledger and recognition facts, apply an append-only correction, and return stable references for Delivery's finalization and lesson.outcome.corrected event.
The following constraints are normative for Revenue's acknowledgment. They refine the implementation and contract shape without changing the chosen option.
Durable correction identity and preview state
correction_id must be Revenue's durable natural idempotency key, not only an input folded into the generic Idempotency-Key cache. Revenue's existing generic mutating-API idempotency records expire after 24 hours, which is not sufficient for recovery after Revenue apply succeeds and Delivery finalization remains pending. Revenue will persist a correction record keyed by organization plus correction id. A replay of the same correction and semantic payload returns existing indefinitely. Reuse of the correction id with a different semantic payload returns 409 correction_payload_mismatch.
The preview state token must be opaque, bounded in lifetime, and bound to the organization, correction, lesson, reservation, credit account, original and proposed outcomes and reasons, signed credit delta, effective financial classification, and the Revenue fact versions used for the preview. Apply must re-read and validate those facts in the same transaction that writes the correction. A stale token fails without posting any entry.
Credit balance and reservation coverage
A negative correction is not automatically safe merely because its arithmetic is correct. Between the original outcome and the correction, the customer may have spent credits or created new reservations against the returned balance. Preview must return the post-correction balance and available balance, including active reservation coverage, and must block automatic apply when the debit would create a negative balance, impair an active reservation, or encounter drift between stored balance and ledger-derived balance. Those cases route to manager and Revenue review. The correction endpoint must not silently manufacture account drift to repair outcome drift.
The signed net_credit_delta and the effective_financial_classification remain separate facts. A net-zero correction can still require append-only recognition reclassification. Revenue will link every correction entry and recognition or contra-recognition row to the correction, original reservation, lesson, and source financial facts.
Service-recovery benefit state
Revenue can identify a service-recovery grant tied to the source lesson, but Revenue does not currently allocate later debits across individual credit lots. It therefore cannot truthfully classify a particular granted credit as unused or spent. Until lot allocation or an equivalent explicit use marker exists, preview will report whether a lesson-linked grant is absent, present, or already reversed. If the proposed correction would revoke an unreversed service-recovery grant, automatic apply must block and route to manager and Revenue review. Revenue will not infer spend from aggregate balance and will not automatically claw back the grant.
Delivery remains authoritative for waiver-token use and compensation-task state. Revenue's preview reports only Revenue-owned service-recovery and financial facts.
Contract and readiness boundary
Platform remains the owner of the credit-reservation-lock parent contract. Revenue will author the correction API sub-spec and implementation semantics, Delivery will review the consumer shape, and Platform should publish the parent-contract amendment after the ADR acknowledgment round. The sub-spec must include the durable correction key, token staleness rules, balance and reservation blockers, service-recovery status vocabulary, error taxonomy, and the full transition matrix for positive, negative, and net-zero corrections.
Revenue's conditional commitment is ready when ADR-0038 is accepted. Revenue will clear event:revenue-lesson-outcome-correction-api-ready only in a Revenue-authored production-readiness memo after both endpoints are deployed, migrations are applied, the correction matrix and retry paths pass, the ledger audit passes, and a production request proves stable preview and idempotent apply behavior. Delivery's capability flag should remain fail closed until that memo lands.
Asks
Delivery, please carry these constraints into the accepted ADR or its normative contract amendment:
- Durable correction-id replay must outlive the generic idempotency cache.
- Negative deltas must protect current balance and active reservation coverage.
- Service-recovery spend must not be inferred while credit-lot allocation is absent.
- Platform remains the parent-contract owner, with Revenue owning the correction API sub-spec and implementation.
This memo is Revenue's explicit ADR acknowledgment. The requested clarifications are implementation guardrails, not an objection to Option A.
References
- ADR-0038:
adrs/ADR-0038-guarded-lesson-outcome-corrections.md - Delivery proposal:
2026-07-29-delivery-guarded-lesson-outcome-corrections-proposal - Revenue scope and append-only rule:
domains/revenue.md - Credit reservation lock contract:
contracts/credit-reservation-lock/README.md - Service-recovery grant API:
contracts/credit-reservation-lock/service-recovery-credit-grant-api.md - ADR-0006:
adrs/ADR-0006-credit-reservation-lock-state-machine.md