A Three-Tier Model for Asset Tracking Granularity in ITAD Systems

Motivation

Software for IT asset disposition (ITAD) is usually built on a single implicit assumption: that the unit of inventory is one uniquely identifiable device. Each row in the asset table is one physical thing, with a serial number, a status, and a history. This model is clean, and for laptops and servers it is correct.

It is also wrong for most of what actually moves through a warehouse.

A pallet arriving for disposition is heterogeneous. It carries laptops, which are serialised. It also carries keyboards, mice and cables, which are not — no one tracks an individual USB cable, and pretending to creates thousands of meaningless records. And it carries monitors, which arrive described by variant and count: "twenty 22-inch, thirty-five 23-inch." The serialised model cannot represent either of the latter two, so in practice they escape the system entirely and live in a spreadsheet.

The interesting observation is that this is not a missing feature. It is a modelling error made at the schema level, years before anyone noticed, by deciding that granularity is uniform. The cost of that decision compounds: every report, every count, every reconciliation silently excludes the stock the model cannot see.

The three tiers

Physical stock arrives at one of three granularities, and the data model should mirror them rather than force them into one.

Serialised. One record per physical device, with a unique tag and a full append-only history. This is the conventional model, and it is correct for anything with a serial number worth tracking: laptops, desktops, servers.

Bulk. A stock line identified by SKU, carrying a quantity rather than identity. There is no per-unit record because there is no per-unit question worth asking. Movements are recorded as an append-only quantity log, so the current count is always derivable and never destructively overwritten.

Container. A pallet holding several variants, each with its own count — the monitor case. The container is one record; its contents are lines beneath it, counted by variant. This is the tier that had no representation at all and lived outside the software.

Unification under the purchase lot

Three tiers risk three disjoint systems. What ties them together is that a buyer does not think in any of them — a buyer thinks in the purchase lot, the commercial unit that was acquired as a whole, with a purchase order, a delivery note and a cost.

The purchase lot sits above all three tiers. A single lot can contain serialised devices, bulk lines and containers simultaneously. This is what lets the operational interface be built around lots rather than individual devices — which turns out to be essential at scale, because a device-first list stops being usable at a few thousand units, while a lot-first view stays navigable into the tens of thousands.

Crucially, cost attaches at the lot level and flows down. Per-unit cost becomes a derived value — the lot's total cost apportioned across its units, with a manual override where a unit's cost is genuinely known — rather than a figure that has to be captured device by device at intake.

Implementation notes

The model was implemented incrementally in a live system rather than designed on paper and shipped whole. Two findings are worth recording.

First, the tiers must not be forced to share a table. The temptation is to add a quantity column to the serialised asset table and call a bulk line "an asset with quantity > 1." This collapses under its own weight the moment either tier grows a field the other does not have. Separate tables, unified by the lot, kept each tier honest.

Second, the container tier benefits from an optional intermediate grouping — a sub-lot, or spec bucket — that partitions a lot's devices by declared specification without changing the lot total. The lot remains the source of truth; sub-lots are a view onto it, not a competing sum. Getting that relationship the wrong way round (making the lot total the sum of its sub-lots) introduces a reconciliation problem that did not previously exist.

Conclusion

The granularity of a tracking system should be a property of the stock, not a constant chosen once for all of it. A three-tier model — serialised, bulk, container — unified by a commercial purchase-lot abstraction, represents the physical reality of an ITAD warehouse far more faithfully than the uniform serialised model it replaces, and does so without abandoning the per-device auditability that serialised tracking exists to provide.

The wider lesson generalises beyond ITAD: when software consistently pushes part of a process into spreadsheets, the spreadsheet is not the workaround. It is the specification for the model the software is missing.