Verify Casey Brown's locked-credit balance and post-lesson expectation

Why

The Delivery Workbench payment drawer for Casey Brown showed the following Revenue-backed snapshot on August 2, 2026 at 6:33 PM Central:

• account balance: 2 credits
• open reserved: 0 credits
• available credits: 2 credits
• locked credits: 2 credits

The operator expects the two locked credits to leave Casey with zero available credits and zero balance. Delivery initially interpreted the two-credit balance as already net of the lock debit, which would leave Casey with two credits after the lesson completes. The operator challenged that interpretation and asked Delivery to confirm the financial truth with Revenue.

There is also an apparent specification mismatch. Revenue's current coverage-read implementation sums only RESERVED reservations into open_reserved_credits, while the May 19 coverage memo and API documentation say that open_reserved_credits includes both RESERVED and LOCKED. The lock contract separately states that entering LOCKED posts a Reservation Lock Debit. Delivery must not infer the intended arithmetic from these conflicting descriptions.

Asks

Revenue, please query Casey Brown's current production credit account, reservation, and qualifying ledger entries and reply with:

1. Casey's credit balance immediately before the current two-credit reservation locked.
2. The Reservation Lock Debit identifier and delta, or confirmation that no valid lock debit exists.
3. The authoritative current balance, open-reserved amount, and available-credit amount.
4. The expected balance and available credits after tomorrow's lesson is consumed normally, with the lock-reversal and Lesson Debit entries shown explicitly.
5. Whether the displayed 2 balance / 0 open reserved / 2 available / 2 locked snapshot is correct or represents a Revenue projection or ledger defect.
6. Which rule is authoritative for locked reservations in the coverage API, and whether the conflicting May 19 memo and API documentation need correction.

Please preserve append-only ledger history. This memo requests read-only verification only, with no balance, reservation, or ledger mutation unless Revenue first identifies a defect and returns a guarded repair proposal.

References

• Revenue coverage memo: 2026-05-19-revenue-credit-account-coverage-api-live
• Credit reservation lock contract: contracts/credit-reservation-lock/README.md
• Revenue coverage implementation: modules/credit-account/service.coverage-read.ts
• Prior Casey reconciliation: June 8 Delivery lesson les_019eb8b2-64f4-7f2f-910e-92d67c607d87