ATOMs and EMUs: A Practical Mental Model for Governed AI Decision-Making

Every governed AI system needs to answer two questions at decision time. First: what does the system know right now? Second: given what it knows, what should it do? These two questions map to two distinct architectural concepts that are often conflated in practice — lumped together as "context," "state," or "business logic" — but that must be separated for governance to work.

This article introduces two concepts that make that separation explicit: ATOMs (typed, structured facts about the world) and EMUs (Executable Memory Units: rules that evaluate those facts and prescribe actions). Together, they form a mental model for how governed AI systems can make decisions that are deterministic, auditable, and safe to change. The model is general — it applies regardless of which LLM, orchestration framework, or deployment platform you use.

If you have worked with policy-as-code tools like OPA and Rego, the concepts will feel familiar. But there are important differences. OPA separates data from policy. ATOMs and EMUs go further: they add type enforcement to data, lifecycle management to rules, priority ordering for conflict resolution, and automatic decision trace generation as a first-class property. The result is a model designed specifically for AI decision systems, not adapted from infrastructure authorization.

ATOMs: What the System Knows

The Core Idea

An ATOM is a typed, named, immutable fact — the minimal unit of structured knowledge that a decision rule can evaluate. An ATOM has three properties: a name that identifies what it represents, a type that constrains its possible values, and a value that asserts what is currently true.

The emphasis on "typed" is deliberate and essential. In most agent systems today, context is passed as unstructured or loosely structured data: JSON blobs, key-value pairs, prompt fragments, or conversation history. An agent might receive {"user_plan": "enterprise"} as context — but is "enterprise" a string? An enum value from a defined set? A label that could change meaning between versions? Without a type system, the consuming rule cannot know. And if the rule cannot know the type of its inputs, it cannot guarantee deterministic evaluation.

ATOMs solve this by enforcing type at the schema level. When you define an ATOM schema, you declare what types are valid:

# ATOM schema definitions (declarative, language-agnostic)

atom account.plan_tier:
  type: enum("free", "starter", "growth", "enterprise")
  source: billing-service
  description: "Current subscription tier for the account"

atom transaction.amount_usd:
  type: decimal(precision=2, min=0)
  source: payments-service
  description: "Transaction amount in US dollars"

atom user.jurisdiction:
  type: enum("US", "EU", "UK", "APAC")
  source: identity-service
  description: "Regulatory jurisdiction of the user"

atom session.risk_score:
  type: float(min=0.0, max=1.0)
  source: risk-engine
  description: "Real-time session risk assessment score"

Once defined, ATOMs are enforced. A value that does not conform to the schema — account.plan_tier = "premium" when "premium" is not in the enum — is rejected before it can be evaluated by any rule. This prevents an entire class of production bugs where decision logic receives unexpected input values and produces undefined behavior.

Immutability and Audit

ATOMs are immutable once asserted in a decision context. When a rule evaluates account.plan_tier = "growth" at time T, that fact is fixed in the decision record. If the account's plan tier changes five minutes later, the new value creates a new ATOM assertion — it does not retroactively modify the one used in the previous evaluation. This property is what makes decision replay possible: you can reconstruct exactly what the system knew when any past decision was made.

The NIST AI RMF's Map function requires organizations to document "the data inputs that informed a decision" for AI systems operating in consequential domains. ATOMs are the technical implementation of that requirement. They are not a logging afterthought — they are a structural property of the decision architecture.

How ATOMs Differ from Context Variables

EMUs: What the System Does with What It Knows

The Core Idea

An EMU (Executable Memory Unit) is a named, versioned, lifecycle-managed decision rule that evaluates one or more ATOMs and produces a deterministic outcome. If ATOMs are the facts, EMUs are the logic. An EMU has: a unique name, a semantic version, an owner (the human or team accountable for its correctness), a set of trigger conditions (which ATOMs it evaluates), a logic body (the evaluation expression), a priority (its position in the evaluation order), and a lifecycle stage (Draft, Shadow, Canary, or Active).

The term "Executable Memory Unit" is precise in each word. "Executable" because the rule is evaluated by a runtime, not interpreted by a human. "Memory" because it encodes organizational knowledge — a business policy, a compliance requirement, a risk threshold — in a form that persists and can be queried. "Unit" because it is atomic: a single, self-contained piece of decision logic that can be tested, promoted, and rolled back independently.

An Example EMU

EMU: high_value_transaction_gate
Version: 3.2.0
Owner: risk-ops-team
Priority: 100
Stage: Active

Evaluates:
  - transaction.amount_usd (decimal)
  - account.plan_tier (enum)
  - session.risk_score (float)

Logic:
  IF transaction.amount_usd > 10000
  AND account.plan_tier NOT IN ("enterprise")
  AND session.risk_score > 0.7
  THEN outcome: "require_human_approval"
  ELSE outcome: "permit"

Outcomes: ["require_human_approval", "permit"]
Cooldown: none
Trace: auto

Every property of this EMU is architecturally significant. The version (3.2.0) means when a decision trace records that this EMU was evaluated, it records the exact version — making the decision reproducible even after the rule is updated to 3.3.0. The owner (risk-ops-team) means someone is accountable for this rule's accuracy. The priority (100) means when multiple EMUs could apply to the same decision context, the evaluation order is deterministic. The stage (Active) means this EMU is currently enforcing; a different stage would mean it is logging results without affecting outcomes.

Why "Lifecycle-Aware" Is the Key Differentiator

The concept that distinguishes EMUs from conventional policy rules — including OPA policies, Cedar policies, and ad hoc if/else logic — is lifecycle awareness. An EMU does not simply exist or not exist. It moves through defined stages:

• Draft: The EMU exists in the system but evaluates nothing. It is being authored, reviewed, or refined.
• Shadow: The EMU evaluates against live ATOMs and logs what it would have decided — but takes no enforcement action. Teams use Shadow mode to observe the rule's behavior against real production data before promoting it.
• Canary: The EMU enforces on a defined percentage of traffic. If anomalies are detected, it can be pulled back to Shadow without affecting all decisions.
• Active: The EMU enforces on all eligible evaluations. It is the governing rule.

This lifecycle is not a convenience feature. It is a structural requirement for safe rule management. Without it, rule changes go directly from "someone wrote it" to "it governs every decision" — the equivalent of deploying code directly to production without staging. For a deeper exploration of this deployment pattern, see Safe Rollout for SaaS Decision Rules.

Comparison with Policy-as-Code: Where OPA Ends and EMUs Begin

The OPA/Rego policy-as-code model is the closest existing paradigm to the ATOM/EMU model, and comparing them clarifies what EMUs add. OPA separates data (JSON documents) from policy (Rego rules). A Rego rule evaluates JSON input and produces a decision. This is a sound architectural pattern, and OPA is a mature, well-tested tool.

The differences are in five areas where AI decision systems have requirements that infrastructure authorization does not:

None of this makes OPA wrong. OPA is an excellent infrastructure policy engine. The point is that AI decision governance has additional requirements — lifecycle management, priority resolution, type-enforced inputs, and automatic audit traces — that require either extending OPA or adopting a model designed for these requirements from the start.

The Neurosymbolic Connection

The ATOM/EMU model is, in formal terms, a neurosymbolic architecture. The Garcez and Lamb survey on neurosymbolic AI (2023) defines the paradigm: systems that combine neural network capabilities (pattern recognition, natural language understanding, generation) with symbolic reasoning (rules, logic, structured knowledge). The argument is not that neural systems are insufficient — it is that for certain classes of problems, particularly those requiring auditability, consistency, and formal verification, pure neural approaches produce outputs that cannot be governed.

In the ATOM/EMU model, the neural component is the LLM: it generates proposals, interprets user intent, extracts information from unstructured inputs, and produces candidate actions. The symbolic component is the EMU set: it evaluates typed facts (ATOMs) against explicit rules and produces deterministic outcomes. The LLM proposes; the EMU decides. The LLM is probabilistic; the EMU is deterministic. The LLM output varies across invocations; the EMU output is identical for identical inputs.

This separation is not merely architectural elegance. It has a direct practical consequence: the deterministic component (EMUs evaluating ATOMs) can be formally analyzed. You can prove properties about the rule set — reachability, conflict-freedom, coverage — that you cannot prove about a neural network's behavior. You can test EMUs exhaustively against defined ATOM value ranges. You can version them, roll them back, and shadow-evaluate them against live data. None of these properties apply to logic embedded in prompts or model weights.

How ATOMs and EMUs Produce Decision Traces

One of the most consequential properties of the ATOM/EMU model is that decision traces are a natural byproduct of evaluation, not a separate logging concern. When the decision plane evaluates an EMU against a set of ATOMs, the trace is inherent in the evaluation itself:

• The ATOMs evaluated are recorded with their names, types, and values at evaluation time.
• The EMU evaluated is recorded with its name and version.
• The outcome is recorded as a typed result from the EMU's defined outcome set.
• The timestamp, agent identity, and session context are captured.

This is fundamentally different from the "add logging" approach where decision traceability is an afterthought. In the ATOM/EMU model, the trace is a structural consequence of how evaluation works. You cannot evaluate an EMU against ATOMs without producing a trace, because the trace is the evaluation record.

This property directly satisfies the NIST AI RMF Govern function's requirement for "documentation and processes for human oversight, including mechanisms to capture, log, and address input from relevant AI actors." The trace is the mechanism. It is not optional or configurable — it is intrinsic.

ATOMs and EMUs in Practice: The SOMA AMI Implementation

The ATOM/EMU model described in this article is not purely theoretical. It is the foundational architecture of Memrail's SOMA AMI (Adaptive Memory Intelligence) architecture, where ATOMs and EMUs are implemented as first-class platform primitives. In SOMA AMI, teams define ATOM schemas through a declarative interface, author EMUs with versioning and lifecycle management built in, and the platform handles typed evaluation, priority resolution, trace generation, and safe rollout automatically.

The practical value of a platform implementation is that teams do not need to build the type system, versioning infrastructure, lifecycle state machine, or trace pipeline from scratch. These are infrastructure concerns that every team implementing the ATOM/EMU model would otherwise need to solve independently — and solving them correctly is non-trivial. The model is the architecture; the platform is the implementation.

Applying the Mental Model: A Diagnostic Checklist

Whether or not you adopt ATOMs and EMUs as named concepts, the mental model they represent can be applied as a diagnostic for any AI decision system. Ask these questions about your current architecture:

• Are your decision inputs typed? Can you enumerate every fact that your decision logic evaluates, with its type, its source, and its valid value range? If the answer is "it depends on what the LLM extracts," your inputs are not typed — they are inferred, which means they are non-deterministic.
• Are your decision rules independently versioned? Can you retrieve the exact version of every rule that was active at a specific past timestamp? If rules are embedded in code or prompts, the answer is almost certainly no.
• Do your rules have lifecycle stages? Can you shadow-evaluate a rule change against live data before it enforces? If rule changes go directly to production, you have no lifecycle management.
• Do you have automatic decision traces? Is every evaluation recorded with the inputs evaluated and the rule versions applied? If traces require manual instrumentation, they are incomplete by definition — wherever instrumentation is missing, decisions are invisible.
• Can you identify unreachable rules? Can you verify, before deployment, that every rule in your system can actually fire given the current input sources? If not, you may have governance controls that exist on paper but never execute. For a deep exploration of this problem, see ATOMs, EMUs, and the Decision Plane, specifically the section on deterministic decision authority.

Each "no" represents an architectural gap between what your system does and what governed AI decision-making requires. The ATOM/EMU model is one way to close those gaps. It is not the only way — but it provides a concrete vocabulary for naming the problems and a concrete architecture for solving them.