Cohesive Systems logoCOHESIVE SYSTEMS
Knowledge GraphOverview

Cohesive System Model

Core Thesis

Domains can be described as semantic system graphs composed of:

Cohesive operationalizes these primitives by assigning persistence, reconstitution, interaction, delivery, acknowledgment, commit, coordination, and control semantics, then realizes them through concrete compute, runtimes, network, storage, and infrastructure components while preserving coherence across layers.

Realms of Description

0. Principles

Describe modeling disciplines used across the system model.

1. Semantic Dynamics

Describes change, time, observation, and participation.

2. Operational Semantics

Describes how semantic dynamics are made executable and reliable.

3. System Structure

Organizes semantic dynamics into a system graph. System Structure describes placement, composition, ownership, boundaries, dependencies, and graph shape; it is distinct from primitive semantic definitions and concrete realization substrate.

4. Realization Substrate

Provides concrete mechanisms.

5. Architecture Practices

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

Semantic Dynamics

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.

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 with 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.

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.

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 of an observer is an operational concern (part of interaction and delivery semantics), not intrinsic to the definition. 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 when they interpret inputs relative to their own state, history, policies, and boundary.

An endogenous event emitted inside one observer’s boundary can be observed as an exogenous event by another observer.

Commands and queries are observer-relative interpretations: the same incoming value or event may be interpreted differently (or rejected) depending on the observer’s current view of entity state, projections, 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, primarily the endogenous events it produces when transitions are committed

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.

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.

Command

A command is an observer-relative interpretation of an input event or incoming value as an attempted transition.

Exogenous event
  -> input event at an Observer [[Boundaries|boundary]]
  -> command intent (relative to the Observer and target subject)
  -> validation against current Entity state + required observations + invariants + policies + authority + expected version
  -> endogenous event | nil

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 / etag (the version of entity state the observer believed was current when formulating the command)

Query

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

Exogenous event or incoming value
  -> input at an Observer [[Boundaries|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: An input event interpreted as an attempted transition for a target subject.
  • Query: An input event or incoming value interpreted as a request to observe, compute, or return information without requesting a modeled semantic state transition.
  • Endogenous event: An event committed within the observer’s own semantic history (emitted by an entity it hosts).
  • Output event: An endogenous event emitted across a boundary.
  • Nil endogenous event: The observer observed the input but no domain transition event was committed for the target entity (version unchanged).

Some systems may still record rejection, audit, telemetry, or diagnostic events when interpretation yields nil. 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
  -> endogenous event | observation | value | nil

Examples of nil:

  • Duplicate input
  • Failed validation or precondition
  • Unauthorized request
  • Version conflict (expected version mismatch)
  • Telemetry-only or correlation-only signal

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

Commands (Expanded Flow with Versioning)

A command carries an optional expected version / etag — the version of entity state the observer believed was current when it decided to issue the command.

The entity transition runtime, aligned with the interpreting observer, performs:

  • Validation against current entity state + required observations + invariants + policies
  • Expected version check (if provided)
  • Decision: commit endogenous event → new state version, or reject → nil (version unchanged)

Operational Semantics

Persistence

What is made durable and authoritative?

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

Reconstitution

How is usable state recovered?

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

Interaction

How do observers address, observe, notify, or invoke one another?

  • One-way send
  • Request/reply
  • Publish/consume
  • Stream/session
  • Shared-state interaction
  • Synchronization/rendezvous

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?

Durable Execution

How does process execution remain coherent across failure, restart, suspension, timeout, or delayed external work?

  • Persist execution state, history, checkpoints, timers, signals, or pending work
  • Reconstitute usable process context after interruption
  • Resume, replay, retry, compensate, or escalate without changing semantic history
  • Preserve idempotency at effect boundaries
  • Preserve commit boundaries and acknowledgment meanings
  • Bind the guarantee to an explicit execution boundary

Control

What constrains execution?

  • Optimistic concurrency (via expected version)
  • Pessimistic locking / fencing tokens
  • Actor identity serialization
  • Retries, rate limiting, 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 semantic dynamics, system structure, and operational semantics 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 semantics, but the semantics 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 dynamics (State, Observation, Event, Observer, Entity, Command, Query, ...)
  -> System structure (Entity Models, Observers, Relations, Projections, Flows, Boundaries, ...)
  -> Operational semantics (Persistence, Reconstitution, Interaction, Delivery, Coordination, Durable Execution, 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, and flows, then projects those primitives into operational systems running on existing infrastructure while maintaining semantic 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.