A unified namespace is one agreed structure where every system publishes what it knows, named the way the operation is actually laid out: enterprise, site, area, line, machine, signal. Publish once, and anything that needs the value subscribes to its path instead of asking for another point to point connection. That is the whole idea, and it is a good one. It is also an agreement between teams before it is a piece of software, which is why no vendor can sell you one. I sat in a room once where two groups spent forty minutes on whether Line 3 meant the filler or everything from the depalletizer to the case packer. The same oven was OVN_03 in the historian, Oven 3 on the operator screen, and asset 41187 in the maintenance system. Nobody was wrong. Each name was correct inside the system that produced it. The cost only appears when someone asks a question that has to cross all three, and then it appears every single time, forever, as a person doing translation by hand. What a unified namespace actually is Three parts, and only one of them is technology. A hierarchy that mirrors the physical operation. Most teams shape it like the ISA-95 hierarchy: enterprise, site, area, line, work cell, then the signals underneath. The test is not whether it is elegant. The test is whether a technician who has never seen it can find the right oven on the first try. A broker in the middle. Usually MQTT, often with Sparkplug B defining the payload and birth and death certificates so a subscriber knows whether a silent tag is steady or its publisher has dropped off. Publishers push on change. Subscribers take what they need. An agreement that everything goes there. One address per thing. No side channels, no private point to point link between two systems because it was faster that week. The moment there are two ways to get a value, you have two versions of the truth and an argument about which one is right. What a unified namespace is not It is not a product. Vendors sell brokers, edge gateways, and modelling tools, and some of them are very good. The namespace itself is what your people agree to call things. It is not a database. It carries current state. Retention, query, and history still need somewhere to live, and that decision has to be made deliberately rather than discovered later. It is not a security boundary. A broker with one shared credential and a wildcard subscription is the entire plant available in one connection. That is a different risk profile than the one you had when the same data sat in six systems nobody had bothered to connect. And it does not know how your operation works: which line an oven belongs to, which order is running on it, or what a bad reading means. This is the gap that costs the most, because nobody notices it until much later. What a namespace tells you, and what it leaves out A namespace gives every fact an address. It does not give it a meaning. Here is a message: site/plant2/packaging/line3/oven3/zone1/temp = 214. A subscriber now knows exactly where that number came from. It does not know that 214 is fifteen degrees under spec for the product currently running. It does not know that the last three times the zone drifted this way, the cause was a door seal. It does not know that this lot belongs to a customer with a tighter spec than the standard, or that the technician who fixed it in March wrote four words in the work order and those four words are the most useful thing in the building. Addresses locate. They do not explain. Your operation runs on real things and real actions: the order, the lot, the oven, the deviation, the release. Schedule, inspect, hold, ship. A namespace tells you the oven exists and where to find its temperature. Context is knowing that the oven belongs to a line that runs orders for customers, that an excursion opens a deviation, and that a deviation without a disposition blocks release. This is where good projects stall. The tree is clean, the data flows, and then someone points an AI model at it and gets confident answers about ovens in general. Not this oven, on this line, running this product, with this history. The namespace delivers the numbers. It does not deliver what they mean. The naming rules to write down before you connect anything Pick one asset. Any asset, ideally an awkward one. Write down every name it carries in every system that touches it, then answer these in writing before a single broker is installed. What are the levels, exactly? Name them, then find the assets that do not fit. Shared utilities, mobile equipment, and anything serving two lines will break a tidy tree, and it is better to break it on paper. Who approves a new branch? One person, named. Without that, you get three trees by spring and a translation layer to reconcile them. What are the units and whose clock? Units in the path or the payload, timestamps in UTC, and a written answer for which device is authoritative when two disagree. What happens when something is renamed? Silent renames break every subscriber downstream. Deprecate, publish both for a defined window, then retire. Who can subscribe to what? Credentials per publisher, permissions per topic branch, and a default of read only from operations into the business side. If a write path back to a control system is needed, it should exist for a written reason and be visible to whoever owns that system. What has no name at all? Every exercise like this turns up an asset that is invisible to one system entirely. That gap is the most valuable output of the hour. If one asset takes you more than a day, that is not a failure of the exercise. That is the finding, arriving cheaply instead of eighteen months into a rollout. What this changes for the people who own the network A unified namespace concentrates access, so the value of a single credential goes up sharply. Before, someone who got into the historian got a historian. After, a broker account with a wildcard subscription is every line in every plant, live, in a format designed to be easy to read. Segment it, scope it per topic, log who subscribes to what, and protect the broker accordingly, because it is now the highest-value target on the network. The upside is real too. When an auditor asks where a piece of data comes from and where it goes, a namespace is an answer you can draw on one page. Retention and record requirements are governed by the rule text and by your compliance people, not by the architecture. The architecture only decides whether answering takes an afternoon or a month. Tag names outlive the people who choose them. The structure someone sketches on a whiteboard this quarter is the vocabulary that every new technician, every audit response, and every model you ever point at the plant will inherit. Getting the addresses right makes everything after it possible. Stopping there leaves you with tidy, well-named data that still cannot tell you why anything happened. This week: Take one asset, write down every name it carries in every system, and see how long it takes to produce a single agreed path for it.