Platform operator guide

Platform operators work for the platform, not for any venue. Platform authority is a separate axis from the staff roles: it is never a permission in the tenant matrix and never inferred from a venue membership — the cleanest owner in the system holds zero platform power until a platform grant says otherwise. There are five platform roles, every command demands an MFA-verified session plus a mandatory reason, and every command is audited with actor, reason and target.

The five platform roles

Role	Powers in this release
TRUST_OPERATOR	Decide publication reviews; write country capability flags; suspend and resume new-booking intake at a venue.
SUPPORT	The support-case workflow: open, escalate, resolve with a mandatory outcome, list, inspect (safe view only).
PRIVACY_OFFICER	Reads support cases like SUPPORT. A venue’s privacy execution stays with the venue’s own privacy.case.process holders.
PLATFORM_FINANCE	Deliberately excluded from case reading; its only gate membership in this release is the ops-readiness reader list.
SECURITY	Platform-role administration (grant, activate/deactivate, list); quality suites and the risk register; launch readiness reviews; performance workload — and the case reader set like SUPPORT.

What every command requires

Three things, checked server-side on every call:

1. An ACTIVE platform-role row for your user.
2. A live session that is MFA-verified — the session row itself must carry a verified multi-factor timestamp.
3. A mandatory reason (at most 500 characters) that lands in the audit trail with actor and target.

The failure codes tell you which leg is missing. No grant at all → 403 PERMISSION_DENIED (“The acting session holds no ACTIVE platform role for this command”). A grant but no MFA-verified session → 401 MFA_REQUIRED — a precondition, not a permission gap: finish MFA on your session and retry. Enrollment and recovery codes are covered in Your account & security.

There is no impersonation surface anywhere: the platform module mints nothing — no sessions, no tokens, no tenant rows on your behalf.

How grants are administered

SECURITY administers the axis. The first SECURITY row is planted directly by the deployment; every later grant, reactivation or deactivation goes through SECURITY-only commands. Re-granting an existing user/role pair reactivates the single row rather than duplicating it, and deactivating kills access immediately — the next command refuses. Listing grants shows grantee identities, which is how the register stays reviewable.

Publication decisions (TRUST_OPERATOR)

A venue whose owner requested publication sits in PENDING_REVIEW until you decide it:

• APPROVE publishes the venue — it becomes publicly resolvable, bookable and listed in the directory and sitemap.
• REJECT returns it to DRAFT with the reason recorded.
• Deciding a review that is not pending (already decided, or not in the review state at all) refuses with PUBLICATION_NOT_PENDING; replaying a decided review is a 409, not a double publish.

Publication, the readiness blockers owners see, and the slug registry: Venues, slugs & publication.

The capability registry (TRUST_OPERATOR)

Country capabilities are deny-by-default: absent row means disabled. Two capabilities exist in this release — payment and sms. Every write, including a disable, requires an evidence reference, one row is kept per country/capability pair, and enabling in production additionally requires an approved non-sandbox provider configuration — a sandbox or unconfigured provider is refused with CAPABILITY_NOT_ACTIVATABLE. These are the F28 gates: during the pilot they are closed on purpose, so paid bookings refuse honestly and SMS stays off while the machinery is complete and exercised in sandbox posture. The user-facing consequences are in Payments (pilot posture) and What works today & known limits.

Intake suspension (TRUST_OPERATOR)

Suspending a venue stops new booking intake only, for a mandatory recorded reason: existing reservations stand, guests can still cancel, refunds still run and exports still work — suspension is never a silent deletion. Resuming needs a reason too; suspending twice or resuming a venue that is not suspended each refuse with their own code. The venue side of that state (and the entitlement rule when billing, not the platform, suspends intake) is in Subscription billing.

Support cases (SUPPORT, TRUST_OPERATOR, PRIVACY_OFFICER, SECURITY)

Cases move OPEN → ESCALATED → RESOLVED, with a mandatory outcome at resolution and a mandatory reason on escalation. PLATFORM_FINANCE is deliberately outside this reader set. The inspect view is a safe view by construction: case metadata plus venue-level counts — future reservations, active waitlist, outbox states, failed messages, payment-account facts, subscription state and honest provider configuration states. It contains zero guest PII, no note bodies and no reservation rows, and every read is audited. The counts answer “how big is the problem”, never “who is the guest”.

Ops readiness, alerts and backup evidence (all five roles)

The operational surfaces are readable by every platform role (still on an MFA-verified session): threshold alerts that each name a runbook action and owner, and the append-only backup evidence ledger (kind, completion instant, off-server location reference, optional LSN and size). The readiness probe itself is a trusted-peer surface — an untrusted caller to /health/ready gets a bare 403 — and its body is counts, ages and codes only. The runbooks these alerts point at live in the operator handbook; the honest backup posture of this deployment (no off-server target mounted yet, so the backup-age check reports WARN) is in What works today & known limits.

Launch readiness, quality suites and performance (SECURITY, TRUST_OPERATOR)

• Launch reviews. The eight launch gates (G-01 Legal entity and first country through G-08 Public listing rights) are recorded with evidence owner and reference; every gate select defaults to BLOCKED — approval is an explicit act, never a form default. Running the review executes four real end-to-end journeys in a throwaway scratch database and records a signed decision; every stored signature is re-verified on read and a tampered record fails closed (READINESS_SIGNATURE_INVALID). Requested country capabilities are recorded with the review and stay disabled until their own gates pass.
• Quality suites. Running the security and end-to-end correctness battery needs SECURITY or TRUST_OPERATOR; writing risk-register rows and third-party assessment evidence needs SECURITY alone. A verdict of READY requires every registered check to pass in the same run — unselected checks are NOT_RUN and block.
• Performance workload. Runs the real service commands against a scratch database the runner creates and drops itself; budget overrides may only tighten, never widen. The measured numbers describe the shared development host — they are not production capacity claims.

Where you work: the operator panel host at /app/panels carries the platform forms (the DEV-042, DEV-046, DEV-049, DEV-050 and DEV-051 panels); the product story is in Platform operator console.

What platform authority cannot do

• Touch tenant data as a tenant. No platform role books, cancels, seats, refunds or edits a venue’s records — the tenant matrix never sees a platform grant.
• Impersonate anyone. No surface mints sessions or tokens for another user; support answers come from counts, not from borrowed logins.
• Skip evidence. Capability writes, intake suspensions, decisions and grants all demand a recorded reason; the registry refuses unevidenced rows.
• Turn the pilot on by writing a flag. A capability flag alone is not enough — the non-sandbox provider check stands behind it.

The honest scope of this deployment

This is a single-market unpaid pilot: free bookings only, SMS off, and email dead-lettering visibly because no provider is configured. The operator’s pinned scope note governs every claim: Single-market pilot evidence only: one approved country and its listed capabilities do not constitute global support; unlisted countries and capabilities stay disabled. There is no availability or recovery promise attached to a single-server deployment; what is measured instead is described in What works today & known limits, and the whole vocabulary of gates and roles is in the Glossary.