The Batch That Couldn't Be Replicated Because Nobody Wrote It Down
You pulled a 72-hour conche on Premiere A with beans from a Peruvian estate, a 10% cocoa butter addition, and sunflower lecithin at 0.3%. The result was the best bar you've ever made — clean fruit forward with no astringency. Six months later, a wholesale buyer wants a repeat order. You remember the country, roughly the percentage, vaguely the roast. You do not remember whether it was the 140°C drum roast for 18 minutes or the 125°C for 22 minutes. You do not know if you used Premiere A or Premiere B. The batch is gone, and the bar is unrepeatable.
That is the entire argument for this system.
The Calculated Batch ID That Timestamps Itself
The Batch ID field is a calculated string derived from the batch timestamp — formatted as B{year}-{month}{day}-{hhmm}. You enter the timestamp once and the identifier generates automatically in a consistent format across every batch. B24-0312-0830 is the batch started on March 12, 2024 at 08:30. No manual entry, no collisions, no "Batch 47b revised" ambiguities in your records.
The corresponding Roast ID in the linked Roast library uses the same schema with an R prefix. This means every batch record carries a human-readable pointer back to exactly which roast session supplied the nibs, and every roast record carries a pointer back to which stock SKU the green beans came from. The chain from farm to finished bar is traceable through three linked libraries without querying a separate system.
Processing Time is recorded as a duration in hours. Combined with the Equipment field — Premiere A or Premiere B — this is where your melanging log lives. At fifty batches, the pattern between processing time, equipment selection, and perceived chocolate texture in batch notes becomes visible. Shorter melanging on Premiere B versus Premiere A for the same bean origin is data, not anecdote.
The Formulation Engine Inside the Template
Batch Size is calculated — the sum of all ingredient weights: nibs, cocoa butter, cane sugar, sunflower lecithin, and up to two inclusion ingredients. You never enter total batch weight. You enter each component and the database adds them. This prevents the common error of recording weights that do not sum to the stated batch size, which corrupts your cost-per-gram calculations.
Suggested (c/butter) calculates recommended cocoa butter addition at 10% of nib weight. Suggested (sugar) computes the sugar quantity needed to hit the target Percent Cocoa value, accounting for existing cocoa butter, lecithin, and inclusions. These are guidance figures, not locked values — you enter your actual gram weights independently — but they give you a sanity check against your formulation intent before you close the record.
The inclusion percentage calculations — First Inclusion % and Second Inclusion % — express each inclusion as a percentage of total batch size. A 50g addition of dehydrated raspberry powder to a 1,200g batch is 4.2%, and that figure appears automatically. When you are scaling the formula for a larger production run, percentage-based formulation is what you work from, not absolute gram weights.
The Stock Remainder That Catches Your Inventory Before You Run Out Mid-Batch
The Stock library's Remainder field computes automatically: Stock weight in kilograms minus the cumulative sum of all roasts drawn against that stock entry, converted from grams to kilograms. When a stock entry hits 0.2kg remainder, you are two small roasts away from running out of that origin. The warning is in the record before you open the roaster lid.
The Roasted total field in the Stock library is a lookup that pulls the cumulative weight of all roasts linked back to that stock SKU. It does not require manual update. Every new Roast record that links to a Stock entry increments the total automatically. The only data entry required is the roast size at the time of roasting.