Golf tee sheet

The shape

This is a Seldon appointment Offer with a fixed duration, a grid Availability projection backed by a TimeScheme with a side dimension, Trantor resource types for tee-time slots and carts, Terminus tier groups for member access rules, and Hober + Payments for the after-round pro-shop sale.

• Seldon models the round itself: Offer + Availability + Booking.
• Trantor holds slots and carts. Atomic all-or-nothing on confirm.
• Terminus identifies members and their tier; the Gold tier is a Group(kind=tier) with active GroupMember rows.
• Radiant holds the pricing rules and the cancellation policy, pinned into each Booking at confirm time so a mid-week price change doesn't move the goalposts.
• Hardin + Hober + Payments + Mallow handle the sleeve of balls and the ledger entry on close.
• Speaker sends the booking confirmation and the day-before reminder, gated by Terminus consent.

Walk-through

Setup

The shop's admin defines the TimeScheme — ten-minute intervals starting at 7am, with a side dimension carrying values front and back. They create the Offer "18-hole round, foursome" with kind=appointment, durationShape={mode: fixed, fixedSec: 14400}, partyCapacity={min: 1, max: 4, default: 4}, requirements of one tee-time slot and zero-or-one carts. A BookingAccessRule on the TimeScheme grants Gold tier members a 14-day booking horizon; the default for public is 7.

Member books

Greg, a Gold member, opens the booking site twelve days out. Seldon queries Availability for the next 14 days because Terminus confirms his Gold entitlement is active. He picks 8:20 on Saturday, front nine, foursome, two carts. The Booking call atomically holds one front-nine slot and two carts in Trantor, pins the current pricing and cancellation YAML versions from Radiant, and records the booking with status=confirmed. Speaker dispatches the confirmation email after Terminus reports active consent for transactional.email.

Tournament collision

Wednesday, the shop creates a TimeExceptionWindow on the TimeScheme for the front nine, 7am to noon Saturday. The exception sets capacity_modifier=0 for those slots. Bookings already on those slots are flagged; Daneel runs a "tournament reschedule" workflow that messages affected parties through Speaker with one-tap reschedule links.

Saturday morning

Greg arrives. The starter taps his Booking, which auto-advances to checked_in via the Seldon emission pipeline (the BookingLifecycleAutoAdvancer subscribes to booking.starting). The carts in his Trantor hold get assigned to specific cart Resources (cart 7 and cart 12) via a direct allocation. Eight hours later, his Booking reaches completed.

The sleeve of balls

On the way out, he grabs a sleeve. The pro behind the counter opens a Hober Order with orderType=retail_quick_sale, adds the Hardin product variant for "Pro V1 sleeve", and tenders the $14 charge on his card. Payments confirms the auth-and-capture in one step. On close, Mallow generates the Invoice and posts DR Cash / CR Sales Revenue / CR Sales Tax Payable. Trantor decrements the sleeve out of inventory via the RecipeIngredient on the variant.

Why this is hard without LatticeKit

Most golf-management software glues a custom tee sheet to a custom POS to a custom CRM, each with its own database, its own auth, and its own opinion on what a "round" is. The hard parts — atomic resource allocation, dimensioned slots, lifecycle events, consent-gated comms, audit history that ties the ball sleeve to the round to the member — either get reinvented for each integration or fall through the cracks. LatticeKit gives the shop one cohesive substrate where the Booking, the cart hold, the pricing snapshot, the receipt, and the ledger entry all carry the same tenantId and chain to the same audit events.

Try it

The Getting started walkthrough uses this exact narrative — seven curl calls take you from registering your config repo to a confirmed Booking. Join the waitlist for a sandbox tenant.