Differences

This shows you the differences between two versions of the page.

--- dido:05-semantics:01-kinds-of-semantics:05-implementation-semantics [2026/07/11 11:06] – ↷ Links adapted because of a move operation nick_dido
+++ dido:05-semantics:01-kinds-of-semantics:05-implementation-semantics [2026/07/18 12:33] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== Implementation Semantics ======
-[[fxdemo:dido_99_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 =====
-Implementation semantics defines meaning through executable artefacts, deployed configurations, runtime behaviour, database constraints, message handlers, validation functions, policy enforcement points, and system operations.
+Implementation semantics defines meaning through executable artifacts, deployed configurations, runtime behavior, database constraints, message handlers, validation functions, policy enforcement points, and system operations.
-Implementation artefacts express semantic content when their behaviour preserves [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] to the defined domain meaning. That meaning comes from authoritative semantic sources such as [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:s:semantic|semantics]], [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:c:conceptual_model|conceptual models]], [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:s:schema|schemas]], [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:t:type_system|type systems]], rules, policies, [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:o:ontology|ontologies]], [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:r:report|reports]], and conformance criteria.
+Implementation artifacts express semantic content when their behavior preserves [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|traceability]] to the defined domain meaning. That meaning comes from authoritative semantic sources such as [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantics]], [[dido:99_annexes:annex-b-terms-and-definitions:c:conceptual_model|conceptual models]], [[dido:99_annexes:annex-b-terms-and-definitions:s:schema|schemas]], [[dido:99_annexes:annex-b-terms-and-definitions:t:type_system|type systems]], rules, policies, [[dido:99_annexes:annex-b-terms-and-definitions:o:ontology|ontologies]], [[dido:99_annexes:annex-b-terms-and-definitions:r:report|reports]], and conformance criteria.
-Implementation semantics differs from conceptual semantics. Conceptual semantics defines meaning before an architecture selects implementation technology. Implementation semantics expresses selected meaning through runtime behaviour and technical artefacts.
+Implementation semantics differs from conceptual semantics. Conceptual semantics defines meaning before an architecture selects implementation technology. Implementation semantics expresses selected meaning through runtime behavior and technical artifacts.
-Implementation semantics also differ from implementation details. Implementation detail describes how a system performs work. Implementation semantics identifies what the implemented behaviour means with respect to the governed architecture.
+Implementation semantics also differ from implementation details. Implementation detail describes how a system performs work. Implementation semantics identifies what the implemented behavior means with respect to the governed architecture.
 Implementation semantic content includes:
@@ Line 22: / Line 22: @@
   * Message handlers
   * Event handlers
-  * [[fxdemo:dido_99_annexes:annex-b-terms-and-definitions:a:api]] behaviour
+  * [[dido:99_annexes:annex-b-terms-and-definitions:a:api]] behavior
-  * DDS topic behaviour
+  * DDS topic behavior
   * Policy enforcement points
   * Access-control decisions
@@ Line 29: / Line 29: @@
   * Serialisation and deserialization logic
   * Error handling
-  * Logging behaviour
+  * Logging behavior
   * Conformance test outcomes
   * Traceability to semantic sources
-A governed architecture prevents implementation behaviour from becoming the hidden source of meaning. The architecture defines the meaning first; implementation artefacts then express, enforce, validate, or operationalise that meaning.
+A governed architecture prevents implementation behavior from becoming the hidden source of meaning. The architecture defines the meaning first; implementation artifacts then express, enforce, validate, or operationalise that meaning.
 ===== Definition =====
-//meaning expressed through executable artefacts, deployed configurations, runtime behaviour, and technical constraints within an implementation context//
+//meaning expressed through executable artifacts, deployed configurations, runtime behavior, and technical constraints within an implementation context//
 ===== Source =====
@@ Line 45: / Line 45: @@
 ===== Note =====
-Implementation semantics does not replace conceptual semantics. Implementation semantics expresses selected conceptual, schema, type, rule, policy, report, or ontology meaning in executable or deployed form. A governed implementation preserves traceability from runtime behaviour to the semantic source that establishes the intended meaning.
+Implementation semantics does not replace conceptual semantics. Implementation semantics expresses selected conceptual, schema, type, rule, policy, report, or ontology meaning in executable or deployed form. A governed implementation preserves traceability from runtime behavior to the semantic source that establishes the intended meaning.
 ===== Example =====
@@ Line 51: / Line 51: @@
 An FX Demo implementation receives a proposed trade message and executes validation logic before committing the trade state.
-^ Implementation artefact ^ Behaviour ^ Semantic source ^ Implementation semantic meaning ^
+^ Implementation artifact ^ Behavior ^ Semantic source ^ Implementation semantic meaning ^
 | Trade message parser | Reads ''tradeDate'', ''settlementDate'', ''counterpartyLEI'', and ''notionalAmount'' | FX trade schema and conceptual model | The parser recognises the message fields as trade information elements, not as arbitrary data |
 | Date validation function | Rejects a confirmed trade when ''settlementDate'' precedes ''tradeDate'' | FX trade lifecycle rule | The implementation enforces the meaning of a valid confirmed trade lifecycle |
@@ Line 58: / Line 58: @@
 | Audit log writer | Records validation result, timestamp, validator identifier, and rejection reason | Conformance semantics and governance policy | The implementation creates evidence of the semantic decision |
-The implementation semantics do not come from the code alone. The code expresses meaning because each implemented behaviour traces to a governed semantic source. Without that traceability, the runtime behaviour becomes an undocumented interpretation of the domain.
+The implementation semantics do not come from the code alone. The code expresses meaning because each implemented behavior traces to a governed semantic source. Without that traceability, the runtime behavior becomes an undocumented interpretation of the domain.
 ----