A mold is not its MQTT topic
An injection mold may spend months on one machine before moving to maintenance, another line, or another factory. In a Unified Namespace, the path should change as the work moves. The mold's identity should remain the same, and its history should stay attached to it.
Imagine a fictional injection mold called MOLD-4821. In January, it is waiting in the north factory's toolroom. Its current data fits naturally below north/toolroom/molds/MOLD-4821.
In March, the toolroom installs it on press 14 for a long production run. The useful path is now north/press-14/molds/MOLD-4821. It is still the same steel tool. Only its place in the work has changed.
By June, the mold is back in maintenance. Two months later, it is transferred to the south factory and qualified on press 7. Each move is ordinary. The mold should not lose its accumulated story whenever it moves.
The namespace should tell us where the mold is today. It should not force us to forget where it has been.
The path describes the present
The MQTT 5.0 specification describes the useful mechanism at work here: publishers attach a Topic Name to a message, and subscribers use Topic Filters to select the messages they need. A hierarchy that follows factory, line, machine, and asset is therefore a useful operational map.
But that map changes. A line is renamed. A machine is replaced. A tool crosses a factory boundary. If the topic is also the mold's primary identity, each sensible change of path risks creating a second record for the same physical thing.
Press 7 may then appear to receive a mold with no previous cycle count. A maintenance report remains stranded below the toolroom path. A quality engineer has to reconstruct by hand that batches from two factories were made with the same tool.
Identity answers a different question
The location question is Where is it now? Today the answer might be south/press-7/molds/MOLD-4821. The identity question is Which mold is it? That answer can remain mold:4821 wherever the next job takes it.
Once those answers are kept separate, the rest of the model becomes easier to read. Placement records where the mold belongs in the namespace at a given time. Relationships say that it is mounted on press 14, handled by the tooling team, or used to produce a particular batch. History keeps the cycle counts, wear readings, work orders, repairs, process settings, and quality outcomes attached to the mold itself.
People still need one continuous story
A maintenance planner can review the mold's service history after a transfer. A quality engineer can compare defects across every batch made by the tool, rather than only the batches published below one press. Production can ask where the mold is now without overwriting where it was last year.
The same distinction lets integrations change without treating the mold as a new asset. Publishers can use a topic that reflects today's layout while the governed model resolves that placement to the durable asset. A reorganisation becomes a recorded move, not an accidental break in continuity.
Keep the two ideas separate
Use topics and namespace paths for routing and current context. Give the physical mold a stable identity of its own. Record moves as time-aware changes of placement and relationship, then attach operational history to the identity that survives them.
That small modelling decision is what allows a moving asset to keep one understandable life.