I built a Unified Namespace from scratch. A third of the plant was invisible.

If you have read anything about a Unified Namespace in the last two years, you have probably concluded two things: that it is mostly an MQTT broker with a sensible topic structure, and that the products being sold around it are therefore optional.

I believed roughly that, so I built one from parts to see what was really involved. The building was easy. What I could not build is the interesting part.

What a namespace actually consists of#

Two agreements, and that is genuinely all.

The first is the address: every reading published to a topic that spells out where in the plant it comes from, enterprise down to tag. The second is the payload: every message carrying a timestamp, a value, a unit and a quality flag, so a consumer never has to guess what a number means.

Neither of these is technology. They are conventions, written down, and a broker will happily carry data that ignores both.

For the test I built a plant of three sites, two areas each, two lines, two cells and six tags — 144 tags in total, published onto Mosquitto. The whole broker, carrying the lot, used 2.36 MiB of memory. That number is why people look at a commercial UNS product and wonder what they are paying for.

Then I tried to find out what was on it#

Here is the thing nobody mentions. A broker does not know what exists. It has no catalogue, no directory, no list of tags. It is a post office, not a phone book. So the only way to discover a namespace is to subscribe to everything and wait to see what turns up.

I did exactly that, for three minutes.

The curve climbs to 96 and stops. It never gets to 144, and it never will, because the remaining forty-eight tags did not publish during the run.

They were not broken. They were correctly configured, correctly named, sitting on the right topics, doing precisely what they were designed to do. They simply had nothing to say.

And notice which ones they are. Real plants do not publish everything at the same rate. Pressures and flows report every second. Run-hour counters report every half minute. And then there are the tags that only change when something happens: filter_blocked, estop_tripped.

Those are the tags a consumer most needs to know exist, and they are exactly the ones that listening cannot find. A dashboard built by discovery will show you every pressure in the plant and no emergency stops at all — not because they are missing, but because they have not tripped yet.

You cannot distinguish, by listening, between a tag that is quiet and a tag that does not exist. Nor between a tag that is quiet and a tag that died last Tuesday.

What stops bad data#

The other job I assumed the structure was doing for me.

I mixed defects into about two and a half per cent of publishes — not silly ones, the sort that actually happen. A missing unit. A timestamp in seconds instead of milliseconds. The word "OK" where the contract says good. A bare number published with no envelope at all. A topic with capital letters and a space in it, because somebody typed it by hand.

The broker delivered every single one. All 239, faithfully, instantly, to every subscriber. It has no opinion about your contract and it never will.

My validator caught all 239 — but only because I wrote the validator, and only because the contract existed as code rather than as a paragraph in a design document. Delete those forty lines and the malformed data flows on untouched, looking exactly like good data until something downstream falls over.

The timestamp defect is the one worth sitting with. Forty-four readings arrived timestamped in 1970. Nothing rejected them. In a historian they would either disappear into an ancient partition or quietly poison every average that touched them, and nobody would find out for months.

So what are you actually buying#

Four of the five parts took an afternoon and run in two and a half megabytes. Anyone telling you a product is required for those is overselling.

The fifth cannot be built by listening at any level of effort, because the information is not there to be found. Something has to hold a catalogue: what tags exist, what they mean, what they are supposed to be publishing, and whether they have gone quiet. That catalogue has to be maintained as the plant changes, and it has to be maintained by someone.

That is the honest buy-versus-build question, and it is not "can I run Mosquitto instead". Obviously you can. It is whether you want to own a catalogue and a validator and keep them true for the next ten years, or pay somebody else to.

Plenty of teams should build it. If you have three sites, a stable tag list and an engineer who enjoys this sort of thing, the DIY version is genuinely fine and you will understand your own data better for having built it. If you have forty sites and a new one every quarter, the maintenance of that catalogue is the whole job, and it is the thing you are actually buying.

What nobody should do is build the first four parts, skip the fifth, and call it a Unified Namespace. That is a broker with tidy topic names, and a third of your plant will be invisible on it.

The rig, the contract, the defect injection and every measurement are in the lab write-up. For the bought version of this, see United Manufacturing Hub, explained.