System Graph

The system graph is the realm that composes domain semantics into the cohesive system graph of a modeled system.

It asks how semantic roles are placed, composed, owned, related, scoped, and prepared for realization once they are part of a model of a whole system. It describes graph shape: which entity models exist, which observer models interpret which boundaries, how process graphs coordinate work, which relation models connect subjects, which projection models expose derived observations, which policy scopes and invariant scopes constrain transitions, and where effects leave a boundary.

This realm sits between primitive meaning and concrete implementation:

Domain semantics defines meaning-bearing primitives such as entities, observers, processes, relations, invariants, policies, state, events, commands, and queries.
The system graph arranges those primitives into model-specific ownership, dependency, composition, authority, scope, and correspondence.
Operational concerns assign guarantees such as persistence, coordination, delivery semantics, ordering, isolation, and recovery.
Realization substrate supplies concrete mechanisms such as compute, runtimes, storage systems, brokers, and workflow engines.

Use this realm to answer questions such as:

What are the system's entity models, observer models, process graphs, relation models, projection models, and boundaries?
Which participant owns or interprets a piece of state, a transition, a policy, or an invariant?
How do observations, commands, events, effects, and artifacts move through flow views and business transactions?
Which relation models make the graph navigable, dependent, constrained, derived, or causally connected?
Where does a semantic role change meaning because it crosses a boundary?
Which infrastructure graph projection binds modeled structure to public substrate roles?
Which structural choices must later be given operational guarantees and concrete realizations?

The system graph does not by itself choose a database, broker, scheduler, workflow engine, service deployment, or runtime. Those choices belong to realization substrate. It also does not by itself assert durability, ordering, isolation, retries, or recovery. Those belong to operational concerns. Its job is to make the shape of the system explicit enough that those later choices can preserve the intended meaning.

Core system graph notes:

Secondary views and projections:

flow views