The control plane
State: open/active · Genre: strategy
Status: working draft, 2026-10-02. Part of the strategy hub.
N-41AZ-vision defines the control plane as “Ontological as deployed: the thing that adopts
projects and runs their work”. It is not the SDF app alone, not an agent host, and not a hosted
server. SDF is its console (D-0018-sdf-control-plane-app), Foreman its engine
(PR-FRMN-foreman), harnesses do the hands-on work, and git refs carry its coordination
(D-VSLI).
Two planes
Section titled “Two planes”This is D-S30G-task-state-plane-split applied to the whole product.
| Plane | What it holds | Where it lives |
|---|---|---|
| Intent | What should exist and happen: products, capabilities, milestones, tasks, standards, decisions, and the project’s sdlc.yaml (workflows, limits, filters, trust). | The corpus under docs/planning/ and sdlc.yaml. Plain files in the project’s repo, never behind a port. |
| Execution | What is happening: leases, runs, sessions, PR verdicts, cursors, rounds, deliveries, pause state, the control-plane version. | refs/sdlc/* on the git remote, the code host, and per-machine files under .sdlc/. |
The control loop
Section titled “The control loop”The loop compares intent with what is actually happening and acts on the difference. Today it
is sdlc orchestrate run, ticking through work, prs, merges and issues. The Foreman
contract becomes the engine underneath it, with a TypeScript and a Rust implementation.
Rules that make it a control plane:
- Deterministic first. An LLM is a bounded step inside a workflow, never the loop itself.
- Bounded actions. Each action touches one PR, one task or one worktree, and is leased, limited and shown in the plan output.
- A human at the merge.
- No server required.
- It stops on bad intent: an invalid
sdlc.yaml, or an incompatible control-plane version.
Eight functions
Section titled “Eight functions”| Function | Job | Today | Gap |
|---|---|---|---|
| Adopt | Bring a project under the control plane. | SDF one-click setup, sdlc init and apply, the control-plane ref and version gate. | Two rosters: SDF’s fleet and the planned projects: roster in sdlc.yaml. |
| Model | State intent in the project’s files. | 12 entity kinds, OKF v0.2, capability entities, strict audit, sdlc.yaml with drift reporting. | No modular capability model. Control units are not built (D-XCXA-module-graph). |
| Observe | Know what is actually happening. | PR verdicts, leases, session registry, tick digest, SDF read panels, the System page for one repo. | Nothing across projects or machines. SDF’s Rust verdict classifier disagrees with the TypeScript one. |
| Decide | Choose what runs next, under policy. | Task readiness, label scoping, per-operation limits, review rounds, trust. | Policy is spread across config keys, labels and skill prose. |
| Act | Do the work through bounded, leased actions. | Workflow dispatch, the Router (live delivery confirmed on tmux 2026-10-01), worktree isolation. | Orca host broken, cmux unverified, sessions commit without hooks. |
| Steer | Let a person see and change what is happening. | SDF safe controls, pause and resume, labels, the TUI’s PR and task pages. | The consoles do not share a model. The TUI’s orchestrate action is a stub. |
| Coordinate | Share one control plane across machines, then repos. | Task and operation leases as git refs. | Cursors, rounds, deliveries, pause and session records are per machine. |
| Record | Put the evidence back in the corpus. | Task state and completion notes, lease handoffs, the orchestrator log, usage records. | No single run history to show per task or PR. |
SDF fleet. SDF’s list of registered projects, built on the Rust fleet crate (with
fleet-tauri) and stored under SDF_FLEET_ROOT. D-SK9G plans a separate projects: roster in
sdlc.yaml. One of the two should be the source and the other its projection.