Smart Table Service Intelligence

Hospitality · 2024-2025

PublicRepresentative · synthetic data
samplecamera tickchange-gatemotion diffperceivedetect + statetrackitem IDsaggregatetable stateconfirmN=3 framesdeciderulesgoverncooldowndispatchstaff alertmetered · LLMdeterministic · $0
Live diagram - the 9-stage pipeline. Only perceive is a metered vision call; everything else is deterministic at $0.
sample$0change-gate$0$perceivemeteredtrack$0aggregate$0confirm$0decide$0govern$0dispatch$0COST LEVER · change gate
Live diagram - spend accrues only on perceive, and only on changed frames; the change-gate plus sampling keep that surface small.
ASPECTCLOUD · capable readOSS · recordedHalf vs empty glassreads half-fullcalls it emptyCleared vs empty plateclearedemptyItem confidencecalibratedlower on icon framesGlare-degraded framereads the tablenot captured - routed to a human
Live diagram - Cloud (claude-haiku-4-5 vision) vs recorded OSS vision; the deterministic confirmation window absorbs much of the OSS noise.

One pipeline, nine stages

A single pipeline runs end to end, each stage a pure typed function emitting the uniform trace row (stage, provenance, model, tokens, cost, confidence): sample → change-gate → perceive → track → aggregate → confirm → decide → govern → dispatch. Perception folds the real system's separate detect and state-assess steps into one structured-vision call; everything around it is deterministic and shaped to swap to the real engine.

Deterministic vs metered, and the cost lever

Exactly one stage is metered - perceive, the vision call. Every other stage is deterministic and costs nothing in either mode, so the cost meter only moves in Cloud mode, only on changed frames.

The cost lever is the change-gate together with the sampling interval. Because a frame that hasn't moved short-circuits before perception, and because the camera samples rather than streams, vision fires once per stable situation rather than per frame. This is the faithful downscale of "cost-efficient by design - sample every ten seconds, not constant video."

Dual approach - Cloud vs on-prem OSS

The perception stage runs one of two ways. Cloud uses a hosted multimodal model (claude-haiku-4-5 vision), cost-capped and fail-closed - at the budget cap it falls back to the $0 OSS path. OSS uses a self-hosted vision model on local M4 hardware, recorded for the GPU-less host and replayed at $0.

The honest finding, shown as recorded divergences in the inspector: a small open vision model reads the iconographic synthetic frames imperfectly - it is more likely to call a half-full glass empty, or a cleared plate empty, and reports lower confidence - while the cloud model is the more capable read. Because perception is the only model-dependent stage, the deterministic tracking, confirmation and rules are identical in both modes, and the confirmation window absorbs a lot of the OSS noise. One divergence pair is shown as "not captured" - a glare-degraded frame the OSS run couldn't read - rather than inventing an output; that frame simply stays unconfirmed and routes to a manual check.

Out of scope (the real system)

Several production capabilities are deliberately excluded and represented honestly. Real overhead cameras and live video are stood in for by a simulated feed of synthetic top-down frames. A YOLO-style object detector, a multi-object tracker and a dedicated state classifier are downscaled to one vision-LLM call plus deterministic position-tracking. Constant-video processing is represented by sampling plus the change-gate. Real staff push notifications and POS/reorder integration are simulated and labelled - "suggest reorder" raises a prompt, not an order. Multi-tier model routing is downscaled to one cloud model plus the recorded OSS model, many-venue concurrency to twelve synthetic tables, and model retraining to wrong-alert feedback, the owner overlay and the audit log.