One name for
everything real.
Maps, robots, XR systems, scans, and digital twins create different representations of the same world. Once an entity is grounded, 4D-ID gives it a persistent identity that survives different coordinate systems, representations, vendors, and time.
Shared identity, not another coordinate system
Grounding determines what thing an observation refers to. Localization determines where it is. 4D-ID preserves which thing it is across systems, representations, frames, and time. Different systems keep their own maps, coordinates, and internal IDs while resolving the same persistent entity.
One persistent referent
A grounded physical or virtual entity keeps one identity while pose, state, representations, and observations change.
Find the same thing again
Resolve aliases across systems; preserve relationships, representations, provenance, history, and authorized merge or split corrections.
Native systems stay native
ROS frames, Niantic anchors, OpenXR entities, scan segments, and BIM objects remain native and can attach to the same 4D-ID.
A UUID provides uniqueness. 4D-ID adds standardized aliases, resolution, hierarchy, representations, state and time, provenance, merge/split lifecycle, and historical continuity.
Ground first. Identify second.
4D-ID starts where perception and existing data systems leave off. An entity may be grounded from a BIM, GIS, CMMS, MLS, device ID, or asset database; from detection, segmentation, tracking, or re-identification; from human annotation; or from a grounding service such as SEGS.
Scans, cameras, BIM, GIS, robots, registries, or people supply evidence.
An upstream process determines the referent and supplies spatial context.
Resolve an existing entity first; mint only when no acceptable match exists.
Look up the identity, aliases, state, relations, representations, and history.
Robots, XR, AI, twins, and maps share the referent, not one coordinate frame.
Niantic anchor_923
ROS track_47
XGRIDS segment_108
BIM GUID_882
↓ grounding / reconciliation
4did:...DOOR17Detections, tracks, anchors, and scan segments are evidence. They remain native to their systems and can become aliases or supporting observations for one grounded entity.
Spatial Entity Grounding Service (SEGS)
SEGS turns observations into grounded entity hypotheses: detect or segment → classify → track or re-identify → localize in 3D → match known entities → mint or resolve a candidate 4D-ID.
SEGS is an implementation pattern adjacent to 4D-ID, not part of the core candidate standard.
4D-ID does not: object detection, segmentation, SLAM, VPS, localization, geometric registration, rendering, robot navigation, or grasp planning.
Try it, right now
These isolated browser demos illustrate the identity and resolution model. Records created here are sandbox examples and do not enter the live resolver namespace.
Two systems, one forklift
See how independently created identities converge once an external matcher supplies evidence and an authorized actor records the merge.
Reconcile it → Demo 2 · globalAddress → identity, on a globe
Use supplied coordinates or an external geocoder result as grounding, create a sandbox identity, and resolve it again.
Open the globe → Demo 3 · showpieceA building that can be worked
A simulated robot and drone exchange an already-grounded observation by identity; native planning and localization remain outside 4D-ID.
Enter the building → Demo 4 · scaleOne record, ten thousand containers
Sail a ship of named containers and count the records. Naive versus hierarchy, live.
Sail the ship →The live reference resolver
Behind this site runs a real 4D-ID resolver you can query right now. It is read-only: you can look identities up, but you cannot create them here, so the try-it demos above create identities in your own browser instead. Below are the calls the resolver answers.
The four-call quickstart
# liveness curl -fsS $BASE/health # resolve an external identifier to a 4D-ID (sample facility) curl -fsS "$BASE/resolve?registry=asset.register&external_id=TB-WH-01" # bounded, agent-ready context envelope curl -fsS "$BASE/entity/<4did>/context" # deterministic state snapshot curl -fsS $BASE/snapshot
Note: resolve is a lookup, not a mint. It finds an identity already registered in that resolver. The sample facility registers asset.register / TB-WH-01; the globe demo creates separate browser-only sandbox records.
REST surface
| Operation | Route | Notes |
|---|---|---|
| resolve | GET /resolve | external id or 4D-ID to locator + snapshot |
| entity | GET /entity/:id | identity card + relations |
| state | GET /entity/:id/state | current or ?at= record |
| relations | GET /entity/:id/relations | typed, confidence-filtered edges |
| representations | GET /entity/:id/representations | ranked by ?purpose= |
| context | GET /entity/:id/context | bounded envelope for agents |
| query / list | POST /query · /list | filter by cells, layer, class |
| events | POST /events | event-class records |
| watch | GET /watch | changes since a generation |
| snapshot | GET /snapshot | zone generations + reference time |
Built on what already works
4D-ID is a candidate identity layer that composes with existing standards and native systems; it replaces none. Adapters translate native identifiers and grounded records into 4D-ID references only where implementation code exists.
OGC GeoPose & DGGS · ISO 8601 · ROS tf2 · VDA 5050 · ETSI Local Dynamic Map · OpenXR · glTF · MCP
The ideas behind
the identity.
Eight essays on grounding, shared identity, resolution, AI, and practical adoption.
Explore the writing ↗