Federation and groups, one view, regional records kept in place.

An organisation can run its twinTwinNovusLens’s model of one organisation, built from records about its teams, services and how they rely on one another. It is only as current as those records. in more than one region. A data residency rule, a regulator, or a plain preference can keep one region’s records inside that region. NovusLens supports this with one twin per region and a group that lets the regions be viewed together. The group view shows summary figures from each member. It does not read another region’s raw records.

What it is

Each twin has a home region. Each region runs a separate clusterClusterA group of computers running together as one installation. Each regional NovusLens installation keeps its own records.. Its computers exchange updates only inside that region. A group is a named set of regional twins viewed together. A member is an organisation, placed in a region.

The group view is built in PostgresPostgresThe database software that stores the tables read by the NovusLens screens, along with document bodies, access records and protected personnel records. from two kinds of input.

• Each member’s summary figures: its critical pathCritical pathThe dependency chain with the greatest total coordination weight in the map. It identifies a structural constraint. It does not state elapsed time. figures for stated and observed dependenciesDependencyA link where one unit needs something from another. A dependency is not a reporting line: it shows where work relies on something else., its evidence counts (told, shown and measured), its number of domains, and its open findingsFindingA difference in the records that needs a decision. It includes its sources and can describe a slow handoff, disputed fact or missing owner..
• Verified signed federation factsDigital signatureA check calculated with a signing key that can detect whether a record has changed. Identifying the signer also requires a trusted link between that key and its owner. for each cross-region dependency. A federationFederationSharing selected signed facts and summaries between separate regional twins, while their detailed records stay in their own regions. fact says that a cellCellA box on the map that stands for a team, service, supplier or AI agent. It is a unit you can inspect, not necessarily a department or a person. in one region depends on a capability in another.

Evidence counts use the evidence ladder. Findings are described on the findings page.

An example

Meridian Holdings is a fictional demonstration group. It has two regional twins, one in eu-west-1 and one in us-east-1. Its group view shows each member’s figures side by side, and one cross-region dependency: trading in eu-west-1 requires clearing in us-east-1. The dependency is shown with a signed badge naming its source region, eu-west-1.

The couplingCouplingA link where one team or service depends on another. Its Loose, Buffered or Rigid class describes the time needed for a handoff. between the two is marked unknown. Until it is measured, the group’s critical path across regions is partial, and the page says so. Each member’s own critical path is still its own.

How to read it

• Member figures are each region’s own. A member’s critical path is measured inside that member.
• Group fidelityGroup fidelityThe group view’s counts of recorded facts at each evidence level: told, shown and measured. The counts describe the records, not the organisation’s performance. totals are formed from each member’s own counts. They are not a new measurement.
• Cross-region dependencies appear only when a signed fact has been admitted. An unmeasured coupling is shown as unknown, never as loose or tight by default.
• The group-wide critical path is labelled partial while any cross-region coupling is unknown.

Sovereignty, and what the check proves

The design rule is that each region’s raw cells, edges and attributes stay in its own cluster. Only two things cross: the summary figures a member exposes, and signed federation facts. The group snapshot reads a member’s aggregate figures and counts, and the facts table. It does not read a member’s cells, edges or attributes. In the code, those aggregates are read from the analytical tables keyed by each member’s organisation. No separate published summary document is fetched, so the separation depends on which tables the code reads, rather than a separate transfer of published summaries.

Each federation fact is signed, but not yet with an independent identity: the signing key is derived from the region name. A fact is admitted only if its signature verifies. A fact that fails is refused with an error, not dropped silently.

Be clear about what this proves today. The region key is derived from the region’s name. The derivation is public. Anyone who knows the name can compute the key and sign a fact that passes the check. The check therefore proves that a fact was not altered after signing. It does not prove who signed it. The group view says this on every cross-region fact: the signature is valid, but the key is derived from the region name and is not an independent identity. Separate identity keys for each region are not yet in the code.

Where a group is used for board-level questions, the answer draws only on what members publish and the signed facts. It does not open a member’s internal organisation model.

Limits

• Cross-region coupling is unknown until it is measured. A group-wide critical path is partial until then.
• The signature check can detect an altered fact. It cannot establish who signed it, as explained above.
• The demonstration runs one database and one meshMeshA set of connected Mycelium services that exchange updates and keep the NovusLens log., so the separation between regions is modelled rather than physically separated. The signing, the verification and the read-path discipline are real.
• Admitting a fact into a group is the act of the operator or of the executive (cxo) of a member organisation of that group. The board and viewers from outside the group are refused.

What to do next

If you run more than one region, create one twin per region and add each to a group. Decide which cross-region dependencies to declare, and measure their coupling before you rely on a group-wide critical path.

If you are an engineer, treat the region key as a placeholder. Do not describe the signature as a security property until per-region identity keys replace the derived key.

Where it is implemented

• apps/graph/src/conway_graph/group.py holds the group read modelRead modelThe database tables used by the map, Ask and Find. NovusLens rebuilds these tables from its history of recorded changes.: create_group, add_member, ingest_fact, group_snapshot and may_read_group.
• packages/common_py/src/common_py/federation.py signs and verifies federation facts, and publishes the region’s verifying key.
• apps/graph/migrations/0007_sovereignty_federation.sql creates the groups, group_members and federation_facts tables.
• apps/reasoning/src/conway_reasoning/serve.py exposes the federation and group routes, including /federation/ingest and /group/snapshot.