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.
In developmentNot availableVerified
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.
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.
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.
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.
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.
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”.
Was this page helpful?
Opens a prefilled email to info@myrilum.com in your mail app; you decide whether to send it, and it never passes through this site. Do not include passwords or other sensitive information.
Sources and maintenance
- Region
- Global
- Version
- 0.1.0
- Publication
- Published globally
- Document status
- Approved · Drafted
- Authorization
- Public information
- Command authority
- None
- Type
- Concept
- Audience
- Technical leads, Developers, Organization leaders, Integration partners, Agents
- Safety class
- Informational
- Agent tasks
understand_platform_architecture- Owner
- Web3Capital Documentation Steward
- Last verified
- 2026-09-23
- Review due
- 2026-10-23
- Source commit
6b41cce4496d- Canonical authority
SRC-ARCHITECTURE-ATLAS-V2-2- Content digest
919789526d82d662- Stable citation
MYRILUM-DOC-ARCH-025@0.1.0:en#overview
Machine-readableMarkdownMetadataJSON-LDChunks
This documentation grants no execution, release, or production authority.
Sources and maintenance
- Region
- Global
- Version
- 0.1.0
- Publication
- Published globally
- Document status
- Approved · Drafted
- Authorization
- Public information
- Command authority
- None
- Type
- Concept
- Audience
- Technical leads, Developers, Organization leaders, Integration partners, Agents
- Safety class
- Informational
- Agent tasks
understand_platform_architecture- Owner
- Web3Capital Documentation Steward
- Last verified
- 2026-09-23
- Review due
- 2026-10-23
- Source commit
6b41cce4496d- Canonical authority
SRC-ARCHITECTURE-ATLAS-V2-2- Content digest
919789526d82d662- Stable citation
MYRILUM-DOC-ARCH-025@0.1.0:en#overview
This documentation grants no execution, release, or production authority.