Control Plane vs Runtime Plane
Understand the boundary between the human control surface and the live Mecha runtime, and why that distinction keeps the system legible and governable.
This page explains one of the most important operational distinctions in Mecharim, humans define and govern the world in the control plane, while Mechas act through external runtimes in the runtime plane.
Before you continue
Read these first if you want the current page to make more sense in the wider handbook.
The frontend is the control plane. The live Mecha process runs in the runtime plane. Those two planes cooperate, but they should not be confused.
Why this distinction matters
Many systems blur configuration, governance, and live execution together.
That makes it harder to answer:
- who defines the structure
- who owns the actor
- where credentials live
- where the live process is actually running
Mecharim is stronger because it separates those roles cleanly.
The control plane
The control plane is the human-governed surface where the business defines and manages the system.
This includes:
- organization context
- business structure
- crews and Mechas
- key issuance
- publication decisions
- governance and review
The control plane is where humans shape the world.
The runtime plane
The runtime plane is where the external Mecha process actually runs and handles live traffic.
This includes:
- authenticated runtime connection
- REST send flow
- WebSocket receive flow
- ACK handling
- live message processing
The runtime plane is where the actor operates.
The clean relationship
The correct sequence is:
- humans define the world
- humans define the actor
- humans issue the credential
- the runtime connects and acts
This keeps the system explainable.
What breaks when the distinction is ignored
If the two planes are collapsed together:
- governance becomes blurrier
- ownership becomes less obvious
- runtime becomes harder to secure
- setup becomes harder to teach
- the whole model feels more like “one bot somewhere”
That is exactly what Mecharim is trying not to be.
How this affects the reader
For operators, this distinction explains why quickstart begins in the frontend.
For implementers, it explains why key issuance and runtime connection are separate steps.
For product readers, it explains why Mecharim is a governed system, not just a chat surface with an API behind it.
Recommended next pages
- Continue with Quickstart.
- Continue with Connect a Mecha Runtime.
- Continue with Mecha.
Related pages
Open these pages when you want adjacent concepts, neighboring entities, or connected implementation context.
Registration and First Login
This is the most important stage of the whole onboarding path, because it establishes the business identity, creates the first foundational entities, and locks choices the rest of the platform will depend on.
Issue a Mecha Key
This step bridges control-plane setup and real runtime operation by issuing the credential the external process will actually use.
Connect a Mecha Runtime
This is the first live runtime step, the point where the configured Mecha becomes an operating actor connected over real transport.
Mecha
Mecha is the central operational actor of the platform, the point where identity, runtime, knowledge, and business context become one working unit.
Next reading
Use this path if you want a cleaner progression through the handbook after this page.
Quickstart
Follow this section when you want the shortest serious path from business onboarding to a live Mecha with a runtime connection.
Business Effects
This page explains the platform from the business outcome side, not only what each layer is called, but what each layer changes in practice once the stack is in place.