Skip to content

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