Five shapes. Five doors. One geometry.
The Platonic solids are the oldest known classification of perfect three-dimensional forms: tetrahedron (four faces), cube (six), octahedron (eight), dodecahedron (twelve), icosahedron (twenty). Each is regular — every face identical, every edge equal, every vertex symmetric. The ancient Greeks considered them divine because they could not be accidental. A shape that perfect must be a message.
In production systems, that message has a name: access control. And the way we currently handle it — lookup tables, conditional logic, role hierarchies buried in YAML — is the equivalent of carving sacred geometry into a spreadsheet. The shape is there, but nobody can see it.
The shape is the policy
Solid-keys invert the model. Instead of attaching permissions to a key, the key’s geometry is the permission set. A tetrahedral key has four faces and opens the four-faced door. A dodecahedral key has twelve faces and opens the twelve-faced door. No lookup. No query. No conditional branch. The gate checks the shape; the shape determines the reach.
This is not metaphor. It is architecture. In a solid-key system, each customer tier maps to a Platonic solid. The tier’s access profile is encoded as geometry — the number of faces determines the breadth of access, the symmetry determines the consistency of permissions across domains, and the volume determines the depth of state the key can modify. The tetrahedral tier gets four API surfaces. The icosahedral tier gets twenty. The shape is the policy, and the policy is visible to every layer of the stack.
The north star calls this principle 8: the esoteric is engineering. Platonic solids are not decoration for the brand deck. They are technical diagrams. The hierarchy of access is a hierarchy of form, and the hierarchy is legible to every component that encounters it — the API gateway, the service mesh, the billing system, the customer dashboard. One vocabulary, everywhere.
Why geometry beats configuration
Traditional access control has a legibility problem. A customer on “Tier 3” has no idea what Tier 3 means without reading documentation that may not exist, may be outdated, or may describe a policy that was changed three sprints ago. The relationship between the customer and their access is mediated by text, and text is lossy. The customer trusts the system, but they cannot see the system.
Geometric access is self-documenting. When the customer’s dashboard renders their key as a dodecahedron, the shape communicates scope immediately. More faces = more access. The symmetry communicates consistency: a regular solid does not have one face that grants write access and another that grants read access — the faces are identical, so the access is uniform. The customer can see what they can hold. Upgrade is not “more permissions in a database” but “a new shape with more faces.” The tier is visible, the boundary is visible, and the customer’s sovereignty — the reality with their name on it, principle 11 — is expressed as form.
From the engineering side, geometric keys eliminate an entire class of bugs. Permission-check code collapses into shape-matching code. A gate that checks “does this key’s face-count match or exceed this door’s face-count?” is deterministic, testable, and trivial to audit. There are no cascading role assignments, no inherited permissions that drift from the source of truth, no silent grants that nobody reviewed. The shape is the audit trail.
The five tiers in production
Mapping the five solids to production tiers:
Tetrahedron (4 faces) — Explorer. Read-only access to public surfaces. The smallest solid, the narrowest beam. An Explorer key can observe but not modify. In API terms: GET on public endpoints, no write access, no state mutation. The tetrahedron is stable on its base — it does not wobble. This tier is for evaluation, for trial, for the customer who is still deciding whether to commit.
Cube (6 faces) — Operator. Read-write access to owned resources. Six faces, six domains — the customer can act within their own space but cannot reach into another tenant’s geometry. The cube tiles space perfectly — it is the solid of accumulation, of building. An Operator creates, modifies, and deletes within their boundary. The cube’s symmetry guarantees that every face offers the same level of access; there is no privileged face.
Octahedron (8 faces) — Architect. Cross-domain read access with selective write. Eight faces, four axes of symmetry. The Architect can see across domains — analytics, logs, configuration — but writes only to their own. The octahedron is the dual of the cube: where the cube accumulates, the octahedron observes. This tier is for the customer who needs visibility without authority, the one who designs but does not deploy.
Dodecahedron (12 faces) — Sovereign. Full read-write across owned domains with delegated authority. Twelve faces, the solid of cosmic harmony in Platonic tradition. The Sovereign can authorize sub-keys — tetrahedral or cubic keys for team members — and revoke them. The delegation is itself geometric: a Sovereign’s dodecahedron can emit cubic children, but the children cannot emit dodecahedral grandchildren. The hierarchy is shape-locked.
Icosahedron (20 faces) — Creator. Full access, including system-level configuration and cross-tenant federation. Twenty faces, the most complex solid, the densest packing of authority. The Creator tier is for the architect who builds the platform itself — the one who sets the geometry for all other tiers. This key can modify the solid-to-tier mapping, which means it can change the shape of the access model. It is the key that writes the key system.
Legibility is the point
The entire value of geometric access collapses if the shapes are hidden. A Platonic solid locked in a database is just another permission bit with better branding. The shapes must be rendered — on dashboards, in invoices, in the API response headers, in the error messages. When a tetrahedral key hits a dodecahedral door, the 403 response should say: “Insufficient geometry. This door requires 12 faces; your key has 4.” Not “permission denied.” Not “unauthorized.” The shape is the error message. The shape is the documentation. The shape is the system.
This is the cathedral principle in action — principle 9: the sacred and the digital are the same cathedral. The Platonic solids were sacred geometry because they described the structure of reality. In production, they describe the structure of access. The cathedral is not a metaphor for the server room. The server room is the cathedral, and the geometry is the liturgy.
Building the geometry
Implementation starts with a shape registry. Each Platonic solid is defined once — its face count, edge length, vertex coordinates, symmetry group. The registry is immutable in production; changing it changes every key in the system. Customer tiers reference the registry by shape name. The API gateway checks incoming keys against the registry: shape matches door, access granted. Shape mismatches, access denied. The check is O(1) — a single lookup against a fixed table of five shapes.
The keys themselves are signed JWTs with a geometry claim: {"shape": "dodecahedron", "faces": 12, "tier": "sovereign"}. The signature ensures the key cannot be forged; the geometry claim ensures the key cannot be misinterpreted. The gateway does not need to call an authorization service. It reads the shape from the token and compares it to the door’s requirement. The entire access check is local, fast, and auditable.
Solid-keys are not a abstraction layer over existing permissions. They are a replacement for the permission model itself. The shape is the policy, the policy is the shape, and the geometry is sacred because it is engineering that you can see.
Grounded in the SECTOR9 north star principles — The esoteric is engineering, You are a reality with your name on it — and extending the S7.x security and sovereignty series theme: S7.2 solid-keys. Sector7-grounded series article, SECTOR9 50+50.
