Batch and Sequence Tracking
Using events for batch genealogy and traceability in process industries — indexing, nesting, and what to record.
Process industries — dairy, brewing, pharmaceutical, chemical, food — work in batches rather than in continuous flow. A batch has an identity, a recipe, inputs, conditions it experienced, and outputs. Event schemes model this naturally, and batch tracking is one of the most valuable things you can build in Infohub.
A batch is an event#
Everything about a batch fits the event shape: it starts, it ends, and everything you know about it is an attribute.
Batch 2026-0847
Started 2026-08-13 06:14
Ended 2026-08-13 09:52
Recipe Strawberry Yoghurt 2%
Vessel Fermenter 3
Raw milk lot L-44821
Culture lot C-1093
Peak temp 43.2 degC
Hold time 212 min
pH final 4.41
Yield 97.3 %
Operator N. Dlamini
Status Released
That single event now answers traceability questions — which raw material lots went into it, what conditions it saw, whether it met specification — and aggregates into comparative analysis across hundreds of batches.
Batch numbering#
Use the event scheme's Index settings to number batches automatically rather than relying on a source system or manual entry.
| Setting | Choose |
|---|---|
| Index Interval | The period after which numbering restarts |
| Index Initial | The first number |
| Index Time Scheme | The calendar governing the reset |
The interval should match how the plant refers to batches. If people say "batch 47" meaning the forty-seventh this year, use Yearly. If they mean today's forty-seventh, use Daily.
Decide the numbering before the scheme runs. Changing the index configuration later does not renumber existing events, so you end up with two conventions in one series and a permanent explanation to give. This is a five-minute decision that is awkward to revisit.
Where an external system already assigns the authoritative batch identifier — an MES or ERP batch number that appears on paperwork — capture that as an attribute and treat Infohub's index as secondary. Two competing batch numbers on the same batch causes real confusion on a factory floor.
Where batch boundaries come from#
In order of reliability:
From an MES or batch system. If a batch execution system already records batch starts and ends, query it. Its boundaries are authoritative and match the paperwork.
From a recipe or phase tag. Many control systems expose a current-recipe or current-phase tag. A batch starts when it becomes non-idle and ends when it returns.
From a vessel state. A fermenter or reactor state tag that cycles through charging, processing, discharging, cleaning.
Manually entered. Legitimate where nothing in the data marks the boundary, but it means the analysis depends on the discipline of whoever enters it.
Whichever you use, verify the boundaries against three real batches before building anything on top. A batch scheme whose ends are half an hour late makes every hold-time and yield figure wrong.
Nested events#
Batches often contain phases — charging, heating, holding, cooling, discharging — and it is reasonable to want both levels.
Model them as separate schemes on the same equipment: a Batch scheme and a Phase scheme. Each phase event falls within a batch event in time, and analysis relates them by overlap rather than by a stored parent link.
Two practical notes. Keep the phase scheme's attribute set small — the phase name and its duration are usually enough, since the batch carries the descriptive detail. And be realistic about whether you need phases at all: they multiply event volume substantially, and many sites get everything they need from batch-level events plus retrieved-from-segment attributes.
Attributes worth capturing#
The temptation with batch tracking is to record everything, and some very large attribute sets exist in the wild. Discipline pays off, because every attribute is either a source to configure or a field somebody has to fill.
Identity — batch number, the external system's batch identifier, recipe or product.
Inputs — raw material lot numbers, one attribute per significant input. These are the backbone of genealogy: they let you answer "which batches used lot L-44821" when a supplier reports a problem.
Conditions — peak and average temperature, hold time, pressure, pH. Retrieved from segments, so each describes its own batch.
Outputs — quantity produced, yield, reject quantity.
Quality — laboratory results, entered manually or read from a LIMS, plus a release status.
Accountability — operator, shift, vessel.
Retrieved-from-segments is what makes this cheap. Peak temperature, average agitation speed, and hold time above a threshold are all retrieved over the batch's own span with no expression writing and no per-batch configuration. This is the capability to lean on — it is why batch condition monitoring in Infohub is far less work than it looks.
Traceability in both directions#
Genealogy questions come in two directions, and both are answerable from the attribute set above.
Forward, from an input. "Lot L-44821 was contaminated — which batches used it, and where did they go?" Filter batch events by the raw material lot attribute.
Backward, from an output. "This customer complaint references batch 2026-0847 — what went into it and what conditions did it see?" Open that event and read its attributes.
For this to work in practice, lot attributes must be enumerated or consistently formatted. A lot number entered as L-44821, L44821, and 44821 across three batches breaks the forward query silently. Where lots come from a source system, read them; where they are entered by hand, constrain the format and validate it.
CIP and cleaning cycles#
Clean-in-place cycles are the natural companion to batch tracking, and they are events in the same way.
A CIP event typically carries the vessel, the cleaning media used, the peak temperature reached, the duration at temperature, the final rinse conductivity, and a pass or fail. That is enough to demonstrate that cleaning happened and met its parameters — which is frequently an audit requirement rather than an operational nicety.
Because cleaning parameters are pass/fail against thresholds, this is a good place for the tri-state format string pattern: a calculated attribute or measure returning 1 or 0, formatted 'Pass';'Fail';'Fail', displayed with a limit for colour.
Campaigns#
A campaign — a run of many batches of the same product before changing over — is another event scheme, containing batch events in time.
Campaign attributes are usually the product, the number of batches, total output, and average yield. Campaign-level analysis is where changeover cost becomes visible: total downtime attributable to changeovers versus productive time in campaign.
Note that a campaign is an event, not a calendar. It is tempting to model campaigns as a manual time scheme because they partition time; resist it, because campaigns have gaps between them and attributes describing them, which is exactly the event shape. See Shifts, Financial Years, and Custom Periods.
Retention#
Batch events carry manually entered attributes and quality results that cannot be regenerated, and traceability is frequently a regulatory obligation with a defined retention period.
Set the scheme's Purge Age against that obligation, not against convenience, and confirm your database backup retention outlives it. A purged batch event takes its lot numbers and quality results with it permanently.
Diagnosing#
| Symptom | Cause |
|---|---|
| Hold times and yields consistently wrong | Batch boundaries late or early; verify against real batches |
| Batch numbers restart unexpectedly | Index interval is shorter than intended |
| Two different batch numbers in use | Infohub's index competing with a source system's identifier |
| Forward traceability query misses batches | Lot numbers inconsistently formatted; enumerate or validate them |
| Condition attributes blank | No source data over that batch's span, or the event never closed |
| Phase events far outnumber expectations | Phase trigger needs a hold time |
| Batches never close | End trigger; every duration-derived attribute will be wrong |