2.3.3 Why SBRM Alone Is Not Enough [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 2.3.3 Why SBRM Alone Is Not Enough ======

[[dido:01-fdis-ra:02-background-and-motivation:02-3-the-role-of-sbrm:start|Return to 2.3 The Role of SBRM]]

Although the Standard Business Report Model (SBRM) provides necessary [[dido:99_annexes:annex-b-terms-and-definitions:s:semantic|semantic]] distinctions, SBRM does not, by itself, constitute an operational or architectural solution.

Systems enact reporting semantics through processes, events, timing constraints, versioning mechanisms, validation workflows, parameters, and governance controls. These mechanisms determine:

  * When an interpretation occurs
  * Which definitions and rules apply
  * Which semantic version governs the interpretation
  * Which evidence and observations serve as inputs
  * How systems validate and record the result
  * When changes in definitions, rules, or conditions require reassessment

These concerns are architectural in nature. They require coordination across components, interfaces, processing stages, governance mechanisms, and system boundaries. Semantic definitions or conceptual models alone do not define how systems perform, govern, observe, or reconstruct interpretation.

Without an explicit architectural framework, implementations may apply SBRM inconsistently, embed its distinctions implicitly within tools, collapse them into implementation-specific data structures, or bypass them in favour of expedient processing logic. Such treatment weakens comparability, traceability, auditability, and controlled semantic evolution.

The Federated Data Interpretation Systems Reference Architecture (FDIS-RA) therefore situates SBRM within a coherent system-level [[dido:99_annexes:annex-b-terms-and-definitions:r:reference_architecture|Reference Architecture]]. FDIS-RA identifies the components, responsibilities, boundaries, interfaces, governance mechanisms, and lifecycle controls needed to operationalise SBRM semantics across the reporting lifecycle, including:

  * Evidence intake and custody
  * Information extraction and observation generation
  * Observation and provenance management
  * Semantic canonicalisation
  * Interpretation, rule application, and calculation
  * Validation, conformance, and assessment
  * Analysis, reporting, and governed consumption

The Reference Architecture also provides the conceptual foundation for a formal architectural model expressed using SysML v2. In this role, SysML v2 supports representing semantic elements alongside architectural structure, behavior, processing flows, events, triggers, constraints, interfaces, governance relationships, and traceability.

The SysML v2 model operates at the [[dido:99_annexes:annex-b-terms-and-definitions:p:platform_independent_model|Platform-Independent Model (PIM)]] level. It expresses architectural responsibilities and constraints independently of particular technologies, products, deployment environments, or implementation mechanisms.

The explanatory material in FDIS-RA provides context, motivation, and design rationale. The formally identified architectural requirements, interface definitions, constraints, models, and conformance provisions constitute the proposed normative response to the [[dido:00-sip-ra:start|Structured Information Processing Reference Architecture (SIP-RA) Request for Proposal]].

Together, SBRM and FDIS-RA serve complementary roles:

  * SBRM defines governed distinctions among reported, observed, and interpreted information
  * FDIS-RA defines the architecture through which systems apply, exchange, govern, version, trace, and assess those distinctions

----

<WRAP centeralign>
© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
</WRAP>