Horizon objectives: write the verification method before the target

Proposal teams often improve an objective by adding a number. That is not enough. A target can be specific and still be impossible to verify because nobody has defined the baseline, evidence source, measurement time, quality threshold or rule for deciding whether the result has been achieved.

The current full Horizon Europe RIA/IA and CSA application forms ask whether project objectives are pertinent to the work programme topic, measurable and verifiable, and realistically achievable. These are connected tests. An objective that cannot be proven is not fully measurable, and an objective that lacks a delivery route is not realistically achievable.

Both forms require a means of verification for milestones and ask applicants to show how attainment will be confirmed, referring to indicators where appropriate. The RIA/IA form also describes milestones as control points whose achievement should be verifiable.

The practical drafting move is to write the verification method before finalising the target. If the consortium cannot state what evidence an independent reviewer would inspect, the objective is not ready.

PRINCEPS recommends an eight-field objective-verification sheet:

1. Objective statement — one intended project-level change or achievement, written in language that is pertinent to the live topic.

2. Baseline — the starting value, condition or state, including date, population, geography, system boundary and source.

3. Target and unit — the intended end value or acceptance state, with an unambiguous unit and denominator where relevant.

4. Verification evidence — the test result, validated dataset, system record, independent review, user acceptance, approval, publication, protocol or other evidence that proves attainment.

5. Measurement method — the calculation, sampling plan, instrument, comparison, quality threshold and responsible data owner.

6. Timing and decision point — when evidence will be available, which milestone or review uses it and what happens if the threshold is missed.

7. Attribution and assumptions — what portion of change the project can reasonably claim and which external conditions must hold.

8. Delivery reconciliation — the work packages, tasks, partner capabilities, person-months, budget, deliverables, milestones and risks that make the target achievable.

This is a PRINCEPS control sheet, not an official European Commission form. It is designed to make hidden gaps visible before the objective is repeated across the abstract, Excellence, Impact and Implementation sections.

Consider the difference between 'improve uptake by 30%' and a verifiable statement. The stronger version defines uptake, names the eligible user group, fixes the baseline date and denominator, states the target date, identifies the system or survey that records use, sets the validation rule and explains which project actions can plausibly influence the change.

Not every objective needs a percentage. Research objectives may be verified through an agreed scientific test, resolution of a research question, validated method, demonstrated feasibility or reproducible result. Coordination and support actions may use operational, policy, capacity or adoption evidence appropriate to their scope.

Avoid confusing an activity with an objective. Holding ten workshops is an activity count. Its value depends on what the workshops are meant to change and what evidence would show that the relevant participants gained capability, adopted a method, contributed to a decision or enabled another project result.

Verification also disciplines ambition. If evidence depends on approvals, market adoption, infrastructure or behaviour beyond the consortium's control, the objective should state the attribution boundary and assumptions. The proposal can still be ambitious, but it should not promise an external decision as if the consortium alone controls it.

African pilot and implementation sites deserve the same evidence precision as technical work elsewhere. Define local baselines with the competent data owner, ensure indicators reflect the affected users and operating context, resource data collection properly and give local partners authority over interpretation and acceptance.

Before submission, run a cross-document test. Each objective should have a delivery route in the methodology and work plan, a responsible partner, sufficient resources, a verifiable milestone or deliverable where appropriate, a risk response and a clear contribution to the expected outcomes. Remove objectives that cannot survive that test.

This analysis is strategic and editorial. It does not guarantee a higher score or funding. The live topic, action type, work programme, application form, General Annexes and submission system remain controlling.

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.