# State machines and exception paths

Orders, payments, plans, tasks, runs, results, verification and acceptance each have their own state and never share one “success” field; saying “done” always means saying which object is done.

> Document ID: MYRILUM-DOC-ARCH-025
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: 919789526d82d6620918f13bc8557046ba319eb28dbba0bcb0e3c703829df1ec
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /en/architecture/state-machines

<a id="overview"></a>

## What this page covers

This is MYRILUM's target architecture. It does not mean everything on the map is live; whether a capability can be used today is stated in “Current availability”.

“Success” on a business chain can never be stated as one thing. This page states principles only; implementation details are not published.

<a id="no-shared-success"></a>

## No single catch-all “success”

A business chain holds several objects, each with its own state. A successful payment does not mean the result is acceptable, and a finished task does not mean the user has accepted it. Screens and records always say which object has reached which step.

<a id="guarded-transitions"></a>

## Every state change has conditions

State moves only through commands: conditions are checked, then the concurrent version, then the change is formally committed and an event is produced. A plan runs only once a specific version is approved; when key content changes it becomes a new version and is approved again where needed.

<a id="honest-branches"></a>

## Intermediate states never pose as final ones

Waiting for material, waiting for a person, paused, external result unclear and cancellation in progress are all explicit intermediate states that show what is missing and who is responsible for the next step. When an external result is unclear, the original operation is queried rather than blindly repeated; permissions are re-checked before resuming, because being resumable does not make something safe to redo automatically.

<a id="separate-objects"></a>

## Result, verification, acceptance and payment are four objects

Once a result is submitted its content is fixed; verification states which method was used, how far the support goes and what the limits are; acceptance is made by an authorized user for one particular version of the result; payment and settlement follow the payment receipt and the contract and are never inferred from the result's state. They are linked through rule-driven events, not by sharing one state field.

<a id="revision"></a>

## Revision creates a new version; history is not rewritten

A revision produces a new version of the result, plan or run. History that has already been accepted is never quietly rewritten.

<a id="source"></a>

## Source

This page follows A25 of the MYRILUM architecture map v2.2. Under the public boundary it publishes principles only and carries no diagram. Related: “From goal to verified delivery: the collaboration operating system”; “Agent runtime and failure recovery”; “Commands, events and consistency”.

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.