Horizon milestones: define the decision, evidence and fallback

Many Horizon Europe milestone tables are calendars disguised as controls. They list a month, a short label and a document, but do not explain what the consortium will decide or how the project changes when the evidence is weak.

The current full RIA/IA and CSA application forms define milestones as project control points. They may correspond to achievement of a key result that allows the next phase to begin, provide an intermediate opportunity for corrective measures or support a critical choice between alternative technologies. Their achievement should be verifiable.

The milestone table therefore asks for a means of verification. The strongest response identifies the observable evidence and acceptance rule, not merely the name of a deliverable or meeting.

PRINCEPS recommends a seven-field milestone decision gate: decision question; evidence package; acceptance threshold; decision owner or body; due month; consequence of passing; and corrective or fallback action if the threshold is missed.

The decision question should be specific. 'Prototype complete' is a status statement. 'Does the validated prototype meet the agreed accuracy, safety and user-acceptance thresholds required to enter field demonstration?' creates a control point.

Evidence should be available before the meeting that uses it. Identify the test report, validated dataset, user acceptance record, authority response, reproducibility check or other material that decision-makers will inspect. State who validates it and how disagreement is resolved.

Thresholds need a unit or acceptance rule. A milestone that can always be declared achieved creates no governance value. Where research uncertainty prevents a fixed number, define a transparent scientific or management criterion and the evidence required to apply it.

The consequence matters because milestones should influence the work plan. Passing may release the next task, procurement, pilot or resource tranche. Failure may trigger redesign, additional testing, narrowed scope, a different technical route or escalation to the project board.

Milestones should be few enough to remain meaningful. Routine task completion belongs in project management. Reserve formal milestones for dependencies, irreversible commitments, major integration points, external permissions and decisions that protect objectives.

Governance language should be explicit about who has the deciding vote and who advises. A technical lead may confirm test quality, a pilot owner may accept local readiness and a project board may authorise resource changes. Combining those functions in an unnamed 'consortium decision' makes accountability difficult when evidence is contested.

Record the decision and its evidence after the gate. The minutes should identify the reviewed material, threshold applied, dissent or conditions, approved next action and owner. This creates a management trail for later reporting and prevents a passed milestone from being reinterpreted when downstream work encounters difficulty.

Cross-border pilots should include acceptance authority at the implementation site. A central consortium body should not declare local readiness without evidence from the partner responsible for users, infrastructure, permits and operating conditions.

Before submission, trace each milestone backwards to the tasks that generate its evidence and forwards to the work it controls. Confirm that the decision body exists in governance, the relevant partners have effort to prepare and review evidence, and the fallback is resourced.

This analysis is strategic and editorial. It does not replace the live application form, Model Grant Agreement, consortium agreement, technical standards, ethics approvals or professional project-governance advice, and it does not guarantee funding or delivery success.

Editorial note: This is PRINCEPS analysis for general information. It does not replace the official work programme, topic conditions, submission system, grant rules or professional advice specific to an application.