Unit
Understand how a Unit works as a more specific operating subdivision inside a Base and why it improves precision, routing, and ownership.
Unit adds the finer operating layer inside a Base, which makes routing, ownership, and later Anchors much more precise.
Before you continue
Read these first if you want the current page to make more sense in the wider handbook.
A Unit is a more specific operating subdivision inside a Base. It gives the business twin a more precise layer of structure before the model reaches Anchors and Xenkeys.
What a Unit is
The Unit layer sits inside the business twin here:
Organization -> Base -> Unit -> Anchor -> Xenkey
A Unit represents a more specific operating slice inside a Base.
Examples can include:
- a store
- a lab
- a department
- a team slice
- a vehicle
- a repeated operating instance
The Unit exists so the platform can express substructure without flattening everything into one level.
Why a Unit matters
Without a Unit layer, the jump from a major Base to specific real entities can be too abrupt.
That creates weaker precision:
- similar things inside one Base become harder to distinguish
- routing becomes less specific
- ownership becomes blurrier
- repeated structures become harder to model cleanly
With a Unit layer, the system can express a clearer operational map.
How it relates to the other business layers
Organization
Organization is the ownership root.
Base
Base is the major operating node.
Unit
Unit is the more specific subdivision inside that operating node.
Anchor
Anchor fixes a real business thing into that context.
Xenkey
Xenkey attaches meaning to that anchored thing.
This order matters because each layer does one clean job instead of forcing all business structure into one generic level.
Practical examples
If retail-asia is a Base, Units might include:
store-47store-48returns-deskregional-support-cell
If warehouse-east is a Base, Units might include:
cold-storagecustoms-processingdispatch-zone-a
The point is not the label itself. The point is the operational precision the label enables.
Why it matters for Anchors and Mechas
Anchors become more useful when they belong to a more precise business context.
That helps the platform say not only:
- what the thing is
but also:
- where in the business it belongs
Mechas also benefit from Unit-level precision because:
- routing becomes cleaner
- local ownership becomes clearer
- specialized workers can operate in a narrower and more explainable context
Business effect
| Capability | Business effect |
|---|---|
| More specific subdivision | Better operational precision |
| Clearer local ownership | Better routing and less ambiguity |
| Cleaner repeated structure | Easier modeling of branches, slices, and recurring nodes |
| Better context for Anchors and Mechas | More grounded support, retrieval, and operations |
What a Unit is not
- not the ownership root
- not the major geographic node
- not the real entity itself
- not the meaning layer
It is the more specific operating subdivision that sits between Base and Anchor.
Recommended next pages
Related pages
Open these pages when you want adjacent concepts, neighboring entities, or connected implementation context.
Anchor
Anchor is one of the most important concepts in the platform because it is the point where structure stops being abstract and starts binding to something real.
Crew
Crew is the identity scope that makes Mechas addressable, groupable, and easier to govern as a real operational workforce.
Create the Business Structure
Build the world first, the platform becomes much more useful once Organization, Base, Unit, Anchor, and Xenkey exist before runtime work begins.
Next reading
Use this path if you want a cleaner progression through the handbook after this page.