The restaurant already knows.
Nobody has asked it yet.

The product

Five layers, in order

Each layer earns the next. Data that flows becomes a score; a score becomes understanding; understanding becomes a plan; the plan walks onto the floor at 5:55pm.

The noticing engine

Computers do the counting. Humans do the noticing.

Deterministic rules watch the guest graph and the week's bookings. The model writes the story and the questions. Rules find; the model narrates — and every answer a waiter records becomes a dot note that sharpens the next story.

The system

Built like a platform, sized like a pilot

A multi-tenant SaaS from day one — shared-schema Postgres with forced row-level security and four separated database roles, one ingestion contract for CSV and API alike, and an AI that is structurally incapable of arithmetic.

org · restaurant(tenant, timezone, country_code, currency,
                 business_day_cutoff, week_start_dow, region_key)  — a 00:30 seating belongs to which day?
app_user · membership(user_id, scope_type, scope_id, role)     — an accountant can serve five venues

guest(display_name, visit_count, avg_gap_days, segment, computed_at)
guest_identifier(kind, normalised_value, verified_at, status)  — unique per tenant, not an array
guest_consent(channel, state, evidence, effective_at)          — exports are consent-filtered
guest_link(match_method, match_score, status)                  — a number, not high|low
guest_identity_event(op: merge|split|unmerge, inputs[], outputs[])
guest_alias(alias → canonical, scope_kind: all|record)        — per-record scope makes a split possible
guest_segment_history(segment, valid_from, valid_to)          — as-of segments, for backfill

booking(business_date, status, party_size, source_record_id)
visit(guest_id NULL,                                          — anonymous walk-ins are first-class
      covers, covers_source,                                 — THE SPH DENOMINATOR
      net_total_cents, tax_total_cents, food_net, bev_alc_net,
      discount_cents, comp_cents, tips_cents, is_voided,
      menu_type, bev_match_covers, server_id,
      source_system, source_record_id, ingest_run_id)         — unique natural key ⇒ replay is a no-op
dot_note · team_member · shift(kind: rostered|actual) · huddle_entry

supplier · purchase_invoice · purchase_line · gl_account_map       — Phase 3; declared now so the
                                                               model is designed for it

metric_value(metric_key, definition_version, period_type, period_start,
             dimension_key, dimensions, numerator, denominator, value,
             unit, status: draft|published|superseded)              — nothing reads a draft
goal(metric_key, period, target_value, set_by)                 — joins to the metric store
opportunity(template_key, slot, evidence, est_impact_cents,
            impact_basis, ease_score, status, outcome_metric_key,
            baseline_value, measurement_window_days)              — "did it move?" is now a query
story(rule_key, booking_id, suggested_questions, status)      — unique ⇒ idempotent nightly re-run

feedback_item(text, trust: untrusted, sender_verified, source_record_id)
theme(key, label, status: approved|proposed)                  — closed taxonomy
feedback_theme(feedback_item, theme, sentiment, span)        — sentiment belongs here, per mention
feedback_mention(feedback_item, team_member_id FK, sentiment)  — roster-validated, or discarded

ai_output(model_id, prompt_version, facts, metric_value_ids)   — full provenance
source_connection · mapping_version · dataset_version · ingest_run
ingest_dead_letter · resolution_run · erasure_request · source_incident
context_event(region_key, date, kind, label, payload)          — joinable, and numeric
audit_log(actor_kind, before, after, request_id)             — INSERT-only grant

AUTH & TENANT CONTEXT (normative — this is what v1.0 omitted entirely)
  Authorization: Bearer <JWT>         — carries `sub` only, NO tenant claim
  X-AMR-Tenant: <restaurant_id>       — resolved against `membership`, 403 if absent
  tenant_id is NEVER read from a path, query string, or request body.
  Every handler runs in one transaction:
      BEGIN; SET LOCAL app.current_tenant_id = $tenant; SET LOCAL app.current_role = $role;
  Plain SET of an app.* variable fails a CI lint rule.

CONVENTIONS
  Errors       RFC 9457 problem+json, stable `type` URI
  Periods      tenant-local; weeks start on restaurant.week_start_dow; `ending` inclusive
  Idempotency  Idempotency-Key on /imports and /cashup · If-Match on opportunity status

GET  /v1/scoreboard?period=week&ending=2026-01-18
GET  /v1/huddle/{date}                      POST /v1/huddle/{date}/cashup
GET  /v1/opportunities?status=suggested     POST /v1/opportunities/{id}/status
POST /v1/ask                                GET/POST /v1/goals
GET  /v1/segments/{at_risk_first_timer | lapsed_regular | upcoming_celebration}/export
GET  /v1/guests/{id}                        POST /v1/guests/{id}/erasure
GET  /v1/dot-notes                          POST /v1/dot-notes
GET  /v1/review-queue                       POST /v1/review-queue/{id}/decision
GET  /v1/sources/health                     POST /v1/imports
GET  /v1/me

POST /v1/ask — the response the whole guardrail stack depends on
  200  { answer, facts[{metric_value_id, definition_version, period, value, unit}],
         recommendation | no_action_needed(rationale), tool_calls[], cost_cents }
  200  { kind: cannot_answer, missing_data[] }        — refusal is a success, not an error
  422  { type: .../unslotted_numerals, unsupported_tokens[] }

Load-bearing decisions

Three bets the whole design rests on

All three survived review. Two had their justifications rewritten — because the numbers v1.0 leaned on came from vendors of the options being compared, and a design about numeric rigour cannot rest on a statistic it hasn't checked.

New in v1.1

The two things a guest-data product has to get right

v1.0 had no attacker model for the text it ingests, and a deletion mechanism that covered one of the five places personal data actually lives. Both reviews landed on these independently. They are now sections, not assumptions.

Retention replaces "forever"

v1.0 described the raw zone as replayable forever while tokenising PII, and proposed per-guest cryptographic keys so a deletion could shred one guest out of an immutable store. But crypto-shredding only earns its keep against a store you cannot delete from — so the cheaper move is to not have one. Bounding retention removes the un-deletable store, and with it the need for per-guest key lifecycle, rotation and restore behaviour. Less crypto in Phase 1, not more.

Erasing the person is separated from retaining the money. Australian tax retention runs seven years and collides head-on with erasure rights; v1.0 had no policy for the collision. An erasure nulls visit.guest_id and keeps every financial column — which works precisely because anonymous visits already count in revenue, covers and SPH. Re-running the affected periods after an erasure must produce identical published values. Deletion must not restate history.

Every table declares an erasure policy — retain, null_fk, redact_column, delete_row — with no default. A table without one fails CI. That is what makes the cascade machine-checkable rather than tribal knowledge.

Acceptance criteria

Eleven claims, eleven CI gates

v1.0 stated these as guarantees and verified exactly one of them. A guarantee with no test is a preference. These block the build.

• AC-RLSEvery table has RLS forced and a tenant policy; two sessions see zero of each other's rows on every table. Adding a table without a policy fails CI.
• AC-ONE-NUMBERTile, Monday report and Ask AMR return an identical value and cite the same metric_value.id. The test for the product's central claim.
• AC-PUBLISHNo consumer reads a draft row. A failed assertion leaves the period unpublished and the scoreboard shows the last good week, labelled.
• AC-FRESH≥99% of tenant-weeks publish before Monday 06:00 local. A stale source is a breach unless surfaced in-product first.
• AC-GROUND100% of numerals originate from a slot; zero derivations permitted; ≥99% label/period/dimension pairing on the golden set.
• AC-INJECT30 adversarial cases: zero may alter a theme, a staff ID, a metric, a recommendation, or trigger a tool call.
• AC-IDENTITYIdempotent, order-independent across ten shuffled seeds, monotonic, auto-link precision ≥0.995, and merge→unmerge→merge resolves identically.
• AC-NOTICEPer-rule precision and recall against labelled fixtures. Below the floor, a rule is suppressed rather than shipped.
• AC-DELETENo cleartext survives in any table, object, backup restore or index — and re-running the periods yields identical published financials.
• AC-RESIDENCYStores in permitted regions; model provider under zero-retention, no-training terms; no prompt payload leaves the region.
• AC-REGISTRYEvery metric declares a sensitivity class, no default. A staff session asking twenty financial questions gets twenty refusals and zero financial numerals.
• AC-COGSPer-tenant COGS reported monthly against the component budget; break-even tenant count recomputed; circuit breaker exercised.

Roadmap

Thin vertical slices, with gates you can fail

v1.0 had one falsifiable gate across five phases — and used none of the three measurable targets it had already defined. Every phase now exits on evidence, not on a deliverable list.

And the real ceiling isn't Postgres. A thousand venues over ten years is well inside one managed instance. The binding constraint is concierge onboarding, which is human-time-linear — roughly fifty hand-run onboardings before self-serve arrives, each with thousands of match decisions to triage. That, not infrastructure, is what caps growth through Phase 3.

v1.0 → v1.1

The design was attacked twice more before it was built

A three-judge specification critique read the schema field by field. An independent investment and technical due diligence review read the market and the money. Thirty changes were folded in. These are the eight that mattered most.