Your inventory is not incomplete — it is confidently wrong

Ask an MSP about inventory accuracy and you will hear about coverage: how many machines are reporting, how many are stale, how many were never enrolled. Those are real problems and they are the easy ones, because a gap is visible. Nobody acts on a blank field.

The expensive problems are the ones that render as data. A serial number attributed to the wrong chassis. A monitor listed twice under two formats of the same serial. A row that shows a value it inherited from the row above it. All of these look exactly like inventory.

Identity is harder than collection

Collecting hardware facts from an endpoint is mostly solved. Deciding which physical thing each fact belongs to is not. A machine can report a system serial that the manufacturer left as a placeholder, a chassis serial that differs from the baseboard, and a set of attached peripherals whose serials arrive in whatever format each vendor felt like emitting.

So the practical work is identity work: collecting the baseboard identity separately rather than trusting a single system serial, and normalizing peripheral serials so that the same monitor reported by two different code paths is recognisably the same monitor. Neither is glamorous. Both are the difference between an asset record you can act on and one you have to double-check, which is the same as one you do not use.

An inventory nobody trusts enough to act on without verifying is not an inventory. It is a hint.

The display layer can invent facts too

This one surprised us, so it is worth naming plainly. A dense inventory grid needs a stable identity per row. If that identity is derived loosely — from a value that can be blank, or duplicated across records — rows collide, and a collision does not render as an error. It renders as the wrong value, in the right column, next to a real device.

We hit exactly that and fixed it by making row identity deterministic per grid and per record position, so a blank or duplicated display value can no longer overwrite a neighbouring row. The lesson generalises past our stack: any table that keys on data can silently merge two records the moment that data is not unique, and the merged result looks entirely plausible.

Unknown has to survive the round trip

The third accuracy failure is semantic. A device that has not reported is not a healthy device with no problems — it is an unobserved device, and those are opposite conditions. Systems that default to green when data is absent are not reporting health, they are reporting the absence of bad news, and the two diverge exactly when a machine has gone quiet because something is wrong.

Keeping unknown as a distinct state through collection, storage, and display costs you a less satisfying screen. It buys you a technician who investigates connectivity instead of investigating everything except the actual problem.

What to ask your current tooling

• When a machine reports a placeholder or duplicated system serial, what does the asset record key on instead?
• If the same peripheral is discovered by two different mechanisms, do you get one record or two?
• Does a device that has not checked in look different from a device that checked in and was fine?
• When an inventory grid has two records with the same display value, can you demonstrate that neither one overwrote the other?

Nexus collects baseboard identity alongside system identity and normalizes monitor serials on the way in, keeps unknown states rendering as unknown rather than green, and derives grid row identity deterministically rather than from the data being displayed. None of that is a feature anyone asks for in a demo. All of it is why the number on the screen is the number you can quote to a client.