The thread & traceability model

Traceability is the core of TraceUnified — the reason the platform exists. Every other module produces artifacts; traceability is what connects them into a single, navigable thread that runs from a need to the design that realizes it, the test that verifies it, and the risk that constrains it.

Links are real records

The thread is built from links, and a link here is a real record — created deliberately by a person — not a similarity an algorithm guessed at. This distinction matters under regulation: the connection between a requirement and the test that verifies it is an asserted fact you can stand behind in an audit, not an inference that might be wrong. Deterministic links are what make coverage provable rather than approximate.

Directional relationships

A link connects a source item to a target item through a relationship type that gives it meaning — a requirement is verified by a test, an architecture element satisfies a requirement, a risk is mitigated by a control. Relationships are directional, so the thread reads naturally in both directions: from a requirement down to what implements and verifies it, and from a test back up to what it proves.

Configurable relationship types

The set of relationship types — and which types are valid between which kinds of item — is configured for your organization rather than fixed. This lets the thread reflect your process and the standards you work to, so the connections you make match the design-control vocabulary your auditors expect. Defining relationships is covered in the Administration section.

One thread, every module

Because every artifact lives in the same system, the thread spans all of it at once: requirements, architecture, tests, risk, and SBOM components are all connected through the same links. That’s what makes the rest of this section possible — creating links, reading them in the trace matrix, and then using them to measure coverage, flag suspect items, and analyze impact.