Differences

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

--- dido:05-semantics:01-kinds-of-semantics:05-implementation-semantics [2026/07/08 03:02] – removed - external edit (Unknown date) 127.0.0.1
+++ 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 ======
+[[dido:99_annexes:annex-b-terms-and-definitions:start|Go up to Terms and Definitions]]
+===== Discussion =====
+Implementation semantics defines meaning through executable artifacts, deployed configurations, runtime behavior, database constraints, message handlers, validation functions, policy enforcement points, and system operations.
+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 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 behavior means with respect to the governed architecture.
+Implementation semantic content includes:
+  * Executable code
+  * Runtime logic
+  * Configuration files
+  * Database constraints
+  * Validation functions
+  * Message handlers
+  * Event handlers
+  * [[dido:99_annexes:annex-b-terms-and-definitions:a:api]] behavior
+  * DDS topic behavior
+  * Policy enforcement points
+  * Access-control decisions
+  * Transformation rules
+  * Serialisation and deserialization logic
+  * Error handling
+  * Logging behavior
+  * Conformance test outcomes
+  * Traceability to semantic sources
+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 artifacts, deployed configurations, runtime behavior, and technical constraints within an implementation context//
+===== Source =====
+DIDO Solutions' usage is informed by software architecture, model-driven architecture, semantic traceability, validation practices, and conformance testing practices.
+===== 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 behavior to the semantic source that establishes the intended meaning.
+===== Example =====
+An FX Demo implementation receives a proposed trade message and executes validation logic before committing the trade state.
+^ 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 |
+| LEI validation function | Rejects a trade when ''counterpartyLEI'' lacks a valid LEI format | LEI type and validation rule | The implementation treats the value as a legal entity identifier, not as a generic string |
+| Commit guard | Accepts a state transition only when the predecessor state identifier matches the current committed state | lifecycle semantics and state-transition rule | The implementation preserves the meaning of ordered trade-state progression |
+| 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 behavior traces to a governed semantic source. Without that traceability, the runtime behavior becomes an undocumented interpretation of the domain.
+----
+<WRAP centeralign>
+© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
+</WRAP>