3. Readiness review lifecycle

A pretest NCAP readiness review is not a single meeting. It is a controlled lifecycle that starts long before the first sled pulse or barrier impact and ends only when the evidence package is accepted as sufficient to support the projected star rating. The lifecycle exists to answer one question at every stage: do we have enough verified evidence, at the right maturity, to defend the rating we intend to claim? Treating the review as an event rather than a lifecycle is the most common reason programmes arrive at the formal review with unresolved open points and are forced into a conditional pass that later collapses.

This chapter defines the four structural elements of that lifecycle — entry criteria, review milestones, exit gates, and the coupling to design freeze and tooling kick-off — and shows how they interlock so that rating risk is retired progressively rather than discovered late.

Entry criteria: what must be true before the review clock starts

Entry criteria are the preconditions that make a readiness review meaningful. If they are not met, the review will spend its time on missing inputs instead of on rating risk. In practice, entry criteria should be defined per review level and should be objectively checkable — a named document, a released CAD level, a signed test request, a populated risk register — not a subjective judgement such as "design is mature enough."

A workable entry set for a vehicle-level pretest readiness review typically includes:

• Frozen test matrix and load cases. The set of NCAP protocols, configurations, and load cases under review is baselined, with variant coverage (LHD/RHD, seat rows, powertrain, wheel sizes) explicitly listed.
• Released CAE model at a declared maturity. The simulation model corresponds to a specific CAD/BIW level, with correlation status against previous physical tests stated, not assumed.
• Occupant restraint and body hardware definition. Airbag, pretensioner, seat, and steering column states are defined to a revision, including calibration intent.
• Populated rating risk register. Each projected star-critical attribute has an owner, a current confidence level, and an evidence reference.
• Test facility and tooling availability confirmed. Sled, barrier, and dummy resources are booked against the milestone dates.

Entry criteria should be reviewed by the readiness owner, not by the presenting team, to avoid the familiar pattern where a team declares itself ready because the calendar says so. A simple gate check — each criterion marked met, partially met with an accepted deviation, or not met — is sufficient, provided that "not met" blocks the milestone rather than being logged as an action.

Review milestones: a staged evidence ladder

Milestones are the points at which evidence maturity is formally assessed. They should be staged so that each milestone retires a defined class of risk, and so that the cost of a negative finding grows predictably as the programme advances. A three-tier structure works well for NCAP readiness:

Each milestone should have a defined evidence standard. At M2, for example, it is not enough that CAE predicts a five-star outcome; the model must be correlated to physical data within a stated tolerance for the relevant injury criteria, and the correlation basis must be documented. A CAE prediction from an uncorrelated model is a hypothesis, not evidence, and should be recorded in the risk register as such.

Exit gates: the decision, not the presentation

An exit gate is the formal decision that closes a milestone. It differs from the review itself: the review examines evidence, the gate records the outcome and its consequences. Three outcomes should be available, and all three should be legitimate:

• Pass. All exit criteria met; the programme proceeds to the next milestone.
• Conditional pass. A bounded set of open points with named owners, dated closure, and an explicit statement of what rating risk remains open. Conditional passes must carry a re-review date, otherwise they silently become passes.
• Hold. Exit criteria not met; the milestone does not close and dependent activities are re-planned.

The exit gate is also where the rating risk register is formally updated. Every open point that survives the gate must appear in the register with a residual risk statement, and every closed point must cite the evidence that closed it. This is what makes the register a living control document rather than a retrospective summary.

Linkage to design freeze and tooling kick-off

The readiness lifecycle does not float above the product development process; it is coupled to two hard programme events. Design freeze is the point after which geometry and hardware changes carry tooling and validation cost; tooling kick-off is the point after which those costs become largely irreversible. The review milestones must therefore be positioned so that rating risk is retired before these events, not after.

The practical coupling is as follows. M2 (design readiness) must close before design freeze for any attribute that would require a geometry or hard-point change to fix. If M2 closes conditionally with an open structural or restraint-layout risk, that risk is effectively transferred past the freeze and can only be mitigated through calibration or added hardware — a narrower and more expensive solution space. Similarly, M3 must close before tooling kick-off for any attribute whose confirmation depends on production-intent parts, because tooling kick-off commits the part definition that the physical test will eventually validate.

The figure below shows the lifecycle as a coupled sequence: entry criteria feeding each milestone, exit gates producing pass/conditional/hold decisions, and the two programme events acting as hard constraints on when each gate must close.

Making the lifecycle operational

Three practices turn this structure from a diagram into a working control system. First, date the gates, not just the reviews. Each exit gate should have a planned closure date and a latest acceptable closure date derived from the coupled programme event. If Gate 2's latest acceptable closure is two weeks before design freeze, that date — not the review meeting — is the real deadline the team manages to.

Second, carry a single risk register across all milestones. The register is the continuity between gates: an item opened at M1 and still open at M3 is visible as a persistent risk, and its age is itself a signal. A star-critical attribute that has been "medium confidence" for three milestones is not medium confidence; it is unverified, and the gate decision should reflect that.

Third, define the evidence standard before the review, not during it. The most common source of gate disputes is a disagreement about whether a given CAE result or subsystem test counts as sufficient evidence. Agreeing the standard at entry — for example, "correlation within 10% on the relevant injury criterion across at least two load cases" — removes that dispute and makes the exit decision a matter of record rather than negotiation.

When the lifecycle is run this way, the formal pretest readiness review becomes what it should be: a confirmation that the evidence ladder has been climbed, not a last-minute scramble to assemble it. The exit gates provide the audit trail, the risk register provides the continuity, and the coupling to design freeze and tooling kick-off ensures that rating risk is retired while it is still cheap to retire.