2. Evidence artifacts and lifecycle

Safety evidence is not a single document; it is a set of artifacts that each answer a different question, and whose meaning depends on when in the V-model they were produced and what they were produced against. A test specification says what should be verified and why; a test result says what actually happened; a coverage report says how much of the intended verification space was exercised; a model version says which executable representation of the design was under test. Traceability links are the connective tissue that lets an assessor move from a requirement to a test, from a test to a result, and from a result back to the exact model and configuration that produced it. This chapter defines these artifacts, their lifecycle states, and the precise semantics of the links that join them.

Artifact classes and what each one asserts

Each evidence artifact carries a distinct claim. Confusing these claims is one of the most common causes of weak safety cases, because a passing test result is often presented as if it proved requirement coverage, when in fact it only proves that one specified stimulus produced one observed outcome on one configuration.

The critical discipline is that a test result must reference the revision of the test specification it executed, not merely its identifier. If the specification is later edited—say a tolerance is widened—the old result no longer supports the new specification, and the link must be invalidated or re-established. Treating identifiers as stable while ignoring revisions silently breaks the evidence chain.

Lifecycle states and why they matter for traceability

Artifacts move through states, and a traceability link is only meaningful when both endpoints are in compatible states. A reasonable lifecycle for a test specification is draft → reviewed → approved → executed → superseded/retired. A test result is recorded → reviewed → accepted (or rejected on anomaly). A model version is in work → frozen at baseline → released. Coverage reports are generated → assessed → accepted.

The practical rule: a link from a requirement to a test specification is only "satisfied" when the specification is approved and at least one accepted result exists against the same specification revision and a released model version. Any state mismatch downgrades the link to "pending" or "stale." This is what prevents a safety case from citing a draft test or a result produced against a superseded model.

Link semantics across V-model phases

Not all traceability links mean the same thing. A link from a system requirement to a system test specification is a verification relation; a link from a system requirement to a software requirement is a decomposition/refinement relation; a link from a test result to a model version is an execution context relation. Mixing these into a single undifferentiated "traces-to" edge destroys the ability to reason about the evidence. The figure below shows the artifact graph with typed links and the phase boundaries they cross.

Two link types deserve special attention. The subject-of link (test specification → model version) is what makes a result reproducible: without it, a passing result cannot be tied to the design it verified. The measures link (coverage criterion → coverage report) is what makes a coverage number interpretable: "96.4% MC/DC" is meaningless unless the report states which decision set and which model version it was measured against.

Worked example: establishing a valid evidence chain

Consider a brake-by-wire controller. Requirement REQ-SYS-014 (rev 3) states that the actuator must reach commanded pressure within 80 ms under nominal supply. The team writes test specification TS-014-02 (rev 2) with a step-input stimulus, a precondition of supply voltage 12.0 V ± 0.2 V, and a pass criterion of settling time ≤ 80 ms measured at the pressure sensor output. The model MDL-BRK-01 is frozen at v1.4.2 and released. Execution on configuration CFG-A with toolchain v5.1 produces result TR-014-02-017 with measured settling time 71 ms and verdict pass.

To accept this chain, the reviewer checks four conditions in order:

1. The specification revision executed (rev 2) equals the currently approved revision. If rev 3 exists, the result is stale.
2. The model version referenced by the result is the released v1.4.2, not a working copy.
3. The execution context (CFG-A, toolchain v5.1) matches the configuration declared in the test specification's preconditions.
4. The coverage report CR-014 was generated from the same model version and the same test set that includes this result.

If any condition fails, the link status becomes stale or pending, and the safety case must not cite the result as satisfying the requirement until re-execution or re-baselining occurs. A common failure symptom is a coverage report showing high coverage while the underlying results were produced against an older model—an inconsistency that only surfaces when the model-version field is compared across artifacts.

Practical artifact record template

The following record structure, applied per artifact, keeps the chain auditable. Fields are illustrative and should be adapted to the organization's configuration management system.

artifact:
  id:            TS-014-02
  class:         test_specification
  revision:      2
  state:         approved
  baseline:      BL-2024-11
  links:
    - type: verifies
      target: REQ-SYS-014
      target_revision: 3
    - type: subject-of
      target: MDL-BRK-01
      target_version: 1.4.2
  preconditions:
    supply_voltage: "12.0 V +/- 0.2 V"
    config: CFG-A
  pass_criteria:
    settling_time_ms: "<= 80"
  results:
    - TR-014-02-017   # pass, accepted, same baseline

The lifecycle discipline is what turns a folder of documents into evidence. Each artifact must be revision-pinned, state-tracked, and joined to its neighbors by a typed link that carries a baseline. When those three properties hold, an assessor can traverse from any requirement to the exact model, test, result, and coverage measurement that support it—and can see immediately when any of them has drifted out of alignment.