Platform approves ADR-0050 auth and envelope compatibility within existing closure authority

Platform approves the proposed ADR-0050 design within its authentication, identity and event-envelope remit. Explicit immutable predecessor lineage, a shared authoritative head across v1.0 and v1.1, settled predecessors, and fail-closed migration preserve the existing closure authority boundary. This acknowledgment is not Revenue or Delivery approval of financial eligibility, settlement evidence, the lock state machine or final route/schema choices. It does not accept the ADR or clear implementation, deployment or activation gates.

Existing authority is sufficient

Platform inspected modules/service-auth/workload.ts at source 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a and service-auth v1.5.1 section 4.8. No new capability selector, scope, subject, audience, organization reach or issuance policy is needed for the proposed operations:

The proposed shared Revenue POST must discriminate operation kind and enforce the corresponding exact subject and command scope. Accepting either mutation scope for every kind would improperly give Sales release authority or Delivery invoice-cancellation authority. A read scope never authorizes child admission or abort. Any child abort requires the original initiating subject, exact mutation scope and resource binding under the owner-published abort protocol.

Existing policies retain tenant_id: tnt_sguild, the canonical Organization allowlist, required JWT claims, RS256, exact issuer/audience/subject checks, maximum 300-second lifetime, production workload verification and issuance audit. A new operator actor/reason is provenance, not a new workload subject or authorization override. Reauthorize predecessor and child on every command, read, replay and abort against the same subject, tenant, organization, person, closure and resource. A fingerprint, operation ID, valid signature or person/account membership is not authority to retrieve unrelated lineage. Preserve nondisclosing inaccessible-resource responses.

Scope sufficiency does not make the candidate endpoints part of the current published route map. After owners settle exact methods, paths and operation kinds, publish an additive service-auth contract revision and aligned producer sub-spec mappings before those surfaces are used. Allocate the contract version at publication. No issuer code change is indicated by this review; a change in authority would require a separate explicit proposal.

Compatibility and canonical rails

Platform agrees that v1.0 fenced replacement and v1.1 child admission must share one authoritative lineage-head comparison and unique-child rule. An unchanged legacy wire shape is not proof of compatible serialization. Keep v1.1 disabled while any legacy admission writer cannot participate; ambiguous migrated roots or fences remain blocked. Require both winning orders of the mixed-version race and restart/migration evidence before activation. Expired JWTs, expired leases and missing fences do not establish settlement.

Preserve historical request fingerprints, receipts, operation IDs and outbox records. New versioned reads must not leak incompatible child response shapes through strict v1.0 readers. Delayed events must resolve through exact authenticated producer evidence and the current local finalization guard, not event arrival time or a guessed newest journal. No event type, envelope field, dispatcher registry entry or identity schema change is required by this proposal. In particular, do not append lineage fields to an existing strict event payload such as credit.released@2 without a separate versioned contract decision. Platform will not become the domain lineage-head owner; each producer owns its serialization and canonical resource decision.

Remaining owner decisions and evidence

Revenue and Delivery still own the exact settlement and never-admitted proofs, child preparation/abort ordering, strict schemas and conflict codes, and migration/rollback behavior when legacy writers cannot safely admit new work. The new route map must state the subject/scope split above and preserve exact linked reads. No Platform auth objection remains if the accepted contract retains these bounds.

Required authorization evidence includes a cryptographically valid token with a nonempty unrelated scope producing an insufficient-scope denial, as distinct from a malformed-token rejection. Also prove wrong caller, audience, tenant, organization, person, closure and resource; predecessor/fingerprint mismatch; actor substitution; cross-operation reads; scope confusion; and unchanged v1 replay semantics. Financial/provider races, safe settlement and completed-history protection remain owner proofs. Source review does not establish deployed policy availability, and prior local ADR-0048 proofs do not prove the new protocol.

References

• ADR-0050 proposal
• Sales approval request
• Service authentication v1.5.1
• Platform ADR-0048 position