2. Anatomy of a protocol change

A protocol change rarely arrives as a single clean statement. In NCAP programmes it typically lands as a bundle: a formal amendment document (often a UN Regulation amendment, a Euro NCAP protocol revision, or a C-NCAP management rule update), a change log or "summary of changes" annex, and a technical rationale explaining why the requirement moved. The assessment engineer's first job is not to decide impact but to reconstruct the change precisely enough that impact can later be judged. This section treats that reconstruction as a disciplined parsing exercise with three distinct evidence streams that must be cross-checked against each other.

Why the three streams must be read together

Each stream answers a different question. The amendment document answers what the normative text now says — the binding requirement, test procedure, or pass/fail criterion. The change log answers what the drafting body believes it changed — a curated delta list, usually with clause references and a change type (new, amended, deleted, editorial). The technical rationale answers why — the field data, research study, or harmonisation motive that justified the change. None is sufficient alone. Change logs are frequently incomplete or over-broad; rationale documents sometimes describe intent that the normative text failed to capture; and the amendment text itself may contain consequential edits (renumbering, cross-reference shifts, unit changes) that no log flags. A programme that reads only the change log will miss silent normative drift; a programme that reads only the amendment will waste effort re-testing editorial renumbering.

Structuring the parse: clause-level extraction

The practical unit of parsing is the clause, not the document. For each clause touched by the amendment, extract a fixed record so that later comparison across vehicle programmes is possible. A workable extraction schema for NCAP work is:

• Clause identifier and title — the exact numbering in the new text, plus the old numbering it replaces (renumbering is a common source of false positives).
• Change classification — normative-technical, normative-administrative, editorial, or deletion. Only the first two normally drive test or documentation impact.
• Parameter delta — the specific quantity that moved: a speed threshold, a tolerance band, a dummy variant, a measurement point, a dwell time, a scoring weight.
• Direction and magnitude — old value → new value, with units preserved exactly as written.
• Applicability trigger — the vehicle category, seating configuration, or date-of-application boundary that determines whether the clause reaches a given programme.
• Rationale reference — the paragraph in the technical rationale that justifies the change, or an explicit "no rationale stated".

This schema is deliberately parameter-centric because NCAP impact almost always propagates through a changed quantity or boundary condition, not through changed prose. A clause that reads differently but specifies the same numbers is editorial; a clause that reads almost identically but shifts a threshold by 5 km/h is a full re-validation trigger.

Worked parsing example

Consider a hypothetical amendment bundle for a frontal impact protocol. The change log states: "Test speed for the frontal offset test increased; assessment criteria aligned with updated dummy instrumentation." That single sentence hides at least three separable deltas. Parsing the normative text clause by clause might yield the following extraction (values are illustrative, chosen to demonstrate the method, not taken from any published protocol):

Note what the change log's single sentence concealed: the speed change and the dummy change have different applicability triggers. The speed increase applies to all M1 vehicles from the application date, while the THOR dummy requirement applies only to new type approvals. A programme already holding type approval for an existing variant may face the speed change but not the dummy change — a distinction invisible in the log summary and decisive for scoping. This is exactly the kind of discrepancy the reconciliation step is designed to surface.

Reading the technical rationale for impact signals

The rationale document is not merely background. It tells you which failure modes the drafting body expects the change to expose, and therefore where your programme's risk concentrates. Three rationale patterns recur in NCAP work and each implies a different assessment posture:

• Field-data-driven tightening — rationale cites real-world crash or incident data showing the old threshold under-protected occupants. Implication: expect the new threshold to be genuinely harder to pass, and expect your existing margin analysis to be invalidated. Re-baseline, do not interpolate.
• Harmonisation — rationale cites alignment with another regulation or protocol. Implication: the change may be neutral or even favourable for a programme already compliant with the harmonised source; check whether your existing evidence transfers.
• Instrumentation or methodology update — rationale cites improved measurement capability (new ATD, new sensor, revised filtering). Implication: the measured value may shift even if the physical performance is unchanged. This is the most commonly underestimated category, because it looks like a test-method change but behaves like a criterion change.

Reconciling the streams: the discrepancy register

The final parsing artefact is a short discrepancy register recording every point where the change log, the normative text, and the rationale disagree. Typical entries: a clause the log marks "editorial" that in fact alters a tolerance; a rationale that justifies a change the normative text does not actually implement; a deleted clause whose cross-references elsewhere were not updated. Each entry carries a disposition — confirmed normative, log error, text error requiring clarification request, or open. The register is what makes the subsequent impact assessment defensible: it demonstrates that the delta was reconstructed from primary evidence rather than accepted from a summary.

From parse to scoping decision

The parse is complete when every normative-technical delta has an applicability trigger and a rationale reference, and every discrepancy has a disposition. At that point the programme can make its first scoping call: which deltas reach the vehicles in scope, and which are filtered out by applicability boundaries or by editorial classification. That filtered set — not the raw change log — is the correct input to the impact assessment that follows. Programmes that skip this discipline routinely over-scope (re-testing editorial renumbering) or under-scope (missing a methodology-driven criterion shift hidden inside a "test method update" line). The clause-level extraction and the discrepancy register are the two artefacts that prevent both errors, and they are cheap to produce relative to the cost of a mis-scoped validation campaign.