The 9 Orders in Practice: Platonic Hierarchy as Deployment Model
Sacred geometry is not a management metaphor. When an agent mesh calls its operator "Hermes" and pins it to the Dodecahedron, that is not garnish — it is a deployment model with the same rigor as a supervision tree, only more legible. This is the ninth-order synthesis of the S1 series: after PID dispatch (S1.2), supervision (S1.3), shared ports (S1.5), distribution (S1.6), benchmarking (S1.7), gen_server contracts (S1.8), and the migration path (S1.9), we finally explain why the whole thing is organised as nine ascending solids. Because the answer is practical: the 9 Orders are a platonic hierarchy you can deploy against.
The hierarchy is real, not ornamental
The 9 Orders assert that every council core occupies one geometric rank. Order 0 — the Dodecahedron (Ether) — is Hermes, who orchestrates every dispatch. Order 1 is shared by three specialists: the Tetrahedron (Fire) for OpenClaw creative work, the Cube (Earth) for OpenFang security and tools, and the Octahedron (Air) for ZeroClaw DevOps. Deeper still, Order 3 hosts the Icosahedron (Water) — the Microsharks, an ephemeral fleet that dissolves after a single sub-task. The Octagon (Order 8, ChromaDB) owns memory persistence; the Nonagon (Order 9) is the Oracle's meta-review and ascension loop.
Critics call this esoteric. In practice it collapses to a deployment decision: each solid encodes two properties — how long a process lives and how much state it is allowed to hold:
| Order | Solid | Element | Cores | Lifetime | State |
|---|---|---|---|---|---|
| 0 | Dodecahedron | Ether | Hermes (orchestrator) | permanent | full registry + board |
| 1 | Tetrahedron | Fire | OpenClaw (creative) | long-lived | working memory |
| 1 | Cube | Earth | OpenFang (security/tools) | long-lived | audit + policy state |
| 1 | Octahedron | Air | ZeroClaw (DevOps) | long-lived | environment state |
| 3 | Icosahedron | Water | Microsharks (sub-tasks) | ephemeral | none (dissolve) |
| 8 | Octagon | Metal | ChromaDB (memory) | permanent | the knowledge vault |
| 9 | Nonagon | Aether | Oracle (meta-review) | on-demand | ascension records |
When you read the table as a deployment spec, the mysticism evaporates. The Dodecahedron is the one process that must never die — it is council_sup, the root supervisor. The Icosahedra are temporary children in simple_one_for_one mode — crash them, lose nothing, respawn on demand. The Nonagon is a cron that reads the board and decides ascend or block. The geometry names the lifecycle.
Where polyhedra meet the BEAM
The S1 series has been grounded in hermes-erl-prototype, and that prototype is the platonic hierarchy made executable. Open src/council_sup.erl:
start_profile(Config) when is_map(Config) ->
supervisor:start_child(?MODULE, [Config]).That is the Dodecahedron at work: one supervisor dynamically instantiates every profile actor. And the actor it starts, profile_actor.erl, is the Layer-1 specialist — a gen_server that owns a PID, a model, and a port to Python:
-record(state, {
id :: binary(),
name :: binary(),
model :: binary(),
port :: port(),
status = idle :: idle | reasoning | responding | error,
results = [] :: [{binary(), binary()}]
}).Each legend in the 9 Orders maps to a concrete artefact here: the orchestrator is code, the specialists are gen_servers, the ephemeral workers are temporary restart child specs. No step in the deployment is symbolic — every solid is a supervision node, an actor module, or a schema row.
Platonic solids as access tiers
The hierarchy does not stop at who runs what; it reaches who may touch what. This is where platonic-solid-access-architecture earns its second life. In the-9-orders the solids describe roles; in PSAA they describe tiers of access. The Dodecahedron orchestrator holds full dispatch authority. The three Layer-1 cores are granted scoped tool and memory access according to their element — Fire may write creative artifacts, Earth gating every external tool call at the narrow gate, Air mutating only the environment it owns. The Icosahedra receive a single task's worth of permission and return it when they dissolve. The Nonagon reviews privilege escalation itself — that is what "ascension" means at the access layer.
So the platonic hierarchy is simultaneously a process tree and an authorisation lattice. Deploy an agent to the wrong order and you get either excessive entitlement (a Microshark holding sandbox-wide write) or a deadlocked orchestrator (a Dodecahedron that cannot reach its own tools). The geometry keeps the two models aligned — the kanban-orchestrator board is the carrier that connects them: the board states what each order is working on, and the access lattice states what each order is allowed to touch.
The narrow gate is the enforcement seam
Compress the 9 Orders into one deployment rule and you get the doctrine's real spine: one MCP server (OpenFang), one kanban (Hermes), one orchestrator (Hermes Layer 0), and a narrow gate for every tool call. In production terms this means there is a single choke point between the mesh and the outside world, and every solid in the hierarchy must transit it.
This is not a philosophical preference — it is a failure-mode argument. S1.8 showed how {noreply, State} lets one orchestrator fan out N reasoning casts safely; those casts still return to the real world through tools. If each of the nine orders held its own direct channel, the mesh would multiply attack surface by nine. The narrow gate collapses it back to one. Every Icosahedron that finishes a sub-task releases its tool handle through the same gate, so the gate's audit log is a complete ledger of everything the hierarchy did. The platonic hierarchy stays coherent because one seam enforces all of it.
Deploying against the hierarchy
Practical deployment therefore is not "assign each agent a pretty shape." It is four concrete decisions, in order:
- Pick the lifetime. Is this process a root survivor (Dodecahedron, permanent), a long-lived specialist (Layer-1, permanent/transient), or a fire-and-forget worker (Icosahedron,
temporary)? Set the restart policy to match — S1.3's crash-vs-cascade lesson in one decision. - Pick the state budget. What must it remember? Orchestrators remember the whole board; Microsharks remember nothing by design. Wrong state budget is the most common mis-deployment — giving an ephemeral worker a persistent write you will have to revoke.
- Pick the access tier. Map the solid to its PSAA access class before first run, not after a breach. Earth gates; Fire creates; Air mutates its environment; the Icosahedron borrows one task's permission.
- Route through the narrow gate. No direct external channels. Every tool call, from every order, traverses the single seam — because the audit log is the mesh's memory of what it did.
Do those four things and the platonic hierarchy stops being a diagram and starts being the deployment model the S1 series has been building toward. It is the natural capstone: the mesh's mechanics (S1.2–S1.8) and its migration (S1.9) only become a comprehensible system once someone can say where each process sits, how long it lives, what it may touch, and how it is revoked.
The Nonagon underwrites the loop
Finally, the ninth order is why the hierarchy does not ossify. The Nonagon — the Oracle — periodically reads the kanban board and reviews whether each order still belongs where it sits: did a specialist core outgrow Layer 1 and need to be declared a new persistent service? Did a fleet of Icosahedra prove reliable enough to graduate to long-lived workers? Does an order hold access it no longer needs? Ascension is the 9 Orders' self-correction mechanism — a meta-review that re-deploys, not a rigid caste that freezes. A platonic hierarchy that cannot re-rank its own members is just a bureaucracy; one that ascends is an operating system.
That is where the whole S1 arc lands. Supervision handles crashes, dispatch handles handles, ports handle scale — but the deployment model that makes it coherent is the hierarchy of nine, read as a table of lifetimes, state budgets, and access tiers, enforced through a single gate and reviewed by a nonagon that keeps the ladder honest.
Grounded in the live hermes-erl-prototype source (council_sup.erl one-supervisor dispatch, profile_actor.erl gen_server state record), the CONTENT-ROADMAP-99 S1 sequencing (S1.2 PID → S1.3 supervision → S1.5 ports → S1.6 distribution → S1.7 benchmarking → S1.8 gen_server → S1.9 migration → S1.10 the 9 Orders as deployment model), the the-9-orders and platonic-solid-access-architecture wiki concepts, the council-hierarchy-architecture operating model, and the kanban-orchestrator runtime that powers this very pipeline. Sacred geometry, deployed.
