Definition
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.
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.
Embedded decision logic is ungovernable
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.
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.
Among multiple candidate actions, which one is appropriate right now?
What policies, safety rules, and contextual norms apply?
When multiple rules match, which one wins, and why?
What inputs were considered, what was chosen, and what was the outcome?
Decision logic lives outside application code as modular, declarative policies that can be inspected and modified independently.
Given the same inputs, the Decision Plane produces the same outputs. Behavior is predictable, testable, and reproducible.
Every decision produces a trace: what context was considered, which policies applied, what action was selected, and why.
Policies can be added, modified, or retired through a governed process, without redeploying application code.
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, skip 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]
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.
Faster iteration: update policy, not product code
Auditable behavior: every decision has a replayable trace
Safer systems: constraints and precedence are explicit
Portable governance: decisions survive infrastructure changes
Go deeper into the architecture, the engine, and the thinking behind the Decision Plane.
A deterministic Decision Plane for consequential execution. Reliable today, self-improving tomorrow.
→The decision engine behind Memrail. EMUs, reachability, the trigger DSL, foresight/hindsight architecture.
→How context graphs become operational when paired with governed decision execution.
→How context graphs become operational when paired with governed decision execution.
→We'll help you identify embedded decisions, map constraints, and ship auditable policy.