What a logframe is, the 4x4 logical framework matrix explained cell by cell, how to write OVIs that survive evaluation, and how to run a living logframe.
A logframe, short for logical framework matrix, is a one-page planning and monitoring tool that explains how a project expects to create change and how it will check whether that change happened. A standard logframe has four levels — goal, outcome or purpose, outputs, and activities — and four columns: the result, an indicator, a means of verification, and the assumptions or risks that must hold.
A logframe gives a funder, delivery team, and evaluator one shared view of the project: what the team will do, what it will deliver, the change it expects to achieve, the evidence it will collect, and the conditions beyond its control that could affect success.
A standard logframe is a four-by-four matrix. The rows are the results hierarchy: goal, outcome or purpose, outputs, and activities. The first column states those results; the other three columns contain the objectively verifiable indicators, means of verification, and assumptions or risks.
The matrix carries two kinds of logic. Read it vertically to test the results chain. Read it horizontally to test whether each result can be measured, verified, and understood in context. The causal layer beneath a logframe is on theory of change, and the same logic as a nested hierarchy on results framework.
The vertical logic reads from activities toward the goal. If the team completes the activities, and the stated assumptions hold, it should deliver the outputs. If it delivers the outputs, and the next assumptions hold, it should achieve the outcome. If the outcome is sustained alongside wider conditions, the project contributes to the longer-term goal.
The vertical logic is not a guarantee of success. It is a transparent statement of the project's reasoning: what it controls, what it expects to happen next, and what could break the chain.
The horizontal logic runs across each result level. It asks what evidence would show the result happened, how that evidence will be collected, and what condition outside the project's control needs attention.
A youth employment project may train 100 young people. Training completion is an output. The outcome is a measurable change such as graduates entering paid work, apprenticeships, or further accredited training. Attendance records verify the output; follow-up with graduates, training providers, and employers verifies the outcome.
The Logical Framework Approach is the project-design process; the logframe matrix is the four-by-four summary produced at the end of that process. The approach includes context analysis, stakeholder analysis, problem and objective analysis, strategy selection, risk testing, and indicator design. The matrix records the resulting intervention logic, indicators, means of verification, and assumptions.
A team that starts by filling empty cells has created a table, not completed the Logical Framework Approach. The European Commission's Logical Framework Approach guidance likewise treats the matrix as an output of a wider, iterative design process. Use the matrix to communicate and monitor the chosen strategy; use the approach to decide whether the strategy is credible in the first place.
If you need a completed illustration, use the worked logframe example. If you need a blank starting structure, use the four-column logframe template. Those pages own example and template intent so this guide can stay focused on the method and the quality of the logic.
Write an objectively verifiable indicator by naming the result, the population or unit, the measure, the direction of change, and the deadline; then pair it with a source another reviewer could use to reach the same conclusion. An OVI is not merely a number. It is a precise test of whether a planned result occurred.
Use the pattern: [measure] among [population] changes from [baseline] to [target] by [date]. “Participants are more employable” cannot be verified because it omits the measure, population, and timing. “The percentage of program graduates in paid employment, an apprenticeship, or accredited training rises from 22% to 60% within six months of completion” defines all five parts.
A strong OVI also passes three checks. It measures the result rather than the activity; its means of verification names a real source, method, and frequency; and collecting the evidence is proportionate to the decision it supports. FAO's logframe guidance makes the same practical point: when verification is impossible or unreasonably costly, replace the indicator with one that can be verified.
Sopact connects the indicator to the participant and source records behind it. That traceability turns an OVI from a sentence in a proposal into a claim a funder, evaluator, or program team can inspect.
Copy the blank Sopact logframe template when you need the four result levels and four columns ready to fill. The dedicated template page owns the downloadable structure and pressure-testing guidance; this article explains what belongs in each cell and how to judge whether the completed matrix is credible. For fully completed education, public-health, and environmental matrices, use the worked logframe examples.
Means of verification explain where evidence for an indicator will come from and how it will be collected. “Survey” or “project records” is usually too vague to guide a team.
A stronger plan names enrollment records at intake, attendance data after each session, participant surveys at exit and six months later, employer confirmation for a sample of placements, and a monthly owner review. If the evidence does not exist, collecting it needs an owner, budget, and schedule.
Assumptions are external conditions that must hold for one level of the results chain to lead to the next. They are not tasks the team manages directly. “Staff deliver high-quality coaching” is an internal responsibility; “employers continue hiring entry-level candidates” is an assumption.
Useful assumptions are specific enough to monitor: participants can access transport or childcare, employers have suitable roles, partner referrals reach the intended population, and policy changes do not remove eligibility. An assumption matters when its failure could make the next result unlikely even when the project delivers its own work well.
Every logframe has an assumptions column, and it is the column that decides whether the vertical logic actually works: it names the external conditions — that partners deliver, that policy does not change, that beneficiaries engage — on which each step depends. It is also the column no one revisits. Filled once at design, it sits untouched while the project runs, so an assumption fails quietly and the report shows green indicators until the purpose is not achieved.
Sopact calls this The Unrevisited Assumptions Column, and it is a timing problem, not a rigor one. Reading evidence against the assumptions as it arrives turns the column from a design formality into a live risk register. The difference is a data-model one — a static matrix filled at kickoff versus an assumptions column checked against evidence continuously. The wider M&E practice is on monitoring and evaluation, and the sequencing from outcome to indicator on theory of change in monitoring and evaluation. The stage below runs one reporting cycle both ways.
Write the change your project is accountable for. Ask what should be different for participants, communities, or systems if the work succeeds, and keep that distinct from the service delivered.
Describe the wider change to which the outcome contributes. Avoid claiming that one project caused a population-level change on its own.
List the products, services, or capabilities the project will deliver. Test whether each output is plausibly necessary for the outcome.
Write the key work rather than every administrative task. A reviewer should be able to see how the activities produce the outputs.
Start with outcomes, then add outputs. Define the measure, population, timing, baseline, target, and disaggregation where relevant. For each indicator, name the source, collection method, and frequency.
Ask what needs to be true for activities to generate outputs and for outputs to generate outcomes. Prioritize assumptions by likelihood of failure and the damage caused if they fail.
A logframe is the matrix with indicators, verification, and assumptions; a theory of change is the causal logic beneath it; a logic model is the one-page inputs-to-outcomes summary; and a results framework is the nested hierarchy to a goal. They are four presentations of the same underlying logic, each strong where the others are thin.
A results framework shows how results ladder toward a goal, while a logical framework adds the indicators, verification sources, and assumptions needed to monitor each level. A theory of change explains why the links should hold, while a logframe compresses the selected pathway into a format for delivery and accountability. The cleanest workflow builds the theory of change first and derives the required operational view from the same logic.
The structural comparison is on theory of change vs logic model, the matrix version on logic model, and the frame that structures the outcomes on five dimensions of impact.
A logframe whose assumptions are only revisited at the terminal evaluation confirms a failure years after it began; reading evidence against the assumptions as it arrives surfaces the risk while the project can still adapt. That is the premise of the Loop, Sopact's method for continuous impact intelligence: collect clean at the source, analyze the moment data arrives, improve while you can still act.
The Loop is also what makes a logframe defensible. Every indicator value traces to the evidence behind it and every assumption to the data for or against it, so the matrix resolves to its source rather than to a designer's optimism. That standard has its own chapter in reliability and reproducibility. Where a logframe feeds the practice is on impact measurement.
The fastest way to strengthen a logframe is to test its assumptions column against real evidence. Each prompt below pastes into Sopact Sense's Assistant, or reasons through with your team; the arrow above each links the Academy walkthrough that shows the expected output and the tips.
Academy walkthrough → Build the logframe matrix
Build a logframe from this project: [PROGRAM OR THEORY OF CHANGE]. Produce four result levels — goal, outcome, outputs, and activities — and four columns: results hierarchy, indicators, means of verification, and assumptions. Flag any output posing as an outcome, any indicator that measures activity rather than change, and any result with no realistic way to verify it. Return the matrix.
Academy walkthrough → Audit the assumptions column
Review this logframe's assumptions column: [PASTE LOGFRAME]. For each assumption, judge how likely it is to fail, what evidence would confirm or refute it, and how much of the vertical logic depends on it. Rank the assumptions by risk to the purpose. Return a table: Level / Assumption / Failure risk / Evidence to watch.
Academy walkthrough → Fix the indicators and verification
Audit the indicator and means-of-verification columns of this logframe: [PASTE LOGFRAME]. For each row, check the indicator is measurable and the verification is realistic, and flag any indicator that measures activity rather than result. Return a table: Level / Indicator / Measurable? / Verification realistic?
Academy walkthrough → Recover the theory beneath it
From this logframe: [PASTE OR LINK], recover the theory of change beneath it — the mechanism between each level and why the assumptions matter. Name where the vertical logic is weakest. Return the causal version the logframe summarizes.
Each walkthrough is a hands-on companion written to run on your own data: what to do, the prompt to run, the output to expect, and the tips that keep it reliable.
Watch: reading a logframe's assumptions column against evidence as it arrives, so a failing assumption surfaces while the project can still adapt.
A logframe is a logical framework matrix that summarizes a project's results chain, indicators, evidence sources, and assumptions. Sopact uses the logframe to connect what a team will do, what changes it expects, how it will measure progress, and what external conditions could affect success.
A standard logframe has four columns: the results hierarchy or narrative summary; objectively verifiable indicators; means of verification; and assumptions or risks. Sopact can also retain funder-specific baseline, target, frequency, responsibility, or budget fields.
OVI means objectively verifiable indicator. It is a specific measure that shows whether a planned result occurred. Sopact helps define the result, population, time period, baseline, and target so different readers interpret the indicator consistently.
An assumption is an external condition that must hold for the project logic to work; a risk is the possibility that the condition will not hold. Sopact's Unrevisited Assumptions Column turns those conditions into evidence the team checks while the project is running.
A logframe is the matrix — indicators, verification, and assumptions in a grid; a theory of change is the causal explanation beneath it, the mechanism and assumption behind every link. The logframe is compact and fundable; the theory of change is fuller and explanatory. Build the theory of change first and derive the logframe from it. Sopact keeps both as views of the same logic so they never diverge.
A logic model is a one-page inputs-to-outcomes summary without the verification and assumptions detail; a logframe adds the indicator, means of verification, and assumption at every level in a matrix. The logic model is for quick communication; the logframe is for funded, monitored projects. Both derive from the same underlying logic, and Sopact produces either as a view rather than a separate document.
A logframe is a four-row matrix with verification and assumptions; a results framework is a nested hierarchy showing how results ladder from sub-results up to a goal, usually without the verification detail. The logframe is stronger on indicators and assumptions; the results framework is stronger on showing the structure of results. Sopact keeps both as presentations of one logic, so switching between them is a view, not a rebuild.
Review a logframe when the program design changes, at planned monitoring points, and whenever evidence suggests an assumption may be failing. Sopact's Unrevisited Assumptions Column keeps assumptions visible whenever relevant evidence arrives, rather than waiting for a terminal evaluation.
AI can draft a first matrix, identify outputs mistaken for outcomes, suggest clearer indicators, and flag assumptions that need evidence. Sopact keeps the final judgment with people who understand the program, funder requirements, data limitations, and local context.
The Logical Framework Approach is the wider design process that analyzes context, stakeholders, problems, objectives, strategy, risks, and indicators. The logframe matrix is the four-by-four summary produced from that work. Sopact treats the matrix as a living view of the design rather than a substitute for the analysis behind it.
Next: build the causal layer on theory of change, or the same logic as a hierarchy on results framework.
