How to Test Proposal Claims Before Submission
A proposal can contain technically sound work and still lose points because its central assertions have not been proved on the page. That is the practical problem behind how to test proposal claims: not whether the consortium believes a statement, but whether an evaluator can verify it quickly against the evidence provided, the call text and the award criteria.
For Horizon Europe, Digital Europe and Erasmus+ applicants, this matters because submission closes the argument. The consortium may know that it has access to a pilot site, a relevant standardisation route or an exceptional exploitation record. If the draft merely asserts those facts, an evaluator is not required to infer their implications. They mark what is written, within the available time, against the evaluation form.
A claim is not evidence
A proposal claim is any statement that asks the evaluator to accept a conclusion. “Our methodology is innovative”, “the pilot will scale across Europe”, “the consortium has the required expertise” and “the project will deliver measurable impact” are all claims. Some may be true. None earns credit simply because it sounds plausible.
Evidence is the material that lets an evaluator check the conclusion. It can include a named prior result, a benchmark with a source and comparator, letters or descriptions of access rights, a work package task, a quantified KPI, a partner’s demonstrated role, a risk response, or a credible chain from outputs to uptake.
The distinction is especially important where the proposal uses evaluative language: novel, leading, scalable, significant, validated, market-ready, inclusive or sustainable. These words are not automatically weaknesses. They become weaknesses when they replace the comparison, proof or delivery mechanism that the evaluation criterion requires.
A useful test is simple: underline every statement that makes the proposal look stronger, more feasible or more impactful. Then ask, “What passage would an evaluator cite to justify awarding a higher score for this?” If the answer is another assertion, the claim has not yet been tested.
Start with the correct marking frame
Do not test claims against a generic idea of a good proposal. Test them against the published evaluation form for the call’s type of action and version. Admissibility and eligibility come first, but they are not award criteria. A compliant page count, template and consortium composition do not compensate for an under-evidenced Excellence, Impact or Implementation case.
The weighting, thresholds and sub-criteria vary. In many Horizon Europe actions, evaluators score Excellence, Impact and Quality and Efficiency of the Implementation on the 0-5 scale, often using half-points. A score below the threshold in one criterion can exclude a proposal even if its total looks competitive. Digital Europe and Erasmus+ instruments may frame their sub-criteria differently, and call conditions can add specific requirements that change what counts as a convincing answer.
Build a claim register directly from that form. For each criterion and sub-criterion, record the claim, its location in the draft, the evidence offered, and the consequence if the evaluator does not accept it. This is not administrative overhead. It prevents a familiar failure: a strong paragraph in the technical section is assumed to prove Impact, while the Impact section itself gives the evaluator no scored basis for accepting the claim.
How to test proposal claims criterion by criterion
1. Test Excellence claims against the state of the art and the method
Excellence claims often fail because the proposal describes an ambition rather than a methodological advance. “First-of-its-kind” needs a defined comparator. “Beyond the state of the art” needs an account of what the current state cannot do, what the project changes, and how success will be assessed.
Check whether each claimed advance has a baseline, a measurable target and a validation method. If the proposal says it will improve accuracy by 30%, identify the present benchmark, the dataset or operating conditions, the statistical or technical basis for the target, and the task responsible for demonstrating it. Without these, the number is decorative.
Also test internal consistency. A methodology cannot be described as low-risk while its critical data, infrastructure or regulatory permissions sit outside the consortium’s control. The correct repair is not necessarily to remove the ambition. It is to name the dependency, assign ownership, set a decision point and provide a credible fallback.
2. Test Impact claims as causal chains
Impact sections routinely contain the proposal’s largest unsupported claims. Evaluators see statements about European competitiveness, policy contribution, adoption, job creation or emissions reduction. They then look for the route from project output to that result.
Trace every material impact claim through five questions: what output will be produced; who will use it; why would they adopt it; what barriers stand in the way; and how will the proposal measure progress? A dissemination list is not an exploitation strategy. A stakeholder workshop is not proof of uptake. A market estimate is not a route to market.
For expected outcomes in the call text, test explicitness. The proposal should not rely on semantic resemblance. Show which output contributes to which expected outcome, who owns the action, when it happens and which indicator will be monitored. Where contribution is indirect or conditional, say so. Inflated certainty can damage credibility more than a narrow, defensible impact pathway.
3. Test Implementation claims against delivery mechanics
Implementation claims must survive a project manager’s reading. If a work package promises a prototype, policy recommendation or training package, can an evaluator find the tasks, inputs, deliverable, milestones, dependencies, effort and accountable beneficiary that make it deliverable?
Look for false precision. A Gantt chart can appear complete while concealing impossible sequencing, unresourced tasks or dependencies between work packages that have no formal handover. Equally, a risk register can list generic items - “technical risk”, “partner delay”, “low engagement” - without probability, impact, trigger, owner or mitigation action.
Test whether the budget and person-month allocation support the narrative. A large pilot cannot credibly rest on a lightly resourced task with no operational partner. Conversely, a heavily staffed activity needs a stated output and decision value. Evaluators do not expect certainty; they expect a coherent implementation logic.
4. Test consortium-capacity claims partner by partner
“We have assembled a complementary consortium” is a conclusion, not a demonstration. Test it by mapping each critical capability to a named beneficiary, person or affiliated entity, then to a task and a prior basis for confidence.
Particular scrutiny is warranted where the proposal relies on a partner’s customer access, clinical network, public authority mandate, data holdings or commercialisation capability. Does the draft establish that access is real and available to this project? Is the relevant partner responsible for the associated task? If a subcontractor or external stakeholder is essential, is the arrangement sufficiently defined?
A consortium can be excellent on paper but weakly integrated. Look for duplicated roles, unexplained interfaces and a coordinator expected to solve every cross-work-package issue. These are common sources of significant weaknesses under Implementation.
Use an adversarial reading, not a proofreading pass
A claim test works best when the reader is instructed to withhold benefit of the doubt. Ask them to mark each assertion as supported, partially supported or unsupported, and to quote the exact text on which their judgement rests. Quoting matters. It distinguishes a genuine finding from a vague impression and gives the drafting team something specific to repair.
Then ask a second reader to assess the same high-value claims independently. Where their conclusions differ, do not average the disagreement away. Find the reason. One reader may have noticed evidence buried three pages later; the other may reasonably conclude that the link is too obscure for an evaluator working at pace. Both observations are useful.
This is the logic behind a panel-shaped review. At BidShark, six independent readings examine the draft across Excellence, Impact, Implementation, consortium capacity, unsupported claims and sector context before disagreement is adjudicated against the relevant scoring form. The automated assessment is not a human verdict, and it cannot predict a panel’s decision. Its value is narrower: it creates an auditable record of where the draft does and does not support its own case before the real evaluation begins.
Prioritise fixes by score consequence
Do not attempt to repair every sentence equally. Rank findings by the criterion affected, the claim’s importance to the proposal and the likely score consequence. A missing citation for a minor contextual statement is different from an unproven claim that the consortium can access the users needed for a central demonstration.
Start with issues that could pull a criterion below its threshold or prevent a move into the next score band. Repair the evidence chain, not merely the wording. Add a comparator, assign an owner, quantify a target, clarify a dependency, or move decisive evidence into the section where it is scored. Only then polish the prose.
The final question before submission is not whether the proposal sounds persuasive to the people who wrote it. It is whether a sceptical evaluator can locate, test and credit its most consequential claims without supplying missing reasoning. Find the gaps while amendments are still possible. After submission, the panel has the last word.