2. Evidence readiness lifecycle

In NCAP rating work, evidence is not something assembled after the test programme finishes. It is a controlled asset that begins at programme kick-off, matures through each test event, and must survive scrutiny long after the last dummy has been inspected. A vehicle can pass every physical test and still lose a star if the evidence chain is incomplete, inconsistent, or untraceable. This chapter treats evidence readiness as a lifecycle with four distinct phases — planning, generation, consolidation, and audit — and explains how each phase feeds the rating decision.

Why the lifecycle view matters

Assessment bodies such as Euro NCAP, ASEAN NCAP, and Latin NCAP publish protocols that specify not only what must be demonstrated but how it must be documented: witness requirements, calibration certificates, channel lists, video coverage, and photo evidence of setup geometry. A common failure mode is treating these as administrative overhead and reconstructing them retrospectively. Retrospective reconstruction almost always produces gaps — a missing calibration certificate for a load cell used three months earlier, a camera angle that does not show the pedal displacement reference, or a channel name in the data file that does not match the test request. The lifecycle approach front-loads these constraints so that each test produces audit-ready evidence by default.

Phase 1 — Pre-submission planning

Planning converts the applicable protocol into an evidence requirements register. For each planned test, the register should capture: the protocol clause being demonstrated, the physical test or simulation that generates the evidence, the responsible party, the evidence artefacts expected (data files, video, photos, certificates, signed witness sheets), the storage location, and the acceptance criteria. Building this register early exposes dependencies — for example, that a pedestrian head-impact test requires both a certified impactor calibration and a photographic record of the bonnet reference grid before the first shot.

A practical technique is to derive the register directly from the protocol's test and documentation clauses rather than from the engineering test plan, because the two are not identical. The engineering plan optimises for development insight; the evidence register optimises for defensibility. Where they diverge, the stricter requirement governs.

Treat the evidence register as a living document with a named owner per row. Unowned evidence requirements are the ones that go missing.

Phase 2 — Evidence generation during testing

During execution, evidence readiness depends on discipline at the test cell. Three controls matter most. First, pre-test verification: confirm that all measurement channels are live, named according to the agreed channel list, and time-synchronised with video; confirm calibration validity dates; and capture the setup photographs specified in the register before any dynamic event. Second, in-test capture: ensure the required camera views are recording and that witness attendance is logged. Third, post-test sealing: export raw data immediately, compute and record checksums, and store files in the controlled location with a naming convention that encodes test ID, date, and artefact type.

A reproducible naming and integrity convention removes ambiguity at audit. For example:

NCAP/2025/VEH-07/PED-HEAD/
  T-PH-014_20250312_raw.mf4
  T-PH-014_20250312_raw.mf4.sha256
  T-PH-014_20250312_video_cam1.mp4
  T-PH-014_20250312_setup_photos/
  T-PH-014_20250312_witness_sheet.pdf
  T-PH-014_20250312_calibration_refs.pdf

The checksum file is not bureaucracy: it allows an auditor to confirm that the data file reviewed months later is byte-identical to the file generated at the test cell. Where a file has been re-exported or converted, the conversion log should be retained alongside it.

Phase 3 — Consolidation and internal review

Consolidation is where most rating risk is introduced or eliminated. The evidence package for each protocol clause is assembled, cross-checked against the register, and reviewed by someone who did not run the test. The reviewer's job is adversarial: can every claimed result be traced to a raw artefact, and does every artefact satisfy its acceptance criteria? Typical findings at this stage include channel scaling errors, video that does not cover the full impact event, missing pre-test photographs, and results reported to more precision than the measurement uncertainty supports.

Consolidation should also reconcile the evidence against the rating calculation itself. If a star rating depends on a points threshold, the reviewer must be able to reconstruct the point allocation from the evidence package alone. Any point that cannot be reconstructed is a point at risk.

Phase 4 — Post-test audit and the rating decision

The assessment body's audit is the final gate. Auditors sample evidence, request clarifications, and may witness re-tests. The quality of the earlier phases determines whether the audit is a confirmation exercise or a negotiation. Evidence that is complete, internally consistent, and traceable supports the rating decision directly; evidence with gaps forces either conservative interpretation (points disallowed) or conditional acceptance with follow-up obligations.

The diagram below shows how evidence maturity and rating confidence move together across the lifecycle, and where the two most common failure points occur.

Evidence readiness lifecycle and its effect on rating confidence Four phases from pre-submission planning through post-test audit, showing evidence artefacts produced at each phase, maturity progression, and two failure points that reduce rating confidence. 1 · Planning Pre-submission • Protocol clause map • Evidence register • Channel list • Calibration plan • Witness schedule • Naming convention Output: approved register + test readiness gate 2 · Generation During testing • Raw data (.mf4) • Video (all views) • Setup photos • Witness sheets • Calibration refs • SHA-256 checksums Output: sealed test artefacts in controlled store 3 · Consolidation Internal review • Package per clause • Traceability check • Independent review • Point reconstruction • Uncertainty check • Gap closure log Output: reviewed evidence package 4 · Audit Assessment body • Evidence sampling • Clarifications • Possible re-test • Clause sign-off • Rating decision Output: confirmed rating + audit record Evidence maturity Low — plan only High — audit-ready ! FP-1: missing pre-test capture / bad channel names ! FP-2: unreconstructable point allocation

How evidence shapes the rating decision

The rating decision is a mapping from demonstrated performance to protocol points, and evidence is the warrant for that mapping. Three properties of evidence determine whether the warrant holds. Completeness means every claimed point has a corresponding artefact that satisfies the protocol's documentation clause. Consistency means the artefacts agree with each other — the channel list matches the data file, the video timestamp matches the data timestamp, the reported value matches the raw trace. Traceability means an independent reviewer can follow the chain from the final report back to the raw measurement without relying on the author's memory.

When any of these properties fails, the auditor has limited options. The most common outcome is that the affected points are disallowed, which can move a vehicle across a star boundary. Less commonly, the assessment body accepts the evidence conditionally and requires a corrective action, which delays the rating and may require a re-test. In both cases the cost is far higher than the cost of building the evidence correctly in the first place.

A worked example of the lifecycle in practice

Consider a frontal offset test intended to support a points claim under an occupant protection clause. At planning, the register records the clause, the test ID, the required channels (vehicle acceleration, seat-belt load, dummy channel set), the camera views, the calibration validity window, and the witness requirement. At the test cell, the engineer verifies channel names against the list, confirms calibration dates, photographs the barrier alignment and dummy positioning, and starts recording before the sled release. After the event, raw data is exported, checksummed, and stored under the agreed path; the witness sheet is signed and scanned.

At consolidation, an independent reviewer opens the package and attempts to reconstruct the claimed points from the raw data alone. Suppose the reviewer finds that the seat-belt load channel was recorded with a scaling factor of 10× the agreed value. The raw trace is intact, so the error is correctable by re-scaling with a documented conversion log — but only because the raw data and channel list were preserved. Had the team exported only processed results, the claim would have been unreconstructable and the points at risk. This illustrates the central principle: preserve raw evidence and document every transformation.

Never overwrite raw files with processed versions. Store processed outputs in a separate directory and record the transformation parameters, software version, and operator in a conversion log.

Practical controls that keep the lifecycle healthy

  • Readiness gate before each test: a short checklist confirming channel list match, calibration validity, camera coverage, witness availability, and storage path — signed by the test engineer.
  • Same-day sealing: raw export, checksum, and storage completed before the test cell is reconfigured for the next event.
  • Independent review: a reviewer who did not execute the test attempts point reconstruction from the package alone.
  • Gap closure log: every identified gap is recorded with owner, action, and closure evidence, so the audit trail shows how gaps were resolved.
  • Post-audit lessons capture: clarifications requested by the assessment body are fed back into the evidence register template for the next programme.

The lifecycle closes the loop: audit findings become planning inputs. A programme that treats the post-test audit as a learning event, rather than a one-off hurdle, steadily reduces the friction of future submissions and protects the rating outcome that the engineering work has earned.

← Previous 📖 Contents Next →