Platform approves the scoped ADR-0050 route authority design with runtime gates unchanged

This owner response accompanies the coordinated ADR/contract change. Contract approval does not establish deployed route availability or activate cancellation.

Platform approves ADR-0050 within its authentication and shared-contract remit, including the exact route mappings in service-auth v1.6.0 section 4.9. This extends the September 29 scoped position to the typed key-settlement, separate Delivery abort, preview/head and original-subject noncommit-proof reads. Existing selectors, subjects, audiences, tenant/Organization reach and exact scopes suffice. No issuer runtime, identity schema, dispatcher registry or event-envelope change is required. Platform has no remaining route-name or canonical auth-code objection to this design.

This is approval of Platform's contract authority design, not approval on behalf of Revenue or Delivery of settlement eligibility, financial effects, locks, migration, writer exclusion or rollback. It neither accepts the ADR for its deciders nor establishes producer implementation, deployed availability, runtime authorization, release readiness or activation. Atomic review and publication of the final agreed contract/ADR/owner responses remain required before implementation under this proposal.

Exact authority approved

Revenue child POST discriminates cancel_order for sales with revenue.onboarding-closure.cancel-order from release_reservation for system:delivery with revenue.onboarding-closure.release-reservation. It cannot accept an OR of these scopes for either kind. Actual child abort retains original subject and original kind's mutation authority. Delivery child and separately identified abort POSTs require sales, audience delivery, and delivery.onboarding-closure.cancel; exact operation, abort and preview GETs require its read scope and the same immutable closure/resource binding.

Revenue key-settlement POST requires Delivery's release mutation scope. Its fresh settlement UUID is separate from the permanently reserved release UUID; aliases never grant additional successor authority. Exact settlement GET remains Delivery-only with revenue.onboarding-closure.read. No delete, unreserve or settlement-abort route is authorized. An immutable actual_operation reference is not proof of terminal settlement; use the proper version-specific operation read/abort.

Revenue GET /api/v1/onboarding-closure-lineage permits Sales invoice-head reads only and Delivery release-head reads only, using exact kind-specific HeadQuery identity. Shared read scope does not expand either subject's head access. GET /api/v1/onboarding-closure-operations/{operation_id}/noncommit-proof permits only the original initiating subject with the read scope and exact original binding, for either command version. Existing correlated financial-operation read permissions do not grant cross-subject access to this proof. Delivery projects its strictly bound upstream terminal evidence through its own authorized reads for Sales; no new direct Sales key-settlement or release-head access is needed by this map.

GET must not initialize or repair a head, reserve a key, execute recovery, abort an operation or manufacture missing evidence. Historical v1 safe-abort reaffirmation remains the existing mutation route under original mutation authority, producing a new separately timestamped audit proof only after owner validation. It cannot invent historical audit facts, overwrite original decisions/receipts, modify the successor's fence/head or change old response envelopes. Existing proof remains immutable. The Revenue cross-version proof wrapper and Delivery migrated-root wrapper are explicit exceptions with strict version fields, not permission to relax ordinary legacy response shapes.

Revenue's draft now uses the service-auth v1.5.1 codes UNAUTHENTICATED, FORBIDDEN and INSUFFICIENT_SCOPE. Preserve nondisclosing resource denials. A valid nonempty unrelated-scope token must independently exercise insufficient-scope rejection; malformed or missing claims are not that proof. JSON Schema unions do not replace semantic subject/kind, proof-to-head, version, intent and resource checks.

Contract references

• ADR-0050, approved draft identity SHA-256 3016f6153f75f12e0c31926fc016e775a956a196c6ff82d0be976b7c2d8a51e9.
• Service authentication v1.6.0, exact section 4.9 method/subject/scope map.
• Revenue re-evaluation v1.1.0, schema and examples, under Sales Ordering Surface v2.8.0.
• Delivery re-evaluation v1.1.0, schema and examples, under Sales Scheduling Surface v1.12.0.

Platform verified the final ADR correction: Revenue retains tenant/operation-kind/resource heads, while Delivery requires UNIQUE(tenant, lesson) across kinds with immutable root kind and no parallel soft-hold/held-lesson heads. The final ADR pin supersedes earlier 1ffc8666 review identity. This correction does not alter Platform's auth design or certify database enforcement.

Review audit history

Platform reviewed source 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a and the September 29 scoped position 263a6277. These SHA-256 values record the local design artifacts at the final scope-review snapshot on October 2. They are retained as audit history, not asserted as the byte hashes of the later canonical publication files. Canonical schema IDs and composed references are reviewed in the atomic publication bundle.

Proof and release gates

The Platform authorization matrix contains 42 design cases, not 42 executed tests. Producer schema examples and fingerprint vectors establish syntax/hash coverage only. The coordinator's composed-schema validation is separate from producer HTTP authorization, database serialization, admitted-worker exclusion, durable migration and provider evidence. Prior ADR-0048 proofs do not establish the new lineage protocol.

Required implementation evidence remains: independent route authentication/scope/linkage denials; no business mutations from reads; shared heads and unique-child admission across versions; permanent target and rejected-key retention; safe historical reaffirmation; admitted-work drain; delayed admission and partial-child recovery; migration privilege separation and complete writer coverage; compatibility, rollback and owner financial/Delivery races. Runtime roles, database trigger coverage and provider drain are not certified by this auth approval.

Retain existing ADR-0048/0049 release and activation gates. Revenue and Delivery own producer semantics and their final positions; Sales owns consumer/operator integration and ADR acceptance. Neither this memo nor contract publication performs implementation, migration, deployment, provider calls or activation.