The sovereign methodology, in three pictures.
A Standard Module Interface. A 4-Layer Permission Model. A documented anti-patterns catalog. Read the methodology — then build with the AI engine that knows it.
Section 1
The Standard Module Interface
Every sovereign module conforms to one contract. Same shape, same boundaries, same composition rules. The framework reads modules through their SMI manifest. Modules talk to each other through the SMI surface, never through each other's internals.
Modules declare identity, a role envelope, scope, endpoints, a role catalog, and a manifest. The full primitive specification — field shapes, manifest schema, endpoint contracts — is part of the Sovereign Dev Pass.
What this gives you:
- Modules can be installed and uninstalled cleanly
- The framework provides one Role Settings UI for every module
- Operators get composed access to every module the same way
- Audit logs aggregate across modules the same way
- New modules don't break old ones
Section 2
The 4-Layer Permission Model
Sovereign software is loose-coupled. The four layers are sovereign and they compose — they are not a strict hierarchy.
| Layer | What it owns |
|---|---|
| Users | Identity, auth, sessions |
| Companies | Tenancy, organizational membership |
| Workspaces | Operational units within a company |
| Modules | First-class services that compose against any of the other three |
Key properties:
- A user belongs to many companies
- A company hosts many workspaces
- Modules are sovereign — they own their data, their schema, their lifecycle
- Operators use the same permission model as customers, just with operator-mode composed in
This model is what makes "zero-touch customer expansion" possible. New users, new companies, new workspaces, new modules — all configuration, no code.
Role catalogs, capability vocabularies, and the operator-mode composition rules are part of the Sovereign Dev Pass.
Section 3
The Anti-Patterns Catalog
Seventeen documented mistakes we caught and fixed in our own production code. Every entry is a real scar — a specific class of bug we made, the cost it caused, and the fix that resolved it.
This catalog is the most valuable artifact we ship. It is the only artifact a competitor cannot fabricate — it is the scar tissue of running this methodology in production. The Sovereign Dev Pass is trained on it and detects these patterns in your codebase automatically.
Section 4
The Module Registry and Settings Retrofit
The Portal framework provides a module loader, a Role Settings UI, a tenant switcher, and an audit-log aggregator — so every module ships with these for free. Modules don't build any of it. They declare their role catalog and the framework does the rest. New modules ship faster because the boilerplate is shared.
Implementation details — the loader contract, the settings-retrofit pattern, the aggregation surface — are part of the Sovereign Dev Pass.
Section 5
What sovereign means.
We use "sovereign" deliberately. It means:
- Sovereign data — each module owns its own schema, its own collections, its own migrations
- Sovereign API — each module owns its own endpoints, talks to other modules only through declared SMI surfaces
- Sovereign lifecycle — each module can be installed, upgraded, and uninstalled independently
- Sovereign deployment — each module can run on its own Cloud Run service or its own VPC
The opposite of sovereign is what most legacy software is — tightly coupled, shared-database, can't-remove-one-piece-without-breaking-three-others.
Section 6
How the methodology compares.
| Traditional | Sovereign | |
|---|---|---|
| Data ownership | Shared monolith database | Per-module ownership, decoupled at the schema |
| Permission model | Hardcoded roles in source | Standard role catalog, capability-driven |
| Auth | One auth service for everyone | Pluggable adapter, standard contract |
| Composition | Shared imports | Manifest-driven, framework-loaded |
| Operator access | Special admin role | Composed operator mode, same model as customers |
| Audit | Centralized log | Per-module log, framework aggregation |