Control Plane and Execution Plane

3. Enduring Principle

The control plane decides; the execution plane performs

The control plane owns governed intent and the rules for changing authoritative state. The execution plane consumes a bounded grant of authority, performs effects, and returns observations. Execution results may inform a decision, but they do not approve themselves.

The orchestrator sits at the boundary. It sequences work and reconciles events, but it does not own the authority it coordinates. If it can approve its own plan, change policy, widen repository scope, or accept its own evidence, the separation has failed.

Control-plane responsibilities

The control plane owns:

• human and service identity;
• Company, Workspace, Repository, and environment scope;
• versioned Factory Configuration;
• Mission, Plan, WorkOrder, and acceptance contracts;
• policy evaluation and risk classification;
• approvals, exceptions, budgets, and autonomy ceilings;
• dispatch eligibility and idempotency;
• leases, lifecycle state, cancellation, and retry authority;
• evidence requirements, freshness, waivers, and acceptance;
• immutable audit history; and
• the operator's required decision and safe options.

The control plane may calculate projections and recommendations. It should not perform repository mutation simply because it stores the WorkOrder.

Execution-plane responsibilities

The execution plane owns:

• model and agent runtime processes;
• repository checkout and attempt-specific worktrees;
• tool invocation and subprocess management;
• implementation, tests, builds, and browser operations;
• ephemeral runtime context;
• ordered execution events;
• output artifacts and hashes;
• heartbeats, local cancellation, and health signals; and
• interaction with authorized CI/CD or deployment systems.

The execution plane may report completion. It may not convert that report into acceptance or grant itself another attempt.

The interface is an execution contract

The control plane should dispatch an immutable execution manifest. At minimum, the manifest identifies:

• Mission, Plan, WorkOrder, Task, and Attempt;
• exact repository, base commit, branch, and worktree;
• Factory Configuration, workflow, executor, model, and policy versions;
• allowed tools, paths, network access, secrets, and environment;
• acceptance criteria and required evidence;
• cost, time, token, concurrency, and retry budgets;
• lease, heartbeat, cancellation, and expiry rules; and
• idempotency and correlation identifiers.

The worker should reject a manifest it cannot satisfy. It must not silently weaken isolation or substitute an unauthorized environment.

Execution returns ordered events and artifacts. Each event should carry an Attempt identity, sequence number, timestamp, producer, correlation identifier, and bounded metadata. The control plane treats delivery as at-least-once unless the transport proves otherwise. Idempotency and reconciliation are therefore part of correctness, not optional hardening.

State ownership

Independent validation is a separate execution path

Validation belongs to the factory's governance model but runs through an execution path separate from implementation. The control plane freezes the criteria and artifact identity. A validator receives no authority to alter the implementation it evaluates. It emits independent evidence, and the control plane determines whether that evidence satisfies policy.

Different people or models can strengthen independence, but technical separation is essential: separate execution identity, clean environment, independent commands, fresh evidence, and immutable receipts.

Failure must be contained

The execution plane is expected to fail. A safe design assumes workers can crash, hang, duplicate events, lose connectivity, or produce incorrect output. The control plane responds through leases, timeouts, bounded retry, cancellation, stale-evidence rules, and explicit reconciliation.

A retry is a new Attempt with a recorded reason and a new hypothesis. Resume is valid only when the executor can prove deterministic checkpoint semantics. An expired lease prevents new effects but does not erase late events; the control plane retains and classifies them without allowing them to overwrite the authoritative outcome.

8. Notes and lessons learned

My current conclusions are:

• Authority and state ownership define the plane, not deployment topology.
• The browser is an operator surface, never the final policy boundary.
• The orchestrator coordinates authority but must not manufacture it.
• Convex can own durable execution state without performing long-running work.
• Executors are replaceable when they consume one stable manifest and emit one stable event contract.
• External systems remain authoritative for their own facts; Mission Control owns the governance decision based on those facts.
• At-least-once delivery, duplicate commands, late events, and lost workers are normal design conditions.
• An execution-complete event is evidence, not acceptance.
• Logical separation should exist even when every component initially runs on one laptop.

9. Interview and discussion questions

1. Define the control plane without naming a technology.
2. Define the execution plane without naming a model or agent framework.
3. Why is the React UI not the authority boundary?
4. Why should Hono not maintain a competing source of truth?
5. Which responsibilities make the orchestrator a boundary component?
6. What belongs in an immutable execution manifest?
7. How should the control plane handle a duplicate completion event?
8. What happens when a worker completes after its lease expires?
9. Why is executor-reported success insufficient for acceptance?
10. How does independent validation cross the two planes?
11. When is resume safer than creating a new Attempt?
12. Why should GitHub remain authoritative for pull-request state?
13. Which parts of Mission Control's boundary are implemented, partial, or unproven?
14. How would this architecture change for thousands of concurrent workers?