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)  -> asset refs  # client selects and renders
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

For each row, first attempt to resolve an existing entity using identifiers, geometry, spatial context, and other evidence. Mint a new 4D-ID only when no acceptable match exists under an authorized naming policy. Attach the row's existing identifiers as identified_as relations and preserve its supplied grounding; 4D-ID does not infer location.

From a robot or a sensor

A ROS node, a LiDAR rig, a camera

Keep ROS frames and tf2 native. An adapter can associate an already-grounded object, such as ROS object_47, with a persistent 4D-ID. Detections and tracks remain observations; external grounding and re-identification determine whether they refer to an existing entity.

From a scan or a model

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

Once an upstream registration or grounding process establishes what a capture depicts, it can attach through a represents relation carrying kind, capture date, accuracy, and license. A re-scan can resolve to the same building identity; 4D-ID stores continuity and history but does not register scans or perform change detection.

How two systems end up on the same name

External identifiers, geometry, spatial context, and re-identification evidence can help a grounding or matching service propose that two records refer to the same entity. 4D-ID records that candidate and its evidence; an authorized action promotes a merge, after which aliases and historical references resolve to the survivor.

Where AI plugs in

Once observations are grounded and named, an AI agent can retrieve a persistent subject together with the representations and evidence it is authorized to inspect. 4D-ID complements raw geometry and perception; it does not replace them.

Refer. A natural-language description can resolve to a persistent entity and its 4D-ID alongside the bounding box, point cluster, or pose supplied upstream.
Understand. context(4did) returns a bounded envelope of producer-supplied class, labels, pose, affordances, relations, and provenance. It retrieves identity context; it does not perform perception or localization.
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 receives a 4D-ID as the target of a workflow. Its own planner, localizer, renderer, and controller decide how to carry it out; results return as observations or events linked to the same identity.

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 current proposal, reference resolver, and SDK are open and Apache-2.0. You can evaluate identity creation and resolution without an account or fee. The published schemas currently have 15 schema-level checks passing; functional conformance work continues.

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 asking anyone else to adopt it. 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.

Two tools make this concrete today: an implemented IFC importer that maps BIM objects into 4D-ID entity records, and a conformance CLI that checks a resolver against the published schemas and fixtures. The current suite has 15 schema-level checks passing; functional conformance work continues.

Mint your first identity on the globe →

← All writing