Suspect links

A link asserts that two items are consistent with each other. But items change — and when one end of a link changes, that assertion may no longer hold. A suspect link is how traceunified flags exactly that situation, so a change on one side can’t quietly invalidate the work on the other.

Why suspect links matter

Consider a requirement verified by a test. If the requirement is edited, the test that passed against the old wording may no longer prove the new one — but nothing about the test itself changed, so without a signal, it would still look “covered.” Suspect links close that gap: when the requirement changes in a way your trace rules treat as suspect-triggering, its links are marked suspect, telling you the verification needs another look.

What triggers suspect, and how far it goes

Suspect is rule-driven rather than automatic for every edit. Fields configured as triggersSuspect raise the flag when they change, and your trace rule set decides which links are affected. By default the cascade is single-hop: only the items directly linked to the changed item are flagged. An administrator can enable a multi-hop option so the flag carries further along the thread. Changes to a field that isn’t configured to trigger suspect — including editing the content of an architecture block — do not flag its links automatically.

A flag with a reason

A suspect link isn’t just a warning light — it carries the reason it became suspect: what changed, and when. That context is what lets you judge quickly whether the change actually affects the link or was cosmetic, instead of re-doing work blindly. The flag is explicit and visible on the items and in the Suspect Links view, which lists everything currently outstanding.

Reviewing and resolving

Clearing a suspect link is a deliberate act, not a dismissal. You review the change, decide whether the linked item still holds — re-running a test, updating a control, revising a downstream requirement as needed — and then resolve the suspect flag. The resolution is recorded, so there’s evidence that someone looked at the change and confirmed the connection is sound again rather than just silencing the alert.

The safety net under coverage

Suspect links make live coverage more trustworthy. They’re the reason a requirement can be “covered” yet still flagged as needing re-verification — the platform distinguishes linked from currently validated. Combined with impact analysis, they turn change from a source of hidden risk into something you manage deliberately.