What is a Decision Plane?

A Decision Plane is a layer that separates an application's core logic from its decision-making processes. It governs what should happen now and how that decision logic evolves over time.

The problem it solves

In most AI systems, decision logic is embedded: scattered across application code, prompt templates, orchestration scripts, and ad-hoc guards. When a decision is made, it's often unclear exactly why, and changing behavior typically requires modifying and redeploying the entire system.

Common symptoms of embedded decisions

• Can't audit why a specific decision was made
• Can't update behavior without code changes and redeployment
• Can't add new constraints without refactoring
• Can't keep behavior consistent across agents, teams, or configurations
• Can't replay or explain decisions after the fact

A Decision Plane solves this by making decision logic a first-class, decoupled artifact: something that can be inspected, tested, versioned, and modified without touching the underlying application.

What a Decision Plane does

A Decision Plane doesn't just approve or deny requests. It resolves which action is appropriate given the current context, and produces an auditable trace of how that resolution happened.

Core capabilities

• Action selection: Among multiple candidate actions, which one is appropriate right now?
• Constraint enforcement: What permissions, policies, safety rules, and limits apply?
• Precedence resolution: When multiple rules match, which one wins, and why?
• Decision traces: What inputs were considered, what was chosen, and what was the outcome?

Key properties

• Decoupled (decision-as-code): Decision logic lives outside application code as modular, declarative policies that can be inspected and modified independently.
• Deterministic: Given the same inputs, the Decision Plane produces the same outputs. Behavior is predictable, testable, and reproducible.
• Auditable: Every decision produces a trace: what context was considered, which policies applied, what action was selected, and why.
• Evolvable: Policies can be added, modified, or retired through a governed process, without redeploying application code.

Example

Consider a product that summarizes customer calls. The decision logic isn't a single rule. It's a surface of conditions: only summarize paid accounts, deny if credentials expired, redact private fields, retry if the transcript is incomplete, escalate if the customer asked for a supervisor.

Without a Decision Plane, these rules scatter across code paths, prompts, and scripts. With a Decision Plane, they're decoupled as policy.

How decision logic evolves

A Decision Plane isn't static. It must support safe evolution of decision logic over time, without letting changes quietly become authoritative.

In practice, policies change through two paths:

• Deliberate changes: A human adds or modifies a policy based on new requirements or observed failures.
• System-proposed changes: The system analyzes production traces and surfaces candidate policies. These proposals move through staged evaluation (shadow mode, limited rollout, promotion) before they can affect production decisions.

The core principle

A Decision Plane separates what should happen from how it executes, so behavior can be governed now and evolved safely over time.

Why it matters

• Reliable behavior: decisions are repeatable and testable
• Explainability: every decision comes with a trace
• Safe evolution: changes go through staged rollout
• Portable governance: decisions survive infrastructure changes

Learn more

• SOMA AMI: The decision engine behind Memrail. EMUs, reachability, the trigger DSL, foresight/hindsight architecture.
• The Rise of the Decision Plane: Why modern stacks need a dedicated layer for decision logic, and what that layer does.
• Context Graphs Need a Decision Plane: How context graphs become operational when paired with governed decision execution.

Build with a Decision Plane

We'll help you identify embedded decisions, map constraints, and ship auditable policy.