Revenue requests guarded pre-completion charge flow in Delivery
Why
A Delivery operator changed a lesson from a six-credit Lesson Type to a three-credit Lesson Type while recording the Completed outcome. Delivery persisted the selected three-credit details, but its normal settlement request sent only the existing reservation identity. Revenue correctly consumed the immutable six-credit reservation, leaving a visible and real three-credit mismatch that required an append-only financial correction.
Revenue's ADR-0042 break-glass flow repaired the completed case, but the normal UI should prevent the mismatch when the operator already selected the changed Lesson Type before completion. ADR-0046 proposes the pre-completion branch that ADR-0042's revisit trigger anticipated.
Proposed flow
Delivery compares the selected Completed Lesson Type cost with the linked Revenue reservation before writing a terminal outcome. Same-cost completions continue unchanged. A mismatch pauses the completion, shows the operator a Revenue-owned preview of the signed credit adjustment and projected balances, and requires explicit confirmation.
On confirmation, Revenue atomically consumes the active reservation and appends the difference plus correction-period recognition under a durable correction identity. Delivery then finalizes its Completed outcome and selected Lesson Type. If Delivery finalization fails after Revenue succeeds, it retries from the durable Revenue result. It must not fall back to the existing unpriced completion command for a mismatch it has detected.
Revenue is also correcting its Workbench read model so a successful adjustment is displayed as the effective charge while the original reservation quantity remains visible as immutable financial history. A resolved reservation will no longer continue presenting the duplicate break-glass correction action.
Asks
Delivery, please review and acknowledge ADR-0046. In the acknowledgment, declare the implementation commitment for the completion-form mismatch detection, financial preview and confirmation, pending finalization, and idempotent recovery. Please include a regression test for the exact six-to-three-credit case and prove that the unpriced completion fallback is not called.
Platform, please review and acknowledge ADR-0046. Confirm whether the additive completion_charge mode fits the existing exact Delivery-to-Revenue workload scopes, and identify any registry or contract version work required before enablement.
Finance, please acknowledge the preserved original reservation and debit, same-transaction append-only adjustment, and correction-period recognition treatment.
Revenue will not claim the permanent flow complete until the ADR is accepted, the contract is amended, both domain implementations are deployed, and one controlled end-to-end mismatch and replay are verified.
References
adrs/ADR-0046-guarded-lesson-completion-charge-adjustments.mdadrs/ADR-0042-guarded-completed-lesson-charge-corrections.mdcontracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.mdcontracts/lesson-lifecycle/README.md