Cohesive.Processes

Why Processes Exist

Most systems already contain process logic. It is just scattered.

It appears inside:

• controller methods
• service functions
• queue handlers
• cron jobs
• integration callbacks
• retry loops
• UI state machines
• database transactions
• background workers
• migration scripts
• operational runbooks

When workflow logic is hidden this way, it becomes hard to inspect, test, resume, monitor, cancel, signal, or expose to other systems.

Cohesive.Processes makes the coordination model explicit.

A process can be generated, validated, executed, observed, resumed, projected into a UI, exposed through an API, or bound to a durable execution engine.

The Shared Model

Cohesive.Processes uses one process model for several related patterns:

• multi-transition operations
• multi-step system workflows
• scheduled jobs
• sagas
• human approval flows
• ML pipelines
• integration syncs
• agent-invokable workflows

The common shape is the same:

1. A process is started by a trigger.
2. It receives input.
3. It executes steps.
4. It may wait, branch, retry, compensate, or start child processes.
5. It records execution state.
6. It produces an output or terminal status.

The process model is the stable semantic layer. Different runtimes can implement the execution.

Process Steps

A process consists of steps. A step can be simple, durable, conditional, nested, or externally coordinated.

Query Steps

A query step reads facts from entities, relations, projections, repositories, or external sources.

Query steps integrate with Cohesive.Relations, allowing processes to make decisions over declared relation/query models rather than ad hoc data access code.

Example uses:

• find eligible carriers for a load
• list tenants that need reindexing
• fetch records changed since the last sync offset
• load the current state of an onboarding application
• retrieve model evaluation results

Entity Transition Steps

A transition step invokes a legal entity transition.

Transition steps integrate with Cohesive.Entities. The process does not mutate arbitrary state directly. It asks an entity to perform a declared transition, preserving entity invariants and domain semantics.

Example uses:

• assign a carrier to a load
• reserve capacity
• mark a tenant index as rebuilding
• attach a vehicle to a driver profile
• approve or reject an onboarding case

Effect Steps

An effect step interacts with the outside world.

Effects include API calls, messages, webhooks, emails, file writes, search index updates, payment calls, model training jobs, notifications, or any other interaction beyond local state.

This is where ordinary database transactions stop being enough.

An RDBMS transaction can provide ACID guarantees when all participating state lives inside one database boundary and the full update can be enclosed in one transaction. But many real operations include effects. A database transaction cannot make an email unsend, force an external API to roll back, or atomically coordinate a payment provider, search index, message broker, and third-party system.

Cohesive.Processes makes effects explicit so they can be retried, isolated, audited, correlated, compensated, or guarded by idempotency keys.

Wait Steps

A process can wait for time or for an event.

Examples:

• wait 30 minutes before escalating
• wait until a webhook arrives
• wait until a human approves a task
• wait until a model training run completes
• wait until a child process finishes
• wait until an external system sends an acknowledgment

Waits are process semantics, not incidental infrastructure callbacks. They should be visible in the model.

Decision Steps

A process can branch based on query results, entity state, effect results, policy evaluation, user input, elapsed time, or external signals.

Decision logic can determine:

• whether to continue
• which path to take
• whether compensation is required
• whether a human approval step is needed
• whether a child process should be started
• whether an operation should be retried, skipped, or escalated

Child Process Steps

A process can start another process.

Child processes can be:

• coupled, where the parent waits for the child result
• fire-and-forget, where the parent starts the child and continues
• fan-out/fan-in, where many child processes run and the parent aggregates their results
• supervised, where the parent monitors progress and handles failure or timeout

Large workflows can be decomposed without losing traceability.

Multi-Transition Operations

Many API operations act on more than one entity, perform more than one transition on the same entity, or invoke several service calls.

For example:

1. Ingest a tender.
2. Create a load.
3. Create a trip.
4. Reserve carrier capacity.
5. Send an acknowledgment.
6. Wait for a downstream confirmation.
7. Mark the operation complete.

Some of those steps may be database-backed. Others are effects. Some may be synchronous. Others may require durable execution.

Cohesive.Processes models the whole operation as one coordinated flow. The process can expose a single API capability while preserving each underlying entity transition and effect as inspectable steps.

Sagas and Compensation

A saga is a multi-step process with designated compensating actions for failure, timeout, or cancellation.

Sagas are softer than ACID transactions. They do not provide full isolation or atomicity across all participants. Instead, they define forward steps and compensating steps.

Example:

1. Reserve carrier capacity.
2. Create load.
3. Create trip.
4. Send acknowledgment.
5. Wait for downstream confirmation.

If the process fails after capacity is reserved but before the trip is accepted, compensation may release the reservation, cancel the draft trip, or send a corrective message.

Cohesive.Processes treats sagas as a workflow pattern, not as a separate primitive. A process can define normal execution, retry paths, timeout paths, cancellation behavior, and compensating actions.

Multi-Step System Workflows

Some processes operate at system scope rather than user request scope.

A system-wide index rebuild may need to:

1. List tenants.
2. Start a rebuild for each tenant.
3. Scan source records.
4. Materialize index documents.
5. Write batches.
6. Record progress.
7. Throttle work.
8. Retry failed batches.
9. Resume after worker restart.
10. Mark the rebuild complete.

This is not just a script or cron job. It is a durable system workflow.

Cohesive.Processes gives the operation a visible execution history, progress model, retry semantics, and control surface.

Scheduled Jobs

Scheduled jobs are processes with schedule-based triggers.

A job may run:

• on a CRON schedule
• after a delay
• in response to a domain event
• from a webhook
• from a manual operator action
• from another process

The schedule starts the process. The process defines the work.

This distinction matters because scheduled work often needs more than a timer. It may need offsets, deduplication, pagination, leases, retries, backoff, observability, cancellation, and replay.

Example: an external API sync process may run every 15 minutes, read the last import offset, fetch changed records, normalize them, apply entity transitions, persist the new offset, and emit a completion result.

Durability

Some processes can run ephemerally inside a request. Others need durable execution.

Durable execution means process progress can survive:

• worker crashes
• machine restarts
• deployments
• long waits
• transient failures
• external callbacks
• retries
• partial completion
• fan-out/fan-in coordination

A durable process records enough state to resume execution without losing semantic progress.

Depending on the runtime, durability may include checkpoints, event history, deterministic replay, persisted timers, idempotency keys, leases, queues, or storage-backed execution records.

Cohesive.Processes does not require every process to be durable. It gives the process model enough structure so durability can be supplied when the workflow needs it.

Monitoring and Control

A process should be operationally visible.

For durable or long-running workflows, the system should be able to:

• start a process
• stop a process
• cancel a process
• signal a process
• retry a failed step
• inspect current status
• inspect execution history
• inspect current wait state
• query process output
• correlate process execution with entities, users, effects, and child processes

This is where Cohesive.Processes integrates with Cohesive.Api.

A process can expose control APIs without each workflow inventing its own operational interface.

Process Model

A process definition can include:

The important point is that a process is not merely executable code. It is an inspectable model of temporal system behavior.

Example Process Shapes

Runtime Adapters

Cohesive.Processes is not a single workflow engine.

It defines workflow semantics that can be executed by different runtimes.

Runtime adapters may target:

• Durable Task
• Temporal
• local in-memory test harnesses
• hosted workers
• queue-backed workers
• custom storage-backed runtimes
• infrastructure built from storage, messages, timers, leases, and event streams

Process intent stays portable while execution binds to the runtime that fits the operational requirement.

A short-lived process may run in a lightweight harness. A long-running, restart-safe workflow may run on a durable workflow engine. A UI process may be projected into presentation state. The process definition remains the semantic anchor.

Integration with Other Cohesive Blocks

Cohesive.Processes sits at the temporal coordination layer of the Cohesive model.

It integrates with:

• Cohesive.Entities for entity-transition steps
• Cohesive.Relations for query and relation steps
• Cohesive.Storage for execution state, checkpoints, history, offsets, and durability
• Cohesive.Api for start, status, signal, cancel, retry, and query operations
• Cohesive.Presentation for UI workflows, progress views, human tasks, and action surfaces
• Cohesive.Identity for actor context, initiator context, authorization, delegation, and agent identity
• Cohesive.Infra for binding process execution to workers, schedulers, queues, workflow engines, and hosted runtimes

Processes and Agentic Workflows

Agentic systems make process modeling more important, not less.

Agents need tools, context, memory, goals, and permissions. But they also need declared boundaries. Existing systems need a way to tell agents:

• what workflows exist
• what inputs are required
• what actions are legal
• what state can be read
• what transitions can be performed
• what effects can be invoked
• what requires human approval
• how progress can be observed
• how the workflow can be signaled
• how outputs should be interpreted

Cohesive.Processes can provide this declaration layer.

A process can be exposed to an agent as a structured capability. The agent does not need to invent the workflow, scrape a UI, or guess the correct sequence of service calls. It can invoke a declared process, provide input, observe progress, signal when needed, and receive a typed result.

This creates a bridge between existing software systems and agentic orchestration.

The process remains governed by the system's domain semantics, authorization model, state transitions, effects, and operational controls. The agent can participate without bypassing the application model.

Agent Interop

For agent interoperability, a process definition can serve as a contract:

• Capability contract: what the process does and when it may be invoked
• Input contract: what information the agent must provide
• Control contract: how the process can be started, canceled, signaled, or queried
• State contract: what progress and intermediate state can be observed
• Approval contract: which steps require human or policy approval
• Effect contract: which external effects the process may perform
• Output contract: what result the process returns
• Audit contract: how the process execution is recorded and reviewed

This is a safer model than giving agents unrestricted access to low-level APIs.

Agents can invoke workflows as durable, typed, inspectable system capabilities.

Why It Matters

Processes are where system meaning becomes temporal.

Entities describe what can change. Relations describe what can be derived. Storage preserves state. APIs expose capabilities. Presentation guides interaction. Infrastructure runs the system.

Processes coordinate behavior over time.

When processes are explicit, temporal behavior is no longer hidden in handlers, jobs, timers, and runbooks. The workflow can be declared once, then generated, tested, executed, monitored, resumed, controlled, and exposed to humans, services, and agents.