The outcome you are walking toward
A hardware specification for one Ember dining room you can hand to a site surveyor and an installer: which edge, commerce, vision, and back-of-house components the location needs, which kit tier they roll up into, what the stack is designed to keep doing when the uplink drops, and where agent activation sits in the deployment sequence.
One honesty note up front. Everything below is a reference configuration, finalized per site survey — power, network, mounting, kitchen flow, and guest flow on your actual floor decide the final bill of materials. Where a capability is in staged rollout rather than generally shipped, the wording says "designed for" or "designed to". And nothing on this page is a price list: kit contents are scoped through MCV.STORE against the survey, not quoted from a guide.
The design principles the spec follows
Five principles shape every Ember location stack. Read them before the component lists — they explain why the lists look the way they do:
- Service tempo is a first-class signal — every ticket, every station, every guest interaction must be visible in real time.
- Kitchen and front-of-house are one nervous system — not separate systems that occasionally talk.
- Offline resilience is non-negotiable — a network outage cannot stop order taking, payment, or ticket flow.
- Agents must be able to see and influence the physical world — the agents running your floor need high-fidelity, low-latency data.
- Standardized kits over custom snowflakes — every location should feel like a variation of the same organism.
Layer 1: the core edge (mandatory)
Every Ember location, whatever the tier, starts with the same foundation:
- Primary Edge node — industrial, fanless, with a hardware trust anchor and dual connectivity.
- Optional hot-standby edge for locations where an edge failure would stop service.
- Managed PoE switch feeding cameras, access points, and terminals.
- UPS sized for at least 45–60 minutes of critical load — long enough to ride out a utility blink without dropping a ticket.
- The local software tier — local Mesh, local Synapse, local policy, and the critical agent runtime.
The L0–L4 layer model owns what each platform layer is; this guide is about the physical spec that carries it.
Layer 2: the commerce and service surface
This is the kit class a dining room lives on:
- Counter POS terminal(s) for the fixed point of sale.
- Mobile / handheld POS for floor and patio service.
- EMV + NFC payment terminals with offline store-and-forward — card-present acceptance that keeps working when the uplink does not.
- Kitchen Display System (KDS) at expo and prep stations — the ticket surface the kitchen actually works from.
- Ticket / receipt printers.
- Optional self-order kiosks or QR ordering hardware where the format calls for it.
- Customer-facing display for order status.
On the KDS, one staged capability to plan around honestly: the units are designed for hands-free operation — voice, gesture, and plate-ready computer vision — with that hands-free flow in staged rollout on the line. The baseline you can schedule today is the KDS at expo and prep; the hands-free bump flow arrives through the staged program, not the initial install.
Layers 3–5: vision, inventory, and access
- Vision and sensing — cameras covering the entrance / host stand, dining room zones, the pass / expo window, key kitchen stations, and the bar where applicable; occupancy / people-counting sensors; optional heat and motion sensing for back-of-house flow. Vision zones are defined at install and privacy policy is applied before any agent consumes a feed.
- Inventory and back-of-house — smart scales or weight sensors on high-value or high-waste prep items, barcode / RFID for dry goods and alcohol where valuable, and label printers for prep and allergen control.
- Access and staff — staff access control on the kitchen door, office, and alcohol storage; time-clock integration where your operation requires it; manager override hardware.
The offline contract the kit is designed to keep
The full offline behavior contract — the MUST / MAY / FORBIDDEN lists, the buffering rules, and the reconciliation protocol — is owned by the offline resilience guide. Its Ember note is the sentence this hardware spec is built around: Ticket flow, KDS, and payment capture are sacred offline (EDGE §12).
Concretely, when connectivity is lost the stack is designed to hold this behavior:
- POS continues to take orders and payments (store-and-forward)
- KDS continues to display and advance tickets
- Local Edge maintains ticket state and station timers
- Payments are queued with cryptographic integrity
- On reconnect: ordered replay, deduplication, reconciliation with Ledger
- No ticket is ever lost
- No payment is ever double-charged
This is why the UPS sizing and the store-and-forward payment terminals above are mandatory line items rather than options: the hardware is what makes the contract physical. Every event captured while disconnected lands in the local durable log with the evidence shape described in the audit trail & evidence model.
The four kit tiers
Kits roll the layers up into standard packages — the same organism at different scales. All kits are Mesh-native and arrive pre-configured for Ember Service agent activation.
- Ember Core Kit — Edge + basic POS + 1–2 KDS + essential cameras + UPS. For small format / fast casual.
- Ember Full Service Kit — Core + full floor POS + multi-station KDS + rich vision + inventory sensing. For full-service restaurants.
- Ember High-Volume Kit — Full Service + additional Edge capacity + kiosks + advanced inventory. For high-throughput or multi-brand locations.
- Ember Cloud Kitchen Kit — Edge + KDS-heavy + packaging stations + minimal FOH vision. For delivery-only / virtual brands.
Treat these lists as the reference configuration, not a quote — per-site contents and options are scoped through MCV.STORE once the site survey is on file.
Deployment sequence and Ember Service activation
Hardware arrives in a fixed sequence, and agent activation is a step inside it — not an afterthought:
- Site survey (power, network, mounting, kitchen flow, guest flow)
- Kit selection and any vertical options
- Physical installation and calibration
- Mesh join + policy download
- Commerce and KDS configuration
- Vision zone definition and privacy policy application
- Agent activation (Ember Service + supporting general agents)
- Pilot mode with human oversight
- Full production cutover
- Continuous forging of service playbooks
Note where activation sits: after the Mesh join, the policy download, and the privacy policy application — and before production cutover, with a pilot mode under human oversight in between. The governed agent boundaries doc covers the authority envelope Ember Service runs inside, and the agent authority model guide walks that envelope end to end.
What the stack feeds back
Once live, the hardware's job is to make service tempo a live, controllable variable instead of a post-mortem metric: ticket time by station and daypart, order accuracy and recovery speed, guest wait signals, labor versus cover count, food cost and waste signals, and offline resilience events all stream to the agents that act on them. That loop is the product described on the Ember vertical page, and the conformance levels guide covers the evidence gate every device class passes before it joins the production Mesh.