skip to content

What can a maintained traceability record prove that links left as a by-product of ordinary work cannot?

level: middleimportance: must knowfreq 52%

answer

  1. Two ways of holding the same links
  2. One accumulates, one is deliberately kept
  3. Ask each a completeness question
  4. Upkeep cost against evidentiary strength
  5. Stale records still answer confidently

basics

~20 s

A maintained traceability record proves, as of a stated moment, that every requirement had a named verification against a named version. By-product links only show what someone happened to reference, and fall silent wherever nobody referenced anything.

solid answer

~50 s

By-product links are the connections ordinary work already leaves behind: a requirement identifier typed into a change description, a test case named after the criterion it exercises, a defect naming the case that found it. They cost nothing to keep, and they answer *what did this change touch* well. What they cannot answer is completeness — a requirement with no link is indistinguishable from a requirement whose verification exists and whose author never typed the identifier. A maintained record is a deliberate second thing, edited whenever a requirement, criterion or case changes, and absence in it is a maintained state rather than an accident. That is what it can be asked to prove. Its cost is continuous upkeep proportional to churn, and its decay is silent: a stale maintained record keeps answering confidently about a system that no longer exists, which makes it worse than honest by-product links.

code

pseudocode · 14 lines
pseudocode
MAINTAINED LINK  (a row somebody edits when anything below changes)
  requirementId:   REQ-418
  criterionId:     REQ-418-AC2
  verifiedBy:      CASE-2231, CASE-2240
  verifiedAgainst: build 7.4.2
  lastExecuted:    2026-04-11   result: pass
  upkeepOwner:     team-payments
  # absence here is a maintained state: an empty cell someone answers for

DERIVED LINK     (recomputed from work already done)
  for each change in change_history:
      for each id in extract_requirement_ids(change.description):
          emit link(id -> change, basis: "identifier in description")
  # completeness = whatever anyone remembered to write down

go deeper

for a junior

Be able to say what a traceability link is — a stated connection from a requirement to the case that verifies it — and to add one when you write a case or describe a change.

for a middle

Explain the mechanics of both arrangements: where by-product links come from, what upkeep a maintained record needs, and the completeness question only the maintained one can answer.

for a senior

Show judgement about decay: how you would notice a maintained record has gone stale, and why honest by-product links beat a confident record that no longer matches the system.

for a principal

Own the commitment. Decide what evidentiary strength the business genuinely needs, and be explicit that a maintained record is permanent upkeep rather than a one-off project.

## Two ways of holding the same links A traceability link is a stated connection from a requirement — or from one acceptance criterion of a requirement — to the test cases that verify it, and onward to the executions that ran them and the defects they found. There are two ways of holding those links, and they differ in kind rather than in effort. **By-product links** are the connections that already exist inside ordinary work because somebody referenced something. A requirement identifier typed into a change description. A test case named after the criterion it exercises. A defect record that names the case which found it. Nobody maintains these as a separate thing; they accumulate as a side effect, and they can be extracted and displayed at any time. **A maintained record** is a deliberate second thing: rows connecting a requirement, its criteria, the cases that verify them, the last execution and its outcome, edited whenever any of those change. It exists to be read by someone who was not there, and it is kept in step on purpose. ## The question each can be asked The useful distinction is not cheap versus thorough. It is which question each can answer, and how the answer degrades when nobody is watching. | Question | By-product links | Maintained record | | --- | --- | --- | | What did this change touch? | Answers directly | Answers indirectly | | Which cases mention this requirement? | Answers directly | Answers | | Is every requirement in this release verified? | Cannot answer | Answers, if upkeep held | | Was this criterion verified, against which version, when? | Rarely | Answers | | How complete is the answer above? | Unknowable | Stated | The row that decides everything is the last one. By-product links are *incidental*: their reach over the requirement set is exactly whatever anyone remembered to reference. From outside, a requirement with no link looks identical to a requirement whose verification exists and whose author never typed the identifier. That ambiguity is harmless while the reader is the person who did the work and can simply remember. It is fatal the moment the reader is not. A maintained record removes the ambiguity by construction: absence becomes a maintained state — an empty cell somebody is accountable for — rather than an accident. It is durable in a second sense too. By-product links live in systems that get pruned, migrated and rewritten; a history rewrite or a move to a different tracking system can silently erase years of them, and nobody notices until the question is finally asked. ## What each costs to keep - **By-product links cost nothing to keep and everything to trust.** There is no upkeep because there is no second thing, but every use of them requires an argument that they are complete, and that argument cannot be made. - **A maintained record costs an edit per change, not per release.** Upkeep is proportional to churn: a split requirement, a renamed criterion, a deleted case and a merged feature each need a corresponding edit. Teams that survive it fold the edit into the same change as the work; teams that batch it into a pre-release reconciliation find the backlog is larger than the release. - **The decay is silent.** Nothing fails when the record goes stale. It keeps answering, confidently, with links describing a system that no longer exists. That is why a stale maintained record is worse than honest by-product links: confidence was the whole property being bought. - **Enforcement narrows the gap without closing it.** Requiring every change to name a requirement makes by-product links more complete, but enforcement can only require *a* reference, not the *right* one, and it says nothing at all about requirements no change ever touched. ## Choosing between them Most work should sit at by-product links, because for the team's own purposes they answer the questions actually asked and cost nothing. Escalate to a maintained record where a reader exists who cannot ask you: an external reviewer, a successor team, a claim that has to hold years after the people who made it have left. Escalate for the part of the system that carries the obligation rather than for all of it. Be honest in the interview that the escalation is a permanent commitment rather than a project. The entire value of a maintained record is in its upkeep, so a record nobody edits is not a lighter version of the same thing — it is a different and worse thing that looks the same from outside, and it will be read at face value by exactly the reader you built it for.

  • What does it actually cost, week to week, to keep a maintained traceability record trustworthy?
    An edit for every requirement added, split, reworded or dropped, every criterion renamed, and every case retired or merged. The cost tracks churn rather than system size, so a stable product is cheap and a discovery-phase product is not. Teams that survive it make the edit part of the same change as the work; teams that reconcile in a batch before each release consistently find the backlog larger than the release itself.
  • Why is a stale maintained traceability record more dangerous than having none at all?
    Because it answers with authority. A reader who was not there takes a link at face value, and a stale record supplies confident answers about verification that no longer holds — a case that was deleted, a requirement that was reworded, a criterion nobody ever covered. With no record, the reader knows to ask. Confidence was the property being bought, and staleness sells it back as a false one.

By-product links are footprints in a corridor; a maintained record is the signed logbook at the door. Footprints show that someone passed, never that nobody else did.

saying these in an interview costs you the question

  • Treats by-product links as complete without ever checking
  • Calls any maintained record pure bureaucratic overhead
  • Reads a link's existence as proof the verification passed
  • Assumes stored links never turn stale or get migrated away
  • Cannot say which question each arrangement can answer