3. Score recalculation triggers

A crash test score is not a permanent property of a test. It is a computed result that depends on a chain of inputs: raw sensor channels, the calibration state of those sensors, the firmware that sampled and filtered the data, the injury criteria version applied to the filtered signals, and the integrity of the data record itself. When any link in that chain changes, the previously published score may no longer be defensible. A recalculation trigger is the formal event that tells the audit trail "the inputs changed, so the output must be re-derived and re-justified."

This chapter covers the four trigger classes that appear most often in real programs: post-test sensor calibration drift, firmware updates, revised injury criteria, and data correction requests. For each, the goal is the same — decide whether a recalculation is required, scope it correctly, and leave evidence that the decision was deliberate rather than accidental.

Trigger 1: Post-Test Sensor Calibration Drift

Accelerometers, load cells, and angular-rate sensors are calibrated before the test, but their post-test calibration check is what actually validates the measurement. A common acceptance band for a uniaxial accelerometer is a sensitivity deviation within ±5% of the pre-test value and a zero offset within a small absolute limit (for example ±2 g equivalent). When the post-test check falls outside the band, the channel is suspect, and every injury value derived from it inherits that suspicion.

The practical question is not "did drift occur" but "does the drift materially change the score." A useful procedure is to bound the effect before committing to a full recalculation:

1. Record the pre-test and post-test sensitivity and zero offset for the affected channel.
2. Apply the worst-case correction to the raw signal — scale by the ratio of post-test to pre-test sensitivity, and shift by the offset difference.
3. Recompute the governing injury criterion (HIC, Nij, chest deflection, etc.) on the corrected signal.
4. Compare against the published score and against the criterion threshold.

If the corrected value stays on the same side of the threshold and the delta is within the reporting tolerance, a documented sensitivity check may be sufficient. If the corrected value crosses a threshold or changes a star rating, a full recalculation with a formal trigger record is mandatory. The trigger record should name the channel, the calibration values, the correction applied, and the resulting delta.

Trigger 2: Firmware Updates

Data acquisition firmware affects the score in ways that are easy to overlook: anti-alias filter corner frequencies, sample-rate decimation, channel scaling coefficients, and the order of operations in the CFC (Channel Frequency Class) filtering chain. A firmware update that changes any of these can shift HIC or other criteria by a small but real amount, even when the raw transducer output is identical.

The correct handling is a firmware impact assessment, not an automatic full recalculation of every historical test. The assessment asks three questions: does the new firmware change the signal processing path, does it change scaling or calibration coefficients, and does it change the file format or metadata written to the data record? If the answer to all three is no, the firmware update is recorded as a non-impacting change. If any answer is yes, tests processed under the old firmware are flagged, and the program decides — based on the magnitude of the processing change and the margin to thresholds — whether to reprocess.

A reproducible check is to take one archived raw data file, process it under both firmware versions, and compare the resulting filtered channels and criteria. A delta table like the one below makes the decision auditable:

In this example the deltas are small and the margins are large, so the firmware change is recorded as assessed and non-triggering. Had HIC moved from 690 to 705, the threshold crossing would force a recalculation regardless of how small the absolute delta looked.

Trigger 3: Revised Injury Criteria

Regulations and rating protocols revise their injury criteria periodically — a new HIC interval, a changed Nij intercept, an updated chest deflection limit, or a revised age-dependent scaling. When the governing criteria version changes, every score computed under the old version becomes a candidate for recalculation. The key distinction is between a criteria revision that changes the computation and one that changes only the threshold.

A threshold-only change does not require reprocessing the raw data; the existing criterion value is compared against the new limit, and the score is re-derived from the same computed quantity. A computation change — for example, a different integration window for HIC or a revised filter class — requires reprocessing the filtered signal and therefore a full recalculation. The trigger record must state which type of change occurred, because the two demand different evidence: a threshold change needs the old and new limits plus the unchanged criterion value; a computation change needs the reprocessed signal and the new criterion value.

Trigger 4: Data Correction Requests

Data correction requests originate from channel mapping errors, mislabeled test configurations, transducer polarity reversals, or discovered transcription mistakes in the test metadata. These are the most sensitive triggers because they involve changing the record itself rather than re-deriving a result from an unchanged record. The audit trail must preserve the original value, the corrected value, the reason, the authority who approved the correction, and the effect on the score.

A correction request should be treated as a controlled change: the original data file is retained immutably, the correction is applied as a documented transformation, and the recalculation is run against the corrected input. If the correction does not change the score, that outcome is still recorded — a "no score impact" finding is itself audit evidence.

Deciding and Documenting the Trigger

The four trigger classes share a common decision logic: identify the changed input, bound its effect on the governing criterion, compare against thresholds and tolerances, and record the decision with enough detail that an independent auditor can reproduce it. The figure below shows how the four triggers converge on a single recalculation decision and how the evidence branches depending on whether the change affects computation or only comparison.

The decision is deliberately conservative at the threshold: a crossing forces recalculation even when the absolute delta is small, because the published score's defensibility depends on which side of the limit it sits, not on how far it moved. Conversely, a large delta that stays comfortably within the margin can be closed with a documented sensitivity check, provided the check itself is reproducible.

What the Trigger Record Must Contain

Regardless of which trigger fired, the record should be self-contained enough that a reviewer who was not present can follow the reasoning. At minimum it should capture the trigger class and identifier, the affected test and channel, the before and after input values, the assessment method and its result, the recalculation outcome (including "no change"), the criteria version applied, and the approver. The record is the bridge between the raw data and the published score, and it is the first thing an auditor will ask for when a score is challenged.