Cohesive Systems
  • Products
  • Building Blocks
  • Vision
  • Information
  • GitHub
Cohesive Systems

Contact

About

FAQ

© Cohesive Systems 2026

GitHubXLinkedIn
Cohesive Systems
/Semantic Systems Engineering
Semantic Systems Engineering
Semantic Systems Engineering

Semantic Systems Engineering

Cohesive Systems
/Semantic Systems Engineering
Semantic Systems Engineering

Semantic Systems Engineering (SSE) is a methodology for building software systems by modeling domain semantics first, and treating code, data, workflows, and UI as compiled projections of that model, rather than as primary artifacts.

A system, in SSE, is:

A declarative model of domain state, transitions, relationships, and invariants, equipped with a runtime that faithfully executes, observes, and presents that model under real-world constraints.
  • Core Principles
  • Domains Are Primary, Infrastructure Is Secondary
  • Entities Are Stateful, Normative Systems
  • Fields Are First-Class
  • Transitions Are Declarative
  • Workflows Are Multi-Entity Dynamics
  • Observations Are Projections
  • Runtime ≠ Semantics
  • Formal Reasoning Is Optional but Native
  • What SSE Is Not
  • What SSE Enables

Core Principles

Domains Are Primary, Infrastructure Is Secondary

  • The domain model is the source of truth.
  • Databases, queues, APIs, UIs, and workflows are derivations, not design drivers.
  • Infrastructure choices must preserve semantic intent, not distort it.

Entities Are Stateful, Normative Systems

  • An entity is not a DTO or record.
  • An entity:
    • Owns state in the form of fields
    • Defines valid transitions
    • Enforces invariants
    • Emits effects
  • Entities evolve through time; snapshots are observations, not identity.

Fields Are First-Class

  • A Field is the atomic unit of meaning.
  • Fields:
    • Belong to an entity
    • Carry semantics (type, constraints, derivation rules)
    • Participate in transitions and invariants
  • DTOs and records are projections of fields, not the other way around.

Transitions Are Declarative

  • State changes are specified as declarative transition rules, not imperative mutations.
  • Transitions:
    • Validate preconditions
    • Produce new state
    • Emit domain effects
  • The how (execution, retries, distribution) is separated from the what (semantics).

Workflows Are Multi-Entity Dynamics

  • Some transitions span multiple entities.
  • SSE models these as declarative workflows:
    • Coordinated decisions
    • Long-running, durable, interruptible
    • Observable and resumable
  • Workflow logic is semantic, not orchestration glue.

Observations Are Projections

  • Queries, views, DTOs, indexes, and UI models are projections of domain state.
  • Projection logic is declarative and backend-agnostic.
  • Multiple projections may coexist without duplicating domain logic.

Runtime ≠ Semantics

  • The runtime is responsible for:
    • Execution
    • Persistence
    • Distribution
    • Concurrency
    • Fault tolerance
  • The model is responsible for:
    • Meaning
    • Validity
    • Allowed evolution
  • This separation enables portability, verification, and automation.

Formal Reasoning Is Optional but Native

  • SSE is compatible with:
    • State machines
    • Temporal logic
    • Invariant checking
  • Formalism informs correctness but is not required to use the system.
  • Math validates the framework; it does not burden the user.

What SSE Is Not

  • Not CRUD-centric
  • Not DTO-driven
  • Not schema-first
  • Not framework-bound
  • Not tied to a specific language or database
  • Not “DDD with better names”

What SSE Enables

  • Durable, correct, long-running systems
  • Clear separation of problem space and solution space
  • Multiple frontends and backends from one semantic core
  • AI-authored or AI-assisted system definitions
  • Systems that remain understandable as they scale