AI belongs where it can help without stopping the business
A restaurant should be able to take its next order while a language-model provider is unavailable. In EasyKOT, I separate the selling path from AI-assisted setup and administration. The register reads and writes local data. Menu extraction and supplier-bill reading run as separate online workflows that produce suggestions. Each path has its own failure and recovery behavior.
The order exists locally first
The desktop register uses a Tauri Rust shell with a React and TypeScript interface. Mobile ordering uses React Native. SQLite holds the local data each client works with. PowerSync coordinates changes with the central system. Saving locally gives the order a durable home on the device before synchronization begins.
Two paths with different responsibilities
- Selling path: the client saves the order locally and the restaurant continues its local workflow. Native printing has its own queue, failure feedback and reprint path. Hardware connectivity still matters; an internet outage and a disconnected printer are different problems.
- Synchronization path: pending client changes upload through the Laravel API. The server validates them before applying them to PostgreSQL. PowerSync distributes the resulting data to the relevant clients.
- AI-assisted import path: a person submits a menu image/PDF or supplier-bill photo. The model returns structured suggestions. Application rules check the output, and the operator reviews the draft before committing the relevant change.
Retries are a business rule, not only a network setting
Connectivity can disappear after a request reaches the server but before the device receives its reply. Retrying that request must not create a second payment or a duplicate order. EasyKOT uses client-generated identities and idempotency safeguards for this reason. Its shared money logic uses integer minor units rather than floating-point amounts. Those decisions are separate from the model: a fluent response cannot replace transaction rules.
Structured output makes a boundary easier to check
For menu import, an extraction agent produces draft rows and a separate verification pass checks the proposed interpretation. Deterministic application checks and owner review sit outside those agents. The supplier-bill extractor similarly returns a bounded set of suggestions and marks uncertain fields rather than inventing a missing value. These extractors have no direct write access. A declared output schema helps the application inspect the shape of an answer; it does not establish that a dish, price or date is correct.
What you can inspect
The public browser demo uses sample restaurant data. It lets you inspect the selling interface on a supported desktop browser; the case study covers native printing, background synchronization and AI imports. Hardware behavior still depends on the device and printer. This implementation note includes no performance or accuracy measurements.
A practical checklist for your next AI feature
- Name the business action that must continue when the model or its provider is unavailable. Give that action a complete failure and recovery path.
- Make the model’s authority explicit: suggestion, draft, review decision or permitted automated action. Validate permissions and values outside the prompt.
- Test loss of connectivity and retry behavior independently from model-output tests. A successful model response does not prove data durability.
- Show uncertainty and let the person inspect the source. Measure actual task outcomes before claiming the feature saves time or improves accuracy.
Inspect the work and the underlying mechanisms
See the mechanism before trusting the label
The public EasyKOT demo lets you try sample restaurant orders on a supported desktop browser. My case study explains the broader engineering decisions. For a smaller introduction to model boundaries, the AI Mastery RAG course shows how an answer depends on the evidence supplied to it. Its examples are explicitly browser simulations, not live model evaluations.