What is the difference between a theory of change and a logic model?
A theory of change explains why a program’s work should lead to change and what must be true along the way; a logic model lays out the same chain as inputs, activities, outputs and outcomes, usually with less room for the reasons. The difference is emphasis, not a rule: a good logic model can carry assumptions, and a theory of change still needs clear levels.
Most teams meet the question when a funder asks for one format and they already have the other. You rarely need two documents; you need one change model, shown in the layout each reader expects.
THE SHORT VERSION
- Both formats describe one skeleton, inputs to impact; a theory of change stresses why each step follows, a logic model what is delivered.
- Build the theory of change first, then lay the same levels, definitions and indicators out as a logic model when someone needs the table.
- Neither format proves the program caused a result, so treat each arrow as a question your records will answer over time.
Is a logic model the same as a theory of change?
They describe the same chain under different labels: inputs, activities, outputs, outcomes and impact. A theory of change calls those levels resources, what you do, what you deliver, changes for people and long-term change. A logframe and a results framework relabel the same five levels again.
What differs is how much each layout shows: a theory of change gives room to the assumption under each arrow and to the people affected; a logic model fits on one page and makes responsibilities plain.
Theory of change vs logic model: how do they compare?
A theory of change is the better tool for testing reasoning; a logic model is the better tool for describing delivery and planning what to count.
| Question | Theory of change | Logic model |
|---|---|---|
| What it answers | Why should this work lead to change? | What goes in, and what comes out? |
| Emphasis | Pathways, assumptions, context | Resources, activities, results in scope |
| Usual shape | Narrative, outcomes map or diagram | One-page table or left-to-right flow |
| Assumptions | Central, written under each arrow | Allowed, often in a note beside it |
| Best moment | Designing or questioning a strategy | Agreeing a program description and plan |
| Proves on its own | An explanation to test, not an effect | Intended links, not that they happened |
The Center for Theory of Change stresses the intermediate conditions that link activities to long-term goals, and the CDC’s program-description guidance includes context when building a logic model. “Why versus what” is shorthand, not a full definition.
What does the same program look like in both formats?
Write the program once as a logic model, then add what a theory of change asks for: the condition under each arrow that must hold for the next level to follow. The program is fictional: a job-training partner of a regional workforce fund, the running example in the course Measurement and reporting.
On the fund’s onboarding call, the partner described its pathway: training and mentoring → certification → placement within 90 days → retained at 12 months → living-wage jobs.
| Level | Logic model entry | Theory of change adds: what must be true |
|---|---|---|
| Inputs | Trainers, mentors, employer contacts | Staff and funding are in place for each cohort |
| Activities | Training and mentoring | Content matches what local employers hire for |
| Outputs | Participants enrolled; completed training; certified | Employers recognize the certification |
| Outcomes | Placed in a job within 90 days of exit; retained at 12 months; starting wage by track | Suitable jobs are within reach, and the job fits the person, so they stay |
| Impact | Living-wage jobs | The job, or the next one, pays a living wage |
Fictional workforce example. Inputs and assumptions are illustrative.
The middle column is a plan: who delivers what, and what gets counted. The right column shows where it could fail even if every session runs on time. Enrolled and completed are outputs the program controls; placement, retention and wage also depend on employers.
This short introduction covers outputs, outcomes and impact with a skills example. Watch for where it separates what a program delivers from what changes for people.
Which does a funder want, and when should you use each?
Give each funder the layout it asks for, and pick your own starting point by the decision in front of you: a theory of change when the reasoning is uncertain, a logic model when delivery needs a shared description.
| Your situation | Lead with | Why |
|---|---|---|
| Partners agree on the goal, not the route | Theory of change | A task list hides the disagreement |
| Established program, new staff or partner | Logic model | Shows who does what and what is in scope |
| Evaluation design or strategy review | Theory of change | Assumptions become evaluation questions |
| Government or international donor | Logframe of the same model | Adds indicators and means of verification |
| Board or portfolio overview | Results framework or logic model | Reads from the objective down |
None of these situations requires a second model; the real risk is a second vocabulary. When the logic model says “placed in a job within 90 days” and the proposal narrative says “employed within six months”, two funders soon receive two placement numbers for the same people.
For each format on its own, see the guides to the theory of change and logic models. The video below looks at logic models in practice. Watch for how the table helps a team agree responsibilities, and where the reasoning behind each arrow has to be added beside it.
How do you turn a theory of change into a logic model without rebuilding it?
Re-lay it: keep the same levels, definitions and indicators, change only the labels and how much reasoning shows, and carry the key assumptions into a short note. The course chapter One change model, four formats builds the model level by level first; these steps take it from there.
- Agree the scope. One program, population, period and decision, not the whole organization.
- Keep the outcomes you can influence. Measure those; keep the long-term aim visible as impact.
- Map the activities and resources behind them. An arrow you cannot explain is a question, not a link.
- Separate delivery from change. Completing training is an output; placement within 90 days is an outcome.
- Carry the assumptions into a note. Two or three conditions sit beside the table.
- Check it with the people who use it. Ask staff and a few participants whether the table still says what the theory says.
To go the other way, write one sentence under each arrow of an existing logic model saying why the next box follows. If you already have both documents, check them for drift with the prompt below.
PROMPT · PASTE INTO CLAUDE, CHATGPT OR YOUR AI TOOL
Below are our theory of change and our logic model for the same program. Compare them level by level. Rules: 1. Map both to five levels: inputs, activities, outputs, outcomes, impact. 2. List anything in one document but not the other, and flag every outcome whose wording, unit or time window differs between the two (for example "placed within 90 days" vs "employed within six months"). 3. Flag any output written as an outcome, and any assumption the logic model leaves out. 4. Do not invent outcomes, indicators, targets or numbers. If something is missing from both documents, write "not in our data". 5. End with the edits that would make them agree. Do not make the edits yourself. Our theory of change: [PASTE] Our logic model: [PASTE]
Where do indicators fit in each format?
Indicators belong to the model, not to the format: each output and outcome gets one indicator, defined once, and every layout points to the same one.
In the workforce example, the fund and the partner turned the onboarding call into a reporting agreement with five metrics. Participants enrolled (unique people, not visits) and completed training are outputs; placed in a job within 90 days, retained at 12 months and starting wage by track are outcomes, with wage speaking to the long-term aim.
A metric that fits no level is a cost without a question; an outcome with no metric is a claim nobody is checking.
Each indicator then needs a definition both sides count the same way: the unit (a person, not an attendance entry), the time window and the denominator. The chapter A shared data dictionary shows how to write that row once for every format.
In Sopact Sense, each participant keeps one ID from the first form, so enrollment, completion, placement and the 12-month follow-up attach to the same person, and every line of an AI Assistant answer links to a record you can open.
The video below builds a theory of change in four steps with an evidence table under the diagram. Watch the table: it is where each format’s indicators, and the evidence behind them, are written down.
What can neither a theory of change nor a logic model prove?
Neither format shows that the program caused a result; both are claims about how change should happen, to be tested against records.
Outputs are not outcomes, and a before-and-after change, such as more graduates placed this year than last, is not proof of cause without a comparison, because the local job market may have moved too. The line between a supported explanation and a causal estimate is covered in attribution vs contribution.
Retention and wage often come from graduates’ own answers, and people who stop responding at 12 months may differ from those who reply, so report who is missing. If an AI tool drafts or relabels your model, check its output against the source documents; a named person approves every change.
Give the model an owner and a review date; the CDC evaluation framework names changes in context, resources, knowledge and findings as reasons to revisit a logic model. Record what changed and who approved it rather than quietly rewording a definition.
Start with one model and two layouts
Pick one program and one funder request, and produce both layouts from a single set of levels and definitions.
- Write the long-term change in one line, and name who experiences it.
- Work back three or four earlier changes, add your main activities, and write one assumption under each arrow.
- Mark each level as output or outcome, and attach the indicator your funder agreed to, with its unit and time window.
- Lay the same rows out as a logic model table and move the assumptions into a note beside it.
- Run the comparison prompt on the two documents and fix every place they disagree.
- Book a review date and name who approves changes.
After the first cycle you have one change model, two layouts that agree, and a short list of assumptions your next reports will test. The logic model template gives you a table to start from, and the same rows fit a logframe later.
Frequently asked questions
Is a theory of change better than a logic model?
Neither is better in general. A theory of change is stronger for testing why a program should work; a logic model is stronger for a one-page account of delivery. Build the theory of change first, because the logic model is quicker to check once the reason behind each arrow is written down.
Can a logic model include assumptions?
Yes. Assumptions, context and external factors can sit inside a logic model or in a note beside it. The difference from a theory of change is emphasis: a theory of change makes the assumptions its main content, while a logic model usually keeps them brief so the table stays readable.
Is a logic model always linear?
No. Many logic models run left to right, but the format can show several pathways, shared outcomes and feedback loops. If the program works through more than one route, such as mentoring for some participants and training for all, draw both. Presenting a complex program as one inevitable chain misleads the reader about how it works.
Do we need a logframe as well?
Only if a funder or planning process asks for one. A logframe is the same model as a matrix: goal, purpose, outputs and activities as rows, with indicators, means of verification and assumptions as columns. A logic model plus your reporting agreement already holds most of it, so re-lay the model rather than writing a new document.
Do we need a different model for each funder?
No. Keep one model and one set of definitions, and show them in each funder’s layout. If a funder asks for an outcome you do not track, add it to your model once, with its definition. Parallel models tend to pick up different wording and time windows, and before long the same participants are being counted in two ways.
