A chart, a state, an instance, a snapshot, and an engine describe different parts of one system. Keeping them separate is the first correctness condition. The chart defines possible behavior. An instance has one lifetime of that behavior. A snapshot records one committed point in that lifetime. An engine owns the operational conditions under which instances run.
Separate the five authorities
| Term | Authority | | ------------ | -------------------------------------------------------------------------------------------------------------------------------------- | | Chart | The reusable, immutable definition of states, events, transitions, data slots, and mounted work. | | State | One authored node in the chart's hierarchy. A state gives meaning to a situation; it is not a mutable runtime object. | | Instance | One addressed lifetime of a chart, with its own input, sequence, active configuration, and lifecycle status. | | Snapshot | The committed value of an instance at one sequence: configuration, root data, descendant facets, history, mounted work, and status. | | Engine | The runtime authority that admits operations, owns instance execution, publishes snapshots, and supplies an operational failure model. |
These terms are not interchangeable projections of one object. The same chart may govern many instances. One instance produces a succession of snapshots. An engine may host many charts and instances. Changing the engine changes the guarantees around a chart; it does not redefine the chart's transition meaning.
A facet is the data owned by one state for that state's active lifetime. The
root facet is stored as snapshot.data; descendant facets are stored by state
path in snapshot.facets.
Read the chart as authored structure
The authored root state is the chart. It is a real state node at path "",
not an invisible container above the model. Its state kind, data, actions,
transitions, mounted work, initial child, and descendants are ordinary chart
structure.
Every descendant has a dot-joined path relative to that root. A state named
Screening beneath Review has a path such as review.screening. Paths, not
class names in isolation, provide runtime identity. Two different regions may
therefore contain same-named states without collapsing them into one state.
The chart also owns order. State order, transition order, and action order are semantic. They determine initial geometry, selection priority, entry and exit ordering, and action execution. Canonicalization preserves authored order where order carries meaning.
A chart is still not running behavior. Before an engine starts an instance, the chart has no current configuration, no sequence, no pending work, and no lifecycle status. It states what an instance may do; it does not claim that an instance exists.
Follow one instance through snapshots
An instance is addressed by its chart identity and an instance identifier. Its birth admits chart input once, constructs the root and initial configuration, and commits the first snapshot. Two instances of the same chart may begin from different inputs and then accept different events without sharing data or lifecycle.
While an instance is Running, its current configuration is the set of
active state paths and always includes the root. A compound state has one active
child line; a parallel state has an active line in every region. Active
configuration answers where the running instance is. A terminal snapshot may
retain its ending configuration and facets as historical records, but those
states and facets are no longer live.
The snapshot joins configuration with the other committed facts needed to continue deterministically:
- the lifecycle status;
- root data and descendant facets, active while running and historical after terminal exit;
- recorded history;
- mounted timer, activity, and child slots;
- the instance sequence; and
- the durable identities needed to admit later settlements or reject stale ones.
A snapshot is a value, not a live actor. Reading one does not advance the instance. An engine may retain only the current head, or it may also retain a timeline of earlier committed snapshots and steps. Retention policy changes what history can be inspected; it does not change the meaning of the current snapshot.
Each handled external event can produce at most one next committed snapshot. Internal eventless work and raised events may require several microsteps, but they settle inside that one macrostep and publish one atomic result. A refused event publishes no advancing snapshot and does not increment the sequence.
Let the engine own the failure model
The engine owns operations around instances: start, send, read, observe, await terminal completion, inspect retained steps, and stop. It also owns the resource and failure model under which those operations run.
An in-memory engine may keep every instance, timer, activity, child, and local
timeline inside one Effect Scope. Closing that Scope or losing the process
loses the operational state. A durable engine instead commits the next
snapshot and planned work to storage before enacting that work, so recovery can
resume from committed facts. Browser durability and cross-context coordination
require the owner-approved BROWSER_CLAIM_LABEL before publication; this page
makes no stronger public browser guarantee.
Those engines must run the same chart fold. An event cannot mean one transition in memory and another transition after the chart moves to durable storage. Engine choice may alter restart survival, ownership, retention, and recovery; it may not alter event admission, transition selection, action order, state entry, completion, or terminal meaning.
This boundary also keeps operational status distinct from chart status.
Running, Done, Stopped, and Cancelled belong to the snapshot lifecycle.
Durable conditions such as a faulted or parked instance describe whether an
engine can safely process the future or trust the stored past. They do not add
authorable chart states or synthetic transitions.
Apply the model
When reading or designing a workflow, ask five questions in order:
- Which chart defines the legal structure and transition meaning?
- Which state paths may be active, and what does each state mean?
- Which instance lifetime is being addressed?
- Which snapshot and sequence establish the committed facts being discussed?
- Which engine guarantees surround that instance, and which failures remain outside those guarantees?
Most category errors answer one of these questions with an authority from a different layer. A class declaration is not an instance. A diagram highlight is not the whole snapshot. A retained snapshot is not proof of a live runtime. A durable engine is not a different chart. Keeping the authorities separate makes later laws about selection, commit, recovery, and inspection precise.