A link is a starting point
Suppose a dashboard marks a requirement complete whenever it has a linked, passing test. That rule confuses traceability with verification. Like a logbook, a link helps you locate a record; it does not establish that the recorded check answers the right question. Acceptance needs evidence tied to the requirement's wording, operating conditions, and relevant build. Separate three questions: is there a link, did the test pass, and does that result support acceptance?
A passing test can miss the promise
Consider this requirement: "Reject password reset tokens at or after fifteen minutes." A linked test resets a password with a token aged one minute and passes. An implementation that accepts tokens forever would also pass. The result demonstrates one successful reset, not expiry enforcement. Now submit an otherwise valid, unused token aged sixteen minutes. Acceptance contradicts the requirement, even though the original test is still green.
Make acceptance verifiable
Read the requirement without its status badge. Translate each condition into an observable assertion. For expiry, check unused tokens at fifteen minutes and beyond; include a younger token as a control. Use controlled time and the clock that the system uses. Confirm rejection leaves the password unchanged. Review results for the relevant build and configuration, recording token age and outcome. Record the actual assertion alongside the test name. Missing expiry checks mean unverified coverage; acceptance of an expired token means failure. Preserve the narrower result that actually passed.
A hypothetical boundary case
Imagine, hypothetically, that the token is checked just before fifteen minutes, but the password changes just after. The wording does not identify which event determines expiry. Decision rule: agree whether validation time or update time controls, document that choice, then test across the boundary. For that chosen event, fifteen minutes or more means rejection. Until that choice is explicit, record the boundary as unresolved. These examples are illustrative, not reported test results. ABOLTUS is in development.