What Is a Control Plane in a Software Factory?

Every software factory has a part that moves work from step to step. That part is the control plane. It sequences station calls, records state transitions, and hands artifacts from one process stage to the next. It does not make decisions. It does not run models. It does not evaluate policies. It is the conveyor belt, and keeping it dumb is a deliberate architectural choice in the factory.

The Conveyor Belt Analogy

A factory floor has workstations and a conveyor belt between them. The belt does not inspect the work. It does not decide whether a part passes quality control. It just moves things. The control plane is the same. A spec arrives from intake. The control plane sends it to the spec-lint station. The station emits a new artifact. The control plane sends it to the spec gate. The gate decides. The control plane records the decision and moves the artifact to the next station. Sequence and record. That is the entire job.

What the Control Plane Does Not Do

The control plane holds zero decision authority. That belongs to the gate engine. It holds zero LLM calls. Those belong to the stations. It holds zero credentials for repos, deployments, or secrets. Those live in the adapters. The control plane does not interpret evidence, evaluate risk, or decide whether a change can merge. It calls stations. It records outcomes. It advances the state machine. If the control plane crashed and restarted, the factory would pick up exactly where it left off, because all state lives in durable artifacts, not in the control plane's memory.

This separation is deliberate. The control plane is the only part of the core that touches every transition. If it also held authority, a bug in the belt could corrupt decisions. By keeping it to pure sequencing and recording, the control plane becomes the simplest, most testable part of the system.

Why Thin Matters

The control plane is deliberately kept thin because the workflow engine behind it is a swappable implementation detail. Today the factory uses a lightweight reference implementation. Tomorrow it might use Temporal, or a simple queue, or a serverless workflow. The control plane's contract is so minimal that swapping the engine is a config change, not an architecture change. No business logic lives in the orchestration layer. No decision depends on which engine is running.

This is the hexagonal payoff applied to workflow. The core defines the sequence. The port defines the interface. The adapter implements the engine. The control plane never knows which adapter is behind the port.

Provenance as a Side Effect

Because the control plane records every state transition, provenance is a natural byproduct. Every station call, every gate decision, every artifact transition gets written to the provenance store. This is not extra work. It is what the control plane does as part of moving work. The provenance trail exists because the control plane recorded what happened, not because someone remembered to add logging afterward. This is how the factory builds accountability without overhead.

The Rule

The control plane sequences and records. It never decides. That rule is enforced at the architecture level. Nothing in control_plane.py imports an LLM client, reads free text to make a choice, or holds credentials. It is the most boring code in the factory, and that is exactly what makes it trustworthy.