RFC-0101-v2. Labeling§

Status: Accepted.

We have our own labeling system for things, it is designed to be easy. It is optimised for communication, addressing and labelling. It assumes access to a computer system that can handle identifier allocation and help with all the different interactions.

Consider a USB Flash Drive, it’s name could be USBFLASH-014A.

Every item is uniquely identified by it’s category and the tail. The system can contain up to 2475 (= 999 numbers X 26 letters) distinct items of a specific category. Should we every run out we prepend an extra zero expanding the space to 259974 (= 9999 numbers X 26 letters). We can keep prepending zeros ad infinitum.

In communication it is completely acceptable to drop the index, LAPTOP-006A can be expressed as LAPTOP-006. However, this is less future-proof and is to only be used in short-lived communication.

Parenting§

In the system every item can optionally have a “parent” item.

Without devolving into a mereological nightmare, we broadly consider the parent to be any object that contains the item that is also labelled. For example, a PC-006A might contain GPU-004C, CPU-012A and SSD-001A.

This is entirely managed by the system and has no expression on the label.

QR Codes and Barcodes§

Each item is equipped with a machine-scannable respective Code 128. Below the barcode the full label of the item should be visible.

More on this in RFC-0102.

Ownership and Responsibilities§

Every item has a “responsible person” assigned. This is not visible on the label itself but can be obtained from the QR code.

Symmetric Items§

Some things can be written in two ways, for example a USBA2USBC can also be written as USBC2USBA without loss of meaning. For items like that lexicographic order is preferred (alphabetic, numbers before letters).

Expiration§

Every item has a “last checkup” date. It represents the date that the item was last maintained at. 1 year after the last checkup the item can be safely thrown out unless the date on the item is updated.

The label on the item is authoritative in terms of expiration. If the expiration information is updated within the system the label should be reglued.

This is intended to prevent rot and hoarding. If an item does not get use or is not important enough to check on it can be thrown out.

Reallocation§

This section can get a little technical, skip to the last paragraph if you don’t need the details.

When an item is lost, sold, decomissioned or non-present in any other way it is hidden from the database, but not deleted. When a new item of the same category is added and is about to roll over into the next digit we instead try to reallocate it. For example, if we had DISPLAY-009C and we were about to add one more to become DISPLAY-010C.

When that is about to happen the system checks for smaller numbers that belonged to now-gone items. If such an entry is found, the index is incremented and the past serial number is allocated to it instead. Consider the following example:

  1. Assume we have 9 RAM sticks in very active use: RAM-001A, RAM-002A up to RAM-009A.

  2. For some reason the RAM-003A does not work anymore and is thrown out. Someone marks it in the system. From then it is hidden.

  3. As a replacement we get one more RAM stick. When we add it to the system reallocates. Instead of labelling it RAM-010 it reuses a now-defunct identifier RAM-003, but changes the last letter from A to B. Thus the new RAM stick gets the label RAM-003B.

The index increments in alphabetical order eventually rolling over from Z to AA, then AB and so on.

NB: This design pattern is borrowed from Entity Component Systems and is usually called “the version.”

As a result, the numbers are kept small and memorable. If executed correctly, there will NEVER be two items ending in the same number but with different letters. You can uniquely identify every available item by it’s category and serial number.

Complexity§

It is fair to ask why we need the complexity. We totally could just have a number, but the system gives us several beneficial properties:

  1. The numbers don’t keep growing. In a simple sequential labelling the longer this system persists the more numbers are allocated. Without reallocations you will have to deal in hundreds. No one will want to do that and we’ll drop into lower numbers out of convenience. Here we handle this case explicitly and safely.

  2. The system roughly represents current quantities. The number never exceeds the current number of items in circulation.

Prefixing§

An item can start with a prefix. For instance, an item belonging to Thinkin’ Rocks* could be labelled TR-USBFLASH-001A. The serial number and the index live separately for each entity. The items with different prefixes are assumed to be in different namespaces and have separately counted numerical part.

When an item is tranferred from entity to entity it needs to be relabelled.

Edgecases§

System Failure§

Assume the system is not available during a non-deferrable labeling process. In that case no labeling can be done with reliability. This kind of failure is expected to be rare.

Overflow Handling§

Assume that we run out of letters or numbers. In terms of numbers this is highly unlikely, but we can just add a zero to the left. When we run out of letters we do what Excel does: use more letters. This is not a problem for communication since you are not expected to have to voice the letters in verbal communication.

Category Error§

Assume an item is put into the wrong category. Then, once the mistake is noted, the system can nicely recover using Reallocation. The new item can just get a fresh label and the previous one will be carried over once a new item from the mistaken category appears.

Transfer§

Sometimes there is a need to move things from one prefix to another. This is effectively like creating an entirely new item.