Cohesive Machines

Cohesive.Machines is the forthcoming Cohesive block for defining finite state machines as a semantic intermediate representation.

It provides a formal model for state evolution: the legal states of a lifecycle, the labeled transitions between those states, the initial and terminal states, and the coherence rules that make the lifecycle analyzable.

A Cohesive machine defines what state changes are legal. Other Cohesive blocks define what those changes do, how they are executed, how they are surfaced to users, and how they participate in larger workflows.

State Evolution as Semantics
What a Machine Defines
Execution Independence
Integration with Cohesive.Transitions
Integration with Cohesive.Presentation
Integration with Cohesive.Processes
Machine Relations
Refinement and Perspectives
Tasks and Approval Workflows
Coherence and Verification
Example Authoring Shape
Authoring Philosophy
Why It Matters
The Cohesive.Machines Principle

State Evolution as Semantics

Most software systems contain state machines, even when they are not named as such.

They appear as:

Status fields on domain records.
Approval flows.
Task lifecycles.
Order, load, trip, shipment, or case lifecycles.
UI wizards and interaction flows.
Integration workflows.
Runtime orchestration stages.

When those lifecycles are represented only by application code, switch statements, status strings, or scattered validation logic, the system becomes difficult to verify and evolve.

Cohesive.Machines makes state evolution explicit.

The machine definition becomes the source of truth for legal lifecycle movement.

What a Machine Defines

A machine is a labeled transition system.

It consists of:

States: stable points in a lifecycle.
Transitions: labeled edges between states.
Initial states: valid starting states.
Terminal states: completed or closed states.
Constraints: rules that govern valid structure and relationships.
Metadata: domain labels, descriptions, tags, ownership, and analysis hints.

For example:

Received --Accept--> Accepted
Received --Reject--> Rejected
Accepted --Cover--> Covered
Covered --Dispatch--> Dispatched
Dispatched --Deliver--> Delivered

The machine describes the legal graph of state evolution. It does not require a database, workflow engine, actor runtime, API transport, or user interface.

That separation is the point.

Execution Independence

Cohesive.Machines defines lifecycle semantics independently of execution infrastructure.

A machine definition does not depend on:

Actors.
Threads.
Message queues.
Databases.
HTTP.
Durable workflow engines.
User interfaces.
Cloud infrastructure.

This allows the same lifecycle model to be reused across domain entities, workflows, user interfaces, task systems, approval flows, and runtime orchestration.

The machine says which transitions are structurally legal. Execution layers decide how those transitions are applied.

Integration with Cohesive.Transitions

Cohesive.Machines integrates with Cohesive.Transitions for formal state machine execution.

The split is precise:

Cohesive.Machines defines legality.
Cohesive.Transitions defines executable semantics.

A machine might define:

Covered --Dispatch--> Dispatched

The corresponding entity transition can define:

Inputs.
Preconditions.
Invariants.
Field updates.
Read sets and write sets.
Permissions.
Outputs.
Effects.
Continuations.

At runtime, the machine can validate that Dispatch is legal from the current state. The transition definition can then validate domain invariants, apply state updates, emit outputs, and produce effects.

This makes state execution both formal and meaningful. The system knows not only that a transition is allowed, but also what it means.

Integration with Cohesive.Presentation

Cohesive.Machines also provides a formal substrate for UX flows.

Many user experiences are state machines:

Onboarding flows.
Review and approval screens.
Multi-step forms.
Exception handling flows.
Case management screens.
Task completion paths.
Operational consoles.

By connecting Cohesive.Presentation to machine definitions, UI flows can be generated or validated against the same state model used by the domain.

This helps presentation layers expose:

Valid actions for the current state.
Disabled or unavailable transitions.
Explicit terminal states.
Expected error states.
Process phases.
Recovery paths.
State-specific forms, panels, and commands.

The UI no longer has to rediscover lifecycle rules through hand-written conditionals. It can project the machine and its transition semantics into a concrete user experience.

Integration with Cohesive.Processes

Cohesive.Processes coordinates work across time, entities, effects, queries, waits, and events.

Cohesive.Machines gives processes a formal way to express their own state transition semantics.

A process can use machines to describe:

The stages of the workflow.
Which waits or events move the process forward.
Which entity transitions are valid in each stage.
Which failure, timeout, retry, or compensation states exist.
Which states are terminal.
Which process paths are unreachable or incomplete.

This is useful for both durable and ephemeral process execution.

Durable backends such as Durable Task or Temporal can execute the process. Cohesive.Machines can define and validate the state evolution model that the process is expected to follow.

Machine Relations

Business systems rarely have only one lifecycle.

A single domain area may involve many related machines:

Order lifecycle.
Load lifecycle.
Trip lifecycle.
Task lifecycle.
Approval lifecycle.
Billing lifecycle.
Exception lifecycle.

Cohesive.Machines supports the idea that machines can be related.

State relations describe correspondence between states:

Load.Delivered => Order.Completed
Load.Covered   => Order.Accepted

Transition relations describe correspondence between transitions:

Order.Accept => Load.Create

That relation may mean that a transition in one machine causes, enables, requires, or corresponds to a transition in another machine.

These relations make cross-lifecycle coherence explicit instead of leaving it buried in integration code.

Refinement and Perspectives

Different users often see different versions of the same lifecycle.

A customer-facing machine may be simple:

Accepted -> InProgress -> Delivered

An operational machine may be more detailed:

Accepted -> Covered -> Dispatched -> InTransit -> Delivered

Cohesive.Machines can model one machine as a refinement of another:

Customer.InProgress =
    Operational.Covered
    or Operational.Dispatched
    or Operational.InTransit

This allows multiple perspectives over the same process without losing formal correspondence.

Examples include:

Carrier perspective.
Shipper perspective.
Customer perspective.
Operations perspective.
Finance perspective.
Compliance perspective.

Each perspective can have its own machine. Machine relations define how the perspectives remain coherent.

Tasks and Approval Workflows

Cohesive.Machines encourages separation between domain lifecycle and task lifecycle.

Instead of forcing every operational concern into a single status field:

Open -> AwaitingReview -> Approved -> Covered

the system can model separate machines:

Load lifecycle
Coverage review task lifecycle
Approval lifecycle

Those machines can then be related:

Load.Created       => Create CoverageReviewTask
Task.Completed     => Enable Load.Cover
Approval.Rejected  => Disable Load.Cover

This avoids state explosion and keeps each lifecycle focused on one concern.

Coherence and Verification

Because machines are formal graph structures, they can be analyzed.

Cohesive.Machines is intended to support validation such as:

Unknown state detection.
Unreachable state detection.
Dead state detection.
Terminal state validation.
Invalid terminal transition detection.
Cycle detection.
Strongly connected component analysis.
Safety analysis.
Liveness analysis.
Machine composition analysis.
Refinement verification.
Bisimulation analysis.
Temporal logic verification.

Some validations are simple structural checks. Others are deeper formal verification capabilities.

The direction is the same: make lifecycle semantics inspectable before they become production behavior.

Example Authoring Shape

The exact authoring syntax will evolve with the module, but the intended shape is declarative.

Users should not have to hand-author graph data structures. They should define lifecycle semantics in a domain-oriented way and let Cohesive synthesize the machine IR.

For example:

public sealed partial class LoadLifecycleMachine : MachineDefinition
{
    public State Received { get; } = State.Initial();
    public State Accepted { get; } = State.Named();
    public State Covered { get; } = State.Named();
    public State Dispatched { get; } = State.Named();
    public State InTransit { get; } = State.Named();
    public State Delivered { get; } = State.Terminal();
    public State Cancelled { get; } = State.Terminal();
    public State Rejected { get; } = State.Terminal();

    public override void Define(IMachineBuilder machine)
    {
        machine.From(Received).To(Accepted).On("Accept");
        machine.From(Received).To(Rejected).On("Reject");
        machine.From(Accepted).To(Covered).On("Cover");
        machine.From(Covered).To(Dispatched).On("Dispatch");
        machine.From(Dispatched).To(InTransit).On("Depart");
        machine.From(InTransit).To(Delivered).On("Deliver");

        machine.From(Received).To(Cancelled).On("Cancel");
        machine.From(Accepted).To(Cancelled).On("Cancel");
        machine.From(Covered).To(Cancelled).On("Cancel");
    }
}

That definition can produce a machine IR that is used by entity transitions, process execution, presentation flows, analysis tools, and code generation.

Authoring Philosophy

The machine IR is the source of truth, but authoring should not feel like manually editing a graph.

Preferred authoring experiences include:

Conversational authoring.
Example-driven authoring.
Graph-assisted editing.
Validation-assisted design.
AI-assisted lifecycle discovery.

The system should continuously synthesize and validate the formal machine model while presenting a domain-oriented experience to users.

Why It Matters

Cohesive.Machines helps teams avoid hidden lifecycle complexity.

Without an explicit machine model, lifecycle rules tend to spread across:

Domain services.
API handlers.
UI conditionals.
Workflow code.
Database constraints.
Message handlers.
Task systems.
Reporting logic.

That makes the system harder to understand, harder to verify, and harder to change.

Cohesive.Machines gives lifecycle semantics a formal home.

It allows teams to define legal state evolution once, relate machines across perspectives, verify lifecycle coherence, and reuse the model across execution, workflow, and presentation layers.

The Cohesive.Machines Principle

Define state evolution explicitly.

Separate legality from execution.

Relate lifecycles instead of collapsing them into one status field.

Project the machine into entities, processes, and user experiences.

Cohesive.Machines turns finite state machines into a reusable semantic substrate for the Cohesive ecosystem.