> ## Documentation Index > Fetch the complete documentation index at: https://docs.alforse.com/llms.txt > Use this file to discover all available pages before exploring further. # Traceability > Serial and batch tracking, and the genealogy that links what went into what. Alforse represents individual serials and batches as **tracked entities**. Consumption and production records create a genealogy that supports backward tracing from a finished unit and forward tracing from a suspect lot. ## Tracked entities A **tracked entity** is a tracked quantity of an item. A **Serial** item gets one entity per unit (quantity 1); a **Batch** item gets one entity per lot. The serial or batch number, and where it came from, live on the entity's attributes. An entity carries a status as it moves:
**Available** In stock, free to pick or consume.
**Reserved** Allocated: e.g. a job's output before it's made.
**On Hold** Received but not yet released (awaiting inspection).
**Consumed** Issued to a job or shipped out.
**Rejected** Failed inspection.
**Scrapped** Written off as unrecoverable, with a reason. Unlike Consumed and Rejected, it can be reversed with [Unscrap](/docs/reference/scrap.md#unscrap).
## Where entities come from Receiving a tracked item creates entities **On Hold**; posting the receipt releases them to **Available**, unless the item needs inspection. Then they stay On Hold until it clears, or become **Rejected** if it fails. On the make side, a job reserves its output entity up front and flips it to **Available** when the unit is produced. ## Genealogy Every material event (consume, produce, split, ship) is recorded as an **activity** with **inputs** (what was consumed) and **outputs** (what was produced). Parent and child link through the activity, so the genealogy graph is built as work happens and walked later to trace a unit's ancestry or descendants. Consuming part of a batch records a **split**, linking the original lot to the consumed portion and the remainder. The inverse is a **merge**, which combines lots of one item into a single lot carrying their summed quantity and the earliest expiry date among them. Both lots stay in the graph as inputs to that merge, so the new lot traces back through each of them. [Operation batching](/docs/reference/batching.md) merges the members a run completed under one batch number; lots kept separate can still be merged from the batch's drawer. Alforse screenshot**The genealogy graph at Inventory → Traceability → Graph: circular entity nodes colored by status (Available, Consumed, Reserved, On Hold, Rejected), diamond activity nodes between them, a stacked node for a serial group, and the legend popover open** The graph is walked from any unit outward — upstream to its ancestry, downstream to everything it ended up in. NOTE There are no separate serial-number or batch-number tables — one tracked-entity model represents both, and the number itself is an attribute. Genealogy isn't a stored parent pointer; it's reconstructed by walking the activity graph from a unit outward. ## Shelf life Tracked items can carry a **shelf life**: a fixed duration, a date set at receipt, or one calculated from the earliest-expiring component consumed. Alforse stamps the resulting expiration date on the entity, and picking favors the earliest expiry first (FEFO). Shelf life applies only to Serial and Batch items. There has to be a per-unit record to stamp. ## Related **Jobs** Where entities are consumed and produced as a job runs. [Open](/docs/reference/jobs.md) **Quality** Inspection holds and rejects tracked entities. [Open](/docs/reference/quality.md) **Scrap and unscrap** Writing an entity off to Scrapped, and restoring it. [Open](/docs/reference/scrap.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.