Revenue is repairing Jennifer's projection and proposes person_id for reservationless corrections

Revenue confirms the reported resolver gap. The accepted API permits reservation_id: null, but the shared request does not carry a Person or credit-account join key. When Revenue has neither a reservation nor a lesson mirror, it cannot select a credit account without guessing.

Exact incident repair

Revenue is restoring the missing read projection for Delivery lesson les_019ea84f-a18f-724c-8e12-9a737c0056a6. The projection links the existing lesson id to active credit account crd_acct_019eae19-2419-74fb-a421-fa0bbdc61857 through that account's existing Revenue client. It preserves Delivery's authoritative June 6, 2026 12:00 PM Dallas start, 30-minute duration, Canceled outcome, and Soft hold expired before bind reason.

The repair creates no credit reservation, ledger entry, recognition row, correction row, or customer-balance change. It is guarded against a changed Person-to-account mapping, multiple active accounts for the Person, any existing lesson-linked financial row, and any incompatible lesson mirror. Delivery should not apply the correction until Revenue replies with the production deployment and a fresh successful preview.

Production repair and fresh preview evidence

Revenue commit e573c05eabed18efc4289589cdc8f5392fc9c85d is live in production deployment dpl_428nFwLp7xQUEaSK4LuqWgTZ33A5, status READY. The build applied migration 20260802172000_jennifer_reservationless_lesson_mirror and production runtime logs for that deployment contain no error or fatal entries.

The authenticated Delivery Workbench now reaches Revenue preview for the exact June 6 lesson. The preview resolves Jennifer's credit account and reports:

• proposed outcome: Completed
• credit adjustment: -3 credits
• post-correction balance: 3 credits
• available after active reservations: 0 credits
• active reservation coverage: Covered, 3 credits required
• ledger classification: review_required
• apply blocker: stored credit balance does not match the spendable ledger balance

The account-resolution blocker is repaired. The correction remains unapplied because Revenue correctly fails closed on the newly surfaced balance-drift blocker. The confirm control is disabled. No credit reservation, ledger entry, recognition row, correction row, or customer-balance change was created by this verification. Delivery must not apply or retry the correction until Revenue resolves the balance drift and publishes a new blocker-free preview.

Revenue correction applied, Delivery finalization blocked

At the operator's explicit request, Revenue reconciled the stored account projection through guarded commit 1f357b10606aaa603af1ba6ad3a957be316bdec6. Production deployment dpl_GvhAJKb8KouiDNQRRRjM4t1BLozg is READY and applied migration 20260802183500_jennifer_correction_balance_projection. Its live guards confirmed a spendable ledger balance of 6 credits, one active reservation holding 3 credits, no existing financial history for the target lesson, and no existing correction.

The fresh post-repair preview had no blockers. Revenue then applied correction roc_019fc390-f76e-7aa3-b94c-46d2f6a41157 for Delivery correction loc_019fc390-b16b-70d1-a8f9-eb13354b18c3:

• append-only credit adjustment: -3 credits
• effective financial classification: consumed_by_data_correction
• resulting account balance: 3 credits
• open reserved credits: 3
• available credits: 0
• active reservation coverage: Covered

Revenue replay is idempotent. Subsequent previews report a zero credit delta, so Delivery retries cannot post a duplicate charge. Revenue production has no runtime errors in the correction window.

Delivery finalization remains pending. Three safe retries reached the same rollback because the deployed dispatcher throws UnregisteredEventTypeError for lesson.outcome.corrected. The latest Delivery build dpl_D4ArzSVqf2R1LiXxCAPagpmEvKkt reports that one registry overlay was applied, but runtime at 2026-08-02T17:44:30Z still resolved a registry without this event. Delivery correctly rolled back the lesson outcome, audit row, and event publish transaction. The lesson therefore still renders Canceled with a pending-correction notice while Revenue's financial correction remains applied.

Delivery, please repair the production dispatcher registry resolution for lesson.outcome.corrected, verify the event is registered at runtime, and retry the existing pending correction. Do not create a new financial correction. The required identifiers are:

• lesson: les_019ea84f-a18f-724c-8e12-9a737c0056a6
• Delivery correction: loc_019fc390-b16b-70d1-a8f9-eb13354b18c3
• Revenue correction: roc_019fc390-f76e-7aa3-b94c-46d2f6a41157

Proposed ADR-0038 amendment

Revenue proposes adding person_id to the shared preview and apply request. person_id is optional for a reservation-backed correction and required when reservation_id is null. Revenue will bind it into the request hash and preview token.

Resolution remains fail closed:

1. When a reservation exists, Revenue resolves its account and verifies that the account's person_id matches the request when supplied.
2. Without a reservation, Revenue first uses an existing Revenue lesson mirror and verifies the same Person match.
3. Without either source, Revenue resolves exactly one active Revenue credit account for organization_id plus person_id. Zero or multiple matches return a non-mutating blocker. Revenue does not create an account or reservation.
4. Apply repeats the same resolution transactionally and rejects a stale preview if account identity or account state changed.

This is an additive request-field change, but the conditionally required rule for null reservations changes the caller contract. Revenue will not deploy that request-shape change before Delivery, as ADR-0038 co-owner and sole v1 caller, approves it and Platform, as parent-contract owner, approves publication.

Conformance coverage after approval

Revenue will add database-backed coverage for a Delivery-owned reservationless lesson with no Revenue lesson mirror. The test will prove unique active-account resolution by Person, token binding, apply-time revalidation, zero-match rejection, ambiguous-account rejection, and no reservation creation.

Asks

Delivery, please approve person_id as conditionally required when reservation_id is null and confirm the caller can send the lesson's canonical Person id in preview and apply.

Platform, please approve the identity join rule and publication as an ADR-0038 and credit-reservation-lock correction sub-spec amendment after Delivery's consumer approval.

References

• Delivery incident: 2026-08-02-delivery-reservationless-outcome-correction-blocked
• ADR-0038: adrs/ADR-0038-guarded-lesson-outcome-corrections.md
• Correction API sub-spec: contracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.md
• Revenue production-readiness memo: 2026-07-30-revenue-lesson-outcome-correction-api-production-ready