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, or logical framework, is a matrix that sets out a project's logic on one page: four rows — goal, purpose, outputs, and activities — each with three columns for the indicator, its means of verification, and the assumption that has to hold. It is the planning and reporting format development funders and multilateral agencies most often require. Read up the rows it is the results logic; read across the columns it is the verification logic.
The logframe is powerful and widely misused: teams fill the indicators and means-of-verification columns carefully and treat the assumptions column as a formality, even though that column is where the project's real risks live. This guide covers what a logframe is, the four-row three-column matrix and its two logics, why the assumptions column decides whether the plan holds, and how a logframe differs from a theory of change, a logic model, and a results framework.
Key takeaways
The logframe matrix has four rows — goal, purpose (or outcome), outputs, and activities — and three columns — the indicator, its means of verification, and the assumption at each level. The vertical logic reads up: if the activities are done, and the assumptions hold, the outputs follow; if the outputs are delivered, and the assumptions hold, the purpose is achieved. The horizontal logic reads across: every level has an indicator and a defined way to verify it.
The row teams get wrong is the purpose row, where an output often masquerades as an outcome; the discipline of stating the assumption between outputs and purpose catches it. Read the matrix below. The causal layer beneath a logframe is on theory of change, and the same logic as a nested hierarchy on results framework.
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.
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.
Read across the row for what each is best at. The cleanest workflow builds the theory of change first, then derives the logframe, the logic model, or the results framework as the funder requires. 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.
| Artifact | What it is best at | What it under-does |
|---|---|---|
| Logframe | Indicators, verification, assumptions in a matrix | The causal 'why' between levels |
| Theory of change | The causal logic and assumptions | A compact reporting matrix |
| Logic model | A one-page inputs-to-outcomes summary | Assumptions and verification |
| Results framework | A nested results hierarchy to a goal | The verification detail |
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.
One method, three moves that never stop
Then the cycle runs again, a little sharper each cycle. Read the method: the Loop methodology →
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 the four rows — goal, purpose, outputs, activities — each with an indicator, a means of verification, and the assumption that has to hold at that level. Flag any output posing as a purpose and any level with no 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, or logical framework, is a matrix that puts a project's logic on one page: four rows — goal, purpose, outputs, activities — each with three columns for the indicator, its means of verification, and the assumption. It is the format development funders most often require. Sopact's framing highlights the Unrevisited Assumptions Column — the column that decides whether the plan holds but is filled once and rarely checked again.
The logframe matrix is a four-by-three grid. The four rows are goal, purpose (or outcome), outputs, and activities; the three columns are the indicator, the means of verification, and the assumption at each level. It carries two logics: read up the rows for the results logic (activities lead to a goal if the assumptions hold), and read across for the verification logic (every level has an indicator and a way to check it). Sopact keeps the matrix connected to the evidence so it is a live tool, not a static grid.
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.
The assumptions column names the external conditions that must hold for each level to lead to the next — that partners deliver, that policy is stable, that beneficiaries engage, that markets do not collapse. It is where a project's real risks live. The common failure is filling it once at design and never revisiting it, so an assumption fails quietly. Sopact reads evidence against the assumptions continuously, turning the column into a live risk register.
Because the vertical logic only holds if the assumptions hold: a project can deliver every output, report green indicators, and still fail its purpose because an assumption between outputs and purpose was false. The assumptions column is where that risk is stated — and where it is ignored, because no one revisits it after design. Sopact's contribution is checking the assumptions against evidence as it arrives, which is the difference between catching a failure and confirming one at the terminal evaluation.
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.
Start from a theory of change or results logic, then fill the matrix: for each of the four rows, name the indicator, the means of verification, and the assumption that has to hold. Check that no output is masquerading as a purpose and that every level can actually be verified. The step most teams shortcut is the assumptions column. Sopact drafts the matrix from your logic and flags weak indicators and missing assumptions before it goes to a funder.
Next: build the causal layer on theory of change, or the same logic as a hierarchy on results framework.
