Arxi Decision Gate Asset Core
Docs
Asset Core Docs

Deterministic world-state engine documentation and API references.

Decision Gate docs

Namespaces and Identity Boundaries

Namespaces are the isolation boundary in Asset Core. They define where identity begins and ends, who can act, and how to reason about correctness at scale. This concept explains the mental model: what a namespace is, how identities are scoped, and how roles and policy classes draw the access boundaries you can rely on.

Problem this concept solves

When you run deterministic state engines in production, you need strict boundaries. Without them, multi-tenant systems leak state, IDs collide, and governance is a mess. The problems are not subtle:

  • Cross-tenant state bleed when the same numeric IDs mean different things in different worlds.
  • Ambiguous identity when a container or class is referenced without context.
  • Unreliable audit trails when access decisions are implicit or inconsistent.
  • Unsafe automation when agents can call operations outside their intended scope.

Namespaces solve this by making isolation explicit, identity scoped, and access controlled.

Core ideas

Namespaces are worlds

Each namespace is a fully isolated world with its own identity space, commit history, and projection state. The write daemon treats the namespace as a routing key; the read daemon materializes per-namespace projections. This is the scaling model: one writer per namespace, infinite namespaces overall.

Within a namespace, these are scoped and independent:

  • Class registry (class IDs, behavior rules, and shapes)
  • Container IDs and placements
  • Instance IDs and ownership hierarchy
  • Commit log and world sequence numbers

Identity is scoped, not global

Identity in Asset Core is namespace-local. A class_id or container_id only has meaning inside its namespace. The true identity is the pair (namespace_id, local_id). This gives you clean isolation without forcing globally unique IDs.

Example: class_id = 42 can mean “Sample Tube” in namespace 1001 and “Sprocket” in namespace 2002. There is no conflict because they live in different worlds.

This is enforced at execution time. Operations that reference IDs from the wrong namespace are rejected. The runtime never tries to reconcile cross-namespace identity because that would be a data integrity bug, not a feature.

Roles, policy classes, and access control

Namespaces also define who may act. Asset Core uses a default-deny authorization model:

  • A principal must be authenticated and mapped to roles.
  • Roles grant access to specific operations (by domain and action).
  • Policy classes gate risky operations in higher-trust namespaces.
  • Namespace ACLs can add or deny permissions for specific principals.

This is how you keep automation safe. A tool that can move instances in a lab namespace should not be allowed to burn instances in a production namespace unless explicitly granted. Reverse commit is its own permission; commit access does not imply undo rights.

Lifecycle and lineage are explicit

Namespaces have explicit lifecycle states (provisioned, disabled, deleting). They can be frozen or set read-only during incidents. Forked namespaces carry lineage metadata (parent, fork point) so you can model branching without rewriting history.

This turns governance into an explicit, auditable surface instead of an emergent property.

Sequence space is per-namespace

World sequence numbers are monotonically increasing within a namespace. They are the stable ordering for replay, audit, and read-your-writes semantics. Sequence numbers do not have meaning across namespaces. If you need ordering across worlds, you do it at your application layer.

How it fits into the system

Namespaces appear in every critical path:

  • Write path: All commits are routed by namespace_id. The single-writer guarantee applies per namespace.
  • Read path: Projections are built and served per namespace, with freshness metadata scoped to that world.
  • Governance path: Namespace lifecycle, policy class, and ACLs determine whether a request is accepted.

In practice, this means you:

  1. Create or provision a namespace.
  2. Assign roles and policy class gates.
  3. Register classes and containers inside that namespace.
  4. Use world sequence numbers to reason about consistency and replay.

Key invariants and guarantees

Isolation

  • No cross-namespace references are allowed.
  • Every registry and index is namespace-scoped.

Identity stability

  • A local ID is meaningless without its namespace.
  • The same numeric ID can be reused safely across namespaces.

Deterministic ordering

  • World sequence numbers are monotonic per namespace.
  • Replay preserves the same ordering and outcomes within that world.

Default-deny access

  • Unknown namespaces, roles, or policy classes deny access.
  • Access is never inferred; it must be granted.

See also