Better together
“Which dishes are low-margin and high-waste and failed a temp check this week?”
Answering that is a four-table join on one spine — cloud_recipes × cloud_entries × cloud_waste_logs × shield_check_responses, one org_id. A competitor would have to merge four companies, and reconcile four identity graphs, to even parse the question.
The architecture
One shared spine. Not four apps stapled together.
This is a diagram of the actual architecture — one login, one item catalog, one supplier list, one batch identity, one activity feed, one AI. Five join keys connect every product tile below.
org_id
One login, one organization, across every app.
org_catalog_item_id
One item catalog — a case of chicken breast is the same row everywhere.
supplier_id
One supplier list, shared by purchasing, receiving, and recipes.
batch_id
One batch identity — a delivery, a prep item, and a check can all point at the same lot.
family_activity_events
One activity feed — what one app does, the others can see.
What it looks like
Three ways one capture pays for itself twice.
Every step below is a real event kind or table join that exists in the codebase today — not a hypothetical.
The reorder
- OneCount: A count finds a shortfall against par.
- Ops: An order request is sized against that same par level.
- OneCount: The delivery is received once — stock, batch, and any linked check all update together (stock.received).
join: org_catalog_item_id, supplier_id
The failed check
- Shield: A fridge fails its 6am check (check.failed).
- Trace: The affected batches are scoped by batch_id.
- Ops: A move-and-recheck task is raised.
- OneCount: The write-off is priced — the failed check does something, not just gets logged.
join: batch_id
The recall drill
- Trace: A supplier lot number comes in.
- Trace: Every affected batch, prep item, and dish is listed in minutes — lineage, not a search.
- Shield: The corrective action is logged against the same batch.
join: batch_id (parent_batch_ids lineage)
The status board
What's real today, named plainly.
This page makes the biggest claims on the site, so it has to be the most honest one. The event producers and table joins above are merged to main — that's a git fact. Whether a cross-app loop has actually fired for a real venue is a runtime fact, and today it hasn't: every loop below reads 'built, awaiting first live venue' until it does.
On the App Store. Stocktakes, purchasing, variance, and the Xero bill push are live today.
The producer of most cross-app events below.Early access. The Knowledge desk and recipes are real on the web dashboard today.
Built — awaiting first live venue.Early access. The Shield forms desk is real on the web dashboard today.
Built — awaiting first live venue.Early access. The label catalog desk is real on the web dashboard today.
Built — awaiting first live venue.Integrations feeding the spine
Month to month. No proprietary hardware. Works with the POS you have.
Your data exports any day. The ecosystem is a reward for staying, not a tax for entering.