Cross-organization governance

A Sovereign install can host more than one organization: a headquarters and its subsidiaries, a parent company and its operating units, a holding group and the businesses it owns. Each of those organizations is a full Novantra organization in its own right - its own database, its own keyring, its own members, its own audit chain.

Cross-organization governance is the model for how those organizations relate to each other on the same install, and how policies, classifications, lifecycles, and other governance objects travel between them when you want them to.

This page explains the conceptual model, which is stable and decided. The user-facing surface (the admin pages, the publication flows, the import workflows) is being implemented in phases and most of it is not yet in the product. This page is a forward-looking guide so you can plan with the model in mind; revisit when the corresponding UI ships.

The hard rule

Organizations are sealed.

Cross-organization governance does not mean “a headquarters can read into a subsidiary’s data.” It never will. The isolation is a design rule, not a convenience:

An admin in one organization cannot see members, documents, evidence, forms, or audit entries from another organization.
The databases are physically separate.
The keys are separate.
There is no “view as” or “switch into” or “shadow” surface anywhere.

This is intentional. Cross-org governance is built on explicit package exchange between sealed organizations, not federated reads.

The shape

A Sovereign install hosting multiple organizations has three planes:

Plane	What it holds	Who reads/writes
Install	The registry of organizations, license records, install-level settings, package routing metadata. Never raw business data.	Install admins.
Each organization (tenant)	All of that organization’s business data: members, audit, forms, parties, evidence, files. Isolated.	Members of that organization.
Package exchange	Versioned, signed packages of governance objects (policies, lifecycles, eligibility rules, classifications) that one organization has published for others to consume. Routed through the install plane.	Both sides — but only what each chose to publish or import.

The install plane is the coordinator. It knows which organizations exist, what their relationships are, and which packages are in transit. It does not hold the contents of organizations.

Scope: orgs vs. scope nodes

Two concepts you’ll see used together. Easy to confuse, important to keep distinct.

Organizations

An organization is a hard isolation boundary. Separate database, separate keys, separate members, separate audit chain. The boundary you use when:

The business unit is a separate legal entity.
Data may not be visible across the boundary for regulatory or contractual reasons.
You need separate licensing and entitlement enforcement.
Cryptographic custody must be independent (different KMS keys, different storage buckets).

A modern business group with a parent company and three legally separate subsidiaries on the same install would typically use four organizations.

Scope nodes

A scope node is an operational segment within one organization. Same database, same keys, same members (with permissions), same audit chain - but separate evidence rollups, separate reporting boundaries, separate compliance tracking. The boundary you use when:

A facility, a department, or a jurisdiction needs its own evidence trail without being legally separate.
Compliance reporting needs to be split by site or region but operational data should be shared freely.
You want shared people and documents but separate “show me only the Manufacturing-Site-A audit” views.

A single subsidiary with three sites that each want their own evidence rollup would use one organization with three scope nodes.

Picking between them

Ask: “do these two groups of people need to read each other’s day-to-day data?”

Yes → one organization with scope nodes.
No → separate organizations.

You can change scope nodes inside an organization at any time. Moving data between organizations is not a routine operation — it’s a one-way migration that requires planning. Start with the right shape if you can.

How packages travel between organizations

The mechanism by which a headquarters distributes a policy, a classification taxonomy, or a lifecycle definition to its subsidiaries:

1. The source organization publishes

The source organization (typically headquarters) takes one of its governance objects — a classification taxonomy, a party lifecycle, an eligibility rule, a form template, a policy document — and publishes it as a versioned, immutable package. The package is signed by the source organization’s keyring and includes provenance (who, when, source version).

The published package lives in the source organization’s database and is referenced by the install plane.

2. The install plane routes

The install plane records that the package exists and which destination organizations it’s intended for (all subsidiaries, a named subset, etc.). It does not hold the package contents.

3. The destination organization receives a delivery notice

Each named destination receives a delivery record: “package X version Y from organization Z is available for you to import.” The delivery is durable and audited; it appears as an item in the destination organization’s incoming-package tray.

4. The destination imports — or doesn’t

The destination organization’s admin reviews the package and decides:

Accept — import a local encrypted copy of the package’s contents into the destination organization. Tagged with source provenance so you always know it came from organization Z, version Y. Local content can be referenced by the destination’s own lifecycles, forms, etc.
Override — accept the import but modify it locally. The destination keeps a reference back to the source but is no longer in sync.
Detach — accept and then sever the source link entirely. The local copy stands alone.
Pin — explicitly pin to a specific version even when newer versions are published.
Reject — refuse the import. The delivery record still exists in the audit trail.

Imports are explicit: nothing flows automatically into a destination organization without an admin act there. This is the core of the hard-isolation rule.

5. Updates work the same way

When the source publishes a new version, destinations receive a new delivery record. They can re-import (taking the new version), keep their override, keep their pin, or reject the update. Imports are never retroactive — historical evidence captured against an older version remains tied to that version.

What this enables

Once the surface is built, the model supports:

Policy distribution. Headquarters publishes its data classification taxonomy; all subsidiaries import it; the group has a consistent vocabulary without legal entities sharing data.
Lifecycle standardization. Group-wide party lifecycle definitions; each subsidiary applies them to their own parties.
Form standardization. Required onboarding forms published from headquarters; each subsidiary uses them locally with their own captured responses.
Evidence rollups. With scope nodes inside organizations and package provenance across organizations, the install plane can produce summaries like “across the install, here is the count of parties in each lifecycle state, by source policy version.”

What this does not enable

It’s worth stating clearly what the model deliberately does not allow:

Cross-org reads. Headquarters cannot view a subsidiary’s audit log, forms, parties, or evidence.
Cross-org administration. A member of one organization cannot administer another.
Cross-org user identity. A user is a member of each organization independently. There is no group-level “log in once, work in all”.
Automatic propagation. A subsidiary always has the right to refuse an imported package or override it locally. Headquarters cannot force.
Backwards data flow. Subsidiaries do not publish into headquarters by this mechanism. (Evidence rollup, which is read-only and aggregate, is a separate planned capability.)

Where this stands today

The model above is decided and documented. The implementation lands in phases:

Phase	Scope	Status
A	Single-install, single-org foundations (organizations, members, audit, lifecycles, forms, classifications).	Shipped.
B	Organization relationships in the install plane (registering “this org is the parent of those orgs”).	Spec only.
C	Catalog scope for governance objects (an object knows whether it’s `install`-scoped, `group`-scoped, or `organization`-scoped).	Spec only.
D	Package publication and import workflows (the source → install → destination flow described above).	Spec only.
E	Evidence equivalence (one evidence item satisfies multiple framework controls).	Spec only.
G	Regulator submission rollups across organizations.	Spec only.

For the moment, a multi-org Sovereign install works — you can create the organizations, give each its own admin, run each one independently. What you don’t yet have is the fabric between them. The framework above is what you can plan against.

Cloud

Cloud is structurally single-organization per customer. Multi-organization governance is a Sovereign-first capability because it presumes one install hosting multiple organizations. Cloud customers with multiple subsidiaries today operate them as separate Cloud customers; cross-organization governance for Cloud is on the longer-term roadmap.

Workspace governance — the per-organization governance hub. The objects that can be published cross-org are defined here first.
Organization — what an organization is, and why it’s a hard isolation boundary.
Sovereign Installation — how a multi-org install is stood up.