Glossary
Plain-language definitions of every DineGlobe term: offering, policy, allocation, business date, capability session, capability gates and more.
These are the words DineGlobe uses on its screens, in its emails and in its error messages. Each definition is plain language; where a term has an exact on-screen shape (a code, a label, a limit) the shape is given.
Allocation — the database-enforced hold of specific table(s) for one booking at one time. Two parties can never hold the same table at the same time; the rule lives in the database itself, not in application discipline.
Availability — the read that answers “what can this party book?”: the computed times for a service, party size and business date, each labelled AVAILABLE, NOTICE (inside the notice window) or UNAVAILABLE, with a best-fit table suggestion per time. Booking commands must carry the availability read’s service revision with them.
Business date — the venue-local calendar day a booking belongs to, written YYYY-MM-DD. It stays distinct from both the UTC instant and the wall-clock time: a 23:30 booking in one timezone can land on a different UTC day, and lists are always anchored on the business date.
Capability gates — the country-level switches that control paid bookings and SMS. They are closed during the pilot: opening one requires recorded evidence, an approved non-sandbox provider configuration, and an explicit operator act — approval is never a form default.
Capability session — the 60-minute guest session created by a one-time exchange of a link fragment, scoped to exactly one reservation. It allows viewing, reconfirming or cancelling that booking and nothing else; it is never a staff session, and staff commands refuse guest actors.
Check-in pass — an opaque credential issued for a confirmed booking so a door scan can record its arrival. Only the latest pass is live (reissuing rotates it), a scan works from 60 minutes before the booked start until the planned end, and the pass alone authorizes nothing: every scan still requires staff holding checkin.record.
Confirmation code — the short code that identifies a booking: DG- followed by 8 characters from an alphabet that omits the ambiguous letters I, L, O and U, so codes read aloud well (DG-XXXXXXXX). Guests show it at the venue; staff find the booking instantly with it. The code alone never grants account access.
Guest link — the private /b#… link that lets a guest manage one booking. The secret part exists only in the link, is exchanged exactly once, and expires after 24 hours. Reissuing a link invalidates every earlier link and every session it created.
Hold — a short, exclusive table reservation created through the same allocator real bookings use — for example the 5-minute hold created when a host offers a waiting party a table. If the offer expires, the hold releases and the table becomes bookable again.
Horizon — how far ahead a service can be booked: per offering, at most 365 days, 90 by default. Dates beyond it answer “That date is past the venue’s booking window.”
Minor units — money as exact integers in a currency’s smallest unit (cents, and whole units for zero-decimal currencies such as JPY). There is no floating-point money and no automatic currency conversion anywhere; deposits may display as raw minor units with the currency named beside them.
Notice window — the lead time a service requires between booking and start (60 minutes by default). Online, times inside the window render disabled with the suffix “too soon — call us”; staff at the door can still take the same booking, because staff presence satisfies the notice rule.
Offering — a bookable service a venue publishes, such as “Dinner”. It carries an approval mode (instant or request), a default duration (15–480 minutes), a notice window and a horizon. A venue with no active offering honestly shows “Online booking is not available for this venue yet”.
Organization — the business entity that owns venues, staff memberships and ownership. Ownership is org-wide, transfer is a deliberate owner-to-member act, and the last active owner cannot be removed until ownership moves.
Outbox — the durable queue of outgoing side effects (confirmation emails, reminders, waitlist notices). Jobs survive crashes and are retried; during the pilot, with no provider configured, dispatch dead-letters visibly with PROVIDER_NOT_CONFIGURED rather than pretending to have sent.
Party — the group a booking is for, sized 1–200. The party size feeds availability: a party only fits where the floor plan says it fits.
Policy — a versioned set of booking terms for a service: payment mode, free-cancellation minutes (24 hours by default), late-cancellation and no-show retention, and a grace window (15 minutes by default). Published versions are immutable — editing means retiring one version and publishing another — and a cancellation is quoted against the version the guest accepted, never the venue’s current terms.
Queue token — the waitlist credential a guest receives on joining a queue. It expires at venue-local midnight after the business date and is exchanged once for a 60-minute session scoped to that one queue entry, which can accept a table offer or withdraw.
Reconfirmation — a venue’s request that a guest confirm they are still coming. The guest answers on their booking page (“Yes, I am coming”), and the answer is recorded as a new version of the booking.
Request — a booking made on a request-mode offering. It stays REQUESTED until a manager approves or declines it, or until it expires at the earlier of its 24-hour review deadline and the service start; expiry notifies the guest honestly rather than quietly confirming.
Request key — the idempotency key a client submits with a booking or cancellation. Retrying with the same key returns the same result: a double click replays one booking, it never creates two. A genuinely new attempt mints a fresh key.
Schedule — the weekly set of service windows for an offering, plus dated exceptions (a closed day, or an override window). Publishing a full weekly set updates rows that match, creates new ones and removes absent ones; weekday 0 is Sunday.
Service revision — the version number of a service’s bookable state for a business date. Reads carry it; writes must echo it back. If the state changed in between — a new booking, a closure — the command refuses with AVAILABILITY_STALE instead of guessing.
Slug — a venue’s public address, such as dineglobe-demo: lowercase letters, digits and single hyphens, with reserved words refused. Renaming a venue keeps its retired addresses redirecting permanently to the canonical one, and a draft or deleted venue is simply not found.
Slot — one bookable start time offered for a service on a date. Slots are pinned to exact UTC instants (a clock-change hour yields two distinct slots), rendered in the venue’s own timezone, and labelled by the availability read.
Venue — one restaurant or location with its own floor plan, IANA timezone, currency, language settings, policies, staff memberships and slug. Venue data never crosses venue lines: two venues sharing a guest’s email each see only their own record, and there is no automatic identity merging.
Visit — the record of a party’s progress at the door: arrival counts, seating and departure. It drives the board’s “Arrived 2/4”, seated and departed states and the floor-right-now occupancy list.
Waitlist entry and offer — a same-day queue position that consumes no inventory, with an explicitly approximate quote (“position 3, ~25 min (approx)”). A host’s offer holds a real table for 5 minutes; accepting converts that same hold into a confirmed booking, and an expired offer releases the table and returns the party to their original place in the queue.
Walk-in — a booking a staff member takes at the door or by phone, through the same allocator and policy checks as an online booking. A mid-flight policy change answers POLICY_STALE rather than booking under unstated terms.