A label is a claim
A project link joins artifacts such as a requirement and a test report. Its type names the claimed relationship. If your team uses “verifies” to mean complete verification, a passing related test may seem enough. That assumption needs checking. A bookmark locates a passage without certifying its accuracy. Likewise, a link can make relevant material easy to find while leaving the requirement only partly checked.
One result, two obligations
The requirement says, “Export every row unchanged within two seconds.” A report records a one-second export but never checks whether every input row appears in the output.
A truncated file could satisfy that timing measurement while violating the requirement. The report supports a timing observation for that run, not complete verification. Under the stated meaning of “verifies,” use a weaker relation or split the requirement before assigning that type.
Make the link earn its type
Read the link as a sentence: “This report verifies this requirement.” Identify its direction, requirement version, tested inputs and observed outcomes. Could the report be correct while the requirement is false? The missing row check makes the answer yes. Compare row identities and values as well as timing; equal counts can hide a duplicated row replacing an omitted one. Alternatively, separate timing from completeness and link each claim to suitable evidence. Define relation meanings consistently so the label states what is known.
Hypothetical boundary: offline use
Suppose the same export requirement later applies offline, while the report covers only online operation. Decide whether that mode change can affect either obligation. Retain the verification claim only when a documented justification establishes that the existing evidence covers offline behavior; otherwise, keep the report as related evidence and obtain the missing checks. Mere reuse of wording does not transfer coverage. These examples are illustrative, not reported test results.