Cohesive System Model

Vision

Cohesive has two linked goals:

Establish a standard language for describing systems.
Build a family of compiler-like realizations that lower that language into working infrastructure while preserving meaning.

The Markdown graph is the public source of truth for that language. It should make Cohesive building blocks traceable to well-defined concepts, and it should make important concepts precise enough to guide realization.

The model is inspired by categorical principles, including the Lawvere tradition of using category theory to organize mathematical knowledge. The practical test, however, is executable systems: semantic descriptions should be reconcilable with actors, transactions, logs, brokers, workflows, storage systems, networks, runtimes, and other infrastructure through explicit realization relations.

See system language and realization for the broader vision and process theories for the first guiding principle under active refinement.

Core Thesis

Domains can be described as cohesive system graphs composed from semantic constructs and arranged as:

Entity models with stable identities and transition models
Relation models over semantic relations
States, values, transitions, and events
Observer models for active participants
Commands and queries as observer-relative interpretations
Process graphs that compose processes, participants, decisions, and effects over time

Cohesive arranges interactions among these primitives through its system graph and qualifies that structure with operational concerns, including delivery semantics and commit boundaries. Realization maps the structure and its property demands to concrete compute, runtimes, network channels, storage systems, and infrastructure while preserving meaning across layers.

Realms of Description

0. Principles

Describe modeling disciplines used across the system model.

1. Domain Semantics

Defines the meaning-bearing constructs used to describe domain state, events, effects, values, observation, identity, behavior, processes, interactions, and transitions before assigning operational guarantees or realization mechanisms.

2. Operational Concerns

Describes the properties required for domain semantics and system-graph structure to be made executable and reliable.

3. System Graph

Organizes domain semantics into a cohesive system graph. The system graph describes placement, composition, ownership, boundaries, dependencies, graph shape, and public substrate-facing projections; it is distinct from primitive semantic definitions, operational guarantees, and concrete realization substrate.

System Graph
Entity Models
Transition Models
Observer Models
Control Models
Relation Models
Projection Models
Replica Models
Partition Models
Process Graphs, fork and join
Effect Models
Flow Views as movement views within or between process graphs
Service Models, interfaces, interaction protocols
Interaction bindings, endpoints
Messages and Envelopes, interaction channels
Routing Models, multiplexing and demultiplexing, flow operators
Business Transactions
Policy Scopes
Invariant Scopes
Boundaries
Bounded Context
Infrastructure Graph

4. Realization Substrate

Provides concrete mechanisms.

5. Architecture Practices

Contextualizes named architecture practices as cross-realm bundles of problems, constraints, and realization choices.

Domain Semantics

State

A state is the condition or configuration of a subject within a model boundary. It represents what is, relative to a subject, boundary, shape, and time or version.

State is not the same thing as the value used to read, write, transmit, or compare it. State becomes usable through values and contextualized observations produced by observables.

State does not inherently carry identity, version, or lineage. For an entity, entity state is state attributed to an identity at a version.

Entity business state, process coordination state, projection state, and execution material have different authorities even when stored together. A sparse observation must distinguish an unobserved path from absent, null, unknown, failed, and concrete values; a sparse patch becomes authoritative state only when committed.

In event-state duality:

Events carry time and change information.
States carry information and become current at a specific version/time.

For a sequential entity, state at version V is the result of applying the event that produced version V. Event-State Duality does not imply isomorphism: event histories and state histories are dual views of behavior, not interchangeable representations.

Value

A value is pure structured data. It is the concrete information used to read, write, transmit, compare, validate, transform, or carry state.

Values are identity-free, version-free, lineage-free, and timeless. A value may be empty, scalar, or composite. It may be understood through a shape and represented as a record, map, array, vector, bytes, dictionary-backed object, ordinal layout, sparse buffer, packed presence bits, columnar storage, or struct-of-arrays storage.

Representation is not semantic identity. Two values with the same logical content are the same value even if their physical representations differ.

Shape

A shape is the logical structure expected of a value, observation, state view, event payload, command input, query result, or projection result within a model boundary.

Shape is distinct from both value and representation. A value is the concrete structured data. A representation is the physical or substrate form. Shape is the declared structure under which the value can be interpreted, validated, compared, transformed, observed, or transmitted.

Observable

An observable is a probe, projection, measurement, or accessor that produces an observation from state.

Observables define how state becomes visible to an observer. Different observables may produce different observations from the same underlying state.

The current state of an entity is not itself an observable; it is state. The accessor, reconstitution procedure, projection, cache read, or subscription that exposes that current state is a current-state observable, producing an entity-scoped observation at a declared boundary, version, and consistency expectation.

Observables include field accessors, read models, metrics, sensors, UI views, policy-shaped views, derived computations, and stream subscriptions. Reactive-programming observables are one operational realization when they emit observations of state; physics offers a useful informal analogy in which an observable names what can be measured rather than the state itself.

Observation

An observation is a contextualized value produced by an observable acting on state. It is the form in which state becomes usable by an observer relative to a boundary.

An observation has:

A value (scalar, array, vector, map, record, bytes, null, or another composite)
A shape or representation (schema, projection, record layout, or optimized internal buffer)
A subject, source, or address indicating what state the value was read from or derived from
Optional context such as version, observer, source, and field-level lineage

The value inside an observation is identity-free, version-free, lineage-free, and timeless. Observation metadata supplies attribution and provenance when correctness requires it. Observations do not carry intrinsic occurrence time; time and occurrence belong to events.

When an entity is reconstituted, its current state is delivered as an entity-scoped observation. Commands are validated against observations of current entity state, related state, policy state, and environmental state. Queries request observations or values from state, projections, read models, or computations.

Entity state is a specialized observation whose subject is an entity.

Event

An event is a time-bearing occurrence carrying a value. It marks, reports, or induces change depending on how it is interpreted by an observer relative to a boundary.

Structurally, an event is a value with occurrence. Semantically, an event may be exogenous, input, command-bearing, query-bearing, endogenous, or output depending on the observer boundary.

An event answers what occurred. A command answers how a receiving observer interpreted an input event. An effect answers what modeled consequence or obligation a decision established. Domain events, requests, signals, and replies are distinct emission roles: a request creates an emitter-side response obligation, while an event does not.

Persistence events record reconstruction, audit, or storage mechanics. They are domain events only when the domain independently assigns them that meaning.

Behavior

Behavior is a time-varying value: a trajectory through state space. For an entity, behavior can be viewed as both an event schedule and a state history.

Process

A process is coherent work unfolding over time. It gives semantic unity to related observations, commands, queries, events, transitions, decisions, effects, artifacts, and participant activity.

A process is not defined by a workflow engine, scheduler, thread, transaction manager, application host, or broker. Those mechanisms may realize a process, execute one activation of it, or host one step of it. The semantic process is defined by its subject or correlation identity, participants, inputs, decisions, state or history, effects, completion meanings, and flows of movement between participants.

Processes compose when the outputs of one process become future inputs to another. Compositions may be pipelines, nested sub-processes, concurrent processes, or feedback loops.

An executable long-lived process advances through finite activations separated by quiescence or explicit durable cuts. It owns coordination state such as active tokens, waits, correlations, interaction results, compensation progress, and terminal outcome; it does not own a copied authoritative version of aggregate business state.

Interaction

Interaction names boundary-relative participation among subjects: how observers, processes, entities, or other participants affect, observe, request, notify, answer, share state with, wait for, or synchronize with one another.

Interaction is cross-realm because no single realm fully describes it. Domain semantics identifies what the participation means; the system graph arranges participants and occurrences as compositional structure; operational concerns qualify that structure with boundary-relative property claims; and realization relates the structure and its property demands to substrate mechanisms and capability evidence. These descriptions must preserve meaning across lowering, but none substitutes for another.

Under the stuff structure property lens, an interaction may be structure when it relates participants and occurrences, stuff when reified as a modeled object, or the subject of properties constraining valid interaction. The aspect being described depends on the model boundary and purpose.

Observer

An observer is a locus of interpretation: the participant, context, or execution locus relative to which values, observations, events, commands, queries, boundaries, and state acquire meaning. Every runtime participant is a potential observer, but an observer is realized only when a context supplies boundary, state view, authority, and interpretation rules.

An observer is characterized by:

Its own identity (distinct from entity identities)
Its own boundary
A realization context or logical execution context in which interpretation occurs
The ability to observe observables, producing observations of state
The ability to host, observe, route, or project entities and their events within its boundary
The ability to receive events from other observers as exogenous events

Addressability is not intrinsic to the definition of an observer. A semantic interaction can identify an intended participant or role; system-graph channels and routing models arrange the addressable path; operational concerns specify its delivery properties; and realization supplies concrete addresses and mechanisms. Some observers have globally addressable identities, such as actors. Others have transient or local identities, such as a request handler or logical execution context created for one operation.

An observer may be realized by an OS thread, logical thread, fiber, coroutine, task, actor mailbox turn, workflow activation, request handler, projection run, process step, or entity command handler. In green-thread, fiber, or async runtimes, the observer follows the logical execution context governed by a scheduler, not necessarily the OS thread.

Actor systems make observers addressable: an actor address gives other observers a delivery path to a receiving observer boundary. Entities and processes can also be modeled as observers; in that model, inputs are interpreted relative to their own state, history, policies, and boundary.

Events, commands, and queries are observer-relative interpretations: an event that is endogenous to one observer may be exogenous to another, and the same incoming observation may be interpreted differently (or rejected) depending on the observer’s current view of entity state, projection models, required observations, invariants, policies, authority, and consistency expectations.

Entity

An entity is an enduring, identifiable subject whose state evolves over time under controlled transitions.

An entity is defined by:

A stable identity that persists across its lifetime
A family of entity-state observations across time, indexed by version
A current state at any point in time, attributed to identity + version
Transitions that define how its state may change
Invariants and policies that constrain valid changes
Effects, including transition effects, endogenous events, and publication, request, signal, or reply obligations established by accepted transitions

An entity is therefore state + identity + version history + transitions + invariants + policies + effects.

Entity state is a specialized observation: a shaped value attributed to an entity identity at a version. It may be complete or partial only relative to a declared shape, projection, transition, or boundary. Related entities, policies, projections, and environmental facts that affect a transition belong to the transition context, not automatically to the entity's own state.

An aggregate authority boundary may span several physical records, while independently authoritative entities require process coordination. Evaluating a transition produces a decision; only a successful commit establishes the transition effect and authoritative new state.

Identity is what allows a sequence of state observations to be understood as successive versions of the same thing.

An entity is not automatically an observer, but it may be modeled or realized as one when it interprets inputs relative to its own state and boundary. Correct entity transitions require the interpreting observer to remain aligned with the realization context that commits the transition: actor hosting can provide this through serialized message handling, while stateless request handlers usually require expected-version checks.

Transition

A transition is a deterministic semantic decision relation over one subject or aggregate boundary. It consumes typed input and finite explicit observations and produces a typed outcome, sparse patch, emissions, movements, trace, and guarantee demands.

transition definition + input + observations
  -> transition decision
  -> capability-checked commit
  -> authoritative state effect and durable obligations

The decision does not commit state. Portable transition structure is finite and acyclic and contains no hidden I/O, waits, retries, service lookup, or arbitrary callbacks. Transition models arrange this structure in the system graph, and concrete interpreters and storage mechanisms realize it.

Effect

An effect is a modeled consequence or obligation established by a semantic decision. Effect declaration, accepted responsibility, local commit, physical attempt, acknowledgment or result, and downstream interpretation are distinct boundaries.

A domain-event emission creates no response obligation. A request identifies an intended receiver and creates a typed terminal-response or terminal-failure obligation. A signal also identifies an intended receiver but creates no response obligation, and a reply discharges one admitted request. Effect handlers are impure realization adapters; they do not become semantic authority or mutate authoritative entity state directly.

Command

A command is the interpretation of an event by a given observer as an attempted transition of a target subject.

Relative to the interpreting observer, the event is an exogenous input event. Relative to the emitter, the carried event is an endogenous output event. A message contract may express singular command intent toward an understood observer, making command interpretation expected and operationally unambiguous. The semantic command remains observer-relative because the receiver must admit and interpret the input in context.

Endogenous output event at an emitter boundary
  -> exogenous input event at an interpreting observer boundary
  -> attempted transition, relative to the observer and target subject
  -> validation against current entity state + required observations + invariants + policies + authority + expected version
  -> typed applied, no-change, alternate, conflict, or rejection outcome

Commands are not mere messages. They are interpretations made relative to:

The specific observer
The observer’s boundary and current view of state
Authority, invariants, and policies
The intended transition
An optional expected version or ETag carried by the input event

The expected version ordinarily represents the emitter's observation of entity state when it formed its request. The receiving observer decides whether that claim is relevant and validates it before accepting the transition.

Query

A query is an observer-relative interpretation of an input event as a request to observe, compute, or return information without requesting a modeled semantic state transition.

Exogenous input event at an observer boundary
  -> query intent (relative to the observer and target subject or view)
  -> selection of observable + projection + read model + authority + consistency expectation
  -> observation | value | stream | nil | rejection

Queries are not mere messages. They are interpretations made relative to:

The specific observer
The observer's boundary and current view of state
The requested observable, projection, read model, or computation
Authority, access policy, and disclosure rules
Freshness, ordering, and consistency expectations

Operational state may still change while serving a query, but the modeled semantic entity transition is not being requested.

Dualities

Events -> State
  Fold or integrate committed events to produce a state sample at a new version.
 
State -> Events
  Observe differences, transitions, or threshold crossings in state samples and emit new Events.
 
Events -> Behavior
  Fold, integrate, scan, switch, or transform event streams through an observer-defined accumulator to produce time-varying values.
 
Behavior -> Events
  Sample, detect changes, or detect crossings in Behavior and emit Events.

Persistence chooses which view is made durable:

Current state records as observations
Event history
Behavior samples
Workflow history
Projection state (derived observations)
Derived observations

Exogenous and Endogenous Events

Relative to an observer’s boundary:

Exogenous event: An event arriving from outside the observer’s boundary. It may originate from another observer’s endogenous event, a runtime, a clock, a user, a sensor, or the external environment.
Input event: An exogenous event in the role of entering the observer boundary.
Command: The receiving observer's interpretation of an input event as an attempted transition for a target subject.
Query: The receiving observer's interpretation of an input event as a request to observe, compute, or return information without requesting a modeled semantic state transition.
Endogenous event: An event that occurs or is accepted within the observer’s own semantic history.
Output event: An endogenous event emitted across a boundary.
Applied no-change outcome: The input was admitted but the accepted decision changed no entity value. The outcome is not an event.

Some systems may still record audit, telemetry, or diagnostic events when interpretation yields no change or rejection. Those records are operational traces or events for another subject, not a committed domain transition for the target entity.

Interpretation flow:

Exogenous event
  -> input event
  -> command | query (observer-relative)
  -> validation or observation selection
  -> typed transition outcome | observation | value | nil query result

Examples of explicit no-change or alternate transition outcomes include duplicate input whose domain effect was already committed, a valid no-op against current state, and telemetry-only or correlation-only input. Failed validation and failed authority are rejections; an expected-version mismatch is a concurrency conflict.

One observer’s endogenous event may become another observer’s exogenous event.

Commands (Expanded Flow with Versioning)

A command may carry an optional expected version / ETag based on the emitter's observation of entity state when it formed the request. The receiving observer interprets and validates that claim.

The entity transition interpreter, aligned with the interpreting observer, evaluates the definition against current entity state, required observations, invariants, policies, authority, and expected version. It produces a typed transition decision. A storage or runtime realization then validates the commit demands and either commits the patch and local obligations, reports a concurrency conflict, or reports another explicit failure.

Operational Concerns

Persistence

What is recorded as authoritative material?

Current-state records (as entity-scoped observations)
Event histories
Outbox records
Inbox and deduplication records
Actor state providers
Workflow histories
Process execution histories, checkpoints, timers, signals, and pending work
Process state
Projection state (derived observations)

Durability

Which facts, histories, effects, decisions, or execution material survive which failures?

Declare the failure boundary and fate-sharing assumptions
Protect state, histories, decisions, timers, acknowledgments, and recovery material
Preserve enough material for reconstitution, replay, retry, repair, or audit
Distinguish local durability from end-to-end completion
Bind the claim to explicit storage, replication, log, queue, acknowledgment, or commit boundaries

Reconstitution

How is usable state recovered?

Load latest record → produce an observation
Replay events → fold into a current state sample
Load snapshot + events
Reconstitute process execution state, checkpoints, or workflow history
Activate actor by identity
Rebuild projection as a derived observation

Delivery Semantics

What guarantees does an interaction edge provide?

At-most-once / at-least-once / effectively-once within a defined boundary
Ordered per key
Durable / volatile delivery
Replayable / retained
Deduplicated
Requires idempotent receiver
Explicit acknowledgment meaning

Coordination

How is multi-step or multi-participant work made coherent across observers?

Local transaction
Distributed transaction / transactional outbox
Transactional inbox or idempotent receiver
Saga with compensation
Durable execution practice with resume
Choreography through events
Process manager
Projection update protocol

Control

What constrains execution?

Optimistic concurrency (via expected version)
Pessimistic locking / fencing tokens
Actor identity serialization
Retries, rate limiting, and flow control and backpressure
Idempotency

Protocol Layering and Space

Guarantees are always relative to a semantic space and an observer’s boundary.

Addressing space: What kind of thing is addressed? (Entity, observer, actor, etc.)
Message space: What unit is delivered or interpreted? (Observation, event, command, query)
Acknowledgment space: What has actually been accepted, persisted, processed, or committed?
Ordering space: Ordered relative to which key, stream, partition, actor, or transaction?
Failure space: What boundary can fail independently?

None of these automatically mean “the business transition committed” unless the observer’s application semantics define that boundary.

Runtime

Realization is the relation by which domain semantics, system graph, operational concerns, and architecture practices are made concrete in a substrate. Realization is layered: a substrate at one layer can itself be modeled as semantic structure realized by lower-level substrate. Runtime is part of the realization substrate. An actor system, ASP.NET host, workflow engine, durable execution engine, broker, or database can realize operational concerns and architecture practices, but those concerns and practices should be described separately from any specific runtime.

Different runtimes realize observers differently (e.g., actor placement and supervision vs. HTTP request pipeline), while the semantic model (observer, entity, observation, event, command, query) remains consistent. In async, fiber, or green-thread runtimes, the observer follows the logical execution context rather than a fixed OS thread.

Cohesive Role

Cohesive preserves correspondence across realms:

Semantic description (State, Observation, Event, Observer, Entity, Process, Interaction, Relation, Command, Query, ...)
  -> System graph (Entity Models, Observer Models, Relation Models, Projection Models, Process Graphs, Flow Views, Interaction Channels, Boundaries, Infrastructure Graph, ...)
  -> Operational concerns (Persistence, Durability, Reconstitution, Delivery, Acknowledgment, Ordering, Coordination, Recovery, Control)
  -> Realization substrate (Realization, Compute, Runtimes, Network, Storage, Workflow engines, Durable execution engines, Actor systems, ...)

It lets a domain be modeled in terms of entities, observers, states, observations, events, commands, queries, relations, interactions, and processes, arranges them in a system graph, and realizes them as operational systems running on existing infrastructure while maintaining fidelity across layers and across different observers.

Architecture Practices contextualize named industry patterns and methodologies as cross-realm bundles of problems, constraints, and realization choices expressible in Cohesive terms.