Intervention logic is the causal argument at the core of your proposal: the claim that evidenced needs, addressed through specific objectives and activities, will produce outputs that lead to outcomes and, over time, impact. A logframe is that argument laid out as a grid, which means it can be checked mechanically, cell by cell, before anyone with a scoring sheet does it for you. Three checks catch most of the damage: the traceability test, the thirty-second indicator test, and an honest read of the assumptions column. What follows are those checks, one worked example, and a half-hour self-check protocol per work package.
Terminology errors cost credibility before the logic is even examined, because the five core terms look interchangeable and are not.
Mixing these is more than a style problem. When an objective is written as an output ("develop a platform") or an outcome as an activity ("conduct workshops"), the causal chain has a hole, and holes are what evaluators are trained to find.
Evaluators rarely read the grid top to bottom. A typical read picks one objective and traces downward: which activities serve it, which outputs they produce, which indicators will show the intended change. Then it reverses direction from a random activity: which objective does this serve, and which evidenced need sits behind it? The evaluator also cross-reads the needs analysis and the budget, and inconsistencies between the three are where scores drop. Prose can blur a weak link with good writing; a grid cannot.
Run the same two traces yourself, systematically. Downward: every need leads to an objective, every objective to at least one activity, every activity to an output, every output to an indicator. Upward: every indicator measures something an output produces, every activity serves a named objective, every objective answers an evidenced need.
Anything that fails a trace is an orphan, and every orphan is a finding:
Do this on the printed document, pen in hand.
For each indicator, ask one question: could the project hit this indicator while the situation of the target group stays exactly the same? If yes, it measures effort, not change. "Number of workshops held" and "platform launched" pass while nothing changes for anyone. They are legitimate at output level, where you prove delivery, and damaging at objective and outcome level, where the reader wants change: the share of participants who apply what they learned, or a measured shift in competence against a baseline.
The repair is mechanical. Take the effort indicator, ask "so that what?", and measure the answer: workshops held so that teachers use a new method becomes measured use, by follow-up survey or observation, at a stated point. Every objective carries at least one change indicator; effort indicators stay next to outputs.
The assumptions column is where most teams paste generic text at midnight before the deadline, and it is one of the first places an experienced evaluator looks, because it shows whether the authors understand their own causal mechanism. Every arrow in the chain depends on something outside your control, and this column proves you know what.
Apply two tests to each assumption. First, is it specific to a causal step? "Partners will cooperate effectively" is a template line; "school directors allocate teaching time for the pilot" is an assumption someone thought about. Second, is it genuinely external? If the condition is within the project's control, it is not an assumption but a task: move it into the activities and the mitigation plan. A well-filled column lists the exact points where the project could fail for reasons you cannot fix, each paired with the mitigation you can.
The example is generic and illustrative.
Before:
Every cell fails a check. The need is neither evidenced nor specific. The objective restates the activity with the word empower added. "Empowered" is not observable, so the outcome can never be verified. The indicator is pure effort. The assumption is a hope.
After:
Same project, same budget, same partners; now every cell traces in both directions, the indicators measure change, and the assumption names the real external dependency.
Run this once per work package, starting with the one you trust least.
If the protocol keeps surfacing the same class of problem across work packages, the issue is structural and worth an external pass; an intervention-logic check on a live draft is one of the things we do for coordinators. Weak intervention logic is only one of the recurring reasons EU applications get rejected, but it is the one you can fix mechanically before you submit.
StrandsUnited checks intervention logic on live drafts for EU consortia, alongside budget cross-checks and dissemination infrastructure that outlives the funding. The patterns above come from that work and from our grant intelligence engine, a consortium graph built on CORDIS and Erasmus+ open data covering 114,731 organisations and 83,490 projects across the 2014-2027 programming periods.