#CANON — binding decisions for the RestaurantBrain deliverable

Status: authoritative. Every other document in this deliverable MUST use these phase names, stack choices, scope tiers, numbers and terminology verbatim. Where an appendix (r01–r09) or a critique (c01–c03) disagrees with this file, this file wins and the appendix is treated as superseded input.

Date: 2026-08-18. Label key: [verified] = checked with a source in the research session · [known] = training data ≤ May 2026 · [estimate] = reasoned guess.

#1. Recommended shape

Decision: build the full POS, sell it CRM-first, in Czechia only, to counter-service chains of 2–8 sites in Prague and Brno. Ukraine is the engineering and support base and customers #2–10, not the revenue thesis. Do not enter a second paid market before the first is at 50 paying sites.

• Own the POS, or do not do this. A CRM on someone else's POS caps identity coverage at ~24% of checks against 30–38% at v1 (A4 true) / 22–28% (A4 false), rising to ~52% at v2 core when we own the order flow, and ~20 points of that gap is high-quality; more decisively, a CRM overlay has no switching cost, churns at 40–60%/yr, and clears only 3–37% gross margin through middleware. Defensibility here is installed base × switching cost × payment contract. The CRM is why the first 100 customers buy; the POS and the payment rail are why the next 700 stay.
• Czechia is the only correct first market. Zero fiscalization since 1 Jan 2023 [known], no producer liability, no local entity required, the widest Stripe Terminal reader roster in CEE (WisePOS E + S710 + S700 + Verifone) [verified], one language, one wage level, one installer pool, everything drivable in three hours. The hard rule that generates this: enter only markets whose time-to-first-legal-invoice is under 60 days. That admits CZ, UA, NL, UK, DE, AT and FR (self-attest); it excludes PL-via-GUM, BE, PT, SK, HU, GR, and it permanently excludes Spain, where LGT art. 201 bis fines the software producer and the 29 Jul 2025 producer deadline was not postponed by RD-ley 15/2025 [verified].
• CZ + NL is rejected. A Dutch-speaking support FTE is EUR 4,200–5,200/mo loaded against EUR 2,500 in CZ, cannot be served from Kyiv, and drags a second entity, a second accounting-export format, a second acquirer and a second installer network. CZ + NL is two companies sharing a repository.
• Counter-service only, single-station first. This removes table plans, coursing, seat-level splits, transfers and waiter handhelds, and it takes the offline core from full multi-station (48–58 eng-months) to single-station (17–20). It also matches the ICP: 2–8 site chains, not single sites, because the holdout-attribution feature — the demo that closes deals — is statistically undetectable below ~1,500 treated guests and therefore tells a single-site café to cancel.
• The brief's S1 (founder + 2–4 engineers, 24 months) cannot produce a sellable POS+CRM and must be re-framed. The reconciled scope is 125 eng-months for an S1-cut v1; S1 delivers ~126 eng-months only over 36 months at 3.5 average effective engineering FTE. The canonical bootstrapped plan is therefore 5 engineers over 36 months on EUR 1.8–2.4M, not 3 engineers over 24 on EUR 900k. If that capital is not available, the only honest alternatives are (a) POS-only with no CRM beyond a loyalty ledger, or (b) first-party ordering + loyalty for delivery-heavy concepts as a wedge, and neither is the product in this brief.

#2. Canonical phases

These names are fixed. No document may invent, rename, merge or renumber a phase. Durations are stated for S1 with the S2 equivalent in brackets.

P3 scope, S1 vs S2. P3 is the only phase whose scope differs by scenario. S1's 65 eng-months in M32–M46 buy v2 core (§4): T2 LAN multi-station, the two second markets, guest ordering + QR PWA + Wallet passes, card-linked identity, Brand Vouchers, WhatsApp/Viber, segmentation and the payments-attach machinery. Everything else that used to sit in v2 — table service, the handheld waiter app, the customer-facing display, Apps-on-Devices, the HubRise delivery module, cashback and subscriptions, DE+AT, the second cell — is v3 and is P4-and-later for S1. Table service and the handheld serve a different ICP than §1's counter-service, single-station beachhead and cannot be funded before the counter-service base is at ~150 Sites. S2, on ~132 eng-months/year, ships full v2 (+86.5 → +96.5, §5.1) inside the same phase. Cumulative eng-months at P3 exit stays 190 for S1.

Hard stops, at any time, in any phase: a fiscal or tax defect that causes a customer to be fined; a breach of guest PII; two consecutive quarters in which support headcount grows faster than site count.

Financing gates. S1: pre-seed of EUR 900k–1.1M before P0; extension of EUR 900k–1.3M at the P2 entry gate; and — stated here because the plan does not end at profitability — a third financing event at M47, because peak capital through M47 (EUR 1.8–2.4M) is not capital to breakeven (EUR 3.0–3.5M, §5.2). S2: EUR 7M before P0; EUR 15–25M Series A term sheet at M20 on EUR 1.2–1.6M ARR — if that term sheet does not exist, S2 switches immediately to a profitability plan (freeze hiring, one country, EUR 3M ARR at breakeven by M40).

#3. Canonical stack

One row per layer. Chosen is chosen; the runner-up exists only to name the reversal path and its trigger.

#3.1 Non-negotiable architecture invariants

These are decisions, not guidance. Any document that contradicts them is wrong.

1. All money is integer minor units. Never a float, anywhere, in any language.
2. unit_price_minor, tax_rate_bp and menu_snapshot_id are snapshotted onto the Line at order time and never recomputed.
3. Fiscal Document numbers are allocated only by the certified fiscal component, never by application code. Check numbers come from coordinator-leased blocks; kitchen Ticket numbers are cosmetic.
4. Business Day is leased from the coordinator, never stamped from a device wall clock. A device more than 5 minutes from coordinator HLC-physical time may take orders but may not close or tender. The fiscal adapter refuses to sign outside a trusted-time threshold.
5. Every coordinator-issued lease and every print job carries a durable monotonic epoch. Coordinator identity derives from (persisted_epoch, boot_id, monotonic_start); a claim needs majority ack from reachable peers or cloud confirmation; in a two-device venue with no WAN the election loser freezes print dispatch for 60 s.
6. Terminal ownership is a lease with the same fencing epoch as print dispatch, plus nightly PSP reconciliation by idempotency key. This is base scope, not optional.
7. payment_attempt has an explicit unknown state and an idempotency key keyed to {check_id, attempt_seq}. unknown is never rendered as "failed". SCA soft-declines (online_or_offline_pin_required) are classified as in-flight, never terminal, and are filtered before reconciliation matching [verified].
8. The acquirer transaction reference is persisted forever on every Payment. Referenced refunds are mandatory.
9. Guest PII lives in a separate crypto-shreddable store keyed by guest_id; the financial event log holds only guest_id. Erasure tombstones replicate over the same sync channel with per-device ack tracking and per-device revocable data keys. Rendered ticket bitmaps are never persisted beyond a 24h retry window.
10. consent_record.ui_surface is an enum with no pos_staff value and the API rejects it. The cashier-consent button does not exist and cannot be added as a custom field.
11. The migration importer sets marketing suppression by provenance, and the segment builder cannot clear it. Aggregator-sourced guests are never marketing targets.
12. Fiscal logic lives in a slow-release, separately-versioned module, architecturally isolated from the fast app, because certificates bind a named software version.
13. The property suite is written by a human before the fold exists, and the fold is accepted only by the property suite, never by review. Anything touching money is implemented with AI assistance and property-tested by a human who did not write the implementation.
14. Release freeze Thursday 12:00 → Monday 10:00. Rollout cohorts: lab → 3 friendly sites → 10% → 40% → 100%, minimum 24h soak spanning a dinner service at each step. Android rollback does not exist; kill switches are the only mitigation path.
15. On-device retention is 7 days of closed Checks plus all open Checks, hard alarm at 500 MB. Cloud is the archive.
16. No query outside an explicit transaction (lint-enforced), or Postgres RLS is not a backstop.
17. Offline manager PINs are Argon2id-derived, tuned to ~250 ms on the slowest certified SKU, salted per (org, employee), wrapped with the device-bound Keystore key, and scoped to managers at that Site.

#4. Canonical scope tiers

Anything not listed in a tier is out of scope for that tier. There is no implicit inclusion.

#MVP — the P1 pilot build (56 eng-months)

Order domain: counter-service Check aggregate (open, add/void/comp Line, Option selection, quantity deltas, discount, additive payments, over-tender, close), deterministic fold, conflict table, invariants P1/P3/P4/P7/P8 as plain property tests, single-station T0 only · local SQLite + SQLCipher + forward-only migrations · outbox + device↔cloud sync · Business-Day lease, clock-skew guard, check-number leasing. POS Android app: shell, PIN auth, roles, menu grid, Option/Option-Group UI, search, ticket, payment UI, cash management, X/Z, drawer, offline-degradation UX. Printing: raster core, raw TCP 9100, discovery + static-IP wizard + MAC-keyed rebinding, one printer SKU (Epson TM-m30III all-interface, C31CK50152), basic health/failover/dedupe with a verify queue. Payments: PaymentTerminal port, Stripe Terminal adapter, unknown state, idempotency, error taxonomy including SCA soft-decline. Fiscal/tax: FiscalProvider interface, CZ VAT (12% reduced / 21% standard), CZ receipt renderer with golden files, CZK 1 cash rounding on the cash tender only. Back office: menu management core, staff/PINs/roles, device + printer settings, X/Z view. Platform: multi-tenancy, auth, RBAC, config resolution, entitlements + release flags, signed monotonic config bundle, kill switches, staged rollout, CI/CD, IaC, observability, backups. AI: menu ingestion from PDF/photo with citations, confidence scoring and a human review UI that never auto-publishes. CRM: deterministic identity (phone E.164 / email / loyalty ID), POS phone capture, points + stamps ledger, append-only consent record schema with versioned policy text. Fleet: in-app agent (remote config with LKG cache, log ring-buffer upload, Device Health screen), QR provisioning wizard, installer runbook. Design system: one token set, Compose + React component libraries. Device lab + CI on real hardware; fsync power-cut test.

#v1 sellable — the P2 exit build

Two scopes are canonical. S1 cut = 125 eng-months is what the bootstrapped plan actually ships. Full = 168.5 eng-months is what S2 ships — 167 plus the 1.5 eng-months for in-app staff self-onboarding, funded into Full on 2026-08-18 (see the Full-only list below). The S1 cut is unchanged at 125 because that item is deferred there. Any document still quoting 167 predates this decision.

Included in both, on top of MVP:

• Offline core: injected-fault deterministic simulator, production divergence detector, venue replay + force-resync + audited surgical repair, snapshot/backfill/tombstones/purge, coordinator role for print dispatch.
• Menu engine: variant matrices, nested Option Groups (depth ≤3) with free-count policies, per-channel price lists with recurrence, 86 overrides, per-Station routing and language, image pipeline, publish/diff.
• Reporting: metric layer, Daily Close (immutable, hash-chained, per Site per Business Day), cash reconciliation, the 10 canonical reports.
• KDS + expo mode + bump bar, with an on-screen last-heartbeat age and a full-screen state change after 45 s without a coordinator heartbeat.
• Printing: Star CloudPRNT pull driver, routing engine (Station fan-out, per-Station language, void/modify slips, reprint job IDs), full health/failover/dedupe.
• Payments: reconciliation, referenced refunds and the batch-boundary UX, Tip capture and per-employee attribution, payment_method model with nullable par.
• Compliance: allergens (EU FIC 1169/2011), compliance test harness, consent-gated dual receipt renderer (fiscal-only vs promotional), DORA contract addendum, EU Data Act export/switching.
• CRM: capture surfaces (POS phone lookup, SMS e-receipt, QR join landing), loyalty ledger (append-only, hash-chained, points/stamps/tiers/expiry), signed offline-redeemable Vouchers (Ed25519/COSE, pinned key set, trusted clock, local spent-set), promo rules engine (config-schema, ~8 rule types, one shared JSON spec, 500-case golden corpus in CI), consent & preference centre with double opt-in, DSAR/erasure with offline tombstone propagation, six templated automation flows, holdout-based incrementality reporting.
• Commercial: Stripe Billing, payments-partner integration, onboarding workflow tool, AI tier-0 support agent with device telemetry, contracts (MSA/DPA/SLA) that expressly do not warrant third-party connector availability.
• Integrations: Google Business Profile (reviews, hours, order-link repoint), Dotypos migration importer, generic CSV/Excel menu importer.

Included in Full only (deferred in the S1 cut): full injected-fault simulator suite, publish/diff rollback UI, internal support console beyond a read-only impersonation view, KDS beyond a bump-capable ticket list, segmentation query builder UI, multi-channel adapters beyond one SMS aggregator + email, campaign power-analysis UI, residual/margin ledger, Storyous importer, accounting export beyond one CZ format, i18n beyond cs/uk/en, in-app staff self-onboarding (1.5 eng-months, Domain C).

In-app staff self-onboarding is a decided item, not a floating one. It is the named mitigation for 60–100%/yr front-of-house churn and for A20's ≤1.4 tickets/Site/month ceiling. It is in v1 Full at 1.5 eng-months and deferred in the S1 cut, and it is the first Full item the S1 cut repays if A20 trips at the P2 gate. The Storyous importer sits in the same list with its own documented swap trigger: ≥25% of the 40 P0 discovery Sites on Storyous swaps it into the S1 cut against a named 1.0-eng-month Full item.

#v2 core — the P3 build

S1 ships v2 core and nothing beyond it in P3: 58–65 eng-months against P3's 65 eng-months of capacity (§2, §5.1). S2 ships full v2 — v2 core plus every v3 item below — inside the same phase, because S2 carries ~132 eng-months/year. The names v2 core and v3 are canonical; no document may write bare "v2" for the S1 P3 build.

T2 LAN multi-station (elected Coordinator, epochs, fencing, peer rediscovery on subnet change) · Ukraine PRRO via Checkbox/Vchasno · Poland kasa-online printer partner + KSeF + JPK_V7M · guest web ordering + QR PWA + Wallet passes · card-linked identity (PAR, enrolment-only, gated on A6) · Brand Vouchers (single-brand, face value, no top-up, no cash-out) · WhatsApp and Viber channels (per-tenant senders) · segmentation, journeys, RFM/lapse modelling, CRM reporting · the payments-attach machinery including the residual/margin ledger.

Plus repayment of the "Full only" v1 deferrals the S1 cut skipped and v2 core depends on, named here so P3 does not rediscover them: the residual/margin ledger (payments attach cannot be invoiced or reconciled without it) · the segmentation query builder UI (segmentation, journeys and RFM have no operator surface without it) · multi-channel adapters beyond one SMS aggregator + email (WhatsApp and Viber ride on them) · accounting export beyond one CZ format (PL JPK_V7M and the UA export) · i18n beyond cs/uk/en (Polish UI and receipts). These are inside the 58–65, not additional to it.

What was cut out of v2, and why. Table service and the handheld waiter app serve a different ICP than §1's "counter-service only, single-station first" and cannot be funded before the counter-service base is at ~150 Sites. The two things that are load-bearing for P3's own exit gate are kept: Site count (T2 LAN plus the two second markets) and identity capture / CRM renewal (guest ordering + QR PWA + Wallet passes, which are what move blended capture from 30–38% at v1 to ~52% at v2 core). Cutting either of those would break a thesis this deliverable states as proven elsewhere; cutting full-service does not.

#v3 — P4 and later

Table service (courses, seats, splits by item/seat, merges, transfers, floor plan) · handheld waiter app · customer-facing display · Apps-on-Devices (our POS running on Stripe S700/S710) · HubRise-resold delivery module, then a native Glovo connector only when HubRise costs a named deal · cashback and subscriptions · DE+AT with fiskaly or Deutsche Fiskal in the chain · second cell / data residency.

No v1 tier contains any v3 item. In particular the HubRise-resold delivery module is v3, not v1 Full and not v2 core — that settles the three-way tier assignment it currently carries, and Domain I's v1 Full total must be reached without it.

#Out of scope — permanently, or until a named trigger fires

#5. Canonical numbers

These exact figures must appear in the roadmap and risk documents. Do not re-derive them.

#5.1 Reconciled engineering effort by domain

One roll-up, double-counting removed, critics' upward revisions applied. This total is materially higher than any single appendix headline — that is the point of reconciling.

How the v2 column splits by scenario. +86.5 → +96.5 is full v2, and it is the S2/Full figure — S2 absorbs it inside P3 on ~132 eng-months/year. S1 cannot: P3 (M32–M46) has 65 eng-months of capacity, so S1 builds v2 core only, 58–65 eng-months (§4), and every v3 item is P4-and-later. The +86.5 → +96.5 delta is not deleted and not re-derived per domain here; §4 defines v2 core and v3 by contents, and S1's P3 budget is the 65 eng-months in the §2 phase table. Cumulative S1 eng-months at P3 exit stays 190.

Domain C Full now carries in-app staff self-onboarding at 1.5 (v1 Full, deferred in the S1 cut), which is why the Full column is 168.5 and not the 167 quoted before 2026-08-18. The S1-cut column is unchanged.

Domain E includes the whole PCI programme, one-off and ongoing: SAQ D-Service Provider evidence collection, QSA scoping and the run cost of 0.3 eng-months per quarter (1.2/yr). That run cost sits inside the 11.0 S1-cut figure; it is not additive to it, and any document quoting ~0.3 eng-months per month is wrong by a factor of three.

Domain H sub-split (S1 cut, 8.0): billing 1.5 · payments-partner integration 1.5 · onboarding workflow tool 1.5 · AI tier-0 support agent 2.5–3.0 · contracts (MSA/DPA/SLA) 0.5 — 7.5–8.0 against the 8.0 line. Every document quotes the AI tier-0 agent at 2.5–3.0 eng-months, never as the whole of Domain H.

Domain I post-v1 restatement: the column reads +10.5, not the +9.0 originally reconciled. The HubRise-resold delivery module (1.50) moved from v1 Full to v3 under §4, while the three Ukrainian migration importers (Poster 1.25, r_keeper 1.5, iiko/Syrve 1.5) stayed in v2 core because Ukraine entry depends on them. Post-v1 splits v2 core 5.5 / v3 5.0; v1 Full stays at 8.50, reached without HubRise by re-costing the mapping-UI framework and the drift/contract harness to 1.75 each. The full-v2 TOTAL is therefore +86.5 → +96.5. See 06 — Integrations §2.2.

Domain I sub-split (S1 cut, 4.0): connector runtime 1.00 · Google Business Profile 1.25 · Dotypos migration importer 1.00 · generic CSV/Excel menu importer 0.75 = 4.00 exactly. The Dotypos importer is 1.00 eng-months everywhere; no document may price it at 1.5–2.5 without moving this total.

AI-assist multipliers, already baked in above, stated per domain so nobody re-applies them: D ≈ 1.25× · A ≈ 1.10× · B ≈ 1.50× · C ≈ 1.35× · E/F/G legal-and-correctness rows ≈ 1.0–1.10×. Certification queues, field sales, physical install, RMA logistics and trust compress by 0%.

#5.2 Scenario S1 — bootstrapped

#5.3 Scenario S2 — funded

#5.4 Unit economics — canonical inputs

#5.5 Canonical hardware BOM per site

Reseller model only: sell at cost + 15%, never subsidise. Hardware gross margin 10–13% after freight, spares and DOA — cost + 15% is 13.0% of revenue before freight, spares and DOA, so 13% is the arithmetic ceiling of the pricing rule and the previously stated 15–25% was not derivable from it. Model hardware COGS at a 12% gross margin. Sold as a branded bundle of OEM-branded devices — our box, quick-start card, pre-provisioned config, SIM, support number — because the device stays legally Sunmi's/Epson's and CE, GPSR, WEEE, EU Battery Regulation and the Cyber Resilience Act stay with them.

Tier A — counter-service café/bakery, 1 till (the canonical ICP site)

The EUR 465 anchor this table previously carried was the non-GMS SKU, which the GMS/EDLA rule below forbids; the compliant GMS SKU is EUR 579 [verified], and the Tier A total moves with it to EUR 1,374–1,764 (low = 579+230+85+155+125+200; high = 579+320+85+155+125+500). Both ends are pending distributor quotes at P0 exit. Budget Tier A at the top of the range.

Tier B — counter-service, 2 tills + kitchen

Rules that are part of the BOM, not commentary: buy GMS/EDLA SKUs for anything running our app (non-GMS costs an own MQTT push transport at 1.8–2.2 eng-months, an own OTA pipeline and a frozen WebView) · anything that prints gets a cable; Wi-Fi printers are "unsupported, best effort" · kitchen printers are impact, never thermal · the router and a validated AP are a hard requirement of the install, not a recommendation — without them peer sync cannot establish and we owe 1.5–2.0 eng-months of cloud-relayed peer path nobody costed · networking is 20–35% of the hardware bill and the customer never budgets it · spare pool 5–8% in-region, 1 spare terminal per 25 live units, 2–4% RMA/DOA reserve · device lab capex EUR 8–12k for rig 1, a second CI rig at EUR 8–10k by M12 · re-certify the hardware matrix every 18 months at 0.25 eng-months/quarter forever.

#6. Canonical terminology

Use the left column. The right column is banned in every document, schema, API and UI string.

#7. Standing assumptions and their owners

Every row is an assumption the plan rests on, an owner who must resolve it, a deadline, and what changes if it is false. Unowned assumptions do not appear here because they are not allowed to exist.

End of canon. Anything not decided here is not yet decided, and no writer may decide it.