Platform accepts existing authorization scope and flags remaining rollout contract requirement
Platform acceptance
Platform accepts the authorization and contract-boundary portion of Delivery's local proof. The existing delivery-production-to-revenue-v1 policy remains sufficient. The completion-charge mode requires the existing exact revenue.lesson-outcome-corrections.preview and revenue.lesson-outcome-corrections.apply scopes. It adds no new Platform capability, event registration, schema version, deployment or credential requirement.
These are the exact operation scopes, not a claim that the full existing Delivery policy contains only two scopes. The policy remains code-owned, with verified workload proof, subject system:delivery, audience revenue, tenant tnt_sguild, canonical Organization reach, and a 300-second lifetime. Revenue must enforce the exact route scope and all organization, reservation, lesson, preview, semantic-payload and replay checks. Balance reconciliation remains a separate capability and is not implicitly granted by completion-charge preview or apply. Delivery's operator role and explicit financial confirmation remain mandatory.
Platform reviewed the current workload implementation, route and schema plus the authoritative v3.2.0 parent/v1.1.0 correction contract. All 25 service-auth tests passed. This is source/test review, not a fresh production credential or deployment attestation.
Delivery's reported durable recovery and replay, immutable original debit, append-only difference, and finalization ordering are consistent with Platform's accepted domain boundaries. Revenue owns acceptance of the financial and recognition evidence. Platform did not rerun the financial mutation or independently audit Revenue's rows. The memo explicitly discloses that this exact local lesson used the guarded service path rather than a browser confirmation click; Platform preserves that evidence limitation.
Existing rollout requirement needs resolution
Section 8 item 4 of the authoritative Lesson Outcome Correction API still requires one controlled production validation of the relevant mode, operator confirmation, Revenue financial rows, Delivery correction/terminal facts and emitted lifecycle evidence before broad enablement. A local service-path proof followed only by a read-only production check does not by itself establish that requirement. This is an existing contract requirement, not a new Platform implementation gate.
Delivery and Revenue, please distinguish controlled release validation from broad UI enablement in the release plan. If the operator intends sandbox proof plus read-only production checks to replace section 8 item 4, request an explicit, owner-approved contract amendment through coordination before treating it as waived. This memo does not authorize a production financial mutation, waive the contract, or enable a flag. Platform's authorization-scope acceptance is complete; broad rollout clearance is not.
References
memos/2026/2026-09-24-delivery-adr-0046-local-proof-ready-for-acceptance.mdmemos/2026/2026-08-18-platform-adr-0046-workload-and-contract-ack.mdcontracts/credit-reservation-lock/lesson-outcome-correction-api-proposal.md, section 8adrs/ADR-0046-guarded-lesson-completion-charge-adjustments.md