The Engineering Runtime Control Plane¶
The Runtime executes. The Control Plane governs the fleet.
Engineering Runtime executes engineering operations on a machine.
The Control Plane is the optional company layer above those machines.
It publishes one policy for every Runtime, and it collects the audit those Runtimes produce.
It never executes engineering work.
Why a Control Plane¶
A single Engineering Runtime is already governed.
Policy is evaluated before every operation, and every operation is audited.
But governance on one machine is not governance across a company.
Without a Control Plane an organization has:
- Policy edited separately on every laptop, pipeline, and agent
- Audit scattered across machines that nobody reads together
- No answer to "which rules is that Runtime actually running?"
The Control Plane answers those questions without changing how execution works.
Data Plane and Control Plane¶
👨💻 Humans 🤖 AI Agents ⚙️ CI/CD
│
▼
Engineering Runtime ← Data Plane
(policy evaluated locally,
audit written locally)
│ optional, over HTTPS
▼
Control Plane ← Governance Plane
(publish policy, collect
audit, observe the fleet)
│
▼
Dashboard • Fleet • Policies • Audit
The Data Plane executes. The Control Plane observes and distributes.
Execution never travels through the Control Plane.
What the Control Plane does¶
| Function | What it means |
|---|---|
| Policy publishing | One policy version is published centrally, then pulled by every Runtime |
| Fleet visibility | Which Runtimes are active, and which policy version each one holds |
| Central audit | Every allow, deny, success, and failure from every Runtime in one place |
| Executor attribution | Whether an operation came from a human, a pipeline, or AI |
| Catalog | Which Providers and Engineering Capabilities the organization has |
What the Control Plane deliberately does not do¶
This list matters more than the one above.
| It is not | Because |
|---|---|
| Not a second execution path | No engineering operation runs through it, and no Engineering Capability can address it |
| Not remote policy evaluation | Policy is pulled, cached, and evaluated locally — a Control Plane outage cannot widen, narrow, or block what a command may do |
| Not a replacement for the local audit log | Audit is written locally first; the uplink is best-effort and its failure is discarded |
| Not required | The Runtime is a local binary governed by local files, and it is fully functional with no Control Plane at all |
The Runtime keeps working when the Control Plane does not.
How policy reaches a Runtime¶
Control Plane
publish policy version
│
▼
Runtime pulls it explicitly
runtime portal sync
│
▼
Cached locally in Runtime Home
│
▼
Every operation evaluated against the local cache
Distribution is central.
Evaluation stays local.
That is what keeps execution deterministic and offline-safe.
How audit reaches the Control Plane¶
Operation executes
│
▼
Audit record written locally ← authoritative, always
│
▼
Uplinked to the Control Plane ← best-effort, never blocking
A Control Plane that is unreachable cannot make a successful operation report as failure.
It also cannot lose the local trace.
The Runtime side of the contract¶
The Runtime ships the Control Plane client.
It is off by default, and it adds exactly two commands.
runtime portal status # is the client enabled, and what is it pointed at
runtime portal sync # pull the published policy and cache it locally
Policy is pulled only when you ask.
Bootstrap does not sync, and no other command syncs implicitly.
Availability
The Control Plane client is part of the Runtime today. The Control Plane server is a separate component that has not been publicly released. Leaving the client disabled costs you nothing — local governance is complete without it.
Technical details¶
This page describes the architecture.
The configuration keys, environment variables, command output, failure behaviour, and security notes live in the technical documentation.
| You want | Go to |
|---|---|
| Control Plane configuration and commands | Control Plane (Portal) |
| Policy file structure and evaluation | Policy |
| Environment variables | Environment Variables |
| Installing and bootstrapping the Runtime | Installation |
| Full technical documentation | docs.engineeringruntime.com |
Design Principle¶
Policy is distributed centrally. Policy is enforced locally.
Central governance must never become a runtime dependency.
Next¶
- Community and Enterprise — what you get locally, and what a Control Plane adds
- Why Enterprises Need a Control Plane — the full argument
- Architecture — the execution model underneath
- Policy-Driven Engineering — why policy comes before execution