EMUs, ATOMs, and the Decision Plane: A Field Guide to Memrail's Core Abstractions

Every system that makes decisions has abstractions, whether the team building it chose them deliberately or inherited them by accident. Most AI agent systems operate on inherited abstractions: the prompt is the policy, the conversation history is memory, the orchestration loop is the decision layer. These abstractions are not wrong in the way a bug is wrong. They are wrong in the way that using a screwdriver as a hammer is wrong -- the tool was designed for a different job, and the results are unreliable at the margins where reliability matters most.

Memrail's SOMA Adaptive Memory Intelligence architecture is built around three core abstractions that were designed specifically for the problem of making AI decisions explicit, auditable, and safe to change: EMUs (Evaluation and Management Units), ATOMs (Adaptive Typed Object Memories), and the Decision Plane. This article is a field guide to those three abstractions -- what they are, how they interrelate, when to use each, and what misconceptions to avoid when reasoning about them.

If you are new to the vocabulary, the companion article ATOMs, EMUs, and the Decision Plane: A Vocabulary for AI Decision Infrastructure provides definitions and conceptual grounding. This article goes deeper: it covers the internal structure of each abstraction, the runtime behavior of the Decision Plane, the "propose then decide" pattern that ties them together, and the practical decision map for choosing which abstraction to apply in a given situation.

ATOMs: Structured Memory Facts with Provenance

An ATOM -- Adaptive Typed Object Memory -- is the fundamental unit of knowledge in Memrail's architecture. It represents a single structured fact about the world that the decision system can evaluate. But calling it "a fact" understates what distinguishes an ATOM from the informal equivalents that most agent systems use.

The Five Properties of an ATOM

Every ATOM in the SOMA AMI architecture has five properties that together make it suitable for deterministic evaluation:

Provenance: The Property Most Systems Lack

The provenance property is what separates an ATOM from a context variable, a session attribute, or a key-value pair in a state store. When an ATOM asserts customer.risk_score = 0.73, the provenance record answers: this value was computed by the risk-model-v3 service at 2026-05-18T14:22:07Z using input features from the customer-feature-store, triggered by event transaction.created. Without provenance, the fact exists in a vacuum -- you know what the system believed, but not why it believed it or where the belief originated.

The NIST AI Risk Management Framework explicitly calls out data provenance as a governance requirement: organizations must be able to trace the origin and lineage of data used in AI decision-making. ATOMs implement this requirement at the architectural level -- provenance is not a metadata annotation added after the fact; it is a structural property of the fact itself.

ATOM Schemas: Constraining What the System Can Know

ATOMs are not free-form. In the SOMA AMI architecture, every ATOM must conform to a declared schema before it can be asserted into the system. The schema defines the namespace, the permitted types, and the validation constraints for a category of facts.

# ATOM schema definition (illustrative)
namespace: account
atoms:
  plan_tier:
    type: enum
    values: ["free", "starter", "growth", "enterprise"]
    required: true
  monthly_spend_usd:
    type: decimal
    min: 0
    precision: 2
  days_since_signup:
    type: integer
    min: 0
  jurisdiction:
    type: enum
    values: ["US", "EU", "UK", "APAC"]
    required: true

Schema enforcement means that an ATOM with name account.plan_tier and value "platinum" will be rejected at assertion time -- the value does not conform to the declared enum. This is not a convenience feature. It is a safety property. If decision rules are designed to evaluate plan_tier against a known set of values, the system must guarantee that only those values can exist. Without schema enforcement, a single unexpected value can cause rules to evaluate incorrectly or fall through to default branches that were never intended to handle that case.

EMUs: The Atomic Unit of Policy Evaluation

An EMU -- Evaluation and Management Unit -- is the atomic unit of policy in Memrail's architecture. It is the thing that decides. Where an ATOM represents what the system knows, an EMU represents what the system does with that knowledge. Every consequential decision in the SOMA AMI architecture is the output of one or more EMUs evaluating one or more ATOMs.

EMU Internal Structure

An EMU is not a simple if/else rule, though it can express one. Its internal structure supports the full lifecycle requirements of a production decision artifact:

EMU: expense_approval_gate
Version: 3.2.0
Owner: finance-ops-team
Status: active

Inputs:
  - expense.amount_usd       (decimal)
  - expense.category          (enum)
  - requester.department      (string)
  - requester.approval_level  (enum)

Conditions:
  IF amount_usd <= 500
    THEN outcome: "auto_approve"
  IF amount_usd > 500 AND amount_usd <= 5000
    AND approval_level IN ["manager", "director", "vp"]
    THEN outcome: "auto_approve"
  IF amount_usd > 5000
    THEN outcome: "escalate_to_human"
  IF category == "travel" AND amount_usd > 2000
    THEN outcome: "escalate_to_human"

Outcomes: ["auto_approve", "escalate_to_human"]
Default: "escalate_to_human"

Metadata:
  created: 2026-03-10
  last_promoted: 2026-04-15
  review_due: 2026-07-15
  compliance_tag: "SOX-relevant"

The Versioned Lifecycle

Every EMU carries a version identifier that follows semantic versioning conventions. When the finance team decides that the auto-approval threshold should change from $500 to $750, they do not edit the existing EMU in place. They create a new version -- 3.3.0 -- with the updated threshold. The previous version (3.2.0) remains in the system as an immutable historical artifact. This is critical for two reasons.

First, decision traces reference the EMU version that was active at evaluation time. If a trace from April 20th records that expense_approval_gate v3.2.0 evaluated an expense and produced escalate_to_human, that record remains valid and reproducible regardless of what version is currently active. Second, versioning enables rollback. If v3.3.0 produces unexpected outcomes -- a surge in auto-approvals for expenses that should have been escalated -- the team can revert to v3.2.0 without any code deployment, any prompt change, or any model retraining. The rollback is an EMU lifecycle operation, not an infrastructure operation.

Inputs, Conditions, and Outputs

The three-part structure of an EMU -- inputs, conditions, outputs -- is deliberate. Inputs declare which ATOMs the EMU depends on, by name and type. This declaration enables static analysis: the system can verify at definition time that the ATOMs referenced by the EMU actually exist in the schema, that the types match, and that the EMU is reachable (there exists a valid combination of ATOM values that would satisfy at least one condition). Conditions are the evaluation logic. Outputs are the fixed set of possible outcomes. There are no surprise outcomes -- the EMU can only return values from its declared outcome set, or the declared default.

The Decision Plane: Runtime Orchestration

The Decision Plane is the runtime environment where EMUs evaluate ATOMs. It is not a rules engine in the traditional sense -- it is an architectural layer with specific responsibilities and specific boundaries. Understanding what the Decision Plane does and what it does not do is essential to using the architecture correctly.

What the Decision Plane Does

The Decision Plane has four responsibilities, and only four:

• Resolves ATOMs: Given a decision request, the Decision Plane resolves the current values of all ATOMs required by the EMUs that will be evaluated. Resolution includes provenance capture -- recording where each ATOM value came from.
• Evaluates EMUs: The Decision Plane evaluates each applicable EMU against the resolved ATOMs, in the order defined by the evaluation policy (which may be parallel, sequential, or priority-based depending on the configuration).
• Produces Decision Traces: For every evaluation, the Decision Plane generates an immutable Decision Trace that records the ATOMs resolved, the EMUs evaluated (with versions), the per-EMU outcomes, and the final committed decision.
• Enforces Safe Rollout: The Decision Plane respects the lifecycle stage of each EMU. An EMU in Shadow mode is evaluated and traced but its outcome does not affect the committed decision. An EMU in Canary mode is evaluated and committed only for its designated traffic slice.

What the Decision Plane Does Not Do

The Decision Plane does not generate content, call language models, execute external actions, or manage conversation state. It does not suggest, infer, or predict. It evaluates and commits. This boundary is the architectural insight that makes the "propose then decide" pattern possible: the model proposes, the Decision Plane decides, and the execution layer acts on the decision. As research on safe and aligned language model agents has established, separating inference from commitment is a foundational requirement for systems where agent actions have real-world consequences.

Decision Traces in Practice

A Decision Trace generated by the Decision Plane is a structured, append-only record. Here is what one looks like in practice:

{
  "trace_id": "dt-2026-05-18-8f3a2b",
  "timestamp": "2026-05-18T14:22:08.341Z",
  "trigger": "expense.submitted",
  "agent_id": "finance-agent-prod-v2",
  "atoms_resolved": [
    { "name": "expense.amount_usd", "type": "decimal", "value": 3200.00,
      "source": "expense-service", "asserted_at": "2026-05-18T14:22:07Z" },
    { "name": "expense.category", "type": "enum", "value": "travel",
      "source": "expense-service", "asserted_at": "2026-05-18T14:22:07Z" },
    { "name": "requester.approval_level", "type": "enum", "value": "manager",
      "source": "identity-service", "asserted_at": "2026-05-18T14:20:00Z" }
  ],
  "emus_evaluated": [
    { "name": "expense_approval_gate", "version": "3.2.0",
      "outcome": "escalate_to_human",
      "matched_condition": "category == travel AND amount_usd > 2000" }
  ],
  "committed_decision": "escalate_to_human",
  "trace_immutable": true
}

Every field in this trace is recoverable. Six months from now, an auditor can examine this trace and reconstruct the exact facts, the exact rule version, and the exact logic path that produced the decision. This is the property that MIT Technology Review identified as missing from most enterprise AI deployments: the ability to answer "why did the system do that?" with a concrete, verifiable record rather than a probabilistic explanation.

The "Propose Then Decide" Pattern

The three abstractions -- ATOMs, EMUs, and the Decision Plane -- together implement a pattern that is fundamental to Memrail's architecture: propose then decide. This pattern separates the system into two phases with an explicit boundary between them.

In the propose phase, the language model (or any upstream system) generates a candidate action or recommendation. The model has full access to context, can reason over unstructured information, and can apply its training to produce a nuanced suggestion. The output of this phase is a structured proposal -- not a committed action.

In the decide phase, the Decision Plane evaluates the proposal. It resolves the relevant ATOMs, evaluates the applicable EMUs against those ATOMs and the proposal, and produces a deterministic outcome: approve, deny, modify, escalate. The decision is recorded in an immutable trace. Only after the Decision Plane commits the decision does the execution layer act.

This separation is the architectural mechanism that makes AI systems simultaneously flexible and governed. The model retains its full capability to reason, suggest, and generate -- its outputs are not constrained by rigid templates. But the model's outputs do not become actions until they pass through explicit, versioned, auditable policy evaluation. The model proposes; the Decision Plane decides. For a deeper treatment of this architectural pattern, see Infrastructure for Deterministic AI Decisions.

Safe Rollout: How the Decision Plane Manages Change

The Decision Plane does not treat all EMUs equally. Each EMU has a lifecycle stage that determines how its evaluation affects the committed decision. This is the Safe Rollout mechanism, and it is the reason teams can change decision policy without the fear and ceremony that normally accompanies changes to production logic.

The Shadow stage deserves particular attention. When a team deploys a new EMU version in Shadow mode, the Decision Plane evaluates it against every applicable decision request and records the outcome in the trace -- but the committed decision uses the currently Active EMU version. The team can then compare: for every decision made in the past week, what would the new version have decided differently? This is divergence analysis, and it is the mechanism that transforms rule changes from "deploy and pray" into "measure, analyze, then promote."

Common Misconceptions

Working with teams adopting these abstractions, several misconceptions appear consistently. Addressing them directly saves significant design time.

Misconception 1: "ATOMs are just environment variables"

Environment variables are untyped strings with no provenance, no immutability guarantee, and no schema enforcement. An ATOM is a typed fact with declared provenance that is immutable once asserted and validated against a schema at assertion time. The difference becomes apparent when you try to audit a decision: an environment variable tells you what value was set; an ATOM tells you what value was asserted, by what source, at what time, with what type guarantee.

Misconception 2: "EMUs are just business rules"

Business rules in most systems are embedded in application code, unversioned, unowned, and impossible to enumerate without reading the codebase. EMUs are named artifacts with explicit owners, semantic versions, declared inputs and outputs, lifecycle stages, and review dates. The difference is the difference between a condition buried in a function and a governed artifact with its own deployment pipeline.

Misconception 3: "The Decision Plane is a rules engine"

Traditional rules engines (Drools, OPA, Cedar) evaluate rules against inputs. The Decision Plane does this, but it also manages EMU lifecycle stages, enforces Safe Rollout semantics, generates immutable Decision Traces, and performs Reachability analysis. It is a runtime that combines evaluation with governance. Calling it a rules engine is like calling a CI/CD platform a shell script runner -- technically true at one level of abstraction, but it misses the lifecycle management that is the actual value.

Misconception 4: "This replaces the language model"

The three abstractions do not replace the language model. They govern it. The model retains its role as the component that reasons over unstructured context, generates natural language, and produces nuanced recommendations. The Decision Plane evaluates those recommendations against explicit policy before they become actions. The model and the Decision Plane are complementary -- removing either one produces a system that is either ungoverned or unintelligent.

Decision Map: When to Use Each Abstraction

Not every piece of data needs to be an ATOM, and not every condition needs to be an EMU. The following decision map helps teams determine which abstraction to apply based on the characteristics of the data or logic in question.

When to Model Something as an ATOM

• The fact is used as an input to a decision that has real-world consequences (financial, operational, compliance).
• You need to reconstruct what the system knew at the time of a past decision.
• The fact has a clear type that constrains its valid values.
• Multiple rules or multiple systems need to reference the same fact consistently.
• An auditor or regulator might ask "what data did the system use to make that decision?"

When to Model Something as an EMU

• The logic governs a consequential outcome (approve/deny, escalate, route, restrict).
• The logic has a human owner who is accountable for its correctness.
• The logic might change, and you need to change it without a code deployment.
• You need to test the logic in isolation, outside the context of the full agent pipeline.
• You need to shadow-evaluate new logic against live traffic before committing to it.
• An auditor or regulator might ask "what rule governed that decision, and who approved it?"

When to Route Through the Decision Plane

• The action is irreversible or expensive to reverse (sending a communication, modifying a financial record, granting or revoking access).
• You need a complete, immutable record of the decision for compliance or incident investigation.
• Multiple stakeholders (engineering, compliance, business operations) need to review and understand the decision logic independently.
• The decision policy changes more frequently than the surrounding code, and those changes need their own deployment lifecycle.

Conversely, transient data that is only used for display purposes, logic that is purely computational with no policy dimension (string formatting, data transformation), and conditions that have no real-world consequences do not need to be modeled as ATOMs, EMUs, or routed through the Decision Plane. Over-applying these abstractions creates unnecessary overhead. Under-applying them creates governance gaps. The decision map above draws the boundary.

Putting It Together

The three abstractions form a closed system. ATOMs represent what the system knows, with type safety and provenance. EMUs represent the policies the system applies to that knowledge, with versioning and ownership. The Decision Plane is the runtime that brings them together -- resolving ATOMs, evaluating EMUs, producing Decision Traces, and managing the lifecycle of policy changes through Safe Rollout.

For teams evaluating whether this architecture applies to their system, the diagnostic question is simple: when something goes wrong with an AI decision in your system -- a customer is charged incorrectly, an approval is granted that should have been denied, a communication is sent that should not have been -- can you produce a complete, immutable record of what the system knew, what rules it applied, who owned those rules, and what version was active? If the answer involves reading code, searching logs, and interviewing team members, the abstractions described in this article address the gap.

For further reading, ATOMs, EMUs, and the Decision Plane: A Vocabulary for AI Decision Infrastructure provides the conceptual foundation, and Infrastructure for Deterministic AI Decisions covers the broader architectural context. The production implementation of all three abstractions is available in Memrail's SOMA AMI architecture.