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.
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.
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:
when: event: call.completed user.plan: paid transcript.status: complete credentials.valid: true do: action: summarize_call retry: 1 redact: [ssn, dob, address] audit: retain: 90d fields: [plan, status, redactions]
The decision is now explicit, versioned, and auditable, without rewriting the summarization service.
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.
Proposals are not automatically authoritative. They earn authority through validation. The system can propose aggressively; it must act conservatively. This is what keeps decision logic evolvable without becoming unaccountable drift.
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
Learn more
Memrail
A deterministic Decision Plane for production AI agents. Reliable today, self-improving tomorrow.
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.