Coordinating Intent Over Time
Transitions define how a single entity may change. Processes coordinate change across entities and across time.
Cohesive Processes is the coordination layer of the Cohesive Systems architecture. It turns declarative transition effects into structured execution, from simple request handling to long-running distributed workflows.
This module defines coordination semantics. Execution strategy is layered separately.
- Coordinating Intent Over Time
- Where Processes Fit in the Architecture
- What a Process Is
- Core Responsibilities
- 1. Effect Consumption
- 2. Transition Orchestration
- 3. External Side Effects
- Lightweight Mode: Single-Entity Coordination
- Multi-Entity Coordination
- Durability Is First-Class, Not Mandatory
- Cohesive.Processes vs Cohesive.Processes.Engine
- Cohesive.Processes (Semantics)
- Cohesive.Processes.Engine (Execution)
- Evolution Path
- Stage 1: Lightweight
- Stage 2: Coordinated
- Stage 3: Durable
- Transactional Coordination
- Idempotency and Determinism
- Why This Architecture Scales
- Summary
- References
Where Processes Fit in the Architecture
Cohesive Systems consists of five building blocks:
- Cohesive Relations - structured observation (mapping, projection, joins, predicates, query compilation, ML feature extraction)
- Cohesive Entities & Transitions - state structure and legal change
- Cohesive Processes - coordination of change (this page)
- Cohesive Presentation - structured interaction for UI/API
- Cohesive Host - infrastructure composition and runtime wiring
Processes sit between transitions (what changed) and infrastructure (how it runs).
What a Process Is
A process is an execution unit that:
- Consumes effects produced by transitions
- Coordinates follow-up transitions
- Executes external side effects
- Optionally maintains its own coordination state
A process is not:
- A controller
- A message handler
- A workflow engine instance
- A background job
Those are execution bindings. A process defines how intent unfolds over time, independent of runtime.
Core Responsibilities
1. Effect Consumption
Transitions emit deterministic effects. Processes interpret those effects and decide:
- Which follow-up transitions to invoke
- Which external integrations to call
- Whether compensation is required
- Whether coordination state must persist
2. Transition Orchestration
Processes may:
- Invoke multiple transitions across multiple entities
- Enforce cross-aggregate invariants
- Manage ordering constraints
- Coordinate multi-step workflows
This avoids scattering orchestration logic across:
- Controllers
- Services
- Event handlers
- Background workers
Coordination is declared in one place.
3. External Side Effects
Processes may coordinate:
- Payment calls
- EDI publishing
- Email delivery
- ML inference triggers
- External API integration
Transitions remain pure. Processes manage I/O.
Lightweight Mode: Single-Entity Coordination
Many workflows are simple:
- Accept input
- Execute a transition
- Emit effects
- Handle effects immediately
In this mode, a process:
- Replaces traditional "application services"
- Runs inside an ASP.NET request
- Uses a simple transaction scope
- Requires no orchestration engine
No additional infrastructure is required. Semantics remain identical to more complex modes.
Multi-Entity Coordination
More complex workflows involve:
- Multiple entities
- Multiple transitions
- Cross-entity invariants
- Asynchronous steps
- External systems
Examples:
- Tender acceptance → Load update → Carrier assignment → Pricing recalculation
- Settlement spanning Load, Invoice, Payment
- Onboarding spanning User, Organization, Compliance
A process coordinates these transitions explicitly. Instead of implicit orchestration through event chains, coordination logic is declared and testable.
Durability Is First-Class, Not Mandatory
Processes may be:
- Ephemeral (request-scoped)
- Transaction-scoped
- Durable and resumable
- Distributed across nodes
Durability is an operational decision. When durability is enabled, processes can:
- Persist progress
- Resume after failure
- Wait for external events
- Retry idempotently
- Execute compensation logic
When durability is unnecessary, the same process model runs without orchestration overhead. Semantics do not change.
Cohesive.Processes vs Cohesive.Processes.Engine
Cohesive.Processes (Semantics)
Defines:
- Process IR
- Workflow definitions
- Effect routing rules
- Compensation policies
- Concurrency semantics
- Validation and normalization
Pure coordination semantics. No runtime coupling.
Cohesive.Processes.Engine (Execution)
Implements:
- Durable orchestration
- Checkpoint persistence
- Scheduling and timers
- Retry handling
- Concurrency coordination
- Integration with DurableTask, Orleans, or custom runtimes
Execution is replaceable.
Evolution Path
You should not need to rewrite domain semantics to evolve operationally.
Stage 1: Lightweight
- Runs inside ASP.NET
- Executes transitions synchronously
- Uses RDBMS transaction
Stage 2: Coordinated
- Introduces multi-entity orchestration
- Adds retry and compensation policies
- Emits additional effects
Stage 3: Durable
- Runs on DurableTask or Orleans
- Persists checkpoints
- Handles long-running waits
- Survives node restarts
Same transition model. Same effect model. Different execution binding.
Transactional Coordination
Short-lived workflows may rely on:
- Database transactions
- Optimistic concurrency
- Single-writer locking
Long-lived workflows may rely on:
- Versioned state streams
- Durable checkpoints
- Event-driven resumption
The semantic coordination model remains consistent across both. This eliminates the split between:
- "Simple application services"
- "Workflow engine logic"
They are the same abstraction at different operational scales.
Idempotency and Determinism
Effect handlers:
- Perform I/O
- Must be idempotent
- Must tolerate retries
State changes always occur through transitions. Processes coordinate. Transitions mutate. Effects declare intent. This preserves:
- Replay safety
- Deterministic behavior
- Clear failure handling
- Consistent audit trails
Why This Architecture Scales
Traditional systems fragment coordination into:
- Controllers
- Services
- Event handlers
- Workflow engines
- Background jobs
Cohesive unifies these under one abstraction: a process coordinates transitions across entities over time.
It may be:
- A request handler
- A transactional coordinator
- A durable saga
- A distributed actor
Same model. Different operational binding.
Summary
Cohesive Processes:
- Coordinate transition effects
- Separate coordination semantics from runtime execution
- Scale from simple request handling to distributed sagas
- Preserve determinism and idempotency
- Integrate cleanly with Entities, Relations, Presentation, and Host
- Provide a typed coordination DSL
They form the execution counterpart to the semantic model of change. Not a workflow engine. Not an application service pattern. A coherent coordination layer built on explicit semantics.
References
Cohesive Systems Overview
Cohesive Entities & Transitions
Cohesive Relations
Cohesive Host