Traceability

Return to Terms and Definitions

Traceability relates one architectural, logical, implementation, deployment, or evidence element to another. It allows authors and reviewers to follow a concern from concept to logical model, from logical model to implementation artefact, from implementation artefact to deployment artefact, and from deployment artefact to evidence.

Traceability supports governance, review, auditability, impact analysis, conformance assessment, replay, recovery, and controlled evolution. It helps ensure later parts specialise, realise, deploy, and test conceptual elements without redefining them.

Traceability also helps identify the scope of change. When a concept, logical element, implementation artefact, deployment artefact, or evidence requirement changes, traceability helps reviewers determine which related elements may require review.

quality permitting relationships to be followed

Informed by SIP-RA traceable processing and implementation-independent architecture concerns; aligned with FDIS-RA traceability, provenance, comparability, and auditability concerns; adapted from FX Demo Reference Architecture traceability requirements across Nodes, Communication Endpoints, Data Structure Definitions, Runtime Planes, QoS, topics, provenance, and Evidence.

Traceability does not imply that every element maps one-to-one. One conceptual element may influence multiple logical elements, and one evidence item may support multiple claims.

A Communication Endpoint may trace to a logical endpoint in Part 2, a DDS Topic in Part 4, a Kubernetes deployment configuration in Part 5, and captured message evidence in an acceptance test.