Deployment Modes ​

A deployment mode defines the physical and organizational form of the network. It must not redefine object canon.

What must always be preserved ​

Any deployment mode must preserve:

• the distinction between object and record;
• the distinction between event and canonical current state;
• the separation of admission, access, and right;
• the operator boundary;
• the subordinated place of the compatible execution layer in relation to object canon.

Possible modes ​

Centralized mode ​

One operator or a tightly linked group of operators services most service roles.

Such a mode is admissible for early deployment, a pilot, or a controlled environment.

Federated mode ​

Several independent organizations service different contours, roles, or verification surfaces.

This mode is natural for inter-subject coordination.

Distributed mode ​

Service and verification roles are distributed more widely and do not depend on a single operator.

It is appropriate where it genuinely strengthens the coordination model, rather than being used as a decorative slogan.

Hybrid mode ​

Different parts of the network use different organizational and technical forms. For example, the interface layer may be more centralized, while the archival and verification layers are more distributed.

Without a separate distinction of deployment modes, any argument about the architecture quickly collapses into the false question: “Is Realith centralized or decentralized?”

For the project, that formulation is too crude. A more precise question is:

which deployment mode is used, and does it preserve the architectural invariants of Realith?