Horizon methodology: make assumptions testable before they become risks

A Horizon Europe methodology can be detailed and still rest on hidden assumptions. A team may describe pilots, models, user research and validation stages without stating what must be true for those activities to produce the promised result.

The current full RIA/IA and CSA application forms ask applicants to explain the concepts, models and assumptions that underpin the proposed methodology. They also ask teams to identify important challenges and show how the chosen approach will enable the project objectives.

An assumption is not automatically a flaw. Research and innovation proceed under uncertainty. The weakness arises when an assumption is presented as a fact, has no test, or can fail without changing the work plan.

PRINCEPS recommends an assumptions register with nine fields: assumption statement; category; current evidence; confidence; consequence if wrong; earliest test; acceptance threshold; decision owner and date; and fallback or redesign route.

Categories help prevent blind spots. Include scientific, technical, user, regulatory, data, infrastructure, market, policy, partnership and implementation assumptions. A technical consortium may otherwise test its model while leaving user access, approvals or maintenance conditions unexamined.

The evidence test should be proportionate and scheduled early enough to matter. If the project only learns in its final month that a regulator will not accept the evidence route, the assumption was not managed. A pilot, authority consultation, data audit, prototype test or user commitment can create an earlier decision point.

Separate external impact assumptions from internal implementation risks. The application forms distinguish barriers or requirements that affect pathways to outcomes and impacts from critical risks inherent in project management. One may influence the other, but they serve different evaluator questions.

The register should link to milestones. A critical assumption should resolve at a point where the consortium can continue, adapt, narrow scope or stop an approach. A milestone with no consequence is a reporting date; a decision gate changes resource allocation or technical direction.

Document the source and date behind the current confidence rating. Evidence may come from literature, preliminary tests, authority guidance, user research, partner records or a deliberately conservative estimate. Where sources disagree, retain the disagreement and define the project test that will resolve it rather than selecting the most convenient value.

African implementation contexts require locally owned assumptions. Connectivity, logistics, language, informal systems, institutional mandate, user incentives and maintenance capacity should be tested with the organisations that operate in that context, not inferred from a generic country description.

Avoid defensive wording that claims all uncertainty has been eliminated. Evaluators expect ambitious projects to carry uncertainty. Credibility comes from knowing which uncertainties matter, how they will be tested and how the consortium will respond.

Before submission, reconcile the assumptions register with objectives, methodology, work packages, milestones, risks, ethics, exploitation and budget. If the fallback requires expertise, time or equipment that is not resourced, it is not a real fallback.

This analysis is strategic and editorial. It does not replace the live topic, application form, programme guide, grant agreement, ethics review or specialist scientific and regulatory advice, and it does not guarantee funding or successful results.

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.