Ruthless vs ChatGPT

It can clarify a paragraph, improve flow, reduce repetition, suggest alternative wording, summarise technical content, or make a section easier to read. This is the central difference between a general-purpose language model and an evaluator-style proposal review. One works mainly from inside the text. The other judges the text against external requirements. EU proposals are not scored on linguistic quality alone. They are scored against work programmes, templates, award criteria, subcriteria, call scope, expected outcomes, feasibility, impact, implementation credibility, and evidence. A good writing assistant may improve the sentence. A good evaluation review asks whether the sentence should be there, whether it proves enough, whether it answers the criterion, and whether an evaluator can defend the claim.

ChatGPT improves text from inside the proposal

That makes it very useful for drafting. But it also means the model may improve wording without testing the evaluation case.

Large language models are very good at working with the material they are given. If a paragraph is unclear, they can make it clearer. If a section is repetitive, they can make it more concise. If a technical description is dense, they can make it more readable. If a proposal uses inconsistent style, they can make the tone more uniform.

Evaluators work from outside the text

This is why an evaluator-style review feels stricter. It asks whether the text satisfies an external scoring logic, not whether it reads smoothly.

These include:

• the Work Programme
• the call topic
• the scope conditions
• the expected outcomes
• the official template
• the award criteria
• the subcriteria
• the admissibility and eligibility rules
• the evaluation logic behind the score
• the need to justify comments in the Evaluation Summary Report

Evaluators are not asking only:

They are asking:

The problem is not ChatGPT

The tool can be valuable when the task is clear. The issue appears when teams treat better writing as evidence of stronger fundability.

If the task is to rewrite a paragraph, improve grammar, simplify dense wording, draft an outline, or generate alternative phrasing, ChatGPT can be helpful. If the task is to determine whether a Horizon Europe or EIC proposal will survive evaluator scrutiny, the question becomes different. A general language model can identify vague wording, but it may not know whether the section fully responds to a specific call requirement. It can make an impact paragraph sound stronger, but it may not test whether the impact pathway is credible, measurable, and aligned with expected outcomes. It can improve readability, but it may not detect that the work plan does not deliver the claimed result.

Perfectly written does not mean fundable

Fundability requires a proposal that evaluators can understand, assess, and defend. That requires more than polished phrasing.

A polished proposal can still contain unsupported claims, inconsistent assumptions, weak evidence, unclear validation logic, vague partner roles, and superficial call alignment. This is why we previously discussed that perfectly written does not mean fundable. A proposal becomes fundable when the writing supports a credible evaluation argument.

What LLMs tend to optimise

That difference is subtle but important. A sentence can gain fluency while losing precision.

When you ask a general LLM to improve a proposal section, it usually optimises for clarity, grammar, structure, tone, completeness, and rhetorical flow. For example, a model may turn this sentence:

Into this:

What evaluators actually need

This material should be visible where it supports the score. If evaluators have to search, infer, or reconstruct the logic, the proposal loses control.

Evaluators need to understand what the project claims and whether the proposal proves enough. That means:

• clear claims
• explicit baselines
• measurable objectives
• traceable numbers
• relevant evidence
• realistic assumptions
• consistent terminology
• credible validation plans
• specific partner responsibilities
• call-aligned outcomes
• risk-aware implementation logic

The evaluator does not infer your intention

The proposal must make the intended meaning explicit. Otherwise, the evaluator may interpret a claim more narrowly, more broadly, or more negatively than the team intended.

One of the most dangerous assumptions in proposal writing is that the evaluator will understand what the applicant meant. If the proposal says that the project will validate the solution in relevant environments, the evaluator needs to know which environments, why they are relevant, who will provide access, what will be measured, and how success will be defined. If the proposal says that customers have shown strong interest, the evaluator needs to know how many customers, which segment they represent, how the evidence was collected, and what level of commitment exists. If the proposal says that the consortium is complementary, the evaluator needs to know which partner does what, why that capability is necessary, and how it connects to tasks and deliverables. This is also why we have argued that strong projects still get rejected in EU evaluations.

The danger of “make this sound better”

A better prompt is not only about style. It should ask what is missing, what is unsupported, and what the evaluator may question.

“Make this sound better” is one of the most common instructions given to writing tools. If the instruction is only to improve wording, the model may produce a more fluent version of the same weakness.

Example: a sentence improved by language but not by evaluation logic

Consider this sentence:

A writing model may improve it like this:

Example: the same sentence improved for evaluation

A more evaluator-oriented version might read:

This is the kind of improvement that matters for evaluation.

The three layers of proposal improvement

The layers are connected, but they are not interchangeable. Improving language does not automatically improve argument or evaluation fit.

ChatGPT can help significantly with the first layer.

Layer one: language quality

Layer two: argument quality

Argument quality is where many polished proposals remain fragile. The text sounds confident, but the logic is not traceable enough.

Instead of saying that the solution will reduce operating costs, the proposal should explain which cost, for which user, compared to which process, by what mechanism, and with what evidence. Instead of saying that the market is large, it should define the serviceable segment, adoption assumptions, pricing logic, and sales capacity. Instead of saying that the technology is disruptive, it should compare it against the state of the art and show which limitation is overcome.

Layer three: evaluation fit

This is where external documents matter most. The call, template, and criteria define what the proposal must prove.

The Work Programme matters

Call fit must be demonstrated, not implied. Repeating the right keywords is not the same as answering the call.

The official template matters

Placement matters because evaluators use the template to navigate the case. Strong evidence in the wrong place may lose force.

If the proposal answers the right question in the wrong place, the argument may lose force. If an important justification is buried in another section, it may not support the criterion where it is needed. If the work plan contains evidence that should have been in excellence or impact, the evaluator may not give it the same weight. If partner roles are described only in generic profiles and not connected to tasks, implementation credibility may suffer. A writing model can make template sections sound smoother. But it may not detect that the content is misplaced.

Subcriteria matter

Subcriteria turn broad quality into scoreable questions. A proposal should give direct material for those questions.

If a subcriterion asks for credibility of the methodology, the proposal must explain why the methodology is suitable, feasible, and capable of generating the required evidence. If a subcriterion asks for impact, the proposal must show a credible pathway from outputs to outcomes and expected effects. If a subcriterion asks for quality and efficiency of implementation, the proposal must show that the work plan, resources, responsibilities, risks, and governance are coherent.

The ESR is written against weaknesses

Where general LLM support can help

It can help structure an outline. It can simplify complex technical explanations. It can summarise long partner inputs. It can suggest headings. It can improve readability. It can harmonise tone. It can detect repetition. It can help draft a first version of a non-critical section. It can turn rough notes into a coherent paragraph. It can help identify unclear wording. It can also be useful for brainstorming alternative formulations, provided the final content is checked by experts.

Where general LLM support becomes risky

The safest use is supervised use. Experts must check whether the improved text remains accurate, evidenced, and aligned.

This happens when a model fills missing information with plausible language. It happens when the text becomes more confident than the evidence supports. It happens when generic claims are rewritten as polished claims. It happens when assumptions are smoothed rather than challenged. It happens when the model reinforces author intention instead of testing evaluator interpretation. It happens when the draft looks finished because the language is clean.

Ruthless Evaluator has a different purpose

It reads like a critical evaluator, not like a copyeditor. That is why it looks for scoring weaknesses beneath fluent prose.

It is built to test whether the proposal is likely to survive evaluator-style scrutiny. That means comparing what is written against what is expected. Criterion by criterion. Claim by claim. Assumption by assumption. It asks whether the proposal gives evaluators enough basis to understand, assess, trust, and defend the application. An evaluable proposal makes logic explicit, shows evidence, aligns sections, supports claims, reduces ambiguity, and gives evaluators a stronger basis for scoring.

What Ruthless Evaluator looks for

Ruthless Evaluator focuses on weaknesses that often become painful ESR comments later. These include:

• invisible assumptions
• unsupported claims
• vague objectives
• weak baselines
• missing evidence
• inconsistent terminology
• unclear validation logic
• generic risk mitigation
• poor partner role justification
• superficial call alignment
• work plan and impact misalignment
• market assumptions without derivation
• overclaiming
• misplaced evidence
• ambiguity that allows negative interpretation

Example: assumption hidden inside polished text

Consider this sentence:

If that assumption matters for impact, commercialisation, or implementation credibility, it must be made explicit and supported.

Example: claim that cannot be defended

Consider this claim:

A stronger version might focus on a defensible first step:

Example: inconsistency that nicer wording will not fix

A proposal may state in the excellence section that the project targets a breakthrough research result. In the impact section, it may describe near-term commercial deployment. In implementation, the work plan may only validate a laboratory prototype.

Why “inside the text” is not enough

Missing information cannot be solved by style. It must be supplied, evidenced, or the claim must be narrowed.

Evaluation review must ask hard questions rather than simply produce better prose.

What good evaluator-style feedback should do

For example:

Or:

Or:

Ruthless Evaluator does not replace expert judgement

The tool can flag weakness. The team must decide the factual, technical, commercial, or strategic correction.

Sometimes it is adding evidence, narrowing a claim, changing a KPI, redesigning part of the work plan, or admitting uncertainty more clearly.

The best use of ChatGPT and Ruthless Evaluator together

ChatGPT can help draft, clarify, restructure, and improve readability. Ruthless Evaluator can then test whether the improved text is actually evaluation-ready. A practical workflow might look like this:

• use ChatGPT to turn rough technical notes into a readable section
• have the technical team verify accuracy
• use Ruthless Evaluator to test the section against criteria, call expectations, and evaluator logic
• revise claims, evidence, baselines, risks, and alignment
• use ChatGPT again to improve readability without weakening precision
• perform a final evaluator-style check before submission

The proposal must say exactly what you think it says

It is not:

It is:

Before trusting a polished proposal, ask better questions

• Does the proposal answer the exact call requirements?
• Does each major claim have evidence?
• Are baselines and targets clear?
• Are KPIs meaningful and measurable?
• Are assumptions visible?
• Are market numbers derived rather than chosen?
• Are risks specific and connected to mitigation?
• Are partner roles justified by tasks and outputs?
• Does the work plan deliver the promised impact?
• Is evidence placed where it supports the score?
• Could an evaluator defend a high score using only this text?
• Does any section sound stronger than the evidence supports?

Where Ruthless Evaluator fits

It reads the proposal against evaluator-style expectations and flags where the case is ambiguous, unsupported, inconsistent, or misaligned. It explains why the issue matters for scoring. It helps teams fix weaknesses before submission, while there is still time to act.

Better to test the proposal before the ESR does

A proposal should be tested while changes are still possible. After the ESR, the same weaknesses are only lessons.

The decisive question is whether the application can survive evaluation against the Work Programme, template, criteria, subcriteria, evidence expectations, and scoring logic.

Better to meet Ruthless Evaluator before submission than inside the Evaluation Summary Report.

app.ruthlessevaluator.ai