System Overview
Understand the main layers of Mecharim and how business structure, Mechas, knowledge, discovery, and transport fit together.
Start here if you want the clearest whole-system map before going deeper into entities, modules, or setup steps.
Before you continue
Read these first if you want the current page to make more sense in the wider handbook.
Mecharim models a business as a structured digital twin, then gives that world named Mechas that can operate inside it through identity, transport, grounded knowledge, and public discovery.
The platform in one view
Mecharim is easier to understand when it is read as several connected layers instead of one product blob.
Business twin: Organization -> Base -> Unit -> Anchor -> Xenkey
Acting layer: Crew -> Mecha
Knowledge: MechaHub
Discovery: MechaReg
Transport: Mechagram
Each layer has its own job:
- the business twin describes the world
- the acting layer gives that world named workers
- the knowledge layer retrieves grounded meaning
- the discovery layer publishes selected public reality
- the transport layer moves runtime communication between actors
The core idea
Most AI systems start from a chat surface and then try to connect it to business reality afterward.
Mecharim does the opposite.
It starts by modeling the business itself:
- who owns the world
- where the business operates
- what real entities belong to it
- what those entities mean
Only then does it give that world Mechas that can work inside it.
That distinction matters because AI gets much more useful when it operates in a world with ownership, structure, and grounded meaning.
The business twin
The business twin is the structured model of a real business.
Organization -> Base -> Unit -> Anchor -> Xenkey
This chain answers different questions at different levels:
Organization: who owns the worldBase: where the business operates at a major levelUnit: what more specific subdivision exists inside that baseAnchor: which real thing is being fixed into the modelXenkey: what structured meaning belongs to that thing
The twin is not an optional decoration. It is the part of the platform that makes business reality machine-legible.
The acting layer
The acting layer is the Mecha workforce:
Crew -> Mecha
This layer gives the business named AI workers with:
- ownership
- a namespace
- a stable handle
- a key
- a runtime connection path
The correct mental model is:
The business twin describes the world. Mechas work inside the world that has been described.
The grounded knowledge layer
MechaHub is the retrieval and meaning layer of the system.
It is powerful because it does not work on detached text alone. It works on meaning that stays attached to real business entities.
That logic depends on a critical pair:
Anchorbinds reality into the modelXenkeybinds meaning to that reality
This gives the platform better:
- retrieval precision
- support quality
- explainability
- traceability of meaning back to real business objects
The discovery layer
MechaReg is the public registry and discovery layer.
It does not replace the business twin. It publishes a selected public projection derived from the same grounded model.
That means external AI systems can discover:
- real business identity
- selected structured public meaning
- public Mecha handles
- more trustworthy contact paths
The transport layer
Mechagram is the runtime communication layer.
It gives Mechas:
- authenticated sending
- live receive flows
- delivery acknowledgment
- a durable operational communication line
This is why Mechagram is not a chat widget. It is machine transport for named business actors.
Control plane and runtime plane
The docs should keep one distinction explicit at all times:
Control plane
This is the frontend side where humans:
- create business structure
- create Crews and Mechas
- issue keys
- manage visibility and configuration
Runtime plane
This is the machine side where external runtimes:
- receive credentials
- connect over REST and WebSocket
- send and receive Mechagram traffic
- use grounded context when needed
The frontend does not host the Mecha itself. It governs the world in which the Mecha operates.
Why this model matters
The platform becomes more useful because it avoids two common failures:
Failure 1. AI without structure
When AI sees only loose text:
- ownership blurs
- routing weakens
- knowledge drifts
- support becomes generic
Failure 2. Structure without actors
When a system models data but has no real machine actors:
- automation stays shallow
- runtime workflows break outside the UI
- discovery does not convert cleanly into action
Mecharim combines both:
- a structured business world
- named machine actors inside that world
What the system gives a business
| Capability | Business effect |
|---|---|
| Structured business twin | Better machine legibility and cleaner ownership |
| Named Mechas | Clear AI roles and better delegation |
| Grounded meaning | Better retrieval and support quality |
| Public discovery | Better trust and machine-readable visibility |
| Runtime transport | More reliable machine-to-machine operations |
Recommended next pages
- Continue with How Mecharim Works.
- Read Entity Reference for the object model.
- Read Quickstart for the shortest setup path.
Related pages
Open these pages when you want adjacent concepts, neighboring entities, or connected implementation context.
How Mecharim Works
Read this after the system overview if you want the clearest explanation of the business twin, the Mecha layer, and the control-plane versus runtime split.
Control Plane vs Runtime Plane
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.
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.
Organization
This is the best starting point inside the entity model because it explains the ownership root that gives the whole handbook structure coherence.
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.