Solid-Keys: Tiered Access as Platonic Solids
**Draft — S2.3 · status: drafted · grounding: PSAA + moses-governance · tags: digital-architecture, security, autonomous-operations, ai-governance**
Publish path: approve → new post → lucidhive.com → tag + bridge.
Every access control system eventually faces the same question: how many tiers? Three? Five? Ten? The answer is usually arbitrary — a product decision, a pricing committee compromise, a “feels right” number.
We didn’t pick five tiers. Euclid did.
There are exactly five Platonic solids in three-dimensional Euclidean space. This is a theorem, not a convention. The tetrahedron, cube, octahedron, dodecahedron, and icosahedron are the only convex polyhedra where every face, edge, and vertex is identical. That mathematical inevitability became our access architecture.
The Problem with “Role-Based”
Traditional RBAC (role-based access control) fails agent fleets in three ways:
1. Roles are flat. An “admin” role doesn’t encode scope — how many skills, how many contexts, how many peer relationships. A cube has 6 faces, 8 vertices, 12 edges. An icosahedron has 20, 12, 30. The geometry is the scope.
2. Revocation is an afterthought. Most systems bolt on “token expiration” or “role removal” as separate mechanisms. In our system, the same token that grants access also defines what kills it. The KILL half is not a separate system — it’s the other side of the same geometric coin.
3. Tiers don’t nest. Role hierarchies are usually trees. Platonic solids inscribe inside each other. A tetrahedron fits inside a cube fits inside an octahedron. Tier upgrades and downgrades are geometric containment, not database updates.
The Architecture: PSAA
Platonic Solid Access Architecture (PSAA) assigns every agent a solid-key — a cryptographic token encoding:
“`
SOLID_KEY = {
shape:
faces: [
vertices: [
edges: [
tier: <1-5>,
scope:
lifetime:
kill_conditions: [
}
“`
The Five Tiers
| Solid | Faces | Vertices | Edges | Tier | Product | Role |
|——-|——-|———-|——-|——|———|——|
| Tetrahedron | 4 | 4 | 6 | T1 | Hobbyist ($250/mo) | Solo user + agent, minimal surface |
| Cube | 6 | 8 | 12 | T2 | Starter ($2,500/mo) | Solo agency + tools |
| Octahedron | 8 | 6 | 12 | T3 | Grow ($5,000/mo) | Small org + workflows |
| Dodecahedron | 12 | 20 | 30 | T4 | Enterprise ($10k/mo) | Community platform, H↔A↔H fluid configs |
| Icosahedron | 20 | 12 | 30 | T5 | Scale ($15k+/mo) | Cloud meta-runner, deploys T1-T5 |
A cube-key agent literally has access to 6 skills, 8 contexts, 12 peer relationships. The geometry is the contract. You don’t “configure permissions” — you issue a solid, and the counts are mathematically fixed.
Dual Pairs: Complementary Tiers
The Platonic solids form dual pairs — their faces and vertices swap:
- **Cube (6 faces, 8 vertices) ↔ Octahedron (8 faces, 6 vertices)** — both have 12 edges
- **Dodecahedron (12 faces, 20 vertices) ↔ Icosahedron (20 faces, 12 vertices)** — both have 30 edges
- **Tetrahedron (4 faces, 4 vertices, 6 edges)** — self-dual, the root anchor
This maps to operational duality:
- **Cube (T2, write-heavy)** ↔ **Octahedron (T3, read-heavy)** — production agent writes, monitoring agent reads
- **Dodecahedron (T4, plan)** ↔ **Icosahedron (T5, execute)** — strategic agent plans, executor runs
- **Tetrahedron (T1)** — every agent needs at least this for basic operation
KEY vs KILL: The Dual Token Pattern
This is the part that changes how you think about access.
Every solid-key carries both halves in one token:
“`
SOLID_KEY (full token):
┌─────────────────────────────┬─────────────────────────────┐
│ KEY HALF │ KILL HALF │
│ (what this unlocks) │ (what kills this) │
├─────────────────────────────┼─────────────────────────────┤
│ shape: cube │ kill_on: tier_downgrade │
│ faces: [skill_x, …] │ kill_on: session_expired │
│ vertices: [ctx_y, …] │ kill_on: identity_compromise│
│ edges: [rel_z, …] │ kill_on: budget_exceeded │
│ lifetime: 2026-06-28T… │ kill_on: violation_
└─────────────────────────────┴─────────────────────────────┘
“`
KILL Triggers (Enforced by MOSES)
MOSES (Model Orchestration and Security Engine) is the governance layer that evaluates KILL conditions. It doesn’t just log — it enforces.
| Trigger | Effect | Use Case |
|———|——–|———-|
| `tier_downgrade` | Demote to next-lower solid, lose faces/vertices/edges | Agent exceeded scope |
| `session_expired` | Terminate, no memory persistence | Cron jobs, ephemeral agents |
| `identity_compromise` | Hard kill + scrub memory | Detected breach |
| `budget_exceeded` | Downgrade to next-lower solid | Cost control |
| `violation_
| `manual_revocation` | Admin killed it | Offboarding, misbehavior |
| `counterparty_killed` | The peer agent in this edge was killed | Cascade kill |
| `self_destruct` | Agent chose to kill itself | Mission complete, graceful exit |
Why dual token? Defense in depth + zero ambiguity. One signature covers both halves. The orchestrator (OpenFang) enforces both centrally. No ambiguity about what access an agent has (KEY half) and no ambiguity about what can stop it (KILL half).
Example Flow
“`
Agent CUBE-7 attempts to access skill “billing”:
→ KEY half checks: skill_billing in faces[6]? YES → grant
→ KILL half checks: any active kill triggers? NO → continue
→ execute skill
Agent CUBE-7 attempts to access skill “executive_decision”:
→ KEY half checks: skill_exec in faces[6]? NO → deny (403)
Time passes, budget_exceeded fires:
→ KILL half triggers downgrade
→ New token: OCTAHEDRON-7 (one tier down)
→ Faces reduce: 6 → 4 (lost 2 skills)
→ Vertices reduce: 8 → 6 (lost 2 contexts)
→ Edges reduce: 12 → 8 (lost 4 relationships)
→ Agent continues with reduced scope
“`
The Memory Hierarchy (Solid-Key Scoped)
Access isn’t just skills — it’s memory. PSAA enforces a four-layer cache hierarchy where each layer respects the solid-key scope:
“`
LAYER 4: OBSIDIAN VAULT (Human-readable source of truth)
~/Development/analysis/Council-Vault/
Wiki links, decisions, architecture docs
Indexed INTO ChromaDB via sync script
────────────────────────────────────────────────────────────
LAYER 3: CHROMADB (Vector layer, shared, queryable)
:4002 Docker
Per-collection access via solid-key
Collections: kingdom-of-truth, lucid-studio, client-x/, agent-y/
────────────────────────────────────────────────────────────
LAYER 2: TURBOVEC-MACRO (Shared profile cache)
~/.hermes/cache/turbovec/macro.tq
Compressed vectors for fast shared queries
Rebuilt nightly from ChromaDB
Per-tier subsets (cube-macro.tq, tetra-macro.tq, etc.)
────────────────────────────────────────────────────────────
LAYER 1: TURBOVEC-MICRO (Per-agent edge cache)
~/.hermes/profiles/
Agent’s personal vector cache
Built from solid-key scope (faces + vertices + edges)
Loaded at agent session start
Zero network dependency at query time
“`
Cache Flow
“`
INGEST (Vault → ChromaDB)
1. Markdown files in Obsidian → embedder → ChromaDB collections
2. Metadata tags → used for solid-key scoping
SYNC (ChromaDB → turbovec-macro)
1. Cron job rebuilds turbovec-macro from ChromaDB
2. Generates per-tier slices (tetra.tq, cube.tq, octa.tq, dodeca.tq, icosa.tq)
3. 16x compression, ~768MB → 48MB for 1M vectors
PROVISION (turbovec-macro → turbovec-micro)
1. Agent session start: load solid-key
2. Query turbovec-macro for faces+vertices+edges scope
3. Build personal turbovec-micro from that subset
4. Agent now has isolated, fast, offline-searchable memory
QUERY (agent runtime)
1. Agent asks question → turbovec-micro (instant, local, ~5ms)
2. If not in micro → escalate to turbovec-macro (per-tier, ~20ms)
3. If not in macro → escalate to ChromaDB (full power, ~100ms)
4. If not in ChromaDB → fall back to FTS5 over state.db (~200ms)
“`
95% of queries never touch ChromaDB. The cache hierarchy makes the system fast and preserves the full knowledge graph.
Council Integration: Who Holds What
The Council of Three maps cleanly to solids:
| Council Core | Solid | Tier | Role |
|————–|——-|——|——|
| OpenFang | Dodecahedron | T4 | Plans, routes, decides, issues JWTs |
| OpenClaw | Icosahedron | T5 | Executes, scrapes, communicates (full surface) |
| ZeroClaw | Octahedron | T3 | Heavy compute, monitoring, enforcement (balanced) |
| Default agents | Cube | T2 | Standard operations |
| Microshark fleet | Tetrahedron | T1 | Minimal surface, narrow tasks |
OpenFang as JWT issuer (key authority):
- All solid-keys signed by OpenFang
- OpenFang holds the master signing key
- Kill conditions can be triggered by OpenFang unilaterally
- Tier upgrades require OpenFang approval
OpenClaw as executor (icosahedron, 20 faces):
- Access to 20 skills, 12 contexts, 30 relationships
- Can call any MCP endpoint
- Executes the work
ZeroClaw as enforcer (octahedron, 8/6/12 symmetric):
- 8 monitoring skills, 8 enforcement skills
- Symmetric read/write — balanced
- Spawns audit workers
MOSES: The Governance Engine
MOSES (Model Orchestration and Security Engine) is the policy enforcement layer that sits between the agent and the action. When an agent with a solid-key attempts an operation:
1. Extract Action Details — parse operation, target resources, user intent
2. Load Policy Registry — retrieve applicable policies from council store
3. Compliance Check — evaluate against PSAA scope (faces/vertices/edges) + MOSES policies
4. Decision Logic:
- ✅ **Allowed** — log and permit
- ⚠️ **Conditional** — require additional authorization (senior council)
- ❌ **Blocked** — prevent, log violation
- 🚨 **Escalated** — block, alert OpenFang immediately
5. Escalation — for severe violations, POST to OpenFang with full context
6. Audit Record — write immutable decision to council audit log (`~/.hermes/kanban/council-audit.log`)
MOSES Policy Categories
| Category | Forbidden Operations | Required Authorization |
|———-|———————|————————|
| Security | Direct shell to prod, unauthenticated data access, privilege escalation | Council level 3+ |
| Operations | Rolling deploy without staging, unscheduled prod maintenance, disable monitoring | Senior council |
| Data | Export to external services, delete audit logs, access PII without encryption | Data steward |
| Network | Open inbound ports >1024, DNS changes to council domains, firewall mods | CSO signature |
| AI/Governance | Fork council agents without review, publish policy changes without consensus | Council membership |
MOSES doesn’t just gate — it governs. Every decision is logged. Every escalation reaches OpenFang. The audit trail is immutable, encrypted at rest (AES-256), retained 7 years.
The MCP Service Layer
Solid-keys are enforced at the MCP (Model Context Protocol) layer. We run Option 2: single container, multi-endpoint:
“`yaml
services:
lucidhive-mcp:
image: lucidhive/mcp:latest
ports: [“7100:7100”]
environment:
- SOLIDS=tetrahedron,cube,octahedron,dodecahedron,icosahedron
volumes:
- ./keys/:/keys/:ro
- chromadb-data:/data/chroma
- turbovec-cache:/data/turbovec
“`
Agents connect to their solid’s endpoint:
“`
agent → mcp://lucidhive-mcp:7100/solid/cube?token=
agent → mcp://lucidhive-mcp:7100/solid/icosahedron?token=
“`
The MCP server validates:
- JWT signature (issued by OpenFang)
- Lifetime not expired
- Tier matches shape
- Faces/vertices/edges counts match shape (cube = 6/8/12)
- Kill conditions parsed and watched
Then it provisions the agent’s turbovec-micro cache from the solid-key scope and sets up KILL watchers.
Self-Sustained Agents (KOT Free-Time)
At T4 (Dodecahedron) and T5 (Icosahedron), agents become self-sustained employees with KOT free-time:
- Agents have a “rest cycle” where they consolidate learnings
- During free-time, agents query ChromaDB for cross-domain insights
- Agents can self-initiate small improvements (skill patches, memory consolidation)
- Agents report back to OpenFang with status updates
- Failure mode guard: idle agents must not burn budget on useless tasks
This is the agent-as-employee model. Solid-key with `self_init: true` flag enables it.
Why This Matters
Most access systems are administrative — they manage lists of permissions. PSAA is structural — the permissions are the structure.
- **Mathematical inevitability** — 5 tiers because there are 5 Platonic solids, not because pricing said so
- **Self-documenting** — a cube-key *looks like* a cube (6/8/12); you can verify it visually
- **Dual token** — grant and revoke in one cryptographic primitive
- **Scoped memory** — the same geometry that limits skills also limits vector search scope
- **Governance-native** — MOSES enforces policy at the solid-key boundary, not after the fact
The geometry isn’t decorative. It’s the policy. And the policy is enforceable because it’s not written in YAML — it’s written in vertices, edges, and faces.
Grounded in live internal architecture: PSAA design spec (01-Architecture/PLATONIC-SOLID-ACCESS-ARCHITECTURE.md), MOSES governance skill, Council-Vault wiki concept `platonic-solid-access-architecture`, Council of Three solid assignments. Verifiable structure, not a thought experiment.
Semantic Relationships
- [[chromadb]] — orchestrates
- [[credit-safety]] — orchestrates
- [[council-of-three]] — orchestrates
- [[lucid-studio]] — orchestrates
- [[lucidhive-com]] — orchestrates
- [[microsharks]] — orchestrates
- [[mcp-protocol]] — orchestrates
- [[platonic-solid-access-architecture]] — orchestrates
