Farm-to-table traceability on every bowl, labels generated from the actual recipe, and subscriptions billed and retained — 17 wellness solutions, narrated by Iris.
Health-first customers read every label — and one allergen mistake or broken macro promise ends the relationship. Compliance by spreadsheet cannot keep that promise at scale.
Macro accuracy — whether the number on the menu matches the bowl that was built.
Allergen control — the flag, the prep station and the label agreeing every time.
Subscriber contribution — what a meal plan actually earns after fulfilment.
Traceability — the lot behind every ingredient, retrievable in seconds.
Every claim on the menu is generated from the recipe that was actually built — not from a spreadsheet someone updated last quarter.
Labels generated from the actual recipe, so the allergen line and the macro line come from the same source as the cost.
Farm-to-table traceability on every bowl — the lot behind an ingredient retrievable while it still matters.
Subscriptions billed and retained, and waste tracked to the ingredient rather than to a category.
Macro accuracy, allergen control, subscriber contribution and traceability — live, with Iris naming the claim that can no longer be substantiated.
Builds, substitutions, subscriptions and any tender on one screen — with allergen and macro data attached to the line rather than printed on a sheet by the till.
The build carries its own numbers. Swap the grain and the macros, the allergens and the price all move with it, in front of the guest.
Allergen conflicts are blocked, not warned. A build that contradicts a declared allergy cannot be rung through.
Iris upsells against a goal. The add-on suggested is one that fits the guest's stated target, not the highest-margin item on the list.
Macro accuracy, allergen control, subscriber contribution and traceability on one live board — with Iris naming the claim that can no longer be substantiated.
Every module feeds one board. Recipes, sourcing, subscriptions and labour all post into the same view.
Claims are monitored, not assumed. When a substitution breaks a published macro, the claim is flagged rather than quietly served.
Iris names the claim. Not that accuracy fell — which dish, which substitution, which supplier change caused it.
P&L, balance sheet, cash and close on a single balanced ledger — with subscription revenue recognised properly rather than counted when it arrives.
Deferred revenue handled correctly. A prepaid meal plan is recognised as it is consumed, not booked in full on the day it sells.
Contribution per subscriber, not just revenue. Fulfilment, packaging and delivery cost sit against the plan that incurred them.
Ask Iris for any number. Any site, any cohort, any period — answered in the conversation, not a week after close.
Demand-planned replenishment with provenance attached — every delivery carrying its lot, its certification and its expiry into the same chain the kitchen depletes from.
Provenance travels with the goods. Lot, farm and certification are captured at receipt rather than filed separately from the stock.
Certification expiry is tracked. An organic claim whose certificate lapses is caught before it reaches a menu.
Feeds the prep forecast. Ordering runs off the same demand model the kitchen preps against, so neither can drift from the other.
Digital checklists, prep routines and standard operating procedures across every kitchen — completion tracked live, exceptions escalated.
Cross-contact routines, signed off. Station changeover and utensil separation are completed in the system, not assumed to have happened.
Prep quantities tracked against plan. What was prepped against what was forecast rolls up by kitchen and by day.
Exceptions escalate themselves. The routine that didn't complete surfaces to a human; the rest stays quiet.
Rostering, attendance and labour percentage measured against forecast demand. Iris flags the overstaffed lulls and the understaffed peaks before the shift, not after.
Prep labour follows the plan. Meal-plan volume is known days ahead, so the prep shift is staffed to a number rather than a guess.
Allergen training tracked with the roster. Who is qualified to run the allergen-free station is held against the person, not in a folder.
Flagged before the shift. An overstaffed lull or an understaffed peak is caught while the roster can still change.
Deterministic logic under the hood (the “Zen Rules” layer) — the layer that carries the sector's whole promise. Allergens, labelling and traceability cannot be probabilistic. Six solutions run on this layer.
The tahini supplier changed lot — the new one is produced on a line handling sesame and peanut. Three bowls currently labelled nut-free are affected. Publishing blocked until the label is regenerated.
The data layer beneath every claim — allergens and dietary attributes held per item, propagating up through sub-recipes so the flag on the menu comes from the ingredient, not from memory.
Every ingredient carries its allergen set and its dietary attributes — vegan, halal, gluten-free, keto — as structured data rather than as a note.
Flags propagate automatically through every sub-recipe, so a change to a base sauce updates every dish built on it.
Publishing is blocked if any ingredient is untagged — an unknown is treated as a risk, not as an absence.
“May contain” is distinguished from “contains”, because conflating them is how trust is lost in both directions.
The same flag set drives the menu, the app, the printed label and the answer a server gives at the counter.
The operational half of the promise. Knowing an allergen is present is not the same as preventing it reaching a plate — this is the layer that governs the station, the utensil and the order.
A build that contradicts a declared allergy is blocked at the till, not warned about after it is rung.
Allergen-free orders route to a designated station with its own boards, utensils and sequence.
Changeover routines are required and recorded between conflicting builds, so cross-contact control is evidenced rather than assumed.
Only staff with current allergen training can release an allergen-free order, checked against the roster.
Every allergen order carries an audit trail from build to handover — the record you need on the one day it is asked for.
Labels generated from the actual recipe, formatted to the rules of the market you are trading in — so a published claim is one you can still substantiate a year later.
The label is generated from the recipe the kitchen builds from, so the printed claim and the actual dish cannot diverge.
Format and mandatory fields are configured per market, because labelling law is not the same in two countries.
Every published claim is versioned with its date and its source recipe — substantiation is a lookup, not an archaeology project.
A recipe change re-flags every label built on it, and the old version cannot silently remain in circulation.
Marketing claims are held to the same source as the label, so the website and the packaging never disagree.
Trace in both directions inside your own operation — from a lot to every dish it reached, and from a dish back to every lot in it. The question a recall asks, answered in seconds.
Every prep batch records the lots it consumed, so the chain from delivery to plate is continuous rather than inferred.
Forward trace answers “where did this lot go” — every batch, dish, site and order it touched.
Backward trace answers “what is in this bowl” down to the lot, which is the question a customer complaint actually poses.
A withdrawal is scoped precisely, so a recall costs one lot rather than an entire product line.
Transfers between kitchens and sites carry lot identity, so traceability survives a product moving.
The supplier side of the chain — farm, certification and batch provenance captured at receipt, so “farm-to-table” is a record rather than a phrase on a wall.
Farm, supplier, lot and harvest or production date are captured at goods-in rather than reconstructed from invoices.
Organic, halal and fair-trade certificates are held against the supplier with their expiry, and a lapse is flagged before it reaches a claim.
An unapproved substitute supplier cannot be received against a certified line without an explicit override and a reason.
Provenance is available guest-facing, so the story on the menu is backed by the same record the auditor sees.
Supplier performance on quality and certification currency is scored over time, not judged at renewal.
Every system the operation depends on, connected and watched: payments and subscription billing, the delivery aggregators, local tax and labelling rules, and the accounting ledger.
Recurring billing and one-off payments settle through the same reconciliation rather than two parallel systems.
One menu publishes to every aggregator with its allergen and macro data attached, so third-party listings carry the same claims you do.
Tax and labelling rules are configured per market, which is why a new country takes days rather than a release.
Sales, tax, refunds, deferred revenue and settlement post themselves to the accounting system, already coded.
Every connection is health-checked continuously — when an API degrades, Iris quantifies what is at risk rather than letting a site discover it.
Forecasting, cost and scoring models under the hood (the “Zen Models” layer) — prep volume, subscriber churn, macro cost and portion pricing, computed before the week rather than reconciled after it. Seven solutions run on this layer.
The computation underneath every nutritional claim — macros and calories derived from the recipe with real yields, recomputed the moment an ingredient or a portion changes.
Macros are computed from the recipe and its actual yield, not from a rounded figure typed into a menu once.
Nested sub-recipes roll up automatically, so a change to a dressing recompiles every bowl that carries it.
Cooking losses and absorption are modelled, because raw-weight arithmetic overstates what actually reaches the guest.
Cost and macro are computed from the same card, so nutritional engineering and margin engineering never work from different numbers.
A supplier change that moves a macro beyond tolerance flags the published claim for review before it is served.
Prep volume forecast per component rather than per dish — because in a build-your-own operation the unit that runs out is a grain, a protein or a dressing, not a menu item.
Demand is forecast at component level, which is the level the kitchen actually preps and the level that runs out.
Committed subscription volume is known days ahead and separated from walk-in demand, so only the uncertain half is estimated.
Component shelf life bounds the batch, so the plan never prescribes prepping more than can be sold before it expires.
Waste by component and day flows back into the forecast, correcting a repeatedly over-prepped item rather than repeating it.
The same forecast drives ordering and the prep roster, so stock, labour and plan cannot contradict each other.
What a subscriber is actually worth — contribution after fulfilment, cohort retention curves, and the churn risk that shows up in behaviour weeks before it shows up in a cancellation.
Contribution is computed after food, packaging, delivery and discount, because revenue per subscriber is not the number that matters.
Cohorts are tracked by join month and plan type, so a retention problem is located rather than averaged away.
Skips, pauses and downgrades are read as churn signals, since they precede cancellation far more often than a complaint does.
Payback period per acquisition channel is measured, so growth spend follows the cohorts that actually stay.
Iris proposes the intervention with the highest modelled return for an at-risk cohort, while the habit is still recoverable.
The mechanics of recurring revenue — cycles, pauses, skips, proration and failed payments handled so that a card expiring never becomes a cancelled customer.
Plans bill on their own cycle with proration handled correctly when a guest upgrades, downgrades or changes mid-period.
Pauses, skips and holiday freezes are first-class actions rather than cancellations a guest has to be talked out of.
A failed payment enters an intelligent retry sequence timed to when it is most likely to succeed, not a fixed daily retry.
Involuntary churn is separated from voluntary, because an expired card and a disappointed customer need different responses.
Deferred revenue is recognised as meals are consumed, so the ledger reflects delivery rather than collection.
Build-your-own is where margin quietly disappears. Portion spec, price tiers and premium components are governed so a bowl priced as a bowl does not leave as a banquet.
Base price, tiered add-ons and premium components resolve deterministically, so the same build costs the same everywhere.
Portion spec per component is enforced at the line, and served weight is compared to spec rather than eyeballed.
Weight-based pricing is supported where the format calls for it, with the scale reporting straight into the line.
Margin floors are enforced per build, so a combination of cheap base and three premium proteins cannot price below cost.
Component cost moves feed pricing tiers, so a protein that doubles in price does not stay in the base tier by inertia.
Certified stock kept separable from conventional through the whole operation — because an organic claim survives only as long as the two are never quietly mixed.
Certified and conventional stock are held as distinct inventory even where the ingredient is nominally the same.
A recipe requiring certified input cannot deplete conventional stock without an explicit, recorded override.
Batches rotate first-expiry-first-out with expiry alerts raised before product has to be written off.
Suppliers are scored on certification currency, delivery quality and substitution frequency rather than judged at renewal.
Certified stock cover is projected against forecast demand, so a shortage is visible before it forces an uncertified substitution.
Counter, app, web, subscription and the aggregators on one order book — with the same allergen and macro data travelling to every channel, because a third-party listing carries your claim too.
Every source writes into the same queue, so the kitchen works one sequenced list rather than a screen per channel.
Allergen and macro data publish with the menu everywhere — an aggregator listing without them is a liability with your name on it.
Subscription fulfilment enters the same production plan as walk-in demand rather than running as a parallel operation.
A component running out removes affected builds from every channel in the same second.
Each channel settles into the same ledger with its commission and packaging cost attached, giving true margin by channel.
Not a screenshot — the actual agent. Natural-language answers over the live kitchen. Four solutions run on this layer.
The guest-facing build — base, protein, toppings, dressing — with macros, allergens and price updating live as the bowl is assembled, on the counter screen or in the app.
Every choice updates the running macro, allergen and price picture immediately, so the guest decides with the numbers in front of them.
Clustering surfaces the combinations guests actually build as one-tap presets, which is what keeps a build queue moving at lunch.
A declared allergy filters the builder itself, so an unsafe component is never offered rather than merely flagged.
The saved build becomes a reorderable favourite, which is what turns a build-your-own guest into a repeat one.
The same engine drives counter, app and subscription selection, so a bowl means the same thing on every surface.
Recommendations scored against the guest's own stated goal rather than against margin — which in this sector is the only kind of suggestion that survives contact with the customer.
Suggestions are scored against the guest's declared target — protein, calorie ceiling, macro split — not against what the operator wants to move.
Restrictions are hard constraints in the model, so a recommendation can never contradict a declared allergy or diet.
The remaining budget for the day shapes the suggestion, so an evening recommendation accounts for what was already eaten.
Suggestions explain themselves in one line, because a health-first guest wants the reason as much as the recommendation.
The model learns from what is actually accepted, retiring suggestions that consistently do not land.
How the numbers are presented to the guest — on the menu, the screen, the app and the label — adapted to what that guest is actually tracking rather than shown as one undifferentiated block.
Every dish shows its calorie and macro breakdown wherever it appears, from the counter board to the delivery listing.
The display adapts to what the guest tracks — a macro-counting guest and a calorie-counting guest do not need the same emphasis.
Substitutions restate the numbers immediately, so a swapped base never leaves a stale figure on screen.
Portion context is shown honestly — per serving as built, not per 100g where that flatters the dish.
The figures come from the same engine as the label and the cost card, so no surface can disagree with another.
One profile carrying restrictions, goals and history — so recognition means the operation already knows what this guest can eat and what they are working towards.
Allergies, intolerances and dietary choices are recorded once and enforced everywhere, on every channel, on every visit.
The guest's goal is part of the profile, so loyalty rewards progress rather than only spend.
Points, plans and streaks share one wallet and one balance across counter, app and subscription.
Iris picks the reward with the highest modelled redemption for that guest, weighted toward what fits their goal.
Health data is treated as sensitive by default, with consent and retention handled as a first-class concern rather than an afterthought.
Seventeen solutions. Every card opens a live guided demo.
You configure a sector playbook, not a custom project. Iris applies it herself — agentically, from day one.
Onboarding is agentic. Iris connects the till, the recipe book, the label printer and every supplier feed directly — no manual data mapping.
Allergen data is validated on entry. The playbook will not go live with untagged ingredients, because a partial allergen set is worse than none.
A new market takes days. Labelling and tax rules are configured per market rather than coded per customer.
The first line of support is agentic — Iris resolves most of it herself. Our engineers pick up from there.
Layer 1 — Iris, 24/7. Configuration questions, anomalies and routine issues resolved directly, instantly.
Layer 2 — our engineers. Anything Iris can't close escalates automatically to a Zentallio engineer.
No blank tickets. Every escalation arrives with Iris's own diagnosis — engineers start from an answer.
“Health-first customers read every label — and one allergen mistake or broken macro promise ends the relationship. Compliance by spreadsheet cannot keep that promise at scale.”
Zentallio makes trust automatic: farm-to-table traceability on every bowl, labels generated from the actual recipe, subscriptions billed and retained, waste tracked to the ingredient. Underneath sits the same platform every sector runs — one data spine from the till to the ledger, three layers of intelligence, and an agent that narrates every screen, flags what needs a human, and acts on the rest.
A supplier substitution changes an allergen profile, and the label keeps saying what it said last month.
Build-your-own portions drift, so the published macro and the served bowl quietly stop matching.
Subscribers lapse for reasons nobody sees until the cancellation arrives.
Flags propagate, publishing is blocked on untagged ingredients, and cross-contact control is enforced rather than advised.
Macros recompute from the recipe, portions are held to spec, and prep is forecast per component.
“Which claim can no longer be substantiated?” — answered from the same recipe the kitchen builds from.
Every Zentallio sector runs the same three-layer intelligence, tuned to how that format actually loses margin.