CellPOS
A local restaurant point-of-sale system
CellPOS is a restaurant point-of-sale system designed for on-prem operation. It combines POS, kitchen display, customer ordering, and administrative control in one product and is built to run across a venue’s own network without a forced subscription for normal operation.
This page reflects the documented product scope, local verification, and productization work. It does not claim public rollout or customer deployment metrics.
Definition
CellPOS is a restaurant POS product, not a generic software platform. It is designed for restaurants and food-service operators that want front-of-house selling, kitchen workflow, customer ordering, and administration to operate within one local system.
The architecture is built for local LAN and Wi-Fi operation, with normal operation available without cloud dependency. The system is intended to remain usable as a local product even when remote services are absent or intentionally not used.
The documented operating model centers on local runtime control, explicit state, and site-level system ownership. Deployment, setup, backup, restore, and migration are all described within that local product frame.
Surfaces
The POS surface covers operator login, order building, payment handling, shift workflow, and degraded-state actions. It is the front-of-house operating surface and is designed to keep transactional state visible rather than hiding problems behind silent retries or ambiguous status.
The kitchen display surface covers station flow, expo flow, ticket actions, and queue or block rules during offline or degraded operation. It is designed to keep kitchen activity explicit and manageable under normal service conditions as well as partial failure states.
The ordering surface covers menu display, pickup-slot selection, cart quoting, checkout, and order-status visibility. It is intended for customer-facing ordering within the same local operating model as the rest of the system.
The admin surface covers setup, device pairing, licensing, diagnostics, printers, TSE state, help, and AGIF operations wiring. It is the control point for installation, operational checks, and bounded runtime visibility.
Operation
This model is intended for operators who want core restaurant operations to remain inside their own environment, with explicit control over installation, licensing, and system state.
Delivery
CellPOS is structured for three practical delivery forms.
A preconfigured appliance where the software and approved hardware are delivered together as one installable system. This is the simplest form for operators who want a ready-to-run local deployment.
A packaged appliance model where the system is delivered for approved hardware or peripheral bundles, while some surrounding equipment may be supplied separately. This keeps the product local and controlled without requiring a hosted service model.
A local installer for customer-provided or integrator-provided hardware. This form is intended for deployments where the operator or reseller wants to manage hardware choice while keeping the same local runtime, licensing, and operating model.
Controls
CellPOS includes Germany-focused operational controls as part of the documented product scope, including TSE-related state handling, diagnostics, and fail-closed behavior. These controls are treated as part of the product’s local operating model rather than as an external compliance service.
The purpose of this layer is practical: make state explicit, keep blocked conditions visible, and avoid silent bypass behavior in regulated workflows.
Architecture
CellPOS uses bounded Tasklet-style task and runtime boundaries to keep product actions supervised, explicit, and fail-closed.
In the current documented scope, the AGIF layer is exposed through a defined bridge and runtime handshake. It is used to support bounded product functions inside the local system, rather than as an open-ended assistant or remote intelligence service.
AGIF Fabric is the broader software-first coordination and runtime direction above that bounded layer. This page does not claim that a full public AGIF Fabric stack is already shipped inside CellPOS.
The broader AGIF Fabric direction is relevant because CellPOS already documents local runtime, memory, and supervision boundaries. Public copy here keeps that distinction explicit: bounded integration today, broader fabric direction in research.
Verification
These are documented product and verification artifacts. They are not the same as public customer deployment evidence.
Status
This page does not claim public deployment, customer counts, production-scale usage, or field performance metrics.
It does not claim market adoption results. It does not present AGIF as an open-ended or general-purpose intelligence layer.
The active sellable-product initiative in the CellPOS repository is tracked separately and is currently marked in progress, not complete. Public copy here stays inside the documented local product scope, bounded runtime behavior, and completed foundation work represented in internal product and verification materials.
Any future claims about public deployment, operator metrics, or commercial performance should be published separately with external release evidence.
Public records
CellPOS is positioned as a local restaurant point-of-sale product for operators who want POS, kitchen, ordering, and administration to remain under one bounded operating model.
The public repository is available for readers who want to inspect the software directly. The related Tasklet Cells and AGIF Fabric pages provide the surrounding research context for the bounded local runtime model.