4. Risk register architecture for pretest NCAP

A pretest NCAP readiness review produces a large volume of findings in a short window: unresolved test-matrix gaps, ambiguous Euro NCAP or C-NCAP protocol interpretations, vehicle build-state mismatches, instrumentation calibration drift, and open supplier dependencies. Without a disciplined register architecture, these findings degrade into a flat spreadsheet that cannot be filtered by protocol clause, cannot be assigned to a single accountable owner, and cannot be audited when a rating outcome is challenged. This section defines the structural rules that make the register usable as an engineering control instrument rather than a meeting artifact.

Risk taxonomy: separating what can invalidate a rating from what can delay a test

The first architectural decision is the taxonomy. A pretest NCAP register should classify every entry along two independent axes, because the two axes drive different escalation paths and different closure evidence.

The risk domain axis describes the technical source of the risk. A practical five-domain split for NCAP pretest work is:

• Protocol interpretation (P) — uncertainty in how a clause is read, e.g. whether a pedestrian protection test point falls inside the defined wrap-around area, or how a far-side occupant exemption is applied.
• Vehicle build state (V) — the physical test object does not match the declared configuration: trim level, seat variant, battery state of charge, tyre specification, or software calibration.
• Test facility and instrumentation (F) — sled or barrier alignment, dummy certification status, high-speed camera frame rate, onboard data acquisition sample rate, or calibration expiry.
• Supplier and dependency (S) — an airbag ECU calibration, a restraint supplier's CAE correlation report, or a component delivery that gates the build.
• Evidence and documentation (E) — missing test reports, incomplete photo documentation, or a calculation note that cannot be reconstructed for the technical service.

The rating impact axis is orthogonal and should be a small ordinal scale, not a free-text field. A three-level scale works well: Rating-critical (could change star count or a sub-score), Test-validity (could invalidate a test run and force a retest), and Schedule (affects timing only). The combination of domain and impact determines the review cadence: a P-domain, rating-critical item must be resolved with the technical service before the test, whereas an E-domain, schedule item can be closed by a documentation owner within the week.

ID conventions: making every entry addressable and sortable

Identifiers must be stable, human-readable, and sortable without a lookup table. A segmented convention is the most practical:

NCAP-PT-<DOMAIN>-<PROTOCOL>-<NNN>

NCAP-PT-P-AEB-014
NCAP-PT-V-FRONT-007
NCAP-PT-F-SIDE-003
NCAP-PT-S-AEB-021
NCAP-PT-E-PED-002

Here NCAP-PT fixes the programme and phase (pretest), the domain letter comes from the taxonomy, the protocol token identifies the assessment area (AEB, FRONT, SIDE, PED, VRU), and the three-digit sequence is monotonic within that segment and never reused. When an item is closed and later reopened, the original ID is retained and a revision suffix is appended, e.g. NCAP-PT-P-AEB-014-R1. This preserves the audit trail: a reviewer can see that the same interpretation question recurred rather than mistaking it for a new finding.

Two conventions prevent the most common failures. First, never encode the owner or the due date in the ID — both change, and an ID that embeds a name becomes misleading after reassignment. Second, reserve a separate prefix for cross-cutting items that genuinely span domains, such as NCAP-PT-X-, rather than forcing them into an ill-fitting domain.

Ownership model: one accountable owner, explicit contributors

Every register entry needs exactly one accountable owner and any number of contributors. The accountable owner is the person who can declare the risk closed and who signs the closure evidence; contributors supply analysis or artifacts but cannot close the item. In practice the ownership mapping follows the domain:

The ownership model must also define escalation. A rating-critical item that remains open past its review gate escalates automatically to the readiness review board, which has authority to accept the residual risk, defer the test, or reallocate resources. This rule should be written into the register's front matter, not left to informal practice.

Traceability to requirements: linking each risk to a clause and a test

The register's value in an audit depends on bidirectional traceability. Each entry should carry at least three links: the requirement reference (protocol and clause, e.g. Euro NCAP AEB VRU v4.2, clause 3.4.1), the affected test case (the specific test ID in the test matrix), and the verification artifact (the report, calculation, or sign-off that will demonstrate closure).

Traceability should be maintained in both directions. From the requirement side, a coverage view answers: which clauses of the protocol have at least one open risk, and which have none? A clause with no risk entry is either genuinely low-risk or simply unexamined — the review board must distinguish the two. From the test side, a readiness view answers: which scheduled tests still have open rating-critical risks attached? A test with an open rating-critical item should not be released to the facility.

Working the register: a concrete example

Consider a finding raised during a pretest review: the AEB vulnerable road user test matrix specifies a pedestrian crossing speed of 5 km/h, but the protocol revision in force defines the target speed with a tolerance band that the test facility's pedestrian dummy carriage cannot hold at low speed. The entry is created as NCAP-PT-P-AEB-014, domain P, impact rating-critical, owner the NCAP homologation lead. The requirement link points to the AEB VRU clause, the test link points to TM-AEB-VRU-07, and the verification artifact is a written clarification from the technical service confirming the acceptable speed tolerance.

Until that clarification arrives, the test remains blocked. The coverage view shows one blocked test and flags the clause as having an open rating-critical risk. If the clarification is not received by the pre-test gate, the item escalates to the readiness review board, which must either accept the residual risk with a documented rationale or defer the test. This is the practical payoff of the architecture: the register does not merely record that a problem exists, it forces a decision at a defined gate with a named accountable person and a traceable evidence trail.

Register front matter and review cadence

The register should open with a short front-matter block that fixes the rules: the taxonomy definitions, the ID convention, the impact scale, the ownership mapping, the escalation threshold, and the review cadence. For a typical pretest programme, a weekly working review handles schedule and evidence items, while a gate review at T-14 and T-7 days before each test block handles rating-critical and test-validity items. The front matter is version-controlled alongside the register so that any change to the taxonomy or ID rules is itself auditable.

Finally, the register should be exportable in a form that supports the two views described above — a requirement-coverage view and a test-readiness view — without manual rework. If the register is maintained in a spreadsheet, these are pivot tables over the domain, impact, requirement, and test-case columns; if maintained in a requirements management tool, they are saved queries. Either way, the architecture described here — closed taxonomy, segmented stable IDs, single accountable owners, and bidirectional traceability — is what makes those views meaningful and keeps the pretest NCAP readiness review defensible.