The path from an approved recipe to a finished, traceable batch — how plans, schedules, runs, and cooking-and-cooling logs fit together on your floor.
Real help from real food people
Chef Diego runs a real food plant. If this page didn't get you there, tell us — a person reads every message.
It's the start of a shift and today's run lists three recipes. Each one is already broken into batches, and the first operator is weighing rice against a target the recipe set weeks ago — not a number scribbled on a batch sheet that morning. By the time those cases hit the cooler, the run has quietly captured who weighed what, the cooking and cooling temperatures, and how much came out. That whole chain is what production in Bettr is, and this page explains how the pieces connect. Open Recipes next to it and you'll meet the pieces in the order they come up.
Production lives behind the Production module, on the Kitchen plan and up. It takes what you sell and what you know how to make, and turns it into dated work on the floor with a record behind every batch.
Everything starts with the recipe. A recipe holds the ingredients, the steps, the equipment, the yield, and the food-safety settings for one thing you make. Some are ; the rest are final recipes that produce a finished product.
A recipe isn't a single document you edit in place. It carries versions, and a version moves through states: it starts a draft, goes up for approval, and comes back approved or rejected. One approved version is marked the . That's the copy a run actually uses. You can keep editing in a child copy — an R&D version — while the floor keeps running the approved one, then approve the new version and set it as production when it's ready.
The floor runs the production version, not a draft
A run pulls the recipe's production version. An unapproved edit or a draft child recipe never reaches the floor, so a change in the test kitchen can't quietly rewrite the targets an operator is weighing to.
A recipe is how to make something; a plan is what to make and how much. A comes from one of two places. A sales-order plan is pulled from open order lines — the demand waiting on Production needs — so you make exactly what a customer bought. A recipe plan is make-to-stock: you pick a recipe and a quantity because you want it on the shelf.
Either way the plan names a recipe and a quantity, and moves from pending into production as the floor works it. A plan is still a spreadsheet-shaped intention, though — it doesn't put anyone to work on its own. For that, it has to land on a day.
Scheduling a plan spreads its quantity across the days you'll actually make it. Each scheduled recipe on a given day is a line you can sequence, and the Schedule list shows those days in the order the floor will work them. The Master calendar sits above it, showing demand against the shift hours you have, so you can see a day that's overloaded before you promise it.
The schedule is the hand-off from planning to the floor. A production run is built from the recipes scheduled for a day — so the schedule is what a run reads when it opens.
A is where planning becomes sweat. You open a run for a date, and each scheduled recipe becomes a line item on it. The run moves from pending to ongoing to completed as its line items get worked and finished.
A run opens with tabs across the top — Recipes, Output records, and, when the recipe calls for them, Cooking Log and Cooling Log — plus Staff attendance for the supervisor. It also has two faces, toggled between Operator and Supervisor. The Operator view is stripped down for the person at the station: the recipes to weigh, filtered to what still needs inputs or output. The Supervisor view adds the oversight — staff attendance, confirming batches — for whoever is running the line. Same run, two jobs.
A run doesn't make a recipe in one lump; it makes it in batches. A , and the count is simply the scheduled quantity divided by the recipe's yield, rounded up. Each batch gets its own targets, so the record stays batch-by-batch instead of blurring into one daily total.
How the weighing works depends on the recipe's input format:
A line item's status follows the work: pending until someone starts it, in progress while inputs and output are owed, finished when the batch is done. A mistaken weigh isn't erased — you reverse it, and both the weigh and the reversal stay on the record.
When a batch is made, the operator records its output — either by weighing it or by counting it in packaging groups plus loose units. The Output records tab reads each batch as target, recorded, and remaining, so you can see at a glance what's been produced against what was scheduled.
Recording output turns the batch into a lot. That lot shows up in , sorted into raw material, sub-recipes, and final recipes so you always know what's staged in the kitchen. A produced lot carries its own lot number and expiry from the moment it's made — so a final-recipe batch counts as finished inventory and traces forward and backward exactly like a lot you received at the dock, while a sub-recipe lot waits in the kitchen to feed the recipes that use it.
Food safety isn't a separate binder here; it rides on the run. When a recipe turns on its cooking or cooling log, the matching tab appears on every run of that recipe, and the batch can't be called done until the log is complete.
A is captured per batch. The cooking log takes three internal temperatures and the time, checked against the recipe's minimum cooking temperature; a reading below it flags the batch as a Red Alert instead of Ok. The cooling log records the starting temperature and readings at two and five hours, against the cooling limits. Each recipe declares whether it follows FDA or USDA rules, and the log is scored to that authority.
A red alert is a record, not a roadblock you delete
When a temperature comes in out of limit, the batch reads Red Alert and stays that way in the record. The point isn't to hide it — it's to catch the failure on the batch it happened to, so you can act on that batch and show, later, exactly what you did.
Add it all up — the production version that ran, every ingredient weighing and its reversals, the cooking and cooling temperatures, the output, and who was on the line — and each batch carries a . Nothing in it is typed over; corrections are their own entries, so the before and after both survive.
That's why an audit or a mock recall stops being a scramble. The run exports its cooking and cooling logs as FDA and USDA templates — CCP-1B for cooking, CCP-2B for cooling — ready before the auditor reaches the door. And because a finished batch traces forward to every shipment and back to the lots that fed it, the batch record is the spine of your traceability, not a form you fill in after the fact.