Layer Distinction 3 — CKS Is Not a Control Plane: A Standalone Treatment of the Architectural Boundary Between CKS and Control-Plane Primitives in the Coordination Knowledge Substrate Pattern

Abstract
The Coordination Knowledge Substrate (CKS) pattern is at risk of being conflated with control planes
— control-plane-layer objects that manage the operational concerns of a running coordination system:
process lifecycle, resource allocation, identity, access control, observability, and the gateway-layer
policies that determine who or what is permitted to invoke which capability under which conditions.
The conflation is common because Stevens-style operational governance work (approval gates,
reviewer workflows, accountable decision logs, break-glass override) shares the surface vocabulary of
“governance” with the human-governance commitment CKS makes, and because enterprise
deployments routinely host CKS substrates under enterprise identity-and-access-management
infrastructure. This note formalizes the architectural boundary between CKS and control-plane
primitives as having independent operational content. The boundary specifies four operational
components: different architectural questions answered, different authority objects, a
necessary-but-not-sufficient relationship between the two layers, and complementarity rather than
substitution. The note distinguishes the boundary from four adjacent control-plane variations,
enumerates the failure modes that violate it, and provides an operational test for whether a system's
architectural posture distinguishes it from a control plane.