dido:99_annexes:annex-b-terms-and-definitions:l:logical_evidence_traceability

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
dido:99_annexes:annex-b-terms-and-definitions:l:logical_evidence_traceability [2026/07/11 11:14] – removed - external edit (Unknown date) 127.0.0.1dido:99_annexes:annex-b-terms-and-definitions:l:logical_evidence_traceability [2026/07/18 12:33] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== Logical Evidence Traceability ======
  
 +[[dido:99_annexes:annex-b-terms-and-definitions:l:start|Return to L Terms]]
 +
 +===== Discussion =====
 +
 +Logical Evidence Traceability relates logical elements and logical interactions to the evidence expectations that later implementation, deployment, testability, and evidence plans satisfy.
 +
 +Logical Evidence Traceability does not create runtime evidence in Part 2. It identifies what later parts need to evidence. It connects claims about logical behavior to the logical Nodes, endpoints, information structures, Runtime Planes, interactions, governance constraints, and traceability relationships that support those claims.
 +
 +Logical Evidence Traceability prepares Part 5 to define deployment evidence, captured messages, logs, status records, provenance records, test results, configuration snapshots, review records, and evidence packages.
 +
 +===== Definition =====
 +
 +//Traceability relationship connecting logical elements and interactions to evidence expectations for later realization, deployment, testing, and review.//
 +
 +===== Source =====
 +
 +Specialization of Evidence and Traceability from Part 1, Sections 7.9 and 7.10; generalised from acceptance evidence, audit, provenance, replay, and runtime evidence material in the original FX Demo Reference Architecture.
 +
 +===== Note =====
 +
 +Logical Evidence Traceability identifies evidence expectations. It does not prescribe evidence files, logs, screenshots, dashboards, repositories, or test tools.
 +
 +===== Example =====
 +
 +The Report Node Status pattern includes an expectation that later parts capture status records that show the Logical Node Identity, lifecycle state, timestamp, and status reason during a test or operational review.
 +
 +----
 +
 +[[dido:99_annexes:annex-b-terms-and-definitions:l:start|Return to Top]]
 +
 +----
 +
 +<WRAP centeralign>
 +© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.
 +</WRAP>