====== 2.4.6 The Architectural Gap ====== [[dido:01-fdis-ra:02-background-and-motivation:02-4-existing-functional-capabilities-in-reporting-systems:start|Return to 2.4 Existing Functional Capabilities in Reporting Systems]] Although the functional capabilities described in [[dido:01-fdis-ra:02-background-and-motivation:02-4-existing-functional-capabilities-in-reporting-systems:02-4-1-source-artifact-persistence:start|Section 2.4.1]] through [[dido:01-fdis-ra:02-background-and-motivation:02-4-existing-functional-capabilities-in-reporting-systems:02-4-5-rules-and-validation:start|Section 2.4.5]] are widely deployed in modern reporting systems, organizations typically assemble them through ad hoc, tool-driven, or implementation-specific arrangements. Architectural decisions concerning how evidence, observations, [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] representations, rule execution, and validation outcomes relate to one another often remain implicit. Software implementations, analytical pipelines, configuration conventions, and organizational practices embed these decisions without making the governing relationships, authorities, versions, or assumptions explicit. As a result, reporting systems exhibit recurring architectural failure modes: * Semantics remain distributed across tools, systems, analytical logic, configurations, and codebases rather than governed as explicit, versioned assets * Systems blur or lose the distinctions among reported, observed, and interpreted facts * Organizations cannot assess changes to definitions, rules, or interpretive guidance consistently across implementations * Comparability across agencies, jurisdictions, reporting periods, and independently developed systems degrades over time, even when systems share syntactic standards * Artificial intelligence-assisted extraction and interpretation introduce additional opacity when architectural controls do not constrain their authority, inputs, outputs, provenance, and use Without an explicit coordinating architecture, systems may satisfy individual functional needs, such as ingestion, extraction, validation, storage, or analytics, while still failing to provide the long-term semantic consistency, traceability, reproducibility, comparability, and governance sought by the [[dido:99_annexes:annex-b-terms-and-definitions:f:fdta|Financial Data Transparency Act (FDTA)]] and comparable regulatory regimes. Such systems may operate effectively in isolation while remaining fragile, opaque, and difficult to govern as an integrated interpretation environment. The [[dido:99_annexes:annex-b-terms-and-definitions:f:fdis-ra|Federated Data Interpretation Systems Reference Architecture (FDIS-RA)]] addresses this gap by making architectural responsibilities explicit rather than by replacing existing tools, standards, products, or implementations. FDIS-RA: * Clarifies functional and governance responsibilities * Defines relationships among architectural capabilities * Establishes explicit boundaries and interface obligations * Treats semantic interpretation as a first-class, governable architectural concern * Preserves traceability among source artifacts, observations, interpretations, rules, and outcomes * Supports controlled evolution of semantic and interpretive assets By providing a common system-level [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]], FDIS-RA enables existing and future components to participate coherently within governed processing flows. It supports the controlled evolution of meaning and provides a stable foundation for standards-based reporting and interpretation systems. Addressing the architectural gap also requires attention to non-functional characteristics, including: * Manageability * Maintainability * Analysability * Traceability * Auditability * Interoperability * Securability * Reliability * Portability * Scalability * Performance * Controlled semantic evolution These characteristics determine whether system behavior remains explainable, comparable, inspectable, and auditable as requirements, standards, technologies, tools, organizational responsibilities, and analytical techniques evolve. Many systems that support agency-specific implementation of the FDTA joint data standards operate in mission-critical or high-consequence contexts. In such environments, failures of semantic interpretation, traceability, reproducibility, or governance are not merely technical deficiencies. They may produce material regulatory, financial, legal, operational, or systemic consequences. The absence of an explicit architectural framework therefore represents a foundational risk rather than an implementation inconvenience. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.