DocsDiscover SovereignHow the platform fits together
Loading documentation, please wait.
NEMORIONDocsNEMORIONDocsSovereign is the shared platform behind Orbit and Workflows. Its structure is Account → Tenants → Workspaces. Each level has a different responsibility: managing the overall account, separating tenant environments, and organizing the work within them.
An Account can contain multiple tenants. A parent corporation, for example, can hold the account and host a shared Sovereign installation for its subsidiaries. The account provides the common management structure and holds the entitlements covering their use of the platform.
Account administrators can create and oversee tenants. That responsibility does not automatically make them tenant administrators or grant access to tenant content. Additional access requires the appropriate explicit grants.
A platform account is not a person's login. It is the parent of the tenants in which people work.
A Tenant belongs to an account and provides an isolation boundary for its workspaces and data. It has its own membership and administrative permissions.
To continue the parent corporation example, each subsidiary can have its own tenant, with its own tenant administrators, membership, and workspaces. Managing one subsidiary's tenant does not grant access to another subsidiary's tenant under the same account.
A Workspace belongs to a tenant. It groups related work and provides a place to define who may manage it and who may contribute to its contents.
In Orbit, workspaces organize documentation, planning, and the various units of work. A tenant can have multiple workspaces for different teams or areas of work.
Workspace management and content access are distinct permissions. Membership, direct grants, and configured inheritance determine what someone can actually see and do. Access can also be granted to individual items without opening the entire workspace.
Consider a parent corporation hosting Sovereign for two subsidiaries:
Account: Example Holdings (parent corporation)
├── Tenant: Subsidiary A
│ ├── Workspace: Product Delivery
│ └── Workspace: Internal Tools
└── Tenant: Subsidiary B
├── Workspace: Facilities
└── Workspace: Business Processes
Example Holdings operates the shared infrastructure. Subsidiary A and Subsidiary B each appoint their own tenant administrators and organize their own workspaces. They share the cost of running the platform while keeping separate tenant administration and data boundaries.
Hosting subsidiaries together can reduce duplicated infrastructure and operating costs. Each subsidiary does not need to run a separate installation simply to maintain its own tenant boundary.
The parent account still needs sufficient entitlements for all subsidiaries using it, including enough seats to cover their combined usage. Adding a tenant does not create an additional seat allowance or a separate pool of licensed capacity.
The economy of scale comes from sharing the installation and its operating costs while retaining separate tenant boundaries. It does not remove the requirement to license the account for the usage it supports.
This structure describes ownership, not automatic access. Management authority does not automatically grant permission to read every item beneath it. Authority to grant additional access is itself a separate, powerful responsibility.
Orbit and Workflows serve different purposes within Sovereign. Orbit is where people organize work and collaborate. Workflows is where they define processes that perform work across connected systems.
The account, tenant, and workspace structure sits beneath the applications. It gives them a common foundation for identifying people and services, deciding what they may access, applying licensed capabilities, and recording actions. Each application builds its own features on that foundation.
For administrators, this means the applications use the same approach to granting access and separating management from content permissions. The actions people perform differ between Orbit and Workflows, but the underlying authorization model is shared.
Auditing and observability are also platform foundations. They provide a consistent way to record who performed an action, capture its outcome, and investigate application behavior. Each application uses these shared capabilities to support its own features.
There are two places your organization interacts with Nemorion's products. The Nexus handles signup, onboarding, and your organization's license relationship with Nemorion. Your Sovereign installation is where your team uses Orbit and Workflows.
For a self-hosted customer, that installation runs on infrastructure you control. Its administrators manage the platform's accounts, tenants, workspaces, and user access there. Your team's day-to-day work happens in the installation.
Signing in to the Nexus does not automatically grant access to the installation or its contents. The installation manages its own sign-in and permissions; customer login credentials are not copied into it.
These answer three different questions:
An enabled feature does not override a person's permissions. Likewise, being an administrator does not make every licensed feature available.
Auditing records significant actions and their outcomes. Observability helps operators understand service health and diagnose problems through logs, metrics, and traces.
These are shared platform concerns. The deployment configuration, retention policy, and operational practices still matter when evaluating whether an installation meets your requirements.