skip to content

Work shipped under light traceability now needs an evidence trail — what can you honestly rebuild after the fact?

level: seniorimportance: should knowfreq 30%

answer

  1. Inventory what survives before promising anything
  2. Each source supports only certain claims
  3. Label derived links as derived
  4. Contemporaneity cannot be manufactured
  5. Re-verify now, declare the rest

basics

~20 s

Anything still stored can be recovered: which change addressed which requirement, which suite ran against which build, and what it produced. What cannot be rebuilt is what nobody recorded — intent, judgement, and contemporaneity itself.

solid answer

~50 s

Start with an inventory rather than an apology. Version-control history, stored execution outputs, defect records with their re-checks, review threads and deployment records all survive, and each supports some claims and not others — a change naming a requirement shows intent to address it, never that it was verified. Derive links only from stored facts, record the basis of each, and stamp every derived link as derived with the date. Mark requirements with nothing behind them as gaps rather than leaving them blank. For each gap, choose deliberately: re-verify against the current version and record it properly now, or declare the gap and its risk. What can never be reconstructed is contemporaneity — that something was checked at the time, by someone accountable, before the decision that relied on it. Back-dating or silently merging derived rows is fabrication, whatever the intent.

code

pseudocode · 21 lines
pseudocode
for each requirement in scope(release_window):
    derived = []

    for change in version_history where change.description mentions requirement.id:
        derived.add(link(requirement, change,
                         basis: "identifier in change description",
                         supports: "intent to address", not: "verification"))

    for execution in stored_executions where execution.suite covers requirement.id:
        derived.add(link(requirement, execution,
                         basis: "stored output " + execution.outputRef,
                         supports: "suite ran against " + execution.build))

    for d in derived:
        d.derivedAt        = today
        d.contemporaneous  = false      # never omit, never back-date

    if derived is empty:
        record_gap(requirement,
                   choose_one: ["re-verify current version and record properly",
                                "declare unverified, with the risk stated"])

go deeper

for a junior

Know that evidence is recorded while the work is done, not written afterwards from memory, and that anything created later has to say on its face that it was created later.

for a middle

Explain which sources still hold usable facts — version-control history, stored execution outputs, defect records, deployment records — and what each one can and cannot support on its own.

for a senior

Demonstrate the method: inventory what survives, derive links with the basis attached, re-verify where nothing survives, and never let an inference pass as a record made at the time.

for a principal

Own the decision to stop reconstructing. Declare the residual gap and its risk, fix the arrangement going forward, and defend that position rather than manufacturing a trail nobody can defend.

## Start from what the systems still hold Work shipped under a light arrangement leaves real traces, and the first move is an inventory of them rather than an apology. Most teams still hold, without having planned to: a version-control history whose change descriptions often name requirement identifiers, stored outputs from automated executions, defect records with their fixes and re-checks, review threads, deployment records tying a version to a date, and the requirement statements themselves as they were worded then. Each source supports some claims and not others, and the whole skill is refusing to let a strong source carry a weak claim. | Surviving source | Can honestly support | Cannot support | | --- | --- | --- | | Change descriptions naming a requirement | That a change was made intending to address it | That the requirement was verified | | Stored execution outputs | That a named suite ran against a named build with a stated result | That the suite covered the requirement as understood then | | Defect records and their re-checks | That a specific fault was found and later re-checked | The absence of other faults in the same area | | Deployment records | Which version was live when | Anything at all about verification | | Review threads | That a change was read by a named person | The depth of what that person checked | | Anyone's recollection | Nothing, on its own | Anything an outside reader will accept | ## Reconstruct with the derivation attached The method that stands up is mechanical: 1. **Fix the scope.** Which requirements, which release window, which parts of the system. Reconstruction without a boundary never ends. 2. **Derive links from stored facts only**, and record the basis of each — which source it came from and how it was matched. 3. **Stamp each derived link as derived**, with the date of derivation. This is the load-bearing step. 4. **Mark the gaps as gaps**, one row per requirement with nothing behind it. A named gap is a finding; an unmarked gap is a misrepresentation. 5. **For each gap, choose deliberately**: re-verify against the current version and record it properly now, or accept and declare the gap along with its risk. 6. **Change the arrangement forward**, so the next release never needs this exercise again. ## The line you must not cross The one thing that cannot be reconstructed is *contemporaneity* — the fact that something was checked at the time, by someone accountable, before the decision that relied on it. A link derived today from a description written two years ago is a reasonable inference about the past. It is not a record made at the time, and it must never be presented as one. Back-dating, or quietly merging derived rows into a maintained record so that nothing distinguishes them, is fabrication regardless of intent — and it is the failure an outside reader is most practised at spotting. A derived link, honestly labelled, is frequently accepted for what it is. A derived link presented as contemporaneous, once noticed, discredits every other record in the set, including the true ones. The related honest limits are worth saying out loud: - **Intent cannot be recovered.** What a requirement was understood to mean at the time lives in conversations nobody recorded. - **Judgement cannot be recovered.** Whether a reviewer considered the rare input path and decided it was fine left no trace anywhere. - **Absence cannot be proven backwards.** That nothing else was wrong is not recoverable from records of the things that were. ## Re-verifying is usually the cheaper honest answer Teams reach for archaeology because it feels cheaper than work. Often it is not. Re-verifying the current version and recording it properly produces evidence that is contemporaneous, complete and attributable, in a form needing no argument at all, and it commonly costs less than assembling and then defending a partial derivation. Its limitation is that it says nothing about the version that already shipped. So the shape that usually holds up combines all three moves: re-verify now for any claim about the current system, derive-and-label for the historical claim, and declare in plain words what is not evidenced at all. Say that last part explicitly rather than hoping nobody counts. A reader who finds a clearly stated gap reads a team that understands its own records and can be trusted about the rest. A reader who finds a gap you did not mention reads everything else you produced differently, and there is no recovering from that in the same review.

  • Why must a reconstructed link be labelled as reconstructed rather than merged in silently?
    Because the label is what lets a reader weigh it. An inference drawn from a two-year-old description is useful and often accepted for what it is; the same row presented as a record made at the time is a false claim about when and by whom it was made. Once one row is caught misrepresenting its origin, every other row in the set is re-read with suspicion, including all the true ones.
  • When is re-verifying the current version cheaper than reconstructing the historical trail?
    Almost whenever the verification is automated or short, because a fresh execution yields contemporaneous, complete and attributable evidence with no argument attached, while a derivation has to be assembled and then defended row by row. Re-verifying cannot speak to the version that already shipped, so the usual shape is re-verify for claims about the current system, derive-and-label for the historical claim, and declare what remains unevidenced.

Rebuilding an evidence trail is closer to archaeology than to writing: you can date what was left behind, but you cannot recover what was never buried.

saying these in an interview costs you the question

  • Back-dates a record to the day the work happened
  • Claims any evidence can be rebuilt from history
  • Presents inferred links as contemporaneous evidence
  • Reads a change naming a requirement as verification
  • Leaves unevidenced requirements blank rather than flagged