Arxi Decision Gate Asset Core
Docs
Asset Core Docs

Deterministic world-state engine documentation and API references.

Decision Gate docs

Scenario Foundations

A warehouse inventory and a robotic workcell look like completely different problems. One tracks pallets and bins in a grid; the other tracks end-effectors in metric space. But at the level Asset Core operates, they share identical structure: a bounded coordinate space, a set of typed entities, and operations that move or transform those entities. The narrative changes, but the algebra stays the same.

This is the same insight introduced in the documentation overview: a pallet in a warehouse inventory and a fixture on an assembly line are the same shape. The scenarios that follow demonstrate how this abstraction works in practice.

The principle: structure before narrative

Asset Core provides algebraic primitives—containers with geometry, entities with types, operations with semantics—that apply across domains. The same Grid that models a backpack-style inventory also models warehouse aisles. The same Balance that tracks gold coins tracks reagent volumes. The same operations (AddFungible, MoveInstance, and so on) work in both.

This means:

  • A discrete 2D inventory grid and a discrete robot workspace use the same lattice algebra.
  • A slot-based equipment loadout and named workcell fixtures share the same positional semantics.
  • A currency ledger and an aggregate resource pool follow the same scalar arithmetic.

The domain narrative is yours to add. The structural guarantees come from the algebra, which is why the same operations can power so many industries.

Why this matters for you

Three practical consequences:

  1. One system, many domains. Code written for inventory management doesn’t need to be rewritten for warehouse allocation. The patterns transfer because the structure transfers.

  2. Clean tooling for agents. When operations have well-defined semantics, LLMs and automation tools can reason about them reliably. This is where the abstraction pays compound interest.

  3. Future domains fit the same mold. Adding a new domain doesn’t require new primitives. If you can describe what exists, where it lives, and how it moves, Asset Core already supports it.

Mapping your domain

Use this checklist to translate any system into the Asset Core model:

  1. Define the world boundary – one namespace per isolated world (see Runtime Model).
  2. List the entities – classes (types) and instances (unique items), distinguishing fungibles from unique instances.
  3. Choose the memory regions – containers define where state lives (see Containers and Assets for details).
  4. Pick the geometry – Balance (0D), Slots (1D), Grid (2D), or Continuous (1D/2D). The dimensional classification (see Containers and Assets) determines which operations apply and what constraints are enforced.
  5. Encode invariants – policies, class behaviors, operation sequencing (leveraging bounded operations).
  6. Commit transitions – every change is an explicit transaction (see Transactions and Operations).

If you can answer “what exists, where it lives, and how it moves,” you can model it here. The abstraction is universal because these questions apply to every spatial state system, regardless of domain.

From here

The scenario pages demonstrate this in practice: