Stable identities
Moving an element or changing its parent preserves its identity. Moving an anchor changes its descendants’ derived poses without rewriting their local records.
Spatial infrastructure for the united cyber universe
UCUPA is designed for a world that grows in extent and local detail. It organizes space as a tree of local coordinate frames, with different operators maintaining its branches.
How UCUPA organizes space
Objects have stable identities. Non-root objects store their positions and orientations relative to a parent anchor, so each branch can be described in its own local frame.
Anchors and entities
Every Element is an Anchor or an Entity. Anchors contain other anchors and entities; entities are leaves. Each non-root element has one parent anchor and a position and orientation relative to it. The root defines the reference frame for this tree.
STRUCTURE / PARENT → CHILD
- Root RNo parent · no local pose · unbounded range
- Anchor A(3, 1, 1) relative to R
- Anchor B(2, 0, 1) relative to A
- Entity E-04(1, 0, 1) relative to B
- Entity E-05(0, −2, 0.5) relative to A
- Anchor C(−3, 2, 0.5) relative to R
- Entity E-06(1, 0, 1) relative to C
3D SPACE / THE SAME TREE
The tree in three dimensions
A contains B and E-05; B contains E-04. C holds a separate branch. The view uses the local positions shown in the tree.
AnchorEntityAnchor range
Wire spheres show anchor ranges; lines show parentage.
LOCAL → ANCESTOR
TR←E = TR←A · TA←B · TB←ECompose position and orientation along the parent chain to express E-04 in R’s frame.
Ranges for discovery
Non-root anchors have finite spherical ranges covering their descendants. Queries use these ranges to skip branches that cannot intersect the search region.
Spatial inheritance
Descendants follow their ancestor frames. Permissions and application properties do not inherit through this relationship.
Core, Facet, and Realm
Core
Spatial facts
Stores element identity, parent, local pose, and range. Answers spatial queries and commits spatial changes.
element · parent · pose · rangeFacet
Attached content
Stores opaque payloads keyed by element and type reference. Applications define and interpret their formats.
element + TypeRef → payloadRealm
Identity and access
Verifies callers and decides whether they may perform an action on a target.
subject · target · actionFive public behaviors
Applications enter a space, discover objects, read their facts, observe changes, and propose updates.
- 01
Enter
Where do I begin?
Begin at an anchor using a space reference and an authenticated identity.
A viewer enters the space rooted at R.
- 02
Discover
What is here?
Follow a path, list an anchor’s children, or search a region. Results identify what was searched and whether the search was complete.
A region query around B finds E-04.
- 03
Read
What are the facts?
Read an object’s spatial facts from Core and its attached content from Facet, when present.
Read E-04’s position, orientation, and any attached content.
- 04
Observe
What has changed?
Follow recorded spatial and content changes to keep an application up to date.
An editor updates the records it displays as changes arrive.
- 05
Propose
Can I change it?
Request a spatial or content change. The responsible Core or Facet checks permissions and conditions before accepting it.
An editor requests a new position for A.
Viewers and editors
A viewer uses Enter → Discover → Read, then Observe to follow changes. An editor also uses Propose.
Your application handles rendering, simulation, user interfaces, and payload interpretation. Each protected operation is authorized separately.
Connecting an application
Applications connect to Core and Facet through their public interfaces. Go SDKs use gRPC/TLS; other languages can use the same Protobuf contracts.
Anchor mounts
An anchor mount lets another Core maintain the branch beneath an anchor as part of the same spatial tree.
Core A keeps ownership of mount anchor M: its identity, pose, and range. Core B owns M’s direct children and the branch it carries. Those children store poses relative to M, not to a new root.
Connected reads and spatial queries can follow the branch across Core boundaries. Coordinate transforms still compose through the same parent chain.
- Root RCore A
- Mount anchor MCore A
- Children of MCore B
To establish a mount, create M beneath the intended parent in A, request B as its carrier, and obtain approval from both sides. The Cores coordinate the relationship before B begins maintaining the branch. This extends the existing tree; it does not join two independent roots.
Each Core retains its own stores and access decisions. Mounting defines a spatial relationship, not a general permission to read or write another operator’s data.
Run UCUPA locally
Get the source from GitHub, then run the example from the repository root with Go 1.25 or later.
The demo covers discovery, content access, observation, and cross-Core reads. It uses temporary local stores and needs no separate database or service.
For host setup and verification, see the run guide.
$ go run ./cmd/ucupaSuccess requires all five output lines and exit code 0. See the expected output.
Project status
UCUPA is currently an engineering prototype. Core, Facet, and Realm are implemented, including cross-Core access and controlled changes.
Implemented
- Spatial reads, discovery, observation, and controlled changes
- Cross-Core mounts and defined transfer workflows
- Facet content access and lifecycle controls
- Realm identity, authorization, and remote access
Current boundaries
- Network and transfer support covers defined configurations, not arbitrary topologies.
- Storage capacity and numeric precision are finite.
- Production scale, high availability, and operational readiness have not been established.
- The 3D scene illustrates the model; the runnable example uses local connections.