Revenue correction preview uses a stale stored balance and blocks the supervised ADR-0038 correction
Production incident
Delivery started the supervised production correction required for ADR-0038 closeout. The operator previewed a correction of lesson les_019ebd2b-7e77-722d-b9f1-ab74a2f951c3 from Completed to Canceled with reason Bad Weather. The original reservation crr_019ebd2b-7ffa-7b54-a269-aaf5d7bbacd0 is consumed for three credits.
Revenue preview lop_019fb4e6-0e42-7ef6-ab9f-f4dcd45e8742, under correction id loc_019fb4e6-0cdd-746e-9cb5-f60f31df8a0f, returned a positive three-credit adjustment but reported both post-correction balance and available credits as 30. It also returned effective_financial_classification: review_required with blocker stored_ledger_balance_drift.
Delivery did not submit apply. The Workbench correctly disabled confirmation because the preview status was not ready. No Lesson row, Delivery correction row, Revenue correction row, or customer credit record was changed.
Balance evidence
The exact credit account is crd_acct_019e524c-7c60-7acd-8dda-61fc1b7d5059 in organization org_01900000-0000-7000-8000-000000000001.
At preview time, Revenue held:
- Stored
CreditAccount.balanceCredits: 27 credits. - Spendable ledger balance: 3 credits.
- Spendable ledger composition: 27 purchase credits and 24 lesson-debit credits.
- Open active reservations: 0 credits.
Revenue's credit-account coverage read returned the safe three-credit balance shown in Delivery's payment drawer. That read selects the lower of the stored balance and spendable ledger balance. The correction preview instead calculated its hypothetical balance from the raw stored value, producing 27 + 3 = 30, even though the ledger-derived hypothetical is 3 + 3 = 6.
This leaves operators with two conflicting Revenue values. The ordinary coverage surface correctly reports three spendable credits, while the correction preview displays 30 and then blocks on the same drift that made 30 unreliable.
Asks
Revenue, please:
- Reconcile the stored balance for the exact account from 27 credits to the authoritative three-credit spendable ledger balance using a guarded, auditable repair. Preserve all original ledger and reservation history, and do not post a synthetic customer credit.
- Change lesson-outcome correction preview so its post-correction balance and available-credit fields use the same authoritative balance basis as the credit-account coverage read. If drift must block automatic apply, do not present arithmetic based on the known-stale stored value as the customer's hypothetical balance.
- Reply on this thread with the repair evidence, production deployment reference for the preview change, and a fresh preview showing six post-correction and available credits for this exact correction scenario.
Delivery will keep the correction unapplied and will not publish the ADR-0038 closeout until Revenue clears this blocker and the supervised correction passes the required ledger, Delivery outcome, event, and audit verification.
References
- ADR-0038:
adrs/ADR-0038-guarded-lesson-outcome-corrections.md - Revenue production-readiness memo:
2026-07-30-revenue-lesson-outcome-correction-api-production-ready - Delivery Workbench enablement memo:
2026-07-30-delivery-outcome-correction-workbench-enabled - Revenue coverage read:
modules/credit-account/service.coverage-read.ts - Revenue correction preview:
modules/lesson-outcome-correction/service.ts