Core concepts

Sitora uses one fixed vocabulary across every surface and API. These are the terms, and the rules that come with them.

Identity is global, access is contextual

A person has exactly one Sitora identity. What they can do depends entirely on context: the same identity can be a guest in one restaurant, a waiter in another, and an owner of a third. Nothing about access is stored on the identity itself — it all lives in memberships and roles.

The vocabulary

Term	Meaning
Restaurant	The business entity. Owns branding, menus, subscription, and its filials.
Filial	One physical branch. The operational boundary: staff, orders, stock, dining spots, and robotics activations are all filial-scoped.
Membership	The link between an identity and a restaurant or filial, carrying a role.
Role	A named permission set (waiter, cashier, kitchen, manager, inventory manager, admin). Roles gate which workflow actions the backend offers.
Dining session	A guest’s seated visit, anchored to a dining spot. Orders placed at the table belong to a session.
Order	The unit of guest demand. Moves through an explicit state machine (placed → paid → preparing → ready → served, with delivery and takeout variants). Transitions are backend-owned.
Transaction	A money movement. Immutable once recorded.
Stock transaction	An inventory movement. Immutable once recorded; corrections are compensating records.

Workflow truth lives in the backend

Clients never decide what is allowed. Every surface that can mutate state receives allowed_actions from the backend and renders exactly those affordances. This is why, for example, a robot can never advance an order: the order state machine only accepts transitions from principals the backend authorizes, and a robot is not one of them — its completions propose a transition that policy or staff then apply.

Immutability and audit

Actions that change money, access, stock, lifecycle, or governance state are recorded as append-only audit events with the acting principal attached. Owner actions produce business audit events; Sitora-staff actions produce console audit events; robot activity produces an immutable per-task event log. None of these can be edited after the fact.