Platform ADR-0052 exact admission and service-owned recovery position

Assignment ADR-0052/platform/002; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local; participant 01a0ff07-c6a3-7000-81a3-94f9960a4513. This supplements Platform's initial authority review. Platform accepts the coordinator-selected service-owned recovery rule and the fresh-issuance exception below as feasible contract decisions. Full ADR acknowledgment remains withheld until exact admission semantics, resource proof and rollout are settled. No implementation, issuance or activation is authorized.

Trusted admission surface and permission

Platform bootstrap returns data.signedIn, data.tenant_id, data.user.id, data.activeOrg.id and data.membership.{memberId,role,disabled}. It queries membership by the verified user and session's active Organization. disabled is true when membership status is not ACTIVE or disabledAt is present. Role is a string, not an enum authorization verdict. A signed-out response still carries tenant. A successful Organization-detail lookup is not required for bootstrap's membership binding: on lookup failure its active-org ID remains the session's ID, after membership lookup. Names and slugs confer no authority.

The separate trusted GET /api/auth/operator-session?app=sales verdict is data.authorized === true; data.signedIn and data.user.id accompany approval. Its operator.roles aggregates enabled memberships across Organizations, so it cannot identify the requested Organization's scheduling role. Its current app map grants Sales/Coaching access to exact membership role sales; owner, admin, coach and member grant no operator-app access. SuperAdmin can satisfy app access, but supplies no exact Organization scheduling permission.

Platform can support Sales' proposed owner/admin-plus-app predicate using existing surfaces, with this exact proposed wording:

Before creating any new scheduling admission, Sales SHALL obtain uncached successful JSON verdicts from configured trusted Platform bootstrap and /api/auth/operator-session?app=sales, using the same incoming human session cookie. Require both envelopes ok === true, both verdicts signedIn === true, app authorized === true, and equal nonempty user.id values. Require bootstrap tenant_id === "tnt_sguild", activeOrg.id === command.organization_id, the canonical Organization allowlist, present nonempty membership.memberId, membership.disabled === false, and exact membership.role equal to owner or admin. Every predicate is conjunctive. Missing/malformed fields, unavailable verification, other roles, configured tenant substitution, development stubs and SuperAdmin-only access SHALL fail closed before admission persistence or outbound command. Browser mutation entry points retain anti-forgery checks. Role hints, copied client verdicts and caller headers SHALL NOT replace these trusted checks.

This is a new narrow scheduling permission, not today's generic Sales admission. Under the existing map, an ordinary owner/admin without SuperAdmin or a separate enabled sales membership fails the app check; an ordinary sales member fails the owner/admin check. A user's enabled sales membership in another Organization can satisfy generic app access, but only the bootstrap owner/admin membership in the exact requested Organization satisfies scheduling permission. There is no atomic combined snapshot across the two endpoints; require fresh matching-user verdicts at each admission and independent producer resource authorization, without claiming atomic human revocation.

Concrete remaining decision: Sales must explicitly accept those exclusions in its revised owner position. If ordinary Sales-role operators must schedule, specify that exact active-org permission in the ADR, for example an explicitly approved role set including sales. Do not quietly add owner/admin to Platform's app map, treat global operator.roles as active-org permission, or manufacture a permission field bootstrap does not publish. No new Platform verification interface is needed for the stated conjunctive rule.

Exact durable-recovery wording

Once a command is validly admitted and its normalized business request, original actor/admission provenance and stable idempotency key are durably recorded, recovery is service-owned. Subsequent initiating-human session expiry, active-org switching, membership removal/disablement or scheduling-permission revocation SHALL block new human admission but SHALL NOT alone invalidate exact saved-command recovery. Recovery SHALL use the unchanged command/key/original actor under current workload, policy, tenant, Organization and canonical resource authority. It SHALL NOT reconstruct a command from current UI state, substitute a recovering operator, invent missing historical admission evidence, or bypass a cancellation, terminal state or producer resource restriction. Loss of current service/resource authority preserves unresolved outcome and does not establish that an earlier request failed.

Platform accepts this boundary. The workload JWT asserts the service's bounded authority, never a refreshed human permission. Human access revocation does not automatically cancel an admitted business command; any such cancellation requires a separate domain-approved protocol. Historical receipt retention and race-safe bind evidence remain producer-owner decisions. This supplement does not approve the proposed new Revenue bind-evidence scope or route.

Fresh issuance and honest revocation wording

As an exception to service-auth section 8, each scheduling soft-create or reservation-bind outbound attempt SHALL obtain its own newly issued, successfully audited token for the exact policy. The token SHALL be held only in process memory for that attempt and SHALL NOT be reused across attempts, cached across commands, or persisted with proofs/cookies in journals, receipts, logs or evidence. Concurrent attempts SHALL NOT share one issued bearer. Issuance failure or policy disablement prevents new attempts, sends no business request and preserves pending/ambiguous outcome. Every exchange response sets Cache-Control: no-store; successful issuance audit completes before returning the bearer.

Disabling issuance does not revoke an already issued JWT. With offline verification, a token issued immediately before disablement may remain usable for at most its remaining 300-second lifetime plus accepted clock tolerance, capped at 30 seconds. A bearer already issued for an in-flight attempt is subject to that residual window; fresh issuance per later attempt does not remove it. Immediate rejection requires a separately specified producer-side policy disable/revocation check. No instantaneous revocation is asserted. JWT expiry or issuance outage does not prove prior noncommit, and recovery uses a newly issued token with the same saved business command/key.

Platform recommends accepting this bounded residual window for the current proposal. Current Organization/resource reach must still be rechecked by the producer per the final contract. Treat workload identity, issuance policy, producer Organization/resource policy and initiating-human access as separate revocation cases; do not promise a synchronous propagation mechanism that has not been specified.

Acceptance and evidence

Prove the conjunction, including owner/admin without app authorization denied; ordinary sales role denied under the proposed owner/admin restriction; SuperAdmin without matching enabled owner/admin membership denied; missing/disabled/wrong-org membership, missing/wrong tenant, mismatched verdict user, unknown role and Platform outage denied before admission. Prove the chosen post-admission human revocations preserve exact service-owned recovery but prevent new admission. Prove distinct audited tokens per attempt, no token sharing/persistence, issuer failure sending nothing, and the agreed bounded residual validity after issuance disablement. Verify producer resource revocation and ambiguous prior outcomes independently.

Reviewed Platform HEAD 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a: bootstrap route/types, operator-session route, lib/auth/app-access.ts, operator-app.ts, existing app-access tests and operator-auth documentation; these named files have no working diff. Tests were read, not executed. Canonical coordination pin 33da836a4c73ce5d23fa14eb7485f873c698a0ae: Sales initial position, ADR-0036 and service-auth v1.7.0 sections 7-8. Source verification is not deployed proof.

Live Platform inbox/ledger checked for this supplement; no matching ADR-0052 implementation commitment is completed by this review. Only this memo is prepared for the coordinator's serialized batch. No independent publication, indexer or freshness run; those remain the batch publisher's final steps. No runtime edits or mutation occurred.