Adopting 4D-ID: from a record, a robot, or a scan to a working identity

The essays make the case for a shared name. This is the other half: how you actually put one to work, whether you start from a database record, a robot, a scan, or an AI agent that needs to reason about the real world.

The whole adoption path rests on one move, and it is deliberately small: translate once, at the edge, to attach a name. You do not rebuild your system around 4D-ID. You add a thin step that stamps an identity onto the things you already produce, registers the identifiers you already have, and then everything downstream, other systems, other vendors, and AI, can refer to those things by a name they all resolve the same way.

The four calls

A client that holds a 4D-ID needs a small, fixed set of operations, and their meaning is the same over any transport, REST, an agent protocol like MCP, a robotics service, or an engine plugin. The first afternoon is four of them:

resolve(registry, id)      -> 4did:…      # look up an existing identity
context(4did)              -> envelope    # a compact, agent-ready description
get_representations(4did)  -> assets      # the right model for a purpose
watch(4did)                -> changes     # what changed, as it happens

That is enough to build against. Note that resolve is a lookup, not a mint: it finds an identity that was already registered. Creating identities is the edge step below.

Three starting points

From a database or registry

An MLS record, an asset register, a parcel table

Add one ingest step: for each row, mint a 4D-ID anchored at its location, and attach its existing identifiers (parcel number, listing id, asset tag) as identified_as relations. From then on, anyone who has that external id resolves to the same identity, and your rows are addressable by every system that speaks the standard.

From a robot or a sensor

A ROS node, a LiDAR rig, a camera

Bridge your transform tree to the identity layer: the frames you already track get 4D-IDs that survive map reloads and vendor boundaries. Detections start as observations, not identities, and are promoted only when re-identification is confident, so a robot that sees the same pallet twice does not mint two names for it.

From a scan or a model

A point cloud, a splat, a BIM model, a tileset

Each capture attaches to the thing it depicts by a represents relation carrying its kind, capture date, accuracy, and license. A building becomes one identity with many representations, and a re-scan next year carries the same identity, so change detection is a property of the name rather than a manual re-registration.

How two systems end up on the same name

You do not coordinate with the other systems. Convergence happens three ways, in order of how much weight they carry: rendezvous through identifiers the world already assigns (you both attach the same parcel number, you both land on the same identity); spatial dedupe within a grid zone; and re-identification and merge, under which two independently minted names for one thing collapse into one. Most integration needs only the first, and it needs no central authority at all.

Where AI plugs in

This is the part that changes what is possible, not just what is convenient. Once things have stable names, an AI agent stops receiving raw geometry and starts receiving nouns it can reason about.

Refer. An agent names a specific thing, "this door," "that vehicle," "the sprinkler by the conference-room entrance," instead of a bounding box or a point cluster. The name is the same one every other system uses.
Understand. context(4did) returns a bounded envelope, class, labels, pose, affordances, relations, provenance, small enough to put in a model's context window instead of dumping a scene into it. It is a spatial retrieval primitive built for agents.
Reason. Because identity persists, an agent can ask questions that span time and systems: what changed here, what observed this, what is this the same as, what did we propose for it. Those are queries against named things, not bespoke fusion code.
Act. A tool acts on a 4D-ID: inspect a door, navigate to a dock, schedule a showing, highlight a unit. The result comes back as an observation or an event attached to the same name, so the loop closes: identify, understand, reason, act, observe, update.

And a safety rule sits underneath all of it: automation proposes, authority promotes. An agent can suggest that a thing exists or propose a change, but that becomes authoritative state only through an authorized promotion. An AI can enrich the world; it cannot silently turn a guess into ground truth.

Run it yourself, or don't

The specification, the reference resolver, and the SDK are open and Apache-2.0. You can mint, resolve, and run a resolver with no account and no fee, and that path is complete. If you would rather not operate one, a hosted resolver keeps identities current across many parties and serves the convergence and enrichment that gets expensive to run yourself. The standard is free; the hosting and the intelligence on top are the product, and the line between them is deliberate.

Start with one dataset

Do not boil the ocean. Pick one area, one fleet, or one facility where you already have data. Stamp identities on it, prove the four calls against it, and show an agent reasoning over it. It is useful with an audience of one, because it makes your own systems agree with each other, before anyone else adopts anything. Everyone else arriving later is upside.

Translate once at the edge to attach a name, and the rest, interoperability, history, and AI that can actually reason about your world, follows from the name.

Mint your first identity on the globe →

← All writing