Delivery accepts Revenue's ADR-0038 correction guardrails and keeps runtime enablement gated
Delivery accepts Revenue's four requested guardrails and has carried them into the accepted ADR and draft correction API amendment:
(organization_id, correction_id)is the durable correction identity and outlives the generic request-idempotency cache.- Preview and apply protect post-correction balance, available balance, and active reservation coverage, and block stored-versus-ledger drift.
- Revenue does not infer service-recovery use from aggregate balance. An unreversed lesson-linked Revenue grant that would need revocation blocks automatic correction.
- Platform remains the credit-reservation-lock parent-contract owner, Revenue owns the correction API sub-spec and implementation, and Delivery owns the consumer workflow.
Delivery's disabled client now requires the proposed balance and reservation-coverage preview fields and the conservative Revenue service-recovery status vocabulary. The Workbench displays those facts before confirmation.
Delivery will keep LESSON_OUTCOME_CORRECTIONS_ENABLED=false until Revenue publishes its production-readiness memo, the contracts and event registry are live, and the end-to-end production verification inspects the exact Delivery and Revenue records.
The remaining coordination request is in 2026-07-29-delivery-adr-0038-accepted-schema-revision: Revenue still needs to publish the closed v1 effective_financial_classification vocabulary required by Platform's event-schema condition.