What works today & known limits

This is the honest capability map for DineGlobe’s first release: what runs today, what is half-built and what does not exist at all. It is written from the release census — 46 tracked capability families, of which 30 are implemented with on-disk test evidence, 2 are partial, 13 are deliberately deferred and 1 is a governing principle. Nothing on this page is a promise about the future; deferred items carry no dates.

Single-market pilot evidence only: one approved country and its listed capabilities do not constitute global support; unlisted countries and capabilities stay disabled.

What is fully live today

Thirty capability families are implemented and backed by tests. Grouped by area, here is what a venue and its guests can actually do.

Accounts, teams and venues

• A business exists as an organization with venues, members and role-scoped access; staff roles are a fixed, release-enforced matrix.
• An owner signs up self-serve and creates their organization and first venue through the real product, with no hand-seeded rows.
• Staff register with a password, sign in, enroll two-step verification, and every session can be revoked; a lost session stays signed out.

Taking bookings

• A published venue gets its own public booking page a guest can open and book from — DineGlobe’s first-party channel end to end; there is no third-party distribution on top of it.
• A guest books directly, receives a DG- confirmation code, sees the nearest open times offered honestly when a slot is lost mid-submit, and a double click can never create two bookings.
• Request-mode bookings reach the venue for an approve/decline decision, expire on a deadline if undecided, and guests can be asked to reconfirm.
• Hosts take phone and walk-in bookings from the floor, move parties between tables, and read the day’s board live.

Running the floor

• Two parties can never hold the same table at the same time — enforced in the database itself and proven with 100-way concurrent races.
• Venues define areas, tables and approved table combinations; hosts see the floor with live table states.
• Day-of service works: record arrivals and partial parties, seat parties, handle table overruns and departures, with door staff on a contact-free view.
• Guests receive an opaque check-in pass that door staff scan or type in, with manual entry as the designed fallback.
• Cancellations quote the venue’s own policy outcome, and no-shows are marked only after the accepted grace window has passed.

Guests and communication

• Guests open a private portal link (a one-time exchange into a short-lived capability session) to view, reconfirm and cancel their own booking and download a calendar file.
• Venues keep a guest history with purpose-limited encrypted notes (dietary, allergy, accessibility) and role-decided redaction.
• Confirmation emails, reminders and waitlist notices are composed from reviewed English/Japanese templates through a durable outbox — in the pilot they dead-letter visibly because no provider is configured (see limits below).

Money machinery (pilot posture)

• The full payment machinery works end to end against the sandbox provider: holds, hosted checkout, signature-verified webhooks, capture reconciliation and the approved refund workflow. No real money moves — the capability gates are closed on purpose.
• DineGlobe’s own subscription ledger (trial, active, past-due, cancelled, with grace entitlements) works in the same sandbox posture, with no commercial activation.

Data and insight

• Venues import future bookings from CSV with a dry run and crash-safe resume, and export their data as encrypted CSV and bounded PDF service sheets.
• Managers and owners read operational reports computed from real ledgers: accepted parties, covers, cancellation split, lead times, waitlist conversion and per-currency money that is never combined.

Platform, security and privacy

• Platform operators approve publication, manage deny-by-default capability rows, suspend intake, and work support cases (see the Platform operator console).
• Platform roles, security headers, rate limits, audit events, the release security suite and repository hygiene guards are active.
• Privacy requests run as verified cases with retention schedules, legal holds and an append-only deletion ledger that is reasserted after any restore.
• Background jobs survive crashes (durable outbox with leases), alert runbooks exist, deploys go through reviewed scripts with evidence-gated rollback, and an encrypted off-server backup plus isolated restore rehearsal is in place — with the off-server target not yet mounted (see limits).

Web presence and experience

• Published venues have real public profile pages, canonical slugs (retired slugs redirect forever), a sitemap and discovery metadata.
• Anyone can search the public directory by name, city or category — published venues only.
• The app installs as a web app and, offline, shows an honest “you are offline, nothing was recorded” screen instead of faking a saved booking (details).
• English and Japanese are fully reviewed; Arabic ships as the right-to-left locale; anything unsupported falls back to English with a notice (details).
• The whole surface is keyboard-operable with announced errors and status, verified in real-browser end-to-end tests.

Two partial families

Exactly two families are marked partial, and the missing half is specific:

• Venue profiles (content editing). The profile itself, the publication lifecycle (draft → review → published → unpublished), public pages, the slug registry, SEO and public media delivery all exist. What is missing: a content-editing command for the venue’s descriptive text. Those text rows are seed/fixture-backed today, so a venue owner cannot edit their profile prose in the product yet.
• Waitlist (guest self-service). The same-day queue exists with honest approximate quotes and expiring, resource-backed 5-minute offers — a host offers a real held table through the shared allocator and the guest accepts via a one-time queue token. What is missing: the guest self-service queue surface — there is no online command for a guest to join, poll or leave the queue. (The LEFT state exists in the state vocabulary, but nothing sets it yet.)

What is deferred

Thirteen families are deliberately deferred. Nothing user-facing exists for them, none has a date, and nothing on this list should be read as a commitment:

Deferred	What that means for users
Notifications subsystem	None; V1 notification needs are carried by the messaging feature above.
Marketing and loyalty	No campaigns, promotions or loyalty — and no fabricated consent rows anywhere.
Guest reviews	No reviews or ratings.
Events and ticketing	None.
Nightclub operations	No admission, ticketing or promoter tooling.
Hotel rooms	No room booking.
Beach clubs	No beach-club operations.
Group bookings	No group or itinerary tooling.
Large-organization tier	No SSO/SCIM or the big-organization service tier.
Google reservation integration	None; the only Google surface is an honestly labeled Maps search link.
POS connector	None — which is why POS spend metrics are reported as unavailable, never invented.
Property management systems	None.
AI features	Explicitly excluded from this release; no AI feature exists.

Known limits, stated plainly

These twelve limits are known, accepted for the pilot, and reflected in the product rather than hidden:

1. No email actually sends during the pilot. Dispatch fails visibly and is recorded as a dead letter (PROVIDER_NOT_CONFIGURED); a manager can retry once a provider exists. A booking still confirms in the app with its DG- code, but the confirmation email never arrives; staff see the failed outcome with masked recipients, and a walk-in without an email address is recorded honestly as having no recipient — never an invented one.
2. QR codes generate but delivery is manual. The code image renders deterministically, and getting it onto a table card is a human step — there is no QR asset-delivery service.
3. Reports mark unavailable metrics as unavailable. Five metrics (POS spend, online booking conversion, demand lost, resource utilization, actual occupancy) surface with a reason instead of fake zeroes, and zero-denominator rates read “not applicable”.
4. Offline refuses rather than guesses. Offline writes answer 503 OFFLINE; the scanner shows its “nothing has been committed or queued” banner; staff fall back to typing the confirmation code (details).
5. The live demo has a reset window. The demo data resets nightly; between midnight UTC (when the demo venue’s business date rolls) and the reset run about 17 minutes later, the demo shows the new date against yesterday’s story. It is accepted and never faked.
6. No public directory search page yet. The directory service exists and the public discovery path today is the landing page’s pilot-venue list; a dedicated search page is deferred presentation work.
7. The off-server backup target is not mounted yet. The readiness check honestly reports a stale-backup warning; WAL archiving is absent, so the recovery point equals the base-backup cadence and is never advertised as better.
8. Camera capture is not implemented. The device matrix records the host camera scan as not in this release and the physical-tablet walkthrough as pending hardware; manual pass entry is the implemented path.
9. Contact and support pages show an email address only when one is configured. Otherwise they say plainly that the pilot does not publish an inbox.
10. The customers page carries no logos or testimonials — one approved founder quote plus the real pilot venues; nothing invented.
11. Payments screens exist for staff only — there is no guest-portal checkout page yet. Refunds demand a fresh MFA verification and, with no threshold configured, always a second-person approval; the approver can never be the requester (refunds).
12. One automated landing-page check is accepted as environmentally red — the development database has accumulated synthetic demo venues that push fresh seeds past the first page of the list. The purge was declined deliberately and accepted by the operator.

The pilot in one paragraph

DineGlobe runs live as an unpaid pilot: bookings are free, the payment and SMS capability gates stay closed until signed gate evidence exists, and the production provider settings are deliberately unset so paid flows refuse honestly instead of pretending. The deployment is a single server — no availability, capacity or recovery figures are claimed beyond what has been measured on it. The landing page’s live demo runs on fully synthetic data (every demo guest address is unresolvable by design, pilot organizations are never touched), resets nightly, allows ten demo sign-ins per hour per visitor IP, and provisions a fresh real account per role sign-in whose password is discarded — nobody signs back in. Try it via Try the live demo, or read What is DineGlobe for the overview.

Where to look next

• Platform operator console — publication review, capabilities, intake suspension, support cases, launch gates.
• Your account & security — sign-in, two-step verification, sessions and recovery.
• Roles & what they can do — who can do which of the things listed above.
• Error codes & fixes and Troubleshooting by scenario — when something refuses, the refusal is documented.