Lot genealogy map
A lot genealogy map shows the parent-child relationships between material lots across splits, merges and transformations as a graph.
It answers recall and root-cause questions in batch and process production, where a flat trace report grows too long to read.
Key facts
- It is most useful where lots merge, split and transform over many steps.
- A recall can start from any known fact: a supplier lot, a pallet or a customer order.
- Root cause runs upstream and impact runs downstream, often in the same call.
- Where the recorded chain ends, the map has to say so. A clean root that looks complete misleads the quality team.
- The map can only show links that were recorded on the floor.
What it covers
The map covers the read-back side of traceability: the screen a quality manager or auditor opens after a complaint, a failed inspection or a supplier notice.
| Requirement | Reason |
|---|---|
| Start from any node | The known fact may be a supplier lot, a pallet or a customer order |
| Traverse both ways | Root cause runs upstream and impact runs downstream, often in the same call |
| Disposition per node | On hand, consumed, scrapped and shipped stock need different actions |
| Export the affected set | A recall ends with a list that people act on |
Where a table falls short
- Merges. Several input lots become one output, which then repeats across many rows.
- Splits. One lot becomes many, and siblings look unrelated apart from a repeated code.
- Depth. Five or more transformation steps multiply the rows faster than a reader can follow.
In discrete production with shallow bills of materials, a table with expandable rows often answers the same questions. The graph earns its place where depth and merges make the table unreadable.
Who uses it
| Role | Question they bring |
|---|---|
| Quality manager | Which supplier lot is behind this complaint, and which other products used it? |
| Auditor | Can the chain for this lot be shown completely for a past period? |
| Production or plant manager | How much affected stock is still on hand, and where? |
| Customer service | Which customers received the affected lots? |
These people open the map rarely and under pressure, so it has to be readable with clear labels and contextual guidance.
What makes it hard to design
Density. A recall in batch production can touch hundreds of nodes. Showing everything at once produces a picture nobody can read, and the people opening the map still need exact quantities for the affected lots.
Missing links. Where the recorded chain ends, the map should state that no linked inputs were recorded at that step.
Rework returns material to a production step. Record the rework event and its relationship to the original unit and resulting output or version. This preserves history without requiring a unit to be its own ancestor in the data model.
Trade-offs
- Grouping siblings makes the graph readable and puts an extra click between the auditor and the unit being checked. The count on each group has to be reliable enough that nobody expands it to verify.
- A graph shows structure at a glance and is weak at exact quantities, which a table handles well. Most recall work needs both.
Common mistakes
- Drawing the full genealogy at once, with no focus node
- A clean root where the recorded chain actually ended
- No disposition per node, so the team cannot tell what is still on hand
- No export of the affected set at the end of the investigation