Platform overview
Sitora is a multi-restaurant, multi-branch platform for running food service end to end — from a guest scanning a code at a table to the owner reading the day’s numbers. One backend owns all workflow truth; every client renders what the backend publishes and never re-derives policy on its own.
Product surfaces
Section titled “Product surfaces”| Surface | Audience | What it does |
|---|---|---|
| Sitora | Guests | Ordering app: browse the menu, order at the table or for delivery/takeout, follow order progress. |
| Sitora Pro | Staff | Role workspaces — waiter, cashier, kitchen, service manager, storekeeper, supply manager, content manager, branch admin — each a focused operational control panel. |
| Sitora Biz | Owners | Business control: branches, staff and roles, menus, finances, subscriptions, and governed actions such as robotics activation and payment-device registration. |
| Sitora Courier | Couriers | The delivery app: shifts, offered jobs, and cash collected on delivery. |
| Sitora Console | Sitora staff | Internal administration surface. |
| Robotics API | Robot fleet vendors | A public, versioned HTTP surface certified fleets integrate against. |
| Payment Device API | Payment device vendors | A public, versioned HTTP surface smart POS companions and customer displays integrate against. |
How the pieces relate
Section titled “How the pieces relate”A restaurant is the business; a filial is one physical branch and the operational boundary for almost everything — staff act inside a filial, orders belong to a filial, stock is counted per filial. Guests interact with a filial through dining sessions and orders; staff act through role-scoped memberships; owners govern across their filials; Sitora staff govern the platform.
The robotics surface follows the same shape: a robot credential is scoped to exactly one filial’s activation, and every serving task a robot sees belongs to that filial.
Design stance
Section titled “Design stance”Sitora ships production software, not prototypes. Concretely, for every surface:
- Permissions, state transitions, and eligibility are computed in the backend
and published to clients as explicit
allowed_actions— an affordance you do not see is an action you cannot take. - Records that matter — audit events, stock transactions, submitted orders — are immutable. Corrections are compensating records, never edits.
- Failure states (offline, stale, conflict, access loss) are designed explicitly rather than discovered in production.