Why identity beats an interpreter

The most reasonable objection to 4D-ID is also the most instructive: "Why not just build a translator between systems?" It is worth answering carefully, because the answer is the whole reason the standard exists.

When two spatial systems need to work together, the obvious fix is an interpreter: software that maps one system's identifiers, frames, and formats onto another's. A robot talks to a building twin through a bridge. A coalition partner's command system talks to yours through a connector. It works. It is also a trap, and the trap has a shape you can predict.

The N-squared problem

An interpreter connects two systems. Three systems need three interpreters. Ten need forty-five. A hundred need nearly five thousand. The number of translators grows with the square of the number of systems, because every new participant must be taught to talk to every existing one. Each translator is written by someone, maintained by someone, and breaks when either side changes.

Interpreters make interoperability a cost you pay again for every pair of systems, forever.

A shared name inverts that. Each system learns to speak one thing, the identity, once. After that, any two systems interoperate for free, because they already agree on which thing they are talking about. The cost grows with the number of systems, not the number of pairs. N instead of N-squared. Paid once instead of forever.

Interpreters lose what matters most: continuity

Even where an interpreter works, it translates a thing at a moment. It does not, by itself, know that the object it translated yesterday is the same object today. Identity is not just a mapping between names; it is a commitment that a name refers to the same thing across time, movement, re-scanning, and the boundary between real and virtual.

That continuity is what makes provenance, history, change detection, and audit possible. An interpreter can say "system A's object 47 corresponds to system B's object 91 right now." It cannot say "this is the same bridge inspected three years ago," because it never held a durable identity to hang that history on. A shared name does, natively.

Interpreters encode bilateral assumptions

A translator between two systems bakes in what each side means today. When one side changes its schema, its coordinate convention, or its versioning, the translator silently drifts and the two systems quietly disagree. Multiply that by every pair and every release and the fragility compounds. A standard both sides resolve against removes the bilateral guesswork: there is one definition of the thing, not one per relationship.

The DNS lesson

The internet faced this exact choice and chose identity. Before DNS, connecting machines meant hand-maintained tables of who-is-where, growing with every pair. DNS replaced the tables with a shared naming layer: every machine resolves the same name to the same place, and nobody maintains a translator to everyone else. The web did not scale because we got better at writing connectors. It scaled because we stopped needing them.

4D-ID is that move for physical and virtual space: not a better interpreter between spatial systems, but the shared name that makes most interpreters unnecessary.

When an interpreter is still right

To be fair to the objection: interpreters are the correct tool for a genuinely one-off, two-system integration that will never grow, or for bridging a legacy system that cannot adopt anything new. 4D-ID does not forbid them; it is often reached through one, an adapter that stamps identities onto an existing system's output. The point is not that translation never happens. It is that it should happen once, at the edge, to attach a shared name, rather than endlessly, in the middle, between every pair.

Translate once at the edge to attach a name. Don't translate forever in the middle between every pair.

That is the difference between plumbing that grows with your ambition and plumbing that fights it.