What must a verification evidence record carry for a reviewer outside the team to rely on it?

middleshould knowfreq 44%

answer

Written for a reader who cannot ask
What, against which version, by whom
Keep the output, not just the verdict
Identity must resolve years later
Retention is readability, not disk

basics

~20 s

Four things at minimum: what was verified, the exact version it ran against, who or what performed it and when, and the outcome with the stored output it was read from — kept readable for as long as required.

solid answer

~40 s

Evidence for an outside reader has to answer every follow-up question in advance, because the reader cannot ask one. So each record names the thing verified by identifier and in words, the version it ran against as a build or revision rather than a date, the performer as an identity that resolves to one person or one automated agent, when it ran, and the outcome together with the stored output the outcome was read from. Conditions — environment and dataset — belong there too, since a pass under conditions nobody recorded proves little. Retention is the field most often misread: it is a readability commitment, not a storage one. If the outputs, the identifier scheme and the version scheme are pruned around it, the record becomes a citation to a missing document.

Evidence for an outside reader has to answer every follow-up question in advance, because the reader cannot ask one. So each record names **the thing verified** by identifier and in words, **the version** it ran against as a build or revision rather than a date, **the performer** as an identity that resolves to one person or one automated agent, **when** it ran, and **the outcome together with the stored output the outcome was read from**. Conditions — environment and dataset — belong there too, since a pass under conditions nobody recorded proves little. Retention is the field most often misread: it is a readability commitment, not a storage one. If the outputs, the identifier scheme and the version scheme are pruned around it, the record becomes a citation to a missing document.

code

yaml · 16 lines

yaml

evidence_record:
  id: EV-2026-0417-0093
  verified: REQ-418-AC2
  statement: "A refund is refused when the order is older than the refund window"
  against_version: "build 7.4.2 (revision 9f2c1ab)"
  conditions:
    environment: staging-eu
    dataset: SD-14 (manufactured, no real customers)
  performed_by:
    kind: automated suite execution
    triggered_by: E-0472        # stable identifier, not a display name
  performed_at: "2026-04-17T09:41:02Z"
  outcome: pass
  read_from: store/EV-2026-0417-0093/   # kept whole, not summarised away
  written_at: "2026-04-17T09:41:05Z"    # equals performed_at: contemporaneous
  retain_until: "2033-04-17"

go deeper

for a junior

Be ready to say what a verification evidence record is for: showing later that a specific thing was checked. Know that a result with no version attached to it identifies nothing.

for a middle

Explain each field and what it defends against — the identifier of the thing verified, the version it ran against, the performer, the time, the outcome and the output it was read from.

for a senior

Show you have made evidence survive real conditions: outputs stored rather than summarised away, identities that still resolve to individuals, and records a stranger can read without you.

for a principal

Own the retention position: how long evidence must stay readable, what else must be preserved for it to still mean anything, and what that commitment costs the organisation.

What changes when the reader is outside the team

Inside a team, verification evidence is largely conversational. Someone remembers that the refund path was checked before the release, and where the memory is thin, the person who did it is two desks away. That arrangement works because the reader can always ask a follow-up question.

Evidence written for an outside reader — an external assessor, a customer running their own review, a successor team five years on, or your own organisation in a dispute — has to survive without that follow-up. Every question the reader might ask has to have been anticipated and answered inside the record, at the moment the work was done, because the moment cannot be revisited. That is the whole difference, and every required field falls out of it.

The fields, and what each defends against

Field	What it must carry	The question it closes
The thing verified	The identifier of a requirement or one acceptance criterion, plus its statement in words	Verified against what understanding of the requirement?
The version verified against	A build or revision identifier — not a date, not "the current release"	Which code actually passed?
The performer	An identity resolvable to one person or one automated agent, and what triggered it	Who is accountable for this result?
The time	When the verification ran, not when the record was written	Was this before or after the change that concerns me?
The outcome and its basis	Pass or fail, plus the stored output the outcome was read from	How do I know the outcome was read correctly?
The conditions	The environment and the dataset used	Would this result hold where it matters?
Retention	How long the record and everything it points at stay readable	Can I still read this when I need it?

Two rows carry most of the weight. The version is the one teams omit first and regret first: a record saying a requirement passed on a given date, in a product that ships several times a day, identifies nothing. The stored output is the one teams destroy first: summarising an execution down to the word pass and deleting what it produced turns evidence into an assertion, and an assertion from an interested party is not evidence to anyone outside.

Attribution, and why shared identities break it

A performer field naming a shared delivery account, an automation account everyone triggers, or a display name that a later rename overwrites, cannot be resolved to anybody afterwards. The record then proves only that the organisation says the work happened, which is what it was already claiming. Attribution wants an identity that pinned to one individual at the moment of recording, stored as a stable identifier rather than as a name, because names change and a record that no longer resolves defends nothing.

The same applies to automated verification, and there it is a strength rather than a weakness. An automated execution is often better evidence than a person's word, because the trigger, the version, the inputs and the outputs are all machine-recorded. What it still needs is the identity of whoever or whatever triggered it, plus the stored output, so the chain closes.

Retention means readability, not storage

Retention is routinely misread as a storage question: keep the rows for some number of years and the obligation is met. It is a readability question. Suppose a product's agreed window is seven years. For a record to still mean anything in year six, all of the following must survive alongside it:

the stored outputs the record points at, in a form still openable;
the meaning of the identifiers used, so a requirement identifier still resolves to a requirement;
the version scheme, so a build identifier can still be tied to code;
enough surrounding description that a reader who never met the system can follow it.

A record that survives while everything it references is pruned is not evidence; it is a citation to a missing document. Deciding retention therefore means deciding what else you are committing to preserve, and that commitment is usually larger and more awkward than the rows themselves.

What weak evidence looks like

A pass or fail with no version attached.
An outcome summarised from output that was afterwards deleted.
A performer recorded as a shared account or a mutable display name.
Conditions left unstated, so nobody can tell what the result was true of.
A record written after the release from recollection and not marked as such.
A retention window applied to the rows but not to what they reference.

## What changes when the reader is outside the team Inside a team, verification evidence is largely conversational. Someone remembers that the refund path was checked before the release, and where the memory is thin, the person who did it is two desks away. That arrangement works because the reader can always ask a follow-up question. Evidence written for an outside reader — an external assessor, a customer running their own review, a successor team five years on, or your own organisation in a dispute — has to survive without that follow-up. Every question the reader might ask has to have been anticipated and answered inside the record, at the moment the work was done, because the moment cannot be revisited. That is the whole difference, and every required field falls out of it. ## The fields, and what each defends against | Field | What it must carry | The question it closes | | --- | --- | --- | | The thing verified | The identifier of a requirement or one acceptance criterion, plus its statement in words | Verified against what understanding of the requirement? | | The version verified against | A build or revision identifier — not a date, not "the current release" | Which code actually passed? | | The performer | An identity resolvable to one person or one automated agent, and what triggered it | Who is accountable for this result? | | The time | When the verification ran, not when the record was written | Was this before or after the change that concerns me? | | The outcome and its basis | Pass or fail, plus the stored output the outcome was read from | How do I know the outcome was read correctly? | | The conditions | The environment and the dataset used | Would this result hold where it matters? | | Retention | How long the record and everything it points at stay readable | Can I still read this when I need it? | Two rows carry most of the weight. **The version** is the one teams omit first and regret first: a record saying a requirement passed on a given date, in a product that ships several times a day, identifies nothing. **The stored output** is the one teams destroy first: summarising an execution down to the word *pass* and deleting what it produced turns evidence into an assertion, and an assertion from an interested party is not evidence to anyone outside. ## Attribution, and why shared identities break it A performer field naming a shared delivery account, an automation account everyone triggers, or a display name that a later rename overwrites, cannot be resolved to anybody afterwards. The record then proves only that the organisation says the work happened, which is what it was already claiming. Attribution wants an identity that pinned to one individual at the moment of recording, stored as a stable identifier rather than as a name, because names change and a record that no longer resolves defends nothing. The same applies to automated verification, and there it is a strength rather than a weakness. An automated execution is often better evidence than a person's word, because the trigger, the version, the inputs and the outputs are all machine-recorded. What it still needs is the identity of whoever or whatever triggered it, plus the stored output, so the chain closes. ## Retention means readability, not storage Retention is routinely misread as a storage question: keep the rows for some number of years and the obligation is met. It is a readability question. Suppose a product's agreed window is seven years. For a record to still mean anything in year six, all of the following must survive alongside it: - the stored outputs the record points at, in a form still openable; - the meaning of the identifiers used, so a requirement identifier still resolves to a requirement; - the version scheme, so a build identifier can still be tied to code; - enough surrounding description that a reader who never met the system can follow it. A record that survives while everything it references is pruned is not evidence; it is a citation to a missing document. Deciding retention therefore means deciding what else you are committing to preserve, and that commitment is usually larger and more awkward than the rows themselves. ## What weak evidence looks like - A pass or fail with no version attached. - An outcome summarised from output that was afterwards deleted. - A performer recorded as a shared account or a mutable display name. - Conditions left unstated, so nobody can tell what the result was true of. - A record written after the release from recollection and not marked as such. - A retention window applied to the rows but not to what they reference.

Why record the exact build identifier rather than the date the verification ran?
A date identifies a window, not code. In a product that ships several times a day, several distinct builds existed on any given date, and the one that passed may not be the one that shipped. A build or revision identifier ties the result to a specific state of the system that can still be reconstructed later, which is the only form of the claim an outside reader can check.
What else has to be preserved for a retained evidence record to still mean something?
Everything it points at or depends on: the stored outputs in a still-openable form, the identifier scheme so a requirement identifier still resolves, the version scheme so a build identifier can still be tied to code, and enough description that a reader who never met the system can follow it. A record whose references were pruned around it is a citation to a missing document.

saying these in an interview costs you the question

Records only pass or fail, with no version attached
Names a shared account as the performer of the work
Deletes raw output and keeps the summary of it
Says the latest build identifies a version
Treats retention as disk space rather than readability

What must a verification evidence record carry for a reviewer outside the team to rely on it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What changes when the reader is outside the team

The fields, and what each defends against

Attribution, and why shared identities break it

Retention means readability, not storage

What weak evidence looks like

▾common follow-ups2 questions

▾red flags5 flags

What changes when the reader is outside the team

The fields, and what each defends against

Attribution, and why shared identities break it

Retention means readability, not storage

What weak evidence looks like

answer

go deeper