====== 2.5.2 Tool-Driven Interpretations ====== [[dido:01-fdis-ra:02-background-and-motivation:02-5-why-a-reference-architecture-is-needed:start|Return to 2.5 Why a Reference Architecture Is Needed]] In many current reporting-system implementations, [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] interpretation remains implicitly embedded within tools, platforms, configurations, models, or application logic rather than being defined as an explicit architectural responsibility. As a result, meaning becomes tightly coupled to specific technologies, execution environments, vendor products, or implementation-specific configurations. When organizations upgrade, reconfigure, replace, or integrate tools, interpretive behavior may change subtly and without adequate documentation. Such changes may alter: * Classification outcomes * Validation results * Derived facts * Calculated metrics * Confidence assessments * Conformance determinations These changes may occur without any corresponding revision to reporting standards, semantic definitions, regulatory intent, or governing policy. Because the semantic behavior remains implicit within the implementation, organizations may find such changes difficult to detect, compare, explain, reproduce, or govern. This coupling of semantic intent to tool-specific realization constitutes an architectural failure mode. It: * Undermines comparability across implementations * Complicates oversight and audit * Obscures the authority governing an interpretation * Makes historical reconstruction difficult * Increases dependence on particular vendors or execution environments * Weakens the ability to determine whether different systems interpret the same reported information consistently These problems may persist even when systems nominally use the same reporting formats, taxonomies, standards, or source data. A [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]] is therefore needed to separate semantic intent from its technological realization. The architecture makes interpretive responsibilities, definitions, rules, parameters, version context, and outcomes explicit and traceable independently of the technologies used to execute them. This separation allows semantic behavior to remain stable, governable, inspectable, and reconstructable across: * Heterogeneous tools * Evolving platforms * Vendor changes * Independently developed systems * Multiple reporting periods * Differing deployment environments The [[dido:99_annexes:annex-b-terms-and-definitions:f:fdis-ra|Federated Data Interpretation Systems Reference Architecture (FDIS-RA)]] supports this separation without constraining implementation choice, product selection, technical innovation, or deployment strategy. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.