Arxi Decision Gate Asset Core
Docs
Asset Core Docs

Deterministic world-state engine documentation and API references.

Decision Gate docs

Namespace governance

Namespaces are the primary isolation boundary in Asset Core. Governance is about controlling who can access a namespace, when it is writable, and how it is safely decommissioned. This guide focuses on operational workflows rather than internal mechanics.

Create and provision a namespace

Namespaces are created and then transitioned into a provisioned lifecycle state. The exact creation workflow depends on your deployment, but the lifecycle transition is explicit and auditable.

acctl namespaces create --namespace-id 5001 --label "prod-lab"
acctl namespaces lifecycle --namespace-id 5001 --target-state provisioned --reason "initial rollout"

After provisioning, verify the namespace is visible and healthy:

acctl namespaces show --namespace-id 5001

Lock down a namespace to the owner only

Use namespace access control bindings to restrict access to a single owner or a specific group. This is the most common governance pattern for sensitive environments.

When you apply ACLs, immediately verify access with a reader role and confirm the denial outcome. This ensures the ACL is doing what you expect before production traffic flows.

Freeze, drain, or set read-only

Use operational state controls to protect a namespace during incidents or migrations:

  • Read-only: Allow reads, block writes.
  • Draining: Signal that the namespace is shutting down; write traffic should stop.
  • Frozen: Stop all operations when an incident requires a hard pause.

These controls should be paired with clear operator communications and a rollback plan.

Fork-from-snapshot governance

Forking a namespace creates a new timeline and preserves lineage metadata. Governance responsibilities include:

  • Confirming the operator has the required role to create forks.
  • Ensuring the new namespace has explicit ownership and ACLs.
  • Treating forks as independent environments with their own lifecycle states.

If you allow forks in production, document the approval workflow and audit requirements so you can trace every fork to a known operator action.

Undo retention policy (reverse commit)

Reverse commit relies on undo sidecar data that is retained per namespace. Governance should define:

  • Whether reverse commits are allowed for this namespace.
  • How long undo data is retained (time/count/forever).
  • Which roles may execute reverse commits and for what reasons.

Reverse commit applies the stored reverse plan captured at commit time and validates expected post-state; historical reversals can fail when the current state has diverged.

Treat undo retention as part of your compliance posture. If undo data expires, reverse commit must fail closed.

Deletion lifecycle and safe decommissioning

Namespace deletion is a staged process. Use lifecycle transitions to move a namespace into deleting and deleted states, and ensure that audit requirements are satisfied before final decommissioning.

Deletion should be treated as an irreversible action. Always record the reason and retain any required commit log or snapshot artifacts for compliance.

Next steps