Each part is deployed independently and none of them reads another’s database. They agree by publishing events, which is why a failure in one does not silently corrupt the figures in another.
01
Catalog and recipes
One concept for everything you buy, make, hold or sell — and the recipes that turn some of them into others.
One item type. No separate ingredient, base recipe and recipe to keep in step.
What an item is — bought in, intermediate, or finished — is derived from that outlet’s own recipe graph, never typed in by hand.
Company default recipes, per-outlet overrides, and explicit buy-ins, all costing correctly at once.
Yield is applied per recipe line, so trim and peel are recorded where they actually happen.
Takeaway packaging is tracked separately from the recipe, because a box is consumed by selling rather than by cooking.
02
Inventory and costing
An append-only ledger of every stock movement, and the cost model built on top of it.
One immutable row per movement: receipt, sale, production, wastage, transfer, count correction, opening balance.
Moving weighted average cost, with both the running average and the observed cost of each event retained.
Cost explosion rolls a produced item’s cost down its recipe tree to raw ingredients, and materialises the result.
Stock counts state what is there; the system derives the difference and posts it.
Wastage is an approvable document, not an adjustment someone types into a total.
Transfers hold stock on an in-transit ledger that must reconcile to zero before the document can close.
03
Production
A day’s intent to make things, and the record of what was actually made.
One plan per outlet per day, with its status derived from its contents rather than stored.
A production run records the output quantity and the inputs really consumed, and is immutable once posted.
Theoretical and actual consumption are both kept, so variance per batch is always derivable.
Unplanned batches are permitted, because an approved plan must not force anyone to misreport.
Buffet menus are defined once and copied into a day’s session, so editing the menu later cannot rewrite a session already produced.
04
Procurement and the network
Purchase orders, deliveries, goods receipts, and a trading registry that works with suppliers who have never heard of us.
Purchase order through delivery order to goods receipt, with partial fulfilment expressed as multiple deliveries.
Amendments are recorded as their own entries and never edit a posted document in place.
Suppliers with no account can open a purchase order through a share link, and claim their trading history later if they register.
Supplier products, pack sizes and time-bounded price periods, so a price for June and a price for July are two facts rather than an edit.
Landed cost allocates freight and duty across a receipt before it reaches inventory.
05
Sales and POS
Transactions from your own tills and from delivery platforms, deducted once.
Batched ingestion from devices and channels, deduplicated so a retried upload cannot deduct stock twice.
The business date follows the outlet’s own timezone rather than the calendar day in UTC.
Menu items are the per-outlet decision to sell something, at a price, owned alongside the catalog.
Devices authenticate as themselves and are registered, rotated and revoked independently of any person.
Menu and configuration sync ships only what changed since the device last checked.
06
Reporting
Read models shaped for the questions people actually ask.
Built from the events the other parts publish, so reporting load never slows down an outlet mid-service.
Stock summaries, purchase detail, cost history and data quality, each shaped for one question.
Uncosted items are reported as a data quality problem rather than being allowed to read as zero.
Dashboards are assembled per person and follow them between devices.
The rules underneath
These are enforced in the codebase, not aspirations in a slide.
No service reads another’s database
Each part owns its own data and publishes facts. Nothing reaches across a boundary to read a table it does not own, which is what stops one part’s change from breaking another quietly.
Derived figures are never stored
Status, variance, item level and role are all recomputed from the facts underneath. A stored copy is a copy that can be wrong.
Deactivate rather than delete
Something no longer in use stops being selectable for new work but is never hidden from the documents that already reference it, and never removed.
The newest event wins, not the last to arrive
Every copy of another part’s data records how recent the fact behind it is, so an event that arrives late cannot overwrite a newer one.
See how the figures are produced
The platform page describes what each part does. The next one describes why you can trust what comes out of it.