Platform acknowledges ADR-0048 and agrees scoped closure authority and authoritative reread ordering
Platform acknowledges ADR-0048 and agrees with Revenue's guarded unpaid commands and Delivery's prepare, Revenue commit, Delivery finalize composition. This is Platform's written protocol position for Revenue's agreement process. Sales owns ADR acceptance; Revenue owns clearing revenue-adr0048-protocol-agreed. This response does not establish implementation or production readiness.
Caller and resource policy
Platform accepts Revenue's proposed operation scopes with the following exact caller split. Sales uses sub: sales, aud: revenue, revenue.onboarding-closure.read for bounded exact inspection and operation evidence, and revenue.onboarding-closure.cancel-order for guarded unpaid invoice cancellation. Delivery uses sub: system:delivery, aud: revenue, revenue.onboarding-closure.read for its correlated operation evidence and revenue.onboarding-closure.release-reservation for guarded release. Sales receives no authority to invoke that release command. Delivery's read scope does not authorize Sales' general obligation inspection route.
Implement these as separately selected, code-owned closure policies, preserving the existing Sales operations and default Delivery scope sets. Exact capability selector strings and route bindings belong in the settled service-auth revision before implementation. Retain the production workload subject checks, tenant_id: tnt_sguild, canonical Organization allowlist, maximum 300-second lifetime, RS256 verification, required claims and issuance audit. A request cannot select its own subject, organization reach or output scopes. Preview/development proofs must not satisfy production policies.
Revenue must enforce caller, scope, tenant and canonical resource linkage on every command, exact read and replay. Sales may retrieve only evidence for its explicitly correlated closure obligations. Delivery may retrieve its release operation and linked invoice receipts only through the exact intent/closure/resource association validated by Revenue. Knowing an operation ID is insufficient. Neither scope grants person-wide search, unrestricted financial history, refund, forfeiture, capture, correction or generic release authority. Request actor/reason is audit provenance, not an authorization override.
Abort is a mutation, never a read capability. The settled sub-spec must bind abort to the initiating caller and the same exact command scope and resource fingerprint. Delivery must not abort Sales' invoice operations. Durable serialized abort must prove a release cannot later commit before Delivery removes its fence.
Receipt and event ordering
Platform selects Revenue's authoritative reread alternative for this additive protocol. The current credit.released@2 schema has additionalProperties: false and no reservation revision. Keep that wire schema unchanged; put the monotonic reservation revision, operation bindings, current assessment and immutable receipt in the new versioned exact-read/operation contract. Event arrival time, envelope time and an old cached success are not authoritative ordering.
For closure-associated resources, Delivery's synchronous, inbox and recovery writers must serialize through the same durable intent and finalization guard. Record incoming events durably, then use authenticated Revenue exact evidence to resolve ordering. Fetch outside the local transaction; re-lock and verify the intent, resource linkage and local version before applying the result. If the local version changed, retry the read. A reread alone is not a distributed lock: safety also requires Revenue's terminal non-resurrection guarantee and Delivery's fence across all conflicting writers. Delayed events cannot reopen a finalized lesson; contradictory evidence remains visible for reconciliation. Unavailable, absent, unknown or mismatched evidence leaves closure pending.
Delivery must retrieve the committed-release receipt directly from Revenue and verify every binding and the separately returned current assessment. Prior RELEASED/VOIDED state alone is insufficient. Stable-key replay, durable retention, provider/canonical recovery, completed-outcome protection and reservation-less bind-race handling remain as specified by the producer proposals. No unsupported event field or new reason code is authorized by this response. Producers must settle the applicable existing cancellation reason in the sub-spec, or return for a separately versioned vocabulary change.
Publication and remaining work
Local inspection of modules/service-auth/workload.ts and service-auth v1.4.0 confirms that the existing Sales subject is sales, not system:sales, and that closure policies are not yet defined. This is source inspection, not a deployed-runtime audit. Platform will publish the service-auth and stewarded credit-reservation-lock revisions with the agreed sub-spec after ADR acceptance and protocol agreement. Allocate version numbers at publication; preserve existing interfaces and policies.
Revenue may count this memo as Platform agreement to its proposal with the exact caller restrictions and reread strategy above. Please carry them into the settled sub-spec. Sales should file its adapter agreement and complete the ADR owner acceptance process; Delivery should carry the reread/fence requirements into its scheduling contract and writer inventory. No implementation commitment is completed by this acknowledgment.
Authorization proof must cover wrong caller, audience, tenant, organization, person and resource; scope confusion; cross-operation lookup and abort; changed-payload replay; and development/preview rejection. The producer concurrency, provider sandbox, crash/recovery and reordered-event proofs, Sales admission serialization, and unpaid end-to-end rehearsal remain activation gates. No runtime policy, production flag, deployment or live obligation is changed here.