Revenue verifies Casey has two balance credits, zero available credits, and a valid lock debit

Production finding

Revenue queried Casey Brown's production credit account, reservations, and full append-only ledger in a read-only transaction. No account, reservation, lesson, or ledger row was changed.

Immediately before the current reservation locked, Casey's authoritative ledger-backed spendable balance was 2 credits. The stored account projection was still the stale value of 19 credits at that time. Revenue's August 2 balance-integrity sweep later repaired that stored projection from 19 to 2 while preserving every ledger row.

Reservation crr_019fab6b-7d11-7ccc-a6e5-af87fd5d5f05 is LOCKED and FUNDED for 2 credits. Its lesson is les_019fab6b-77da-73ed-8717-59dd4f2571f3, scheduled for August 3, 2026 at 20:30 UTC. The lock transition posted exactly one valid Reservation Lock Debit:

• ledger entry: cmsbyj4j9000004jup3iomwhj
• occurred at: 2026-08-02T20:30:42.695Z
• delta: -2.0000
• reservation: crr_019fab6b-7d11-7ccc-a6e5-af87fd5d5f05
• lesson: les_019fab6b-77da-73ed-8717-59dd4f2571f3

The debit brought the raw append-only ledger sum from 2 to 0. Revenue's spendable-balance projection deliberately excludes both Reservation Lock Debits and their bookkeeping reversals. Under that projection, the gross account balance remains 2 until the lesson is consumed, while the locked reservation uses those 2 credits and leaves 0 available.

The authoritative current coverage is therefore:

• balance_credits: 2
• open_reserved_credits: 2
• available_credits: 0
• locked credits: 2

The current answer is not simply zero or two. Casey has 2 gross balance credits, all 2 are locked, and 0 are available to spend.

Expected normal consumption

If tomorrow's lesson is consumed normally, Revenue's existing transaction will:

1. append an ADJUSTMENT of +2 linked to and reversing cmsbyj4j9000004jup3iomwhj, with reason Lock Debit Reversal - Credits Consumed;
2. append a LESSON_DEBIT of -2 for the same reservation and lesson;
3. decrement the stored account projection from 2 to 0; and
4. transition the reservation from LOCKED to CONSUMED.

The two new ledger identifiers do not exist until that transaction commits. The raw ledger sequence will move from 0, to 2 after the lock reversal, and back to 0 after the Lesson Debit. The spendable projection will move from 2 to 0 on the Lesson Debit. The resulting coverage will be 0 balance, 0 open reserved, and 0 available.

Coverage conflict

The displayed 2 balance / 0 open reserved / 2 available / 2 locked snapshot is not correct. The balance and locked values are correct. The open-reserved and available values are a Revenue coverage-read implementation defect. This is not a missing or duplicate ledger-entry defect.

The May 19 coverage memo and the API documentation are authoritative for this projection: open_reserved_credits includes both RESERVED and LOCKED, and available_credits = balance_credits - open_reserved_credits. The current service includes only RESERVED. At the same time, its spendable-ledger calculation excludes Reservation Lock Debits. That mixes two individually valid projection conventions and overstates availability while a reservation is locked.

The safe repair is code-only:

1. include LOCKED in the coverage service's open-reservation status set;
2. add regression coverage for the exact 2 balance / 2 locked / 0 available state and for normal consumption to 0 / 0 / 0;
3. deploy and verify the authenticated production coverage response against Casey's unchanged rows.

No ledger or account repair is warranted. The May 19 rule does not need to be reversed. Revenue should add one clarification to the API documentation that balance_credits excludes temporary lock bookkeeping and that a locked amount remains in open_reserved_credits until the reservation becomes terminal.

References

• Delivery verification request: 2026-08-02-delivery-casey-brown-post-lock-balance-verification
• Revenue balance-integrity closeout: 2026-08-02-revenue-balance-integrity-sweep-complete
• 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