Planes separate management intent from active execution, payload movement, and durable evidence. The separation is conceptual first; deployment may combine planes when scale and trust allow.
Key takeaways
- Control-plane unavailability should not silently change active execution policy.
- Execution workers should be replaceable without losing durable task or evidence state.
- Data and evidence require different access, retention, and minimization controls.
[ar_diagram id=”control-execution-planes”]
Control plane
Owns desired state: registries, identity mappings, tenant configuration, policy versions, quotas, routes, deployment profiles, provisioning, rollout, and lifecycle. Mutations require authenticated, authorized, auditable administration. Configuration changes should be versioned and safely rolled out.
Execution plane
Owns current work: model processes, queues, caches, sandboxes, tool adapters, and task workers. It applies a resolved configuration and emits state. Workers should hold only the credentials and data necessary for the active operation.
Data plane
Carries tensors, tokens, context, cache transfers, tool payloads, files, and domain data. It needs classification-aware routing, encryption, egress controls, size limits, and backpressure. Data-plane traces should not automatically copy full payloads.
Evidence plane
Preserves the correlation between contract, configuration, model route, tools, policy, approvals, artifacts, failures, recovery, and outcome. It should support redaction, retention, access control, integrity checks, and export for authorized review.
Plane interfaces
- Execution reads immutable or versioned configuration snapshots.
- Control receives health and capacity summaries, not unrestricted sensitive payloads.
- Evidence accepts append or correction events with stable correlation identifiers.
- Data access is authorized independently from control-plane administration.
- Plane versions and compatibility are explicit during rolling upgrades.
Plane failures
| Failure | Expected behavior |
|---|---|
| Control plane unavailable | Continue only under a valid cached configuration and bounded lease; block privileged configuration changes. |
| Execution worker lost | Cancel or replace work; resume only from durable state without duplicating side effects. |
| Data dependency unavailable | Degrade or stop according to freshness and completeness requirements; never invent missing data. |
| Evidence store unavailable | Fail closed for evidence-required work or buffer under a bounded, encrypted policy with an explicit gap record. |
Consistency between planes
The planes need an explicit consistency model. Control-plane configuration should be versioned and signed or otherwise authenticated so execution workers can report exactly which model route, policy bundle, tool registry, quota, and retention rules they applied. A worker should not silently switch to an unknown configuration when the control plane is unavailable. It may continue under a bounded cached configuration, enter a degraded mode, or stop admitting new work according to policy.
Evidence-plane writes also need semantics. For high-impact actions, the runtime may fail closed when the evidence service is unavailable. Lower-risk work may buffer a bounded event stream and reconcile later. In either case, a gap should be represented as an event rather than hidden. Data-plane payloads should carry correlation and classification metadata without assuming that every subsystem may store the raw content.
Ownership matrix
| Plane | Primary owner | Required recovery decision |
|---|---|---|
| Control | Platform governance and service owners | Cached configuration, read-only mode, or stop admission |
| Execution | Runtime and workload owners | Restart, replay, reroute, compensate, or terminate |
| Data | Domain and security owners | Retry transfer, quarantine payload, or use an approved alternate path |
| Evidence | Observability, audit, and compliance owners | Fail closed, buffer with limits, or record a durable gap |