ABOLTUSA Brighter Tomorrow, Together.
← All research notes

Projects from documents

Building a traceability matrix before a graph interface

The important structure can be tested without visual complexity.

Share this article
LinkedInXFacebookTelegramWhatsApp

The important structure can be tested without visual complexity

The small matrix offers a direct way to test whether the underlying records answer useful questions. A graph can make relationships visually impressive while leaving their meanings or missing evidence unclear. In the pilot, the reviewer should choose a commitment and follow it backward to its source and forward to its acceptance check. Empty cells should have explicit meanings such as not decided, not applicable, or not yet verified. That prevents absence from being interpreted as success. The team can observe which navigation tasks become difficult as the matrix grows and use those observations to justify filters, grouping, or a graph view. The initial evaluation should focus on successful reconstruction of decisions, not preference for a visual style. A richer interface is valuable when it reduces demonstrated friction while preserving the same inspectable evidence relationships.

Working through the example

A pilot has twelve requirements and fifteen source excerpts. The team plans a graph visualization before checking whether the proposed links are useful. Start with rows connecting excerpt, candidate revision, approval, criterion, and result. Review missing cells and incorrect relationships with the project owner.

A discriminating check

Use the matrix to answer where a selected commitment came from and how it will be checked. A matrix may become awkward at larger scale, but that is an observed reason to improve the interface. The cited traceability studies motivate useful relationships over time. Typed links and a manual review matrix are project design choices, not a claim that a graph guarantees correctness.

Research sources

Prepared 17 October 2026 from the project's research materials. Examples and proposed workflows are editorial interpretations. ABOLTUS is in development; a research method or design proposal does not establish that a feature is available or validated in customer use.

Make the research practical.

Tell us which documents you work with and the decisions you need to make.

Share your use case ↗