Platform accepts ownership of the operator auth rail for domain web apps

Platform's position: yes, this is Platform's to own. Identity and the auth rails sit with Platform per the domain topology, more than one operator-facing app will need a front door (finance.sguildswim.com today, and the same question arrives with any future operator dashboard), and Finance is right that a reporting domain should not invent a parallel auth mechanism. Platform will author the ADR in the main series per the suggestion in the parent memo; the commitment on this memo tracks it.

The rail mostly exists already

The good news is that the integration shape Finance should code against is not hypothetical. Platform's deploy runs Better Auth (email/password and Google) with two properties that matter here:

First, the session cookie is scoped to .sguildswim.com in production and *.sguildswim.com is a trusted origin, so an operator who signs in through Platform carries a session every subdomain app can see. Second, Platform already serves a session verification endpoint at GET /api/auth/session that returns the signed-in state, the user, and the session record. Authorization on top of that is also in place: a SuperAdmin table with a requireSuperAdmin guard for platform-operator privileges, and the identity layer carries an operator role on PersonRole.

Integration shape for Finance

The shape Finance codes against, ahead of the ADR formalizing it:

The finance dashboard does not run its own credential check. Its Next.js middleware or server component forwards the incoming request's cookies to Platform's GET /api/auth/session and treats the response as the verdict: signed in and authorized means render, otherwise redirect to Platform's sign-in with a return URL back to the dashboard. Operator authorization for the single-role case is the SuperAdmin check; the ADR will settle whether domain apps get a dedicated operator gate distinct from SuperAdmin, but the verification call shape will not change, only what the authorized predicate consults. No Person-grain PII crosses; the response carries the operator's user identity and nothing else, which matches Finance's stated requirement.

Two things the ADR will pin down beyond this: whether verification stays a remote call per request (simple, one round trip inside the same infrastructure) or domain apps verify a signed token locally against Platform's published JWKS (Platform already publishes RS256 keys at /api/auth/service-jwks for service JWTs, so the machinery exists if per-request latency ever matters), and the operator-role model (SuperAdmin only, or a scoped operator role per app). Finance's single-operator requirement is satisfied either way, so Finance does not need to wait on those answers to integrate.

Interim posture

The interim constant-time bearer-token cookie gate is fine as described, and deliberately minimal is the right call. One request: keep the interim mechanism unexported as planned, so the cutover to the rail is a middleware swap and nothing else grows roots against the stopgap.