This is an old revision of the document!
Lifecycle Semantics
Discussion
Lifecycle Semantics defines meaning through states, events, transitions, transition constraints, and lifecycle rules.
A lifecycle describes how a thing changes over time. Lifecycle Semantics explains what each state means, which events establish a state, which transitions are valid, which transitions are prohibited, and which conditions govern movement from one state to another.
Lifecycle Semantics differ from a simple status code. A status code names a state. Lifecycle Semantics defines the meaning of the state in relation to prior states, successor states, events, actors, rules, evidence, and governance constraints.
Lifecycle Semantics also differs from implementation logic. Implementation logic executes state changes. Lifecycle Semantics define what those state changes mean within the governed domain.
Lifecycle semantic content includes:
-
Lifecycle states
-
Initial states
-
Terminal states
-
Events
-
State transitions
-
Transition rules
-
Valid predecessor states
-
Valid successor states
-
Prohibited transitions
-
Triggering events
-
Transition conditions
-
Actor roles
-
Evidence requirements
-
Reversal and cancellation rules
-
Audit requirements
-
Traceability to domain meaning
A governed architecture preserves traceability from lifecycle Semantics to the conceptual model, business rules, policies, schemas, implementation artefacts, and conformance tests that express or enforce lifecycle meaning.
Definition
meaning defined through states, events, transitions, and constraints that govern how a thing changes over time
Source
DIDO Solutions usage, informed by state-machine modelling, business process modelling, software architecture, semantic modelling practice, and lifecycle governance practice.
Note
Lifecycle Semantics establishes the domain meaning of state progression. A lifecycle state has reliable meaning only when the architecture defines the state, the event that establishes the state, the valid predecessor and successor states, and the rules that govern transitions.
Example
An FX trade lifecycle defines the following states:
| State | Meaning |
|---|---|
Proposed | a trade exists as a submitted proposal that has not completed required validation |
Rejected | a proposed trade failed one or more required validation checks |
Confirmed | counterparties or authorised systems accepted the trade as valid under the confirmation rules |
Settled | settlement evidence shows completion of the settlement obligation |
Cancelled | an authorised action ended the trade lifecycle before settlement or reversed the active trade state under governed rules |
The lifecycle also defines valid transitions:
| From state | Event | To state | Lifecycle meaning |
|---|---|---|---|
Proposed | ValidationFailed | Rejected | the proposal does not satisfy the rules required for confirmation |
Proposed | ValidationPassed | Confirmed | the proposal satisfies the rules required for confirmation |
Confirmed | SettlementEvidenceReceived | Settled | the confirmed trade has settlement evidence |
Confirmed | CancellationAccepted | Cancelled | an authorized cancellation ends the confirmed trade lifecycle |
Settled | CorrectionRequested | ExceptionReview | a governed exception process reviews a settled-state correction |
A field named lifecycleState has datatype semantics when the schema constrains it to values such as Proposed, Confirmed, Settled, and Cancelled. The field has lifecycle Semantics only when the architecture defines what each state means and which transitions create valid state progression.
For example, the transition from Proposed directly to Settled violates lifecycle Semantics when the architecture requires confirmation before settlement. The error is not merely an invalid status value. The error represents an invalid interpretation of the trade lifecycle.
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.