Revenue lesson outcome correction preview and apply APIs are production-ready
Revenue clears event:revenue-lesson-outcome-correction-api-ready.
The Revenue production deployment now serves:
POST /api/v1/lesson-outcome-corrections/previewPOST /api/v1/lesson-outcome-corrections/apply
Delivery may treat Revenue's ADR-0038 API dependency as ready. Delivery's separate event-registry and Delivery production-verification gates remain independent.
Production release
Revenue commit 5fa34aa896f270efd84bdd94b32a2cb223033063 deployed to production as Vercel deployment dpl_4dfj3qchxeVQEXgP6mTP8ASxh5eG, which reached terminal READY.
The production build applied migration 20260730153000_lesson_outcome_correction_api successfully to the revenue schema before compiling the application. The build output includes both canonical correction routes.
Live requests reached both production routes at https://revenue.sguildswim.com and returned the expected 401 unauthenticated response without a Platform JWT. This proves the deployed HTTP boundary is present and fails closed before request parsing or financial access. No customer financial record was changed for this route-presence check.
Conformance evidence
Revenue's database-backed route suite covers:
- Positive credit correction with an append-only adjustment and immutable terminal reservation.
- Negative credit correction.
- Net-zero financial reclassification with an explicit audit and recognition fact.
- Durable replay by organization plus correction id after preview-record removal.
- Semantic payload mismatch rejection.
- Stale preview-token rejection after a Revenue fact changes.
- Negative-balance and active-reservation-coverage blocking.
- Lesson-linked service-recovery grant handling in the same transaction.
The focused correction suite passed 6 tests. The full Revenue suite passed 381 tests across 63 files. npm run typecheck, npm run build, and npm run audit:ledger passed. The ledger audit scanned 235 entries and reported zero append-only violations.
The production migration log plus the database-backed route suite establish stable preview, atomic apply, and durable existing replay without using a live customer correction as test data.
Runtime guarantees
Apply requires a Platform JWT scoped to Revenue's tenant, and Idempotency-Key must equal Delivery's correction_id. Revenue persists the natural key (organization_id, correction_id) independently of the generic 24-hour idempotency cache.
Apply re-reads the preview-bound Revenue facts in a serializable transaction. It rejects stale or concurrent facts, stored-versus-ledger drift, negative balance, impaired active reservation coverage, unknown policy classification, and automatic revocation of an unreversed lesson-linked service-recovery grant.
A successful correction appends a durable correction row, linked ledger adjustment, recognition or contra-recognition fact, and any allowed service-recovery grant. It updates the stored credit balance by the signed net delta. It does not rewrite the original terminal reservation, original ledger rows, or original recognition rows.
References
- ADR-0038:
adrs/ADR-0038-guarded-lesson-outcome-corrections.md - Revenue guardrails and implementation commitment:
2026-07-29-revenue-adr-0038-guardrails-and-api-commitment - Closed financial classification vocabulary:
2026-07-30-revenue-effective-financial-classification-v1 - Correction API sub-spec:
contracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.md - Delivery event contract:
contracts/lesson-lifecycle/lesson-outcome-corrected.md