
A next‑generation identifier that binds where, when, and who/what to every asset-digital, physical, or virtual. eVa lets you route data, policies, and workflows with centimeter‑level precision across buildings, bases, campuses, cities, and orbital paths.
Works seamlessly with visualization in MoE and agentic automation via Neural Voyager.
Unified Spacetime Address Model
Space + Time + Plane + Authority. Everything that matters exists somewhere, sometime, in some plane, asserted by someone.
Canonical eVa Address Format
eva://<DOMAIN>/<X>,<Y>,<Z>,<T>@<TimeAuthority>,<PLANE>[@<PlaneAuthority>][:<PlaneDimension>],<V>Every assertion is traceable to a source, time, and authority
Reconstruct any state at any point in time across planes
Plurality preserved; conflicts are data, not errors
Resolution happens via policy, not overwrite
T@TimeAuthorityID (timestamps without authority are estimates)<PlaneID>[@<PlaneAuthorityID>][:<PlaneDimensionID>]Semantic Addressing
With eVa, anything can be addressed meaningfully. AI doesn't just see data — it sees where it belongs, when it matters, and how it relates.

Containers, vehicles, drones, satellites

Documents, models, telemetry streams

Human operators and autonomous agents

Factories, ports, bases, campuses, orbital nodes

Handoffs, maintenance windows, mission phases
The Coordinates
XYZ (Space) provides three degrees of freedom, T (Time) adds the fourth dimension, and Plane defines the fifth — the semantic reality.
Three Degrees of Freedom
XYZ are required and precede time. Coordinates are frame-agnostic until bound to a FrameID.
Frame Types
Timestamp + Clock Source
Time is always bound to an authority. Timestamps without authority are estimates. Different clocks define different realities.
Time Types
Authority Types
Semantic + Source/Dimension
Plane = what kind of reality/meaning. Supports composite encoding for layering.
Composite encoding:
<PlaneID>[@<PlaneAuthorityID>][:<PlaneDimensionID>]Plane Types
Spheres of Influence (SoI) acts as the contextual trust layer on top of the address—defining who can see, do, or access what as entities move through space and time . By binding SoIs to XYZTP addresses, XRDNA ensures every action is secured, time-boxed, and policy-aware, whether in the real world, orbit, or a digital twin.
XYZ represents three spatial degrees of freedom (DOF). Coordinates are frame-agnostic — meaning comes from the XYZ Frame Registry.
Cartesian • Geodetic • Inertial • Relative • Logical
XYZ anchors every interaction to where it actually occurs — whether in the physical world (buildings, vehicles, satellites) or digital/virtual environments (AR/VR, simulations, digital twins).
Digital Twin Alignment
Synchronizes physical coordinates with their virtual/AR/VR counterparts
Object-Level Fidelity
Bind XYZ to rooms, racks, gates, vehicles, avatars, or 3D objects
Actionable in MoE
Renders as live layers in the Map of Everything for targeting, navigation, and tasking
SoI Aware
Crossing XYZ boundaries can elevate or restrict access via Spheres of Influence
Worked Examples
See how the same spatial coordinate can carry different meanings through authority and plane variations.
Road speed limit from OSM roadgraph, located via GPS
eva://CORE/33.457756,-111.987290,0,2026-04-12T14:32:10Z@UTC_GNSS,LOGICAL@MAP_OSM:ROADGRAPH_2026Q1,speed_limitAddress Breakdown
Domain
CORE
XYZ
33.457756,-111.987290,0
Time
2026-04-12T14:32:10Z
Time Authority
UTC_GNSS
Plane
LOGICAL
Plane Authority
MAP_OSM
Plane Dimension
ROADGRAPH_2026Q1
Value
speed_limit
Same location and time, but data from different map providers
eva://CORE/33.457756,-111.987290,0,2026-04-12T14:32:10Z@UTC_GNSS,LOGICAL@MAP_GOOGLE:ROADGRAPH_2026Q1,speed_limitSame source, different layer/model version
eva://CORE/33.457756,-111.987290,0,2026-04-12T14:32:10Z@UTC_GNSS,LOGICAL@MAP_OSM:ROADGRAPH_2025Q4,speed_limitSame observation, different clock sources
eva://CORE/33.457756,-111.987290,0,2026-04-12T14:32:10Z@SYSTEM_LOCAL,LOGICAL@MAP_OSM:ROADGRAPH_2026Q1,speed_limitKey Insight: The same XYZ coordinate can represent fundamentally different data depending on authority and plane. This is not ambiguity — it's plurality by design. Resolution happens at query time via policy.
Specifications
Detailed specifications for each registry that defines the eVa address space.
Key Points
Specification Fields
FrameID
Unique identifier for the coordinate frame
Frame Type
Cartesian | Geodetic | Inertial | Relative | Logical
Origin Definition
Point of origin and axis orientation
Temporal Dependency
Whether frame changes over time
Required Metadata
Epoch, units, precision, uncertainty model
Immutability
Frame definitions cannot be modified after registration
Key Points
Specification Fields
PlaneID
Unique identifier (PHYSICAL, PLAN, SIMULATION, LOGICAL, ORG, COMMAND)
Semantic Type
What kind of reality this plane represents
Cross-Plane Rules
How data translates between planes
Composite Encoding
<PlaneID>[@<PlaneAuthorityID>][:<PlaneDimensionID>]
Hierarchy
Parent-child relationships between planes
Validation Rules
What coordinate types are valid in this plane
Resolution & Fusion
Plurality is preserved; conflicts are data. Resolution happens via policy, not overwrite. Fusion produces new assertions — never destroys existing ones.
ALL
Return all matching assertions
BEST
Return highest-ranked assertion by policy
TOP-K
Return top K assertions by ranking
CONSENSUS
Return if sources agree within threshold
AUTHORITATIVE
Return only from designated authorities
TRACE
Return with full provenance chain
# eVa Resolution Policy Schema
policy:
id: string # Unique policy identifier
name: string # Human-readable name
version: string # Semantic version
mode: enum # ALL | BEST | TOP-K | CONSENSUS | AUTHORITATIVE | TRACE
# Source preferences (optional)
sources:
preferred: # Ordered list of preferred authorities
- authority_id: string
weight: number # 0.0 - 1.0
excluded: string[] # Authorities to exclude
# Fusion rules (optional)
fusion:
enabled: boolean
output_plane: string # Target plane for fused result
output_authority: string
algorithm: string # Fusion algorithm ID
# Constraints (optional)
constraints:
max_age_seconds: number
min_confidence: number
require_trace: booleannav.position.fuse.safe
Fuse GNSS + SLAM for navigation safety
policy:
id: nav.position.fuse.safe
name: "Safe Navigation Fusion"
version: "1.0.0"
mode: BEST
sources:
preferred:
- authority_id: LOC_GNSS
weight: 0.6
- authority_id: LOC_SLAM
weight: 0.4
fusion:
enabled: true
output_plane: PHYSICAL
output_authority: FUSION_PIPELINE
algorithm: kalman_filter_v2
constraints:
max_age_seconds: 1
min_confidence: 0.95Jump to any registry specification for detailed technical documentation.
Ready to implement eVa in your system?
Relational Intelligence
Because eVa is vector-based, relationships emerge naturally:
Assets near each other in space
Systems operating in the same mission window
Payloads tied to the same launch, convoy, or workflow
These relationships are queryable, routable, and discoverable without hard-coded integrations — enabling dynamic coordination across IRL, XR, VR, and space systems.
Key Principles

Engagement Engine
Elastic Vector Addresses (eVa) locate the right content at the right span; Spheres of Influence (SoI) enforce context‑aware policy. Together, they deliver on‑time actions with zero‑trust guardrails.
Movement‑aware delivery
Entering an SoI triggers the right content, controls, or tasks. eVa resolves precise spans, while SoI gates what is visible and actionable.
Safer operations
Nothing leaks outside the sphere; everything is logged. Zero‑trust scopes, SoI labels, and immutable audit trails keep actions bounded and reviewable.
Operational clarity
A single, live picture in MoE with one‑tap actions. Surface the current SoI, status, and next best step—no hunting through tools.
Agentic readiness
Mission Fabric routes requests, runs automations, and writes results back—SoI‑aware plans, human approvals where needed.