| Both sides previous revision Previous revision Next revision | Previous revision |
| dido:05-semantics:01-kinds-of-semantics:06-lifecycle-semantics [2026/07/08 03:02] – ↷ Page moved from dido:01-semantics:01-kinds-of-semantics:06-lifecycle-semantics to dido:05-semantics:01-kinds-of-semantics:06-lifecycle-semantics nick_dido | dido:05-semantics:01-kinds-of-semantics:06-lifecycle-semantics [2026/07/18 12:33] (current) – external edit 127.0.0.1 |
|---|
| ====== Lifecycle Semantics ====== | ====== Lifecycle Semantics ====== |
| |
| [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]] | [[dido:99_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]] |
| |
| ===== Discussion ===== | ===== Discussion ===== |
| Lifecycle Semantics defines meaning through states, events, transitions, transition constraints, and lifecycle rules. | Lifecycle Semantics defines meaning through states, events, transitions, transition constraints, and lifecycle rules. |
| |
| A [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:l: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. | A [[dido:99_annexes:annex-b-terms-and-definitions:l: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 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. |
| * Reversal and cancellation rules | * Reversal and cancellation rules |
| * Audit requirements | * Audit requirements |
| * Traceability to [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:d:domain]] meaning | * Traceability to [[dido:99_annexes:annex-b-terms-and-definitions:d:domain]] meaning |
| |
| A governed architecture preserves [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] from lifecycle Semantics to the [[fxdemo:99_part_annexes:annex-b-terms-and-definitions:c:conceptual_model|conceptual model]], business rules, policies, schemas, implementation artefacts, and conformance tests that express or enforce lifecycle meaning. | A governed architecture preserves [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] from lifecycle Semantics to the [[dido:99_annexes:annex-b-terms-and-definitions:c:conceptual_model|conceptual model]], business rules, policies, schemas, implementation artifacts, and conformance tests that express or enforce lifecycle meaning. |
| |
| ===== Definition ===== | ===== Definition ===== |
| ===== Source ===== | ===== Source ===== |
| |
| DIDO Solutions usage, informed by state-machine modelling, business process modelling, software architecture, semantic modelling practice, and lifecycle governance practice. | DIDO Solutions usage, informed by state-machine modeling, business process modeling, software architecture, semantic modeling practice, and lifecycle governance practice. |
| |
| ===== Note ===== | ===== Note ===== |
| | ''Proposed'' | a trade exists as a submitted proposal that has not completed required validation | | | ''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 | | | ''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 | | | ''Confirmed'' | counterparties or authorized systems accepted the trade as valid under the confirmation rules | |
| | ''Settled'' | settlement evidence shows completion of the settlement obligation | | | ''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 | | | ''Canceled'' | an authorized action ended the trade lifecycle before settlement or reversed the active trade state under governed rules | |
| |
| The lifecycle also defines valid transitions: | The lifecycle also defines valid transitions: |
| | ''Proposed'' | ''ValidationPassed'' | ''Confirmed'' | the proposal satisfies 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'' | ''SettlementEvidenceReceived'' | ''Settled'' | the confirmed trade has settlement evidence | |
| | ''Confirmed'' | ''CancellationAccepted'' | ''Cancelled'' | an authorized cancellation ends the confirmed trade lifecycle | | | ''Confirmed'' | ''CancellationAccepted'' | ''Canceled'' | an authorized cancellation ends the confirmed trade lifecycle | |
| | ''Settled'' | ''CorrectionRequested'' | ''ExceptionReview'' | a governed exception process reviews a settled-state correction | | | ''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. | A field named ''lifecycleState'' has datatype semantics when the schema constrains it to values such as ''Proposed'', ''Confirmed'', ''Settled'', and ''Canceled''. 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. | 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. |