DineGlobeDocs

Docs / Platform & trust / Platform operator console

Platform operator console

Publication review, the country capability registry, intake suspension, support cases, readiness alerts and signed launch reviews.

Platform operator

The platform operator console is the internal surface where DineGlobe’s own operators work: deciding which venues publish, keeping the country capability registry, suspending intake at a venue in trouble, working support cases, and signing launch reviews. It lives at /app/panels behind a normal staff sign-in at /app/login, it asks search engines not to index it, and its own header names its probes: “Operator console. Liveness probe: /health/live · trusted readiness probe: /health/ready”. Nothing on it is a tenant permission — platform authority is its own axis.

The rules every platform command obeys

Every console action, without exception, requires all of the following, re-checked server-side on each call:

  1. A live staff session — a real signed-in account; session cookies alone carry no authority.
  2. An ACTIVE platform role grant for the acting account. A grant that exists but is deactivated counts for nothing.
  3. An MFA-verified session. A valid grant on a session that never completed two-step verification answers MFA_REQUIRED — you finish sign-in with a code first.
  4. A mandatory reason, recorded with the command. Reasons are bounded to 500 characters.

Every command is audited with the actor, the reason and the target. With no grant the answer is PERMISSION_DENIED; the two denials are deliberately different so a missing second factor is never mistaken for missing authority. There is no impersonation surface anywhere in the console — the module mints no sessions and no tenant data on an operator’s behalf.

The five platform roles

Role What it can do
TRUST_OPERATOR Decide publication reviews, write country capability flags, suspend and resume venue intake. Also reads support cases.
SUPPORT Work the support-case workflow: open, list, inspect, escalate, resolve.
PRIVACY_OFFICER Read support cases (the same reader set as SUPPORT). Venue-side privacy execution stays with the venue’s own roles.
PLATFORM_FINANCE Deliberately excluded from case reading; scoped to billing-adjacent work and reads operational readiness signals.
SECURITY Administer platform roles (grant, reactivate, deactivate, list) and run the release, launch and performance suites; the only role that writes risk-register and assessment evidence.

Grant lifecycle is narrow by design: the deployment plants the first SECURITY row directly, and every later grant, reactivation or deactivation goes through SECURITY-only commands. Deactivation takes effect immediately — the next command from that account is refused. Re-granting an existing role/user pair reactivates the one row rather than adding a second.

Publication review

A venue reaches the console only after its owner has cleared the venue-side readiness checks: profile content in the venue’s default language, at least one active table or resource, at least one active offering with an active weekly schedule, and published accepted booking terms for every bookable offering. The venue then sits in PENDING_REVIEW — private to this day, visible to nobody.

The trust operator records a decision with a mandatory reason:

  • APPROVE — the venue becomes PUBLISHED: it gains a public profile page and enters the directory, sitemap and public booking.
  • REJECT — the venue returns to DRAFT and stays private; the owner fixes what was named and requests review again.

Deciding a review that is no longer pending — for example one already decided — answers PUBLICATION_NOT_PENDING instead of re-deciding it.

The country capability registry

Capabilities are deny-by-default and per country. Exactly two capability kinds exist in this release: payment and sms. The registry rules:

  • One row per country and capability configuration; a country with no row is refused, never assumed enabled.
  • Every write carries a mandatory evidence reference — including switching a capability off. The evidence is part of the row.
  • Enabling a capability in production additionally requires an approved, non-sandbox provider configuration; a registry row naming a sandbox or unconfigured provider keeps the capability disabled no matter what the flag says. Attempting otherwise answers CAPABILITY_NOT_ACTIVATABLE.

This is why the pilot runs free bookings only: the payment and SMS flags for the pilot country stay closed until real provider evidence is recorded. Payments (pilot posture) describes the guest-visible consequence.

Intake suspension

When a venue must stop taking new bookings — a dispute, a compliance question, an operator decision — the trust operator suspends intake with a mandatory reason. The suspension is deliberately narrow:

  • Blocked: new bookings from every path — the public booking page, staff walk-in/phone intake, and CSV import all refuse with PLATFORM_INTAKE_SUSPENDED.
  • Untouched: existing reservations, guest self-service cancellation, refunds and data exports stay fully available. Suspension never deletes or hides what a venue already booked, and publication status does not change.

Resuming intake restores new bookings immediately. Suspending an already suspended venue (or resuming one that is not suspended) answers a plain conflict.

Support cases

Support work runs through a case ladder: OPEN → ESCALATED → RESOLVED, each step its own act. Opening a case records the organization, an optional venue, a category and a summary; escalating carries a mandatory reason; resolving carries a mandatory outcome and stamps the closure. Doing the steps out of order answers SUPPORT_CASE_INVALID_TRANSITION.

The inspect view is a safe view on purpose: case metadata plus venue-level counts — future reservations, active waitlist entries, outbox states, failed messages, payment-account facts and subscription state. It contains zero guest personal data: no names, no note bodies, no reservation rows. Case reading is available to SUPPORT, TRUST_OPERATOR, PRIVACY_OFFICER and SECURITY; PLATFORM_FINANCE is deliberately outside that set.

Signed launch reviews

Before a market opens, a supervised review records the eight launch gates G-01 through G-08 — legal entity and first country, payment account and funds flow, data protection, SMS/email operation, the language-readiness and accessibility gate, infrastructure, pricing/tax, and public listing rights. The review discipline:

  • Every gate select defaults to BLOCKED. Approval is an explicit operator act with an evidence owner and an evidence reference — never a form default.
  • The review runs the four real end-to-end journeys (owner-publish, guest-book, host-arrival, finance-paid — an owner publishing a venue, a guest booking, a host-recorded arrival, and a paid deposit booking through the sandbox provider) in a throwaway scratch database it creates and drops itself, so the journeys are proven, not narrated.
  • The decision is recorded as a signed record and the signature is verified on every read. If a stored record ever fails verification — meaning recorded launch evidence was modified outside the review flow — the system fails closed with READINESS_SIGNATURE_INVALID.
  • Requests for country capabilities (free-booking, paid-booking, sms) are recorded against the same review, and a missing gate, journey or registry row leaves the capability disabled with the blocking owner and next action named.

SECURITY and TRUST_OPERATOR conduct reviews. One approved pilot country is never presented as support for any other market — see What works today & known limits for the exact scope statement.

Readiness, quality and load surfaces

Alongside the decision tools, the console exposes the operational evidence surfaces, all aggregate-only — counts, ages, codes, never guest data:

  • Operational alerts — thresholds evaluate against the live system; every firing alert names its runbook action and its owner. Any of the five platform roles can read these.
  • Readiness — the dependency summary is the same aggregate body the trusted /health/ready probe serves.
  • Backup evidence — append-only records of kind BASE, WAL or UPLOADS, each with a mandatory off-server location reference; completion may trail the clock by at most 5 minutes.
  • Release suite — executes the repository’s own security and correctness battery; a READY verdict requires every registered check to pass in the same run, and unselected checks are recorded as NOT_RUN and block the verdict.
  • Performance workload — runs the real service commands under the declared pilot load against a scratch database the runner creates and drops itself; budgets report measured p95/p99 and every gap is reported, never averaged away.

Running the suites needs SECURITY or TRUST_OPERATOR; writing risk-register entries and third-party assessment evidence is SECURITY-only.