GenealogyLot Genealogy / Traceability

Lot genealogy — sometimes "material genealogy", "batch genealogy", "product genealogy" or just "genealogy" — is the bidirectional graph that records which raw-material lots fed which intermediates which fed which finished lots, together with the equipment, operators, procedure (and procedure version), and time stamps for every transformation. It is the dataset that lets a regulated manufacturer answer two questions in opposite directions:

• Forward (downstream) trace — given a raw-material lot, what finished lots were produced from it, where did they ship, and to whom? This is the recall question.
• Backward (upstream) trace — given a finished lot, what raw-material lots fed it, on what equipment, by which operators, against which procedure version? This is the investigation question.

Genealogy is the single most-asked-about dataset in any post-market event. The FDA's inspection FAQ for batch-record reviews puts it first; the EU CHMP's quality-defects guideline puts it first; the FSMA Section 204 final rule for high-risk foods makes it a regulatory mandate as of January 2026. Every regulated industry, with no exceptions, requires bidirectional traceability — what differs is how strictly the recall window is set, how many hops backward / forward must be preserved, and how detailed the per-event capture has to be.

Conceptually, genealogy is a directed acyclic graph (DAG) whose nodes are lots and whose edges are transformations. A real plant graph is messy — divergent (one big raw drum feeds 40 small batches), convergent (a finished pack-out consumes intermediates from 12 different blend runs), looping (a rework lot is fed back into a future batch) — but the DAG abstraction holds.

The edges of the graph are the consumption / production events. Each edge carries the quantity, the equipment used, the operator who performed it, the procedure (and version) that authorised it, and the timestamp. With these, both upstream and downstream queries are simple graph traversals — and the resulting evidence pack is the defensible answer to any recall or investigation question.

Genealogy is captured at four event types, each of which fires inside the EWI workflow as the operator executes the procedure.

1. Receipt — an incoming material is goods-received against a PO. The supplier lot number, the supplier name, the manufacturer, the manufacture / expiry dates, and the CoA reference are all captured at the receipt. The receipt creates the lot node in the graph.
2. Move — a lot moves between bins / cells / cold-rooms. Each move is a graph annotation, not a new node; it preserves the lot identity while updating its location, status (released / quarantined / under investigation) and FEFO / FIFO position.
3. Consumption — a lot is consumed against a work order (dispense, charge-in, weigh). Each consumption is an edge in the graph from the consumed lot to the WO output lot, with the quantity, equipment, operator and timestamp.
4. Production — a WO output lot is created. The new lot is a graph node whose incoming edges are all the consumption events of the WO. The lot inherits attributes (status, holds, deviations) from the WO.

FSMA Section 204 formalises a related but stricter set of events for high-risk foods: Critical Tracking Events (Receiving, Creating, Shipping, Transformation), with Key Data Elements captured at each. The pharma / device / supplements regimes use different vocabulary but the underlying concept is the same — capture at the event, not later.

Every regulated industry requires bidirectional lot traceability. The details — the recall window, the hop count, the per-event data set — differ.

Genealogy is not a compliance line item that sits in a binder. It is the foundational dataset behind half a dozen first-class operational workflows.

1. Recall — a supplier issues a CoA correction, an in-house sample fails stability, a customer reports adverse events. The forward trace identifies every finished lot, every distribution destination, every customer. V5 returns this in seconds with the recall query.
2. Investigation — a finished lot fails QC. The backward trace identifies every input lot, the equipment used, the operators, the in-process check results, the deviations. The investigation pack writes itself.
3. Withdrawal of secondary lots — a parent lot is recalled, and its child lots (re-packs, re-distributions) need to be withdrawn too. The graph traversal finds all children automatically.
4. Supplier scorecard — quality-of-incoming-materials is computed per supplier per material per lot using the failure / deviation density across all consuming WOs. The genealogy is the join key.
5. Yield analysis — actual-vs-theoretical yield per WO is a one-graph-step calculation. Patterns of low-yield (per supplier, per equipment, per operator, per shift) emerge directly.
6. FSMA / DSCSA / FMD reporting — regulatory reporting (e.g. DSCSA T3 information, FMD safety-feature scans, FSMA 204 sortable spreadsheet on 24-h request) is derived from the genealogy, not maintained separately.
7. Reverse-engineering for transfer — moving a product to a contract manufacturer or a second site requires a full genealogy of an existing batch to verify the new site reproduces the result.

Convergent ("many feed one")

A finished pack-out consumes intermediates from N upstream batches. The graph is a fan-in. The reporting question "which API supplier lots fed this finished lot?" requires walking back through every intermediate. V5's recursive CTE returns the full set with quantities apportioned.

Divergent ("one feeds many")

A bulk raw drum feeds 40 small batches over several months. The graph is a fan-out. The recall question "which downstream lots received material from this drum?" walks forward through every consumption event with quantity and timestamp.

Rework

A failed lot is reprocessed and the rework material is fed back into a new batch. The rework lot becomes a graph node with both "failed lot output" and "new batch input" edges. The deviation that authorised the rework is bound to the rework lot. Recall walks both edges.

Re-pack / split

A parent lot is broken into child lots (often for sale or for sub-portioning). Each child lot carries the parent reference; recall on the parent traverses to every child automatically.

Co-product / by-product

Some processes yield more than one output lot from one WO (a fractionation, a separation, a co-blend). Each output is a distinct node whose incoming edges are the same WO. Recall on any one output identifies the WO and, through it, the co-outputs.

Continuous-flow / continuous-mode

Continuous manufacturing (e.g. continuous tablet press, continuous biopharma column) requires time-window-based lot definition. V5 supports time-segmented lot creation with the upstream feeds apportioned by the captured flow rates at the time of segment creation.

1. Make capture inseparable from execution — every kiosk action that touches a lot writes the genealogy event. No separate "genealogy update" job. No nightly batch reconciliation. The operations record is the genealogy.
2. Use one identifier scheme — license plate / barcode / SSCC / UDI / GS1-128 — that travels with the lot from receipt to ship. Inventing different IDs at different stages is the most common reason traceability breaks at the join point.
3. Capture device-fed, not typed — connected balances, scanners, instruments. Typed-in lot numbers are the most-failed entry on any inspection finding catalogue.
4. Enforce status (released / quarantined / on-hold) at consumption — the kiosk refuses to dispense a quarantined lot, refuses to ship a held finished lot. The genealogy graph and the status graph are the same graph.
5. Make recall a first-class user journey — not an export to spreadsheet. The recall view on every lot, with PDF render, is the workflow that gets used in an emergency at 02:00. Build for that, not for the demo.
6. Store immutably — once an event is written, it is immutable; corrections are new events with reason. Edited history is unrecoverable history.

Mistake 1 — "We have it in the ERP"

The ERP knows you bought 100 kg of API and you sold 1,000,000 tablets. It does not know which 5 kg fed which 1,250-tablet batch on which equipment. ISA-95 is explicit about this: lot-level genealogy is a Level-3 artefact, not a Level-4 one.

Mistake 2 — "We have it in spreadsheets"

Spreadsheets are the form-factor in which the most data-integrity findings are written. ALCOA+ is much harder to satisfy when the genealogy lives in xlsx files saved to a SharePoint. PIC/S PI 041-1 is explicit: spreadsheet-as-system-of-record is presumed non-compliant unless rigorously controlled — and rigorously controlled spreadsheets are not cheaper than a proper kiosk.

Mistake 3 — Operator-typed lot numbers

Typing a 14-digit lot number on a kiosk keyboard at 02:00 is the highest-error-rate operation in any plant. Use a scanner. The cost of a scanner is one mis-typed lot number averted, every quarter, in perpetuity.

Mistake 4 — Genealogy only on finished goods

Skipping intermediates because "we only need finished-to-component" makes the graph un-walkable on the day a contract manufacturer asks for the in-flight intermediate genealogy. Capture every transformation; the storage cost is negligible and the recall value is enormous.

Mistake 5 — Forgetting equipment in the edge data

Equipment is a first-class genealogy attribute. The investigation question "is this failure correlated with a specific blender / press / line?" is unanswerable if equipment is not on the consumption / production edges. V5 binds equipment at every event by default; a system that does not is a system you will outgrow in 18 months.

Genealogy in V5 is not a module. It is a property of the operations record. Every lot row, every consumption event, every production event is a node or edge in the live graph.

• /app/lots/$id/genealogy — every lot has a forward + backward trace view; full graph render, with status, quantity, operator, equipment, procedure version, timestamp at every node and edge.
• Recall pack — one-click PDF: every downstream finished lot, every customer ship-to, every supplier upstream lot, every operator involved. Reproducible — same lot, same render, byte-for-byte.
• Investigation pack — for any failed finished lot, a one-click report listing every input lot's incoming CoA, every in-process deviation, every operator e-signature, every equipment calibration timestamp.
• FSMA 204 ready — for tenants on food-related industries, the KDE/CTE schema is captured at every CTE; the 24-hour electronic provision requirement is a query, not a project.
• DSCSA / FMD ready — for tenants on pharma industries, the GS1-128 / FMD-2D / SSCC infrastructure is integrated; T3 information and FMD safety-feature decommissioning are part of the dispense / pack-out flow.
• UDI / 21 CFR 820.65 ready — for tenants on medical-device industries, UDI-DI + UDI-PI is on every finished device, with full component traceability for implantables / surgical / life-supporting.
• Isotope / activity decay ready — for radiopharmaceutical tenants, every lot carries isotope_id + activity_bq + calibration_at; the decay equation A(t) = A0·e^(−λt) is applied at every consumption with the activity-at-time recorded on the edge.
• Recursive CTE under the hood — V5's graph traversal is a Postgres recursive CTE; sub-second response on graphs with tens of thousands of nodes; no separate graph DB, no nightly ETL, no warehouse lag.