Technical notes

A data model for tracking physical objects

Data model · October 2026

A large facility under construction receives thousands of IT devices: switches, access points, cameras, displays, servers. They arrive from several suppliers in several deliveries, go through a site warehouse, are installed, commissioned and handed over to the client. A clothing store receives garments, displays them, sends them to the tailor, sells them, and sometimes takes them back as returns.

Both cases need the same information: where each object is, what state it is in and what has happened to it. This note describes the data model choices that make it available.

1. The object and its label are two different things

The identity of an object often coincides with the code printed on it. In practice labels get damaged, are reprinted, arrive already applied by the supplier, or are printed in batches in advance and attached later.

The model therefore keeps separate:

label: a code that physically exists, with its origin (generated internally or by a third party) and its print log;
item: the real object, created when a label is applied and read for the first time.

The print log prevents the same code from being printed twice and applied to two different objects.

2. A short, opaque, human-readable code

The code carries no product information. It is a string of 8 random characters from a 32-symbol alphabet that excludes I, L, O and U, so it can be read out over the phone and typed without ambiguity when the QR is damaged. There are 32⁸ combinations, about one trillion: collisions are negligible and are checked at generation anyway.

In the QR the code sits inside a URL, https://domain/i/DPQPRXN8. Any camera opens it directly in the browser; no app is needed. When a standard identifier is required, the same scheme extends to a GS1 Digital Link URI, as described in another note.

3. History as an event log

Everything that happens to an item is an append-only event: who, when, what. A state change, a note, a photo, a voice message, a field edit. The current state is a consequence of the history, not a value that gets overwritten.

Entry
  item_id                  → item
  kind                     status | note | photo | video | audio | edit
  text, media_path         event content
  from_status, to_status   for state changes
  user_id                  who
  created_at               when

The log makes it possible to reconstruct who took a garment to the tailor, how long it stayed on display, which device was replaced after commissioning. Storing the from and to state in each event also allows the last action to be undone. Notes and attachments can be removed by whoever added them; state changes remain.

Users see two views of the same log: a simple history of actions for daily work, and the full log for audits.

4. States are explicit transitions

Only some transitions are allowed from each state, and the interface shows only those: a delivered garment can become a return, not go back to "received".

Shop	received → in stock ⇄ on display ⇄ at the tailor → delivered → returned
IT installation	ordered → received → issued to installer → installed → commissioned → in service

In the shop sold is not a state: a sold garment can still be in stock awaiting pickup, or at the tailor for a hem. It is recorded separately from location, with one constraint: "delivered" requires "sold". In the installation the same applies to acceptance by the client versus the physical location of the device.

5. Expected versus received

At receiving, the delivery document states what should arrive; scanning shows what actually arrived. Matching is done on a normalised key (article code, size, colour; in the installation: model and serial number) and yields five outcomes: matched, missing, not in the document, lower quantity, higher quantity.

Document lines can be entered by hand or read by an AI model from a PDF or a photo. In both cases matching follows fixed rules: the AI model extracts the lines, it does not decide the outcome.

6. What changes between a hundred and a thousand objects

The model stays the same. The fields change (in the installation: building, room, rack, IP address; in the shop: size, colour, store), as do the states and the reading technology. With a few hundred items, reading QR codes one at a time is enough. With thousands, and frequent stock counts, UHF RFID is needed: it reads dozens of tags per second without line of sight.

In summary: one identifier per object, separate from the label; history as events; states and transitions defined on the process.

← All technical notes