The Brain

A staff role grants access only for the club it was granted in.

Club CRM notes and records are never visible to other clubs or on the player's global profile.

The reception role has no access to subscription, billing or platform settings.

Only a platform administrator with a platform-scoped role can list, grant or revoke platform staff roles and read the access audit. Grants target existing accounts and only declared platform roles; duplicate grants are idempotent. The last platform administrator cannot be removed. Successful role changes and denied platform staff mutations retain immutable actor, target, action and time records. Administrators can filter recorded access history by action, role, account and UTC dates and page through older records without editing or deleting history. Legacy records do not identify whether a support role change was provisioning or temporary access. Club staff tools never grant platform roles.

Every server function is either an intentional public entry point recorded in the accepted permission matrix or requires authentication. Public entry points are limited to guest discovery, guest checkout and payment start, token-gated booking lookup and rentals, and narrow public reads of published content and display values; their writes remain guarded by database inventory, token and publication rules. The matrix is verified by an automated audit that fails when an endpoint is added without classification or a protected endpoint loses its authentication.

A staff role for a club may only be granted or revoked by a club manager of that club or by a platform admin, and only club-scoped roles can be granted this way — never platform roles.

Each portal's AI assistant is briefed with the Brain modules, rules and stories of that portal only, plus the shared glossary of roles.

A conversation thread and its messages are only readable and writable by the account that created it.

A new thread is titled from the first user message, trimmed to 60 characters.

The assistant is reachable from every portal screen and is told which module screen the user is viewing; only a module of the same portal is accepted as screen context, and that module's rules and stories are highlighted first. Screen context never widens what the assistant may see.

Public club websites offer an anonymous assistant branded "Caddie" as an "Ask us" tab inside the floating tee-time booking panel (no extra floating button). It is briefed only with that club's published pages, course status, public green fees, active pro shop products and whether a restaurant is connected; it cannot book, change or see personal data, keeps no stored history, and conversations are capped at 20 messages of 2000 characters.

The public Whole in One website offers an anonymous sales concierge briefed only with published platform pages in the visitor's language; it never invents prices or features, points interested clubs to the demo form, keeps no stored history and uses the same conversation caps as AI-005.

Each anonymous visitor (identified by a hashed network address) may ask the club and platform website assistants at most 30 questions per hour; further questions are politely refused until the next hour.

Active holds plus confirmed allocations on a tee slot may never exceed the slot's capacity.

A checkout hold expires after the club's hold duration (default 10 minutes); expired holds release their places even inside a long transaction. Confirmation rechecks expiry and rejects starts already in the past.

A 9-hole booking consumes one start. An 18-hole route with a linked second nine also consumes a start on the second nine at start time + turnaround.

A course closure makes affected slots unsellable immediately and lists, but does not remove, existing reservations.

Staff can reduce the participant count without deleting the reservation; a positive remaining count stays confirmed, zero cancels the whole group. Changes preserve the original per-player quote when available and preview the new quoted total; no refund or collection is implied.

Every reservation records its source (online or phone); a staff-created booking also records the staff member who created it.

The public availability feed shows only tee times and remaining places; it never includes customer names, contact details or notes.

Staff may move a confirmed group to a valid open start on the same course; the old allocation is released only when the new allocation succeeds. All inserts and inventory changes share a course lock and recheck capacity. Cancelled bookings cannot reopen.

Signed-in players see only reservations linked to their user ID. Checkout confirmation and successful payment read-back link the token-proven booking to the verified signed-in caller. A booking whose email equals a verified account email is linked automatically when it is created or confirmed, and a new or renamed account automatically picks up its existing unowned guest bookings; only the service role can run this matcher. Guest bookings can still be added from their secure manage link after signing in, which requires its reference and valid access token. An already owned booking can never be transferred.

Only staff of the reservation's club can record a checked-in count between zero and its confirmed participant count. Cancellation resets check-ins; a reduced group clamps the count to the remaining participants.

Each club selects an IANA timezone (UTC until configured). New reservations preserve the booking timezone, start instant and original cancellation hours and payment terms; checkout records explicit acceptance of its held quote. Later rate or timezone edits never rewrite historical terms. Cancellation deadlines subtract elapsed hours from the start instant; historical terms are unknown when not recorded.

Club managers configure a linked route per first-nine course (destination course and turnaround minutes). A player booking a linked route chooses the second-nine start from valid slots at or after the first-nine start plus the turnaround. Both allocations are held and confirmed together or not at all, share one booking reference, one access token and one quoted total, and cancelling or reducing the group applies to both allocations.

Public tee booking runs in one interface with its steps visible at the top — tee time, details, extras only when the club offers rentals (chosen before paying and added once the booking exists), then payment only when the club takes online payment and the held terms charge something now, then a restaurant table only when the club has a linked restaurant, ending in the confirmation. Only tee times that have not started yet in the club's timezone are offered. Details require first name, last name, email and phone; an optional federation number is verified as a membership at the club and otherwise the visitor rate applies.

Course media and flyovers in draft are never visible to visitors; only published items appear on public pages.

Media tied to a hole must reference a valid course and a hole number within that course's hole count; course-level media has no hole number.

Club managers and marketing staff of that club (or platform administrators) upload, order, publish and unpublish course media. Curation stays club-local; ordering is explicit and stable, and publishing never exposes draft items.

The public platform website navigation lists only the latest published revision of each page for the visitor's locale; drafts and never-published pages never appear, the "home" page leads the navigation, and the platform homepage surfaces the same published pages. When a "home" page is published, the platform homepage renders that recorded title and body as its main content; without a published "home" page the homepage keeps its built-in fallback copy, so the site never goes blank.

Each recorded platform page revision may carry a layout of ordered, hideable sections (hero, logos and numbers, cards, feature with photo, steps, pricing, testimonial, FAQ, call to action, demo request form, text, image), menu and footer placement, and an optional share image. Revisions without a layout render their title and body as one text section. Links and images accept only site paths or https URLs. Publication, history and restore follow CMS-003 unchanged; the header menu lists only published pages flagged for it, in menu order. Proof sections support named logo images with optional links, a contextual note, and benefit descriptions; existing text-only club names remain supported. Demo identities are labelled as examples, not customers.

The public demo request form requires name, club, valid email and explicit consent; each accepted request creates a sales pipeline lead with a primary contact and an immutable record of the request, its language and the exact consent text. Repeat requests from the same email within ten minutes are refused and a hidden spam field must stay empty. Nothing is emailed automatically.

Every portal module has at least one user story and an applicable non-retired rule linked through its stories. Every declared role has a persona with at least one story. Every story links at least one non-retired rule, includes acceptance criteria, and appears on the product roadmap. Coverage records requirements, not implementation or release readiness.

Converting a won deal to a club reuses the prospect's organisation and contact data; the prospect record and its stage history are never deleted.

Moving a deal to another pipeline stage writes a stage-history entry with the actor and timestamp.

Churn risk is signalled by club inactivity beyond a configured window and by stalled onboarding. Follow-up is limited to a manual task with an owner, a draft outreach for staff review, and a dashboard alert; the platform never contacts a club automatically.

CRM pipelines render as kanban lanes — one lane per stage with deals as cards, like the product roadmap board. This applies to the admin sales pipeline and to club-side CRM for events, businesses and clinics. Cards support drag and drop into other lanes with mouse, touch and keyboard, retaining alternative stage controls. Moving a card between lanes uses the existing saved stage-change path (CRM-002); a same-lane drop does not write a change.

Every deal carries an append-only activity timeline (call, email, meeting, note) with actor and time. Follow-up tasks have an owner and due date; completing one is recorded once and cannot be undone, and tasks are never edited or deleted. Duplicate prospects (same organisation name or contact email) are flagged before saving; records are never merged automatically.

Platform administrators can run a reachability check on a club's website domain. Each check is recorded append-only with the domain, result, detail, actor and time. A check never certifies domain ownership, website publication or launch approval.

A platform sales deal can hold several contacts, each with a name and optional email, phone and role. One contact is primary and shown on the deal card; the original prospect contact is kept as the first primary. Contacts can be corrected by sales staff but are never deleted.

Only platform_admin and platform_finance roles with no club scope may manage platform billing or access the invoice ledger. Other platform staff retain read-only subscription reporting access; club staff cannot manage platform billing.

Invoices snapshot the subscription recurring amount excluding tax plus a separately recorded tax amount in EUR. Plan and subscription changes never rewrite invoices. Unpaid invoices are overdue only after their due date; paid and void invoices are never overdue. Paid or void invoices cannot be reopened or changed through the ledger.

Invoice exports include club, invoice reference, subscription, due date, net, tax, total, EUR currency and payment status. Amounts use two decimal places without currency conversion and spreadsheet formulas in text cells are neutralised.

Visitors can complete a booking without creating an account; access is via a secure link.

Looking up a booking by reference without a valid access token returns only non-personal fields (club, date, status).

Each confirmed tee booking with an email address (website, paid checkout or phone) sends exactly one confirmation email with the tee time, course, players, price, payment and a manage-booking button; a failed email never fails the booking.

A reminder email goes out automatically 24 hours before each confirmed tee time with an email address, once per booking (linked nines count as one), including any linked restaurant table.

When club staff assign a membership with an email address the member receives a welcome confirmation; a membership for a member number that already had one at the club is confirmed as a renewal.

Members receive an email 30 and 7 days before their membership ends, unless a newer membership already exists; auto-renewing membership types receive a notice that it will renew automatically, manual ones a request to renew.

A pro shop order is confirmed by email when placed for payment at pickup, or once the signed payment notification marks it paid; it lists the items, total and order number.

Within the existing platform-administrator customer-management boundary, each club setup task records a title, named owner, progress status and actor/time history. Blocked tasks require a visible blocker; completed tasks require a named owner and no blocker. Task progress never certifies domain ownership, website publication or launch approval.

Club event screens can compose an AI planning brief from a required objective, optional audience and constraints, and an optional event already read through existing club access. Blank objectives are rejected. Only event offering fields are included, never participant identities or access tokens. Starting co-creation creates an account-private club assistant conversation; the user reviews and explicitly sends the brief, and follow-ups and saved conversation history use the existing assistant. No event, price, publication, communication or inventory writes occur. This first slice is not a shared structured plan or execution tracker; EVENT-002 retains that broader backlog intent.

The player dashboard counts confirmed account-owned reservations and group player places for today and tomorrow through day +7, evaluated separately in each booking's recorded timezone (legacy fallback to club timezone, then UTC). Each club and timezone has eight explicit dated rows, including zero dates; cancelled and other accounts' bookings are excluded. Totals combine these local windows, not a single global date. Read freshness is recorded; loading and failed reads never imply zero bookings. Group places are not individual attendance or revenue. Platform analytics remain separate UX-002 work.

Club staff see recorded confirmed reservation and player counts for today and each of the next seven calendar days, inclusive tomorrow through day +7, in the active club's recorded timezone. Today check-ins count only confirmed groups. Cancelled reservations and other clubs are excluded; empty dates have zero counts, failed reads are unavailable rather than zero. Switching clubs changes the scope. Refresh timestamps and explicit dates identify the read. These are booked rounds and player places, never collected or forecast revenue; platform and player seven-day analytics remain separate UX-002 work.

Admin, club and player entry addresses redirect to their respective existing dashboard modules. Desktop and mobile navigation exclude the redundant Overview and AI assistant destinations while preserving dashboard links, each page's assistant button and full conversation access. This navigation slice does not claim delivery of the today and next-seven-day analytics extension in UX-002.

Club managers keep shared structured event plans per club covering title, objective, offering, preparation/schedule and a communication draft, optionally linked to an existing event, plus an execution checklist with owner and due date. All club staff read plans and checklists; only club managers write them. The database stamps the plan author and checklist completion actor/time from the session; completed items cannot be reopened, and plans and items never move clubs or plans. Plans are working documents only — they never by themselves publish offers, send messages, change prices or allocate booking inventory, and restaurant reservations and vouchers remain managed by TBLS.app. Existing event capacity, payment, permissions and communication-consent boundaries remain in force. AI co-creation of plan content stays in the private assistant brief (EVENT-003); copying suggestions into a shared plan is a manual staff decision.

Club website editors select Google Fonts independently for headings and body and add fonts from a validated Google family catalogue to their club's selectors. Options render in their actual typeface when available, with labelled loading or unavailable fallback. Only known family identities are accepted, never arbitrary stylesheet or script URLs. Added fonts and choices persist in club-local website settings; existing Save style applies immediately to published pages as well as private previews, independently of page draft/publication history. Unsaved choices reset when switching clubs and never change portal typography or another club. Unavailable fonts use a system fallback without blocking website content.

Admin, club and player portals start on their dashboards with today and next-seven-day analytics and page assistant access, without Overview or AI assistant menu entries (UX-003–005). Platform administrators see aggregate confirmed bookings and group places for each club's current local date and tomorrow through day +7, inclusive, in that club's recorded timezone (UTC fallback). All-club totals combine these local windows; a selected club excludes every other club. Every selected club has eight explicit dated rows including zero dates, even without reservations; cancelled and out-of-window records are excluded. Authenticated reads paginate all matching records and return aggregates, not customer identities. Other platform staff have no platform-wide reservation read grant and see unavailable rather than misleading partial/zero figures; no permissions are broadened. Freshness is recorded; failed reads are unavailable rather than zero, and retained results identify the last successful read. These are booked rounds/group places, not attendance, collected revenue or financial forecasts; existing subscription figures stay separate.

The club dashboard requests current conditions and tomorrow through day +7 from Google Weather for the active club's manager-maintained canonical latitude/longitude and location label. Managers search by address or club name through authenticated Google Places requests and select a result to fill the address and paired coordinates, then explicitly save through the existing location permission boundary. Coordinates remain available as a manual fallback. Coordinates are paired and bounded; zero is valid, no club coordinates are inferred or seeded. Only that club's staff can read weather and only managers can change location. Celsius, km/h, explicit provider forecast dates, observation time and read freshness are shown. Current and daily conditions carry an icon mapped from the provider condition text; unrecognised conditions fall back to a neutral icon rather than an invented one. The club dashboard has a single club selector — the shared portal switcher — and never a second one. Missing location, missing forecast dates and provider failure are unavailable rather than fabricated zeros or another club's weather. Switching clubs resets scope. Authenticated requests are bounded and deduplicated with short-lived caching and no automatic polling. Forecasts are informational and never close courses, cancel events or change inventory. Live Google-dependent verification remains separate from offline and location-flow acceptance.

Period-dependent metrics use the selected period and declared timezone. Estimates are labelled and link to supporting records. Churn and active-customer definitions require approval before those metrics are published.

Club accounts retain contact, onboarding and domain history. Duplicate candidates are flagged before creating or converting accounts; launch readiness is explicit and lifecycle changes record actor and time.

Follow-up tasks have an owner, due date and completion state. Sales activities and assignment changes remain attached to the prospect without deleting stage history.

Authorised roadmap changes persist with actor and timestamp. Items retain links to requests, stories, rules and release evidence; a documented requirement is not proof of delivery.

All platform staff may publish a reviewed page revision. Drafts remain private; preview, translations (English, Dutch, French), SEO and rollback target a recorded revision. Rollback re-publishes an earlier recorded revision without editing or deleting history.

All platform staff edit validated platform branding defaults (logo, colours, typography, layout); only a club manager of that club, or a platform administrator, may override a club's branding. Overrides are validated, previewed, recorded with their author, affect only that club and never rewrite platform defaults. Branded email templates exist in English, Dutch and French; previews render supported variables and missing required variables block publication.

Platform role provisioning and module-level permissions require an approved action matrix; club staff tools cannot grant platform roles. Role changes and denied privileged actions are auditable.

Support access requires an explicit approved scope, reason and expiry, records the actor and customer context, and can be revoked. It does not imply unrestricted impersonation or billing access.

Payment notification, email delivery and domain check failures expose redacted status, last attempt and affected record, never secrets. All platform staff may view operations health; only administrators and support may retry. A retry replays the recorded event through the same idempotent handler, records the actor and time of every attempt, and can never duplicate a confirmed booking or captured payment.

A payment notification is claimed atomically in the database before its handler runs. Concurrent provider deliveries and staff retries of the same event yield exactly one processor; the rest are acknowledged as busy without dispatching or auditing again. An already processed event is never re-claimed, a failed event can be claimed again for retry, and an abandoned processing claim becomes reclaimable after a bounded staleness window. Concurrent registration of the same provider event resolves to the single recorded row instead of failing the webhook.

Dashboards use the selected club and local date, state freshness, and distinguish booked value, captured money, recorded refunds and outstanding amounts without mixing currencies.

Club managers of that club, or platform administrators, configure course identity, holes, slot intervals, capacity and booking windows. A change that would affect existing reservations is blocked, and the preview lists the affected starts so staff can resolve them first; changes never oversell inventory or silently delete reservations. Reception works from a searchable day and week tee sheet.

Authorised staff changes to participant details, attendance and booking notes record actor and time, remain club-local, and respect confirmed capacity and group ownership. Named attendance and no-show semantics require approval.

When several rates could apply, the lowest price the party is eligible for wins, and the quote explains the applied rate before acceptance. Member-rate eligibility comes from a linked active member account, or from a member number staff validate against the club register for phone and walk-in bookings. Future rate changes preserve recorded booking terms.

Active holds and bookings consume rental units across the configured use interval plus configurable prep and return buffers. Stock cannot be oversold; a round with rental add-ons confirms only when every requested item has enough stock — booking and rentals confirm together or roll back together.

Rental quotes snapshot quantities and prices. Club managers (or platform administrators) manage the catalog; managers and reception record issue and return. Issued and returned quantities cannot exceed the assigned quantity, and every handover records actor and time. Loss, damage and deposit charges stay out until a separate policy decision.

Contacts, notes, tags, tasks and imports remain in the owning club; club managers, reception and marketing staff work with them, with platform administrators in support. Suggested duplicates require authorised staff review; merging preserves both histories and never claims a guest booking by email alone. Imports show a validated preview with errors and duplicates and apply only after staff confirmation.

Membership types define validity and explicit benefits; in this slice the automatic benefit is member-rate eligibility (PRICE-004). Eligibility is evaluated for the booking club and date; expiry is hard, with no grace period, and expired or unverified membership grants no implicit benefit. Players see their own status, validity and benefits. Billing and renewal policies are set per membership type under MEM-006.

Each membership type defines its own renewal model (manual renewal or automatic renewal with member opt-out), dues collection (club ledger recording, online payment via the platform, or both) and lapse handling (immediate lapse or a grace period in days during which the membership stays visible but benefits stay stopped until payment). Joining mid-period is always prorated by remaining month against the type's period fee. Policy changes apply to future renewals only and never rewrite accepted prices or membership history (MEM-002). Membership dues billing stays distinct from platform SaaS subscriptions.

Club managers (or platform administrators) define membership types; managers and reception assign, renew and end memberships. Every assignment, renewal and ending retains effective dates and actor history; renewal extends the window without rewriting the past, and edits never rewrite previously accepted booking prices. Imports require validation and review.

Club managers and marketing staff of that club (or platform administrators) edit and publish their own club's website revisions. Club website pages, navigation, languages, branding and SEO publish only authorised revisions for that club. Draft previews remain private and public pages expose no member or booking personal data.

The editor offers a few base templates with previews and configurable options. Applying a template creates a club-scoped draft; replacing existing content requires confirmation and never changes shared templates or the live website implicitly.

Editors add, configure, reorder, duplicate, hide and remove typed content blocks with accessible controls and page previews. Block data is validated and published only as part of an authorised club revision.

Each page offers title, description, social preview, canonical URL and indexing controls; sitemap and robots output use published content and the verified club hostname. Draft previews are not indexed and never expose private content.

Club styling options and optional custom CSS remain scoped to the public club website. Head and body code injection requires the club manager role with an explicit warning on every save, revision history and rollback. Custom code never executes in the authenticated portal or its origin; sandboxed previews cannot read portal sessions, tokens or private data. Production isolation and consent policy must be validated before scripts are enabled on live domains.

Cloudflare access is server-only and club-scoped. Domain setup identifies the exact zone and proposed records before confirmation; destructive changes show the affected records and traffic impact. Existing email and unrelated records are preserved. DNS configuration alone never marks a domain live; verified ownership, supported hosting binding, HTTPS and correct club hostname routing must all succeed. Workspace Cloudflare credentials do not grant club staff unrestricted zone access.

A club domain link moves through recorded states only. Proposing a hostname identifies the matching Cloudflare zone, lists the existing records that could be affected and prepares an ownership verification record plus the connection records, without changing any DNS. Ownership is verified by a club-scoped token record before any connection record is offered. Creating connection records is a separate explicit confirmation that names every record being created; existing records are never modified or deleted. Status refreshes re-read the zone and records and report readiness honestly — a domain is at most "connected in DNS" until platform hosting binding and HTTPS are confirmed, which the app cannot assert by itself. Only club managers of that club (or platform administrators) propose, verify or confirm a link.

Club finance distinguishes provider-confirmed captures, recorded refunds, outstanding amounts and unresolved paid-without-booking cases per currency. A recorded refund is not proof of a provider refund or a club payout. Paid-without-booking cases land in a staff review queue; staff either complete the booking manually or record a refund, and nothing resolves automatically. Only club managers of that club (or platform administrators and platform finance in support) view the club finance screen.

Booking confirmations, changes and reminders are operational messages; marketing requires the recorded club-specific opt-in consent basis. Club managers and marketing staff send both operational and marketing messages; reception sends operational booking messages only. Delivery attempts use bounded automatic retries with traceable attempts that avoid duplicate messages; exhausted failures surface in operations health.

Only club managers of that club (or platform administrators in support) change club settings, and every change stays scoped to the active club. Supported currencies require an explicit approved scope. Imports preview validation failures and duplicate handling per row and apply only after staff confirmation. Exports cover the club's own data only and never include secrets.

Assigned coaches manage only their schedules and participants. Lesson and practice-resource holds respect availability and capacity; prices, cancellation terms and payment requirements need approval before launch.

Event registration and reserved tee blocks cannot oversell the underlying event or course inventory. Assigned organisers see only permitted participants; eligibility, waitlists and cancellation policy require approval.

External shop orders retain provider status and club context without claiming native POS or accounting. The first approved integration scope is pro shop orders. Restaurant reservations and restaurant vouchers are provided through the TBLS.app partnership: the platform does not manage them natively. Failures never claim successful fulfilment.

Each club sets its own voucher and loyalty policy: a default voucher validity in days that staff can overrule per voucher, stackable redemption (multiple vouchers may be combined on one booking or order), and a loyalty mode chosen from none, points per euro spent, or visit-based rewards. Voucher sale and redemption only launch for a club after its policy is recorded; financial liability stays with the club and no native POS or accounting is implied.

Restaurant reservations and restaurant vouchers are managed in TBLS.app, never natively in the platform. The platform integrates through the TBLS.app APIs to exchange customers with the CRM and to show restaurant reservations, ideally linked to a booked round. Displayed reservations are read-only and best-effort: an unavailable or failing connection is shown as such and never fabricates reservations. Customer exchange respects recorded marketing consent. Club staff see a dining forecast per service (golfers finishing from one hour before a service until its last seating, at 15 minutes per hole, compared with TBLS open covers), seatings 15–45 minutes after each round, and same-day TBLS reservations linked to a tee booking only by matching guest email or phone.

A club restaurant page with a configured TBLS widget shows the restaurant menu read live from the TBLS Partner API, grouped by category in TBLS display order, with categories without items omitted and items without a price shown without one. The menu is read-only and never edited in the platform; reads are server-side with a bounded cache, and an unavailable menu is simply not shown rather than replaced by invented dishes.

After confirming a tee booking at a club with a TBLS restaurant, the golfer may reserve one table for the whole group at a seating 15–45 minutes after the estimated round finish. Only confirmed, upcoming bookings qualify, access uses the booking's secure link, the chosen seating is re-checked against live TBLS availability, the TBLS reservation carries the tee booking ID for reconciliation, and at most one table is linked per booking. Cancelling the tee booking (guest, owner or staff) cancels the linked TBLS table; a staff change keeps a table that still fits (15–90 minutes after the new finish, same party), moves it to the first free post-round seating, or flags it for staff on the dining forecast. A failed cancellation or move is recorded for staff and never blocks the tee cancellation. TBLS remains the source of truth; a failure never claims a table was booked and never affects the tee booking.

Club managers enter their TBLS restaurant ID. It is saved only when the platform's TBLS connection lists that restaurant and no other club has linked it. Every TBLS read or write (menu, availability, reservation search, table bookings, cancellations) uses the requesting club's own linked restaurant; without a link the restaurant features stay off. Caches are kept per club.

A signed-in player's dashboard lists their own confirmed rounds for today and the next seven days, club-local, each with its estimated finish time. A round with a linked TBLS table shows the table time, party size and confirmation code; a round without one offers the same token-scoped post-round table booking as the guest flow; a table flagged for staff attention is shown as such. Only account-owned bookings appear, and a failed read is shown as unavailable rather than fabricated.

Authorised club CRM staff (managers, reception, marketing) see a dining section on a contact with an email address when the club linked its TBLS restaurant. The insight lists that contact's upcoming and past TBLS reservations at the club's own restaurant, matched by the contact's email address only, with date, time, party size and status. It is read-only, never creates or changes a TBLS reservation, and never claims the contact dined somewhere: an unavailable or failed TBLS read is shown as unavailable, not as "no visits". Contacts without an email, clubs without a linked restaurant and unauthorised roles see nothing. TBLS spend and dietary data are not shown unless the TBLS API supplies them for the contact's own reservations.

Each club runs its own pro shop. Club managers create and edit products from the club portal: name, description, price in the club currency, one image, optional variants such as sizes, an optional stock limit and an active flag. Only active products appear on the club website shop, where visitors fill a cart and order with name, email and phone. Prices, variants and stock are always taken from the database at order time, never from the visitor's cart, and stock can never go below zero. Every order snapshots product names, variants and unit prices, so later catalogue edits never rewrite order history. Online payment is offered only when the club has online payments enabled; otherwise the order is placed as pay-at-pickup. A signed provider notification alone marks an order paid. Club staff see their club's orders and can mark them collected or cancelled; a buyer reads back an order only with its reference and access token.

Personal dashboard bookings and amounts derive only from account-owned records, alongside the player's membership status and benefits. Guest access is token-scoped; repeat booking starts a new availability check and quote, never reuses old inventory.

Player self-service cancellation or modification requires ownership or a valid scoped guest token, checks the recorded deadline and availability atomically, and previews the outcome. Fees and automatic refunds require separately approved policy.

Calendar exports use recorded start instants, timezone and a stable booking identifier for all booked legs; they omit secret access tokens and reflect cancellation or changes without inventing unknown historical times.

Players edit only their own name, contact details and preferences. Email and phone changes apply only after a one-time code sent to the new contact is confirmed; the old contact keeps working until then. Editable profile fields can never assign roles, membership or booking ownership.

Players see only their own club memberships with effective dates, verification state and benefits. A membership display never grants unverified entitlement or changes accepted quotes.

A player links their own account to a club membership by member number; the link succeeds only when the email recorded on the club's membership record matches the account email, and a membership already linked to another account can never be taken over. Linking never changes validity, benefits or accepted quotes; club staff correct the record when emails differ.

Payment history, receipts and refund records require account ownership or a valid booking-scoped token. Pending, succeeded, failed and recorded versus provider-confirmed refunds are distinct. Player receipts are labelled payment receipts only, never legal invoices, until invoice issuance rules are approved.

Course discovery and directions use published club and course content. Media alt text is optional but its absence is surfaced as a warning to curators. Booking calls to action retain the selected club and course but always recheck live availability before showing times.

Players control their own language and club-specific marketing opt-in preferences without suppressing necessary operational messages. Consent changes record time and scope; no club receives another club's private notes or consent. Marketing is opt-in per club: no recorded opt-in means no marketing message.

Account export and deletion requests verify identity and cover only authorised data. Retention periods, legal record exceptions and request-handling deadlines require approval; requests do not silently delete immutable finance records.

A signed-in player can record a privacy request (access, correction or deletion) scoped to their own account. Recording a request never exports, corrects or deletes anything by itself; staff review and act on recorded requests manually. Requests are append-only, actor- and time-stamped by the database, and a player reads only their own requests.

Players see published lessons and events and book only eligible remaining places. Ownership protects registrations; rescheduling, refunds and waitlist treatment follow approved terms, not inferred golf-booking rules.

Discovery, selection, checkout and error recovery support keyboard operation, labelled fields, visible focus and announced validation. Hold expiry and payment uncertainty have recoverable states; text alternatives accompany course media.

Total price, required payment and cancellation terms are shown before a booking is confirmed.

A club sets a price per player for each round format (9 or 18 holes) on a course; the booking total is the per-player price times the party size.

Club managers and reception staff of that club, or platform administrators, may apply a price override. Every override records the reason, the actor and the previous amount; the customer sees the final price before acceptance.

A club decides per rate whether online checkout collects the full amount or a deposit with the balance paid at the club. The deposit is a percentage of the booking total or a fixed amount per player, never exceeds the total, and is snapshotted onto the checkout hold. A deposit is refunded in full when the booking is cancelled before the free-cancellation deadline; after the deadline the club keeps it.

Total refunds on a payment cannot exceed its captured amount. Refunds are recorded by club staff with an amount and a reason; the original payment record is never rewritten or deleted.

A club manager can require online payment for guest online checkout. When enabled, the reservation is created only after the payment provider confirms success; staff and phone bookings are unaffected and still pay at the club.

Online checkout charges exactly the held quote — per-player price times party size, both nines combined for a linked round — in the quoted currency. Later rate or price changes never alter a held or confirmed amount.

A paid reservation exists only after the payment provider's signed notification confirms success. A paid session that outlives its checkout hold is still honoured; if capacity was meanwhile taken, the payment is recorded without a reservation for staff to resolve. Payment records are immutable and never deleted.

A club's balance per currency is the sum of succeeded payment amounts minus recorded refunds. Balances are ledger records of money collected through the platform's payment account; per-club payout splitting is a separate later decision.

A club's access to the platform is active only while its subscription is active, trialing or past due with the current period not yet ended. Activation follows the payment provider's signed notification, never the checkout redirect alone.

When a club cancels its platform subscription, access continues until the end of the already-paid period; only then is access revoked. Cancellation is never immediate.

Upgrades and downgrades between platform plans take effect immediately; the payment provider charges or credits the pro-rated difference for the remainder of the current period.

A signed failure or expiry notification marks a pending payment failed. If the payment is already in a final state, the notification is a no-op. A notification naming an unknown session is logged for staff investigation and never silently accepted.

MRR sums active recurring subscriptions excluding tax and one-off charges; annual plans contribute one twelfth.

Occupancy = occupied player places / sellable player places, excluding closed slots.

Tee-time utilisation = slots with at least one booked place / sellable slots.

Platform dashboards never mix subscription revenue with clubs' booking revenue or payment volume.

For a chosen month, every active subscription is compared with the platform invoices due that month (monthly plans each month, yearly plans in their renewal month). Missing invoices and net amounts that differ from the subscription are flagged for staff; nothing is invoiced or changed automatically. Void invoices do not count.

Platform-scoped administrators, sales, finance, product and support may read, create and edit the live roadmap. Club staff, players and anonymous visitors cannot mutate it. Stable item IDs, validated story and dependency links, immutable actor/time history and version checks protect traceability and prevent silent overwrites. The database is the live roadmap portion of the Brain; checked-in YAML is a reviewed snapshot for deterministic code and coverage tests, not a second editable live authority.

Platform staff record customer requests once, with a summary, an optional club, source label and details. Requests can be corrected but never deleted. Roadmap items link to requests by stable CR-### identifiers; links are validated against recorded requests and every change flows through the existing immutable roadmap history. Recording a request never creates or moves a roadmap item by itself.

A roadmap item can only move to Released when at least one release-evidence note is recorded for it by platform staff, stating what was verified and where. Evidence notes are append-only and immutable, stamped with actor and time, and remain attached when an item later leaves Released. Both roadmap screens show the recorded author and time; an unavailable evidence read is not presented as an empty history. Recording evidence never moves the item by itself, and a documented requirement is not proof of delivery.

Club corporate identity determines website, widget and email-preview colours and fonts, inherited from platform defaults unless the club overrides them. Website presentation resolves that identity rather than a separate palette; font identities use the validated catalogue. Website editors choose button rounding independently of cards. Saved choices apply only to the relevant club and its private preview, never another club or the portal. Public club websites omit the global test-payment notice. The restaurant page shows only its configured restaurant widget and no floating tee-time widget; other club pages show only the tee-time widget. Leaving the restaurant page removes the provider controls.

Website membership forms require name, email, phone, date of birth and address; handicap, federation number and previous club are optional. Editors can add bounded required or optional questions. Submissions preserve the published question snapshot, remain private to club managers and reception, and never grant membership or marketing consent automatically.

Managers and reception of the club maintain dated playing status and notes. The floating website widget shows both courses, date and recorded status; a scheduled closure takes precedence and absent condition reports are labelled not updated rather than invented open conditions. Condition notices never bypass booking inventory or scheduled closures.

Club managers manage lesson slots and coach assignments; assigned coaches manage their own agenda and participants only. Dated published slots have explicit capacity, price and terms; a coach cannot overlap lesson slots. Clubs choose online payment or pay at club. Pay-at-club registrations in open slots confirm instantly; paid bookings confirm only after signed provider success. Full slots reject bookings without inventing a waitlist. Practice resources, player rescheduling and automated refunds remain separate backlog work.

Managers create dated events with explicit capacity, published entry terms, price and online or at-club payment. Registration checks capacity atomically and keeps contact details private. Public readback needs the scoped registration token; online confirmation requires verified provider success for the frozen amount and currency. A paid late checkout with lost capacity is recorded for staff resolution, never falsely confirmed. Tee blocks, eligibility automation, waitlists and refunds remain separately tracked and are not implied by event registration.