---
type: Concept
title: The Control Plane
description: What it means for PMOS to be a control plane — it orchestrates, specs, evaluates, and routes agent work rather than generating production code itself.
tags: [control-plane, architecture, orchestration, identity]
timestamp: 2026-06-28
---

# The Control Plane

**Situating context:** "PMOS is a control plane, not a code generator" was the load-bearing identity
claim of the whole product. **As of D65 (PM-ratified 2026-08-04) the second half of that sentence is
retired:** PMOS is a control plane *and a factory*. This concept still fixes what "control plane"
means — the distinction is more useful now, not less, because there are two graphs and you must know
which one you are in.

The line the old phrasing drew is still drawn, in a different place. It is no longer "PMOS does not
emit app code"; it is **"the executing half may not write the governing half's records, and may not
push or merge."** If a thing anchors, accepts, disposes or approves a contract, it belongs to the
control graph. If it opens a pull request against a product, it belongs to the factory.

## Control plane vs. data plane

The term is borrowed deliberately. In systems architecture:

- The **data plane** does the work — moves the packets, serves the requests, *generates the code*.
- The **control plane** decides what the data plane should do — configures, schedules, routes,
  observes, governs.

**PMOS is the control plane. The coding agents are the data plane.** PMOS orchestrates, specs,
evaluates, and routes agent work; it does **not** itself generate production application code. The
thing PMOS controls is the [agent harness](/okf/core/concepts/agent-harness.md), not the end app.

## What the control plane actually does

PMOS's four control-plane functions map onto the [SDLC loop](/okf/core/concepts/sdlc-loop.md):

1. **Spec** — turn intent into a contract: PRDs, pre-run contracts, done-criteria. The control plane
   says *what* should be built and *why*.
2. **Evaluate** — judge what came back through the
   [three-tier gate](/okf/core/concepts/output-eval.md). The control plane decides whether output is
   acceptable.
3. **Route** — direct work to the right agent, skill, and OKF context; escalate to the human when
   needed. The control plane decides *who/what* does the work.
4. **Orchestrate** — sequence runs, manage concurrency, close the loop by writing knowledge back.
   The control plane decides *when* and *in what order*.

Notice what is absent: *writing the application*. That is the data plane's job.

## Why the distinction is load-bearing

If PMOS starts generating production code, it stops being a control plane and becomes just another
code generator — and it loses the leverage that makes it valuable. The control plane's power is that
it improves the **harness** (instructions, skills, gates, OKF knowledge), and a better harness
improves *every* agent run, not one feature. Conflating the planes collapses that leverage:

- Keep PMOS's outputs at the control altitude — specs, rubrics, routing decisions, knowledge.
- Push code generation down to agents operating inside the harness PMOS defines.
- When a proposed PMOS feature would emit production app code, that is the signal it belongs in the
  data plane, not here.

## Relationship to the harness

The control plane *controls* the harness; the harness *wraps* the model so a run can finish. PMOS's
deliverables — OKF bundle, skills, AGENTS.md, eval gates — **are** the harness configuration. See
[agent-harness](/okf/core/concepts/agent-harness.md) for what the harness contains and the
**Summary Gate** that compresses context into it between sessions.