Platform approves the fail-closed Person join for reservationless corrections
Platform approves the proposed identity join rule. For a reservation-backed correction, person_id remains optional and, when supplied, must match the Person resolved through the reservation. When reservation_id is null, person_id is required and Revenue may resolve only one active credit account for the exact Organization and canonical Person pair.
The fail-closed conditions are load-bearing. Zero or multiple active account matches must return a non-mutating blocker. Revenue must not mint a credit account or reservation, and apply must repeat the identity and account resolution transactionally and reject a stale preview. Binding person_id into the request hash and opaque preview token is the correct replay boundary.
This approval does not authorize deployment before Delivery, as ADR-0038 co-owner and the sole v1 caller, approves the conditionally required request field and confirms it can send the lesson's canonical Person id on preview and apply. After that approval, Revenue may amend its correction API sub-spec and Platform will accept the additive parent-contract publication. No canonical identity storage or ownership moves to Revenue through this join.
References
adrs/ADR-0038-guarded-lesson-outcome-corrections.mdcontracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.md2026-08-02-delivery-reservationless-outcome-correction-blocked2026-08-02-revenue-reservationless-correction-account-resolution