The hidden consistency test in Horizon Europe proposals: 10 checks that strengthen evaluator confidence

A Horizon Europe proposal can contain strong science, a credible consortium and an attractive impact case, yet still lose evaluator confidence when the sections do not describe the same project. Objectives promise one level of validation, the work plan delivers another, the impact section assumes adoption that the timeline cannot support, or the budget assigns little effort to work that the narrative calls critical.

For Research and Innovation Actions and Innovation Actions, the Horizon Europe 2026-2027 General Annexes organise evaluation around Excellence, Impact, and Quality and efficiency of the implementation. The implementation criterion explicitly covers the work plan, risks, effort, resources, participant roles and consortium capacity. The standard application form for HE RIA and IA also warns that proposals are evaluated as submitted, not on what they might become after substantial correction.

There is no separate award criterion called consistency. Still, consistency influences how easily an evaluator can believe the evidence presented under the actual criteria. A useful final review therefore stops reading section by section and starts reading across the proposal.

The following ten checks are designed for that review.

1. Objectives ↔ methodology: does the method prove the claim?

Start with each major objective and ask whether the methodology can generate the evidence needed to demonstrate success. The issue is not whether the method is scientifically sound in isolation. The issue is whether it is sound for the exact objective being claimed.

Suppose the objective says:

If the methodology only describes controlled laboratory testing, the project may generate excellent data, but it has not yet shown how that data demonstrates performance under representative industrial conditions. The logical chain is incomplete.

A stronger chain is:

Objective → method → activity → evidence → success threshold

For example:

The numbers above are illustrative. A real proposal must use project-specific targets supported by evidence.

Practical check

For each objective, record four items: objective ID, method or activity, evidence produced and success threshold. For example, O1 might map to an industrial pilot, an operating dataset plus validation report, and a defined quantitative threshold. O2 might map to user validation, structured user evidence and a predefined acceptance criterion.

If any of those four items is difficult to complete, the objective is not yet fully traceable.

2. Objectives ↔ work packages: where does every promise happen?

Objectives are often refined early, while work packages are developed later by different contributors. That creates a common failure mode: the ambition evolves, but the implementation structure does not.

Imagine that Excellence says the project will validate the solution in three representative European environments. The work plan later contains only “T3.2 Pilot validation”. An evaluator still has to infer where the three environments are, who owns each validation, when each one happens, whether the same protocol is used and what defines success.

A stronger implementation would map the promise explicitly: Site A tests high-humidity operation in M14-M17, Site B tests low-temperature operation in M16-M19, and Site C tests repeatability in M18-M21. All three use the protocol defined in T3.1 and feed into milestone MS4.

The fastest audit is to search for sentences containing phrases such as we will demonstrate, we will validate, we will develop, we will reduce or we will enable, then ask: *Where, exactly, is this delivered in the work plan?*

This is the practical extension of why strong proposal sections can still fail when the proposal is inconsistent. The evaluator should not have to reconstruct delivery logic from scattered clues.

3. Starting point ↔ project work ↔ end point: is the progression credible?

The project should begin where existing evidence ends. If the starting point claims that a prototype has already been validated in a relevant environment, but the first 18 months mainly rebuild the prototype and repeat similar validation, the claimed maturity deserves scrutiny.

The reverse can also happen. A proposal starts from limited evidence, then assumes that integration, industrial validation, regulatory preparation and deployment can all be completed in a compressed period without explaining the uncertainty between those stages.

Use four questions:

1. What has already been demonstrated?
2. What remains uncertain at project start?
3. Which activities remove those uncertainties?
4. What verifiable state will exist at project end?

A strong maturity statement often follows this logic: We know X because of evidence A. We do not yet know Y. The project therefore performs B and C. If criteria D are met, the project reaches state Z.

Apply this beyond TRL. The same check works for scientific maturity, manufacturing readiness, regulatory preparation, customer validation and commercial readiness.

4. Impact claim ↔ baseline ↔ KPI: could an evaluator verify the claimed change?

Impact language becomes credible when the proposal defines the comparison. “Reduce energy consumption”, “improve patient outcomes” or “accelerate adoption” is not yet an evaluable claim until the reader can answer: compared with what, by how much, under which conditions, by when, and measured how?

For example, replace a generic statement such as “the solution will substantially reduce energy consumption” with a testable logic:

Again, X, Y and Z must come from project evidence. Precision without support creates a new credibility problem.

For each important impact claim, define the baseline, metric, measurement method, target value, timing and owner. The same principle is explored in why measurable claims are essential in EU funding proposals.

A useful final question is simple: How would an independent reviewer know that this impact had happened?

5. Market opportunity ↔ customer evidence ↔ revenue forecast: does the commercial story reconcile?

Where a Horizon Europe proposal includes a market-facing exploitation route, market size is only the beginning. A useful evidence ladder is:

Market size → addressable segment → customer problem → engagement → willingness to pay → conversion → revenue

Each step requires stronger evidence than the previous one. A EUR 5 billion market report does not demonstrate that ten customers will buy next year. A positive letter does not prove willingness to pay EUR 250,000. A successful pilot does not automatically prove a three-month procurement cycle.

Consider a proposal that forecasts 20 customers and EUR 4 million revenue in the first commercial year, while another section says enterprise procurement normally requires 9-12 months and commercial pilots begin only six months before project completion. The arithmetic may be correct while the timeline is not.

A stronger forecast identifies which customers are already engaged, which are expected to enter procurement before project end, what conversion rate is assumed, what price or contract value is used, what sales capacity exists and when revenue can realistically be recognised.

For every major revenue figure, ask: Which customers, prices, conversion assumptions, capacity limits and timing assumptions create this number?

6. KPIs ↔ milestones ↔ decision gates: do metrics control the project?

KPIs, milestones and decision gates are related, but they do different jobs.

• KPI: what is measured?
• Milestone: what important state has been achieved?
• Decision gate: what action follows from the result?

Example:

Compare that with “MS3: Validation completed, M18”. The second version records a date. The first version shows management logic.

For every critical KPI, ask what changes if the target is missed. If the answer is “nothing”, the metric may not be critical, or the governance logic may be incomplete.

7. Risks ↔ dependencies: does the risk register describe this project?

Generic risks such as “technical difficulties”, “delays” or “partner communication problems” say little about whether the consortium understands the real failure modes of the project.

Start instead from dependencies: a critical supplier, recruitment of specialised staff, access to a clinical or industrial site, manufacturing yield, availability of a dataset, regulatory timing, customer procurement, external financing or integration with a third-party platform.

Then structure each important risk as:

event → trigger → owner → mitigation → contingency → consequence

For example:

That description is specific enough to show project management rather than generic risk vocabulary.

8. Partner expertise ↔ responsibility ↔ effort: are the right organisations doing the critical work?

A strong profile does not automatically create a credible role. If a participant is described as essential for regulatory strategy but owns no regulatory task, receives little effort and appears in no relevant deliverable or milestone, the proposal creates a disconnect.

Review these elements together:

Expertise ↔ tasks ↔ deliverables or milestones ↔ resources

For each participant, complete this sentence:

A hospital might provide access to the target patient cohort and lead clinical validation. A manufacturer might own the scale-up line and generate manufacturing evidence. A public authority might control the deployment setting required to test adoption. If the role cannot be expressed concretely, the narrative or the consortium design needs attention.

For consortium design in more depth, see how to build a Horizon Europe consortium as a delivery system rather than a logo wall.

9. Workload ↔ budget ↔ ambition: do resources tell the same story as the narrative?

Resources communicate priorities. If industrial validation is described as the central de-risking activity but receives only a small fraction of project effort, the evaluator may reasonably look for an explanation. There may be one: infrastructure already exists, equipment is provided in kind, or substantial preparation sits in another work package. If so, make the logic visible.

Look for critical work packages with surprisingly little effort, participants owning several complex tasks with very few person-months, major experimental work without the expected equipment or access costs, or ambitious exploitation activity with almost no dedicated resource.

The official RIA and IA template explicitly asks applicants to justify resources, align them with work package objectives and deliverables, and ensure that section 3 matches the budget and person-month information.

A useful stress test is to hide the narrative and look only at the budget and effort table. Could a reviewer approximately identify the real project priorities from the allocation? If the answer is very different from the story told in Excellence and Impact, investigate.

10. Timeline ↔ dependencies ↔ exploitation: is there enough time for the story to happen?

Timeline problems often appear between sections rather than inside the Gantt chart. Individual dates may look plausible until their dependencies are connected.

Consider:

This sequence may be feasible in a specific sector, but if certification depends on the final M18 dataset and requires dossier preparation, external review and uncertain authority timing, the two-month interval requires evidence and justification.

The same issue appears when the final prototype is ready at M24, first major customer revenue is forecast at M26, and the commercial section says customer qualification and procurement normally take 12 months.

Work backwards from the five most important end-of-project claims. If first commercial deployment is planned for M30, ask what must already be true at M30, then what must happen before each prerequisite. Continue until the chain reaches activities already scheduled.

This reverse-planning exercise is one of the fastest ways to expose missing tasks and unrealistic intervals.

Build a consistency matrix before submission

A simple matrix can expose cross-proposal gaps quickly. Use it for the claims that matter most, not every sentence. For each major claim, record evidence, delivery location, KPI, owner, timing and resources.

• Technology validated at scale: pilot operating data; WP3 / T3.2; defined performance threshold; Partner B; M18; person-months plus pilot budget.
• Three customer pilots completed: pilot agreements and reports; WP4 / T4.1; three completed pilots; Partner C; M24; commercial team effort.
• Production cost reduced: manufacturing data; WP3 / T3.4; target cost per unit; Partner D; M27; process engineering effort.

Missing fields are useful findings. They show where the proposal asks the evaluator to make an assumption.

The 15-minute cross-proposal audit

If the deadline is close, stop editing wording for 15 minutes and answer these ten questions:

1. Can every major objective be traced to activities and evidence?
2. Does project work begin where existing evidence ends?
3. Can every important impact claim be measured against a baseline?
4. Do market and revenue assumptions reconcile with customer evidence and timing?
5. Do critical KPIs lead to meaningful milestones or decisions?
6. Does the risk register reflect the real technical, operational and commercial dependencies?
7. Are critical responsibilities assigned to participants with the right expertise and sufficient effort?
8. Does resource allocation reflect the priorities described in the narrative?
9. Do budget, workload and ambition tell the same story?
10. Does the timeline leave enough time for the dependencies behind the final claims?

Give the matrix and these questions to someone who understands the project but has not spent the previous weeks drafting every paragraph. Authors remember intended logic. Evaluators can only assess logic that is visible in the submitted proposal.

Consistency is not repetition

A consistent proposal does not repeat the same paragraph in Excellence, Impact and Implementation. Each section has a different evaluative job.

Excellence should explain why the objective is ambitious and why the methodology is sound. Implementation should show which activities, people, resources, milestones and controls will deliver the evidence. Impact should explain what the results can credibly enable for target groups, adoption and wider effects.

The connection should come from shared facts, thresholds and terminology, not duplicated prose. If 95% performance is a critical target, Excellence explains why it represents meaningful progress, Implementation shows how it will be demonstrated, and Impact explains what achieving it enables.

That is coherence.

Reduce the amount of inference required from the evaluator

Near submission, choose the ten claims that matter most and follow each one through the entire proposal. If you claim a scientific advance, find the method that demonstrates it. If you claim technical validation, find the task, KPI, owner and resources. If you claim commercial traction, find the customer evidence and conversion assumptions. If you claim impact, find the baseline and mechanism. If you claim that a critical risk is controlled, find the trigger and contingency.

The aim is not to eliminate uncertainty. Ambitious research and innovation contains uncertainty by definition. The aim is to make the logic traceable, testable and internally consistent.

For a final independent review, the Horizon Europe proposal evaluator can be used to test the application against programme requirements, proposal structure and evaluator logic before submission.

A convincing Horizon Europe proposal is not a collection of strong sections. It is one connected case in which objectives, methodology, evidence, work packages, participants, resources, risks and impact reinforce the same project story.

When those connections are visible, the evaluator has less reconstruction to do and more evidence on which to base a high-confidence assessment.