Platform approves four bounded scheduling policy designs and identifies publication gates

Assignment ADR-0052/platform/003; coordinator 01a0e095-f279-7fd0-a8ef-92ce8f9547fc, host local; participant 01a0ff07-c6a3-7000-81a3-94f9960a4513.

Platform architectural position

Platform approves the four isolated authorization boundaries below as one bounded architecture: soft creation, reservation binding, canonical fenced evidence read, and bind settlement. The evidence read is not broad reservation access; settlement is not cancellation or financial mutation. Platform also ratifies Sales' exact admission role set and service-owned recovery. This approval is of those architectural clauses, not the proposed wire schemas, other owners' writer guarantees, accepted contract publication or runtime readiness.

No full ADR acknowledgment is issued in this memo. The canonical ADR's main decision still says only two routes are authorized and excludes inspection, while its second-review section proposes four. Replace that conflicting decision with one normative four-policy map and link the fenced protocol as its selected architecture. Keep the actual schema, compatibility and affected-owner acceptance gates explicit. Platform's earlier statement withholding approval of evidence/settle policy boundaries is resolved by this memo; unrelated resource-proof and publication gates are not silently cleared.

Exact service-auth v1.8.0 policy map

The evidence scope grants only that exact parameterized GET with validated reservation_id and exact query fields organization_id, lesson_id, bind_intent_id. It requires canonical matching intent/association and current Organization/resource reach before disclosure, including historical evidence. No listing, account-wide read, generic reservation GET, mutation or acquire-fence endpoint is authorized. Retained bound/noncommitted evidence can support receipt verification but cannot authorize a new bind. An as_of timestamp never replaces the persistent fence.

The settlement scope grants only a command bound to the original Revenue bind intent/key/fingerprint and exact canonical reservation/lesson. It may produce the immutable original committed receipt or permanently bar that original bind identity. It cannot release credit, cancel a Lesson, clear Revenue's fence, mutate order/funding state or emit a business event. Revenue clears only its matching fence after authenticating and durably recording the exact settlement outcome. Bind and settle scopes are mutually exclusive route authorities: read does not settle, bind does not settle, settle does not bind. Delayed original bind must encounter the permanent noncommit identity under the same serialization as commit.

All four selectors are additive and do not collide with inspected service-auth v1.7.0. Preserve every existing default, closure, Coaching, comms, Sales-operations and operator policy. In particular, the Delivery default policy must not gain the evidence-read scope, and no existing policy may gain bind or settle. Unknown selectors must fail instead of defaulting.

For the new policies pin proof issuer https://oidc.vercel.com/jack-allreds-projects, team JWKS and RS256; scalar proof audience exactly https://platform.sguildswim.com/api/auth/service-token/exchange; exact production proof subject by caller: owner:jack-allreds-projects:project:sales:environment:production, owner:jack-allreds-projects:project:revenue:environment:production, or owner:jack-allreds-projects:project:delivery:environment:production. Configuration must equal the approved subject for these new policies, not silently redefine it. Revenue's new production identity and each actual exchange remain later readiness proofs, not facts established by this review.

Each output has issuer https://platform.sguildswim.com, scalar audience/subject from the map, tenant tnt_sguild, exactly [org_01900000-0000-7000-8000-000000000001], that row's sole scope, unique UUID jti, integer iat/nbf/exp, nbf = iat, and 0 < exp - iat <= 300. Clock tolerance is at most 30 seconds. Require RS256, JWT header/kid and every claim; reject audience arrays, missing/unknown claims that would substitute authority, preview/dev proofs, aliases and wildcard/prefix scope matching. Caller input may select a policy, never its output claims or resource authority. Do not add caller-chosen resource claims to compensate for missing fence evidence.

Admission, current authority and token rules

Platform ratifies Sales' published exact ["sales", "owner", "admin"] active-Organization roles PLUS the existing trusted Sales app verdict. Require fresh successful bootstrap and /api/auth/operator-session?app=sales verdicts from the same incoming cookie, both signed in, equal nonempty user IDs, app authorized === true, exact verified tenant and command Organization in the canonical allowlist, present member ID and disabled === false. Match roles exactly, with no compound-string splitting/case folding. Owner/admin without independent app access remains denied; SuperAdmin without enabled allowed-role membership in the exact Organization remains denied. Global operator.roles and configured tenant fallback are not permission. The global app-role map is unchanged. The two verdicts are not an atomic revocation snapshot.

Once valid admission is durably recorded, initiating-human expiry, org switch or membership/permission revocation prevents that human's new admission but does not itself cancel exact service-owned recovery. Preserve original request/key/actor. Current verified service policy, tenant, Organization and canonical resource ownership still apply before writes, remote calls and receipt disclosure. Historical successful receipts remain historical, not fresh eligibility/funding/binding authority. Lost current authority or unavailable evidence preserves pending/ambiguous outcome, never proves noncommit.

Service-auth section 8 must explicitly exempt ALL FOUR policies from reusable/coalesced bearer caching: every individual soft-create, bind, evidence GET, settlement and replay attempt obtains its own newly issued, successfully audited bearer. Concurrent attempts do not share one bearer. No credential persistence or human-cookie fallback; same business command/key, distinct token and audit UUID per retry. Evidence GET exchanges are separate from the enclosing Delivery bind/settle request's incoming Revenue token.

Retain audit-before-return and no-store on all exchange outcomes. If issuance/signing/audit fails, return no bearer and send no new business attempt. Issuance disablement blocks later acquisitions but does not instantly revoke an already-issued offline JWT. Residual validity is bounded by remaining lifetime, at most 300 seconds plus accepted clock tolerance capped at 30 seconds. An already-issued in-flight attempt can still arrive in that window. Immediate rejection needs a separately specified producer revocation control; this architecture accepts the bounded window. Producer-local resource/Organization denials remain independent of token expiry. Do not claim all in-flight requests stop immediately when issuance is disabled.

Exact publication and schema amendments still required

Service-auth v1.8.0 must update consumers to include Revenue as workload caller; sections 1, 3.1/3.2 and 4.2 plus a dedicated four-policy route map; section 5's exact resource/receipt constraints; section 6's errors; sections 7/8's audit and four-policy caching exception; and migration/change-log entries. No existing policy deprecation is introduced. Preserve 400 BAD_REQUEST for unknown/invalid selector, 401 UNAUTHENTICATED for invalid proof/JWT or expected issuer/audience/subject mismatch, 403 INSUFFICIENT_SCOPE for missing exact scope, and 403 FORBIDDEN for verified disallowed tenant/org/resource, with nondisclosing resource responses. Issuance failure is an error, not a bearer-bearing success. Resolve the current error table's overlapping subject wording in the new map.

Publish machine-checkable selector/claim validation cases for all four rows: exact singleton scope and org, subject/audience pairing, proof identity, required UUID/time claims and TTL, with wrong-policy cross-use denials. Update the issuer's capability and workload-subject type vocabulary later under the accepted implementation assignment, never by invoking the retired root-mint/operator path. These validation/schema changes are publication requirements, not implementation performed here.

Delivery/Revenue must publish and approve strict evidence, settlement request/result, ReceiptRef and protocol-header schemas in their owning scheduling/credit contracts, including exact digest encoding and canonicalization, date/window normalization, integer revision range, decision discriminants and receipt-nullability rules. Committed references must identify the original authenticated immutable receipt; noncommit must identify the permanent tombstone. Define repeated settlement/replay after Revenue fence clearing and later lifecycle transitions without disclosing foreign resources or reopening old writes. Do not infer schema acceptance from this policy-map approval.

Remaining affected-owner gates: Revenue's complete invalidating-writer/fence coverage and exact ADR-0050 conflict integration; Delivery's shared bind/settle/cancellation serialization and resource checks; permanent identity/receipt retention and legacy quarantine; scheduling v2.0.0 compatibility/deprecation and explicitly approved admission pause/cutover/rollback. A signed JWT does not prove any of those invariants. No new funding/lock lifecycle or financial event is approved by Platform's auth position.

Later proof must cover each actual production exchange and four real routes; wrong caller/policy/audience/scope/tenant/org/time/claims; denied receipt disclosure and zero business effects on denial; distinct audited retries, issuer outage and residual token window; and bind/release/settle/cancellation interleavings. Runtime tests and deployment evidence belong to the separately authorized implementation/release stage.

Evidence and handoff

Reviewed coordination publication e09826ffa22aab5ae3e817df9d7c0e9f7ebb1c30: canonical ADR SHA256 e87a4fb4a19ab23994ec2de78ebb0233274214c7e54d42f0460d7d2b494ad97d, Delivery fenced-bind revision SHA256 2492ac8850c0078da278b55b85b2be6cf306c72af49ad67b55f461ada3389bc6, and Platform/Sales admission-recovery supplements. Service-auth baseline is v1.7.0. Platform role/verification source remains 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a, verified in the previous supplement; existing published role-map and bootstrap predicates underpin this review. No deployed claim is inferred.

Live Platform inbox and ledger refreshed for this review; no ADR-0052 implementation commitment is completed. This memo alone is drafted for the coordinator's serialized publication batch; no independent indexer, freshness, issuance, runtime edit or deployment. The publisher must index/freshness-check after the final batch. No approval or commitment is authored for another domain.