The five components of a logic model — inputs, activities, outputs, outcomes, impact — the outputs-vs-outcomes distinction, examples, and templates.
A logic model maps the intended pathway from resources and activities to outputs, outcomes, and impact. It makes a program's logic visible across five components: inputs, activities, outputs, outcomes, and impact. It is the standard planning and reporting picture most funders ask for.
A theory of change goes deeper by making the assumptions, mechanisms, and external conditions behind each link explicit. That distinction matters when a program moves from a plan to evidence, and it is why Sopact treats the logic model as a live view generated from data rather than a slide drawn once and filed. This guide walks the five components, separates outputs from outcomes, compares the model to a theory of change, and shows how to build one that stays true as the program runs.
Watch: a practical walkthrough of logic-model applications, examples, and how the five components connect in program evaluation.
Key takeaways
Every logic model threads the same five components in the same order: inputs are what you commit, activities are what you deliver, outputs are the direct countable products, outcomes are the changes in the people served, and impact is the long-term systemic change. The one distinction that decides whether a logic model measures anything is outputs versus outcomes.
Outputs are what you did; outcomes are what changed. “200 people trained” is an output; “68% placed in stable jobs” is an outcome. A logic model that stops at outputs counts effort; one wired to outcome data measures result. Sopact keeps both on the same model, each outcome carrying an indicator and a data source rather than an empty box. Filled-in versions across sectors are in the examples guide.
A completed logic model makes each step in the pathway concrete: resources support delivery, delivery produces countable outputs, and outputs are expected to contribute to measurable changes. The example below separates delivery evidence from outcome evidence, so it does not mistake workshop completion for employment.
| Inputs | Activities | Outputs | Short-term outcomes | Longer-term outcomes |
|---|---|---|---|---|
| Staff, curriculum, employer partners, funding | Job-readiness workshops and employer coaching | 120 participants complete six workshops | Participants improve interview confidence and job-search skills | Participants gain and retain employment |
| Indicators Staff capacity, partner agreements | Indicators Workshops and coaching sessions delivered | Indicators Completion rate | Indicators Pre/post confidence score | Indicators Employment at 90 and 180 days |
| Evidence source Budget and partner records | Evidence source Delivery log | Evidence source Attendance records | Evidence source Matched pre/post surveys | Evidence source Follow-up and verified employment |
Build a logic model by defining the population and problem, listing the resources and partners, describing activities, counting direct outputs, and then naming the short-, medium-, and long-term outcomes. For every output and outcome, add the indicator, data source, timing, denominator, and person responsible before treating the model as complete.
| Step | Decision | Make it measurable |
|---|---|---|
| 1 | Define the population and problem | State who the program serves and the specific condition it aims to change. |
| 2 | List resources and partners | Name the staff, funding, curriculum, systems, and partner commitments required. |
| 3 | Describe activities | Write the actual services or interventions the program delivers. |
| 4 | Count direct outputs | Specify the units of delivery: participants, sessions, credentials, or referrals. |
| 5 | Name outcomes, then attach evidence | For each short-, medium-, and long-term outcome, record an indicator, data source, timing, denominator, and owner. |
Output indicators count what was delivered; outcome indicators measure what changed. A useful logic model records the data source, collection timing, denominator, and owner beside every indicator, so a percentage can be traced to evidence rather than repeated as an assertion.
For example, workshop completion can use attendance records; improved interview confidence can use matched pre/post surveys; and employment retention can use follow-up and verified employment records. Sopact's Living Logic Model keeps those fields connected to a persistent participant ID, so teams can see whether a reported outcome has evidence behind it.
The classic logic model is a static artifact — drawn in a workshop, formatted for a grant application, and never touched again until the next report. That made sense when collecting and reading data was slow. It no longer does, and a logic model that has not changed since kickoff is a description of a program that no longer exists.
Sopact calls the alternative The Living Logic Model: the five components are not empty boxes but each output and outcome tied to an indicator, an instrument, and a persistent participant ID, so the model fills itself as data arrives and updates as the program runs. The difference is a data-model one — a diagram is a picture of the plan, while a living logic model is a picture of what is actually happening. The causal layer beneath it is on theory of change vs logic model, and the practice it feeds on impact measurement and management.
Watch: The Logic Model Architecture Most Nonprofits Get Wrong — how to avoid the static, grant-only model and connect the framework to evidence as a program runs.
The logic model spread as a funder template. The W.K. Kellogg Foundation logic model and the CDC logic model — inputs, activities, outputs, outcomes, impact — became the canonical blank forms a program fills in, and general canvases like Miro and Lucidchart made the picture easy to draw and share. These templates did real work: they standardized the shape and made the outputs-versus-outcomes distinction teachable.
What a template cannot do is fill itself. A blank Kellogg or CDC form has no concept of an indicator, an instrument, or a response, so the boxes stay empty of everything that happens after the workshop. A live logic model wires each box to the data that belongs in it.
The one test that separates a template from a working model: after the program runs a cycle, does the logic model update itself from the data, or does someone redraw it by hand for the next report. If it cannot update, it is a picture, however well-formatted. A blank canvas to start from is in the logic model template guide. The stage below runs one build-and-keep-alive cycle both ways.
A logic model and a theory of change are not rivals; they scaffold different layers of the same program. The logic model is the operational layer — inputs, activities, outputs — legible to a funder in under a minute. The theory of change is the causal layer — the mechanism on every arrow and the assumption behind every outcome. Build the theory of change first, then derive the logic model from it as the one-page summary. The full comparison and decision rules are in the theory of change vs logic model guide.
| Layer | Logic model | Theory of change |
|---|---|---|
| What it is | The operational picture | The causal explanation |
| Shows | What a program does, left to right | Why each activity produces the result |
| Assumptions | Left implicit | Named on every arrow |
| Read by a funder in | Under a minute | A design or evaluation review |
The two are complementary, not competing: the theory of change explains why the arrows should hold, and the logic model presents the result in a form a funder reads at a glance. Everything a logic model leaves implicit, the theory of change makes explicit — which is why the cleanest workflow builds the causal version first.
A logframe and a results framework are not different plans — they are different presentations of the same underlying logic, so you build the model once and switch the format rather than maintaining three documents by hand. A logframe adds indicators, means of verification, and assumptions in a matrix; a results framework orders the results hierarchy to a goal.
With one model on one record, switching a grant from a logic model to a logframe is a view, not a rebuild. The matrix version is on logframe, the hierarchy version on results framework, and the evaluation practice these feed on program evaluation.
| Format | What it adds | When a funder asks |
|---|---|---|
| Logic model | The one-page results picture | Most grant applications |
| Logframe | Indicators, verification, assumptions in a matrix | Government and multilateral grants |
| Results framework | The results hierarchy, ordered to a goal | Results-based development reporting |
A logic model formatted for a grant and filed answers the plan, not the program. Reading each output and outcome as the data lands keeps the model current and shows an outcome slipping while there is still time to act. 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 logic model defensible. Every outcome traces to the participant who reported it, so a box on the model resolves to its evidence. That standard has its own chapter in reliability and reproducibility.
One method, three moves that never stop
Then the cycle runs again, a little sharper each cycle. Read the method: the Loop methodology →
A logic model earns its keep at four moments — drafting the five components, attaching an indicator to every output and outcome, deriving the causal layer, and converting to the funder's format. 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 five components
Build a logic model from this program description: [PROGRAM URL OR DOC]. Fill the five components — inputs, activities, outputs, outcomes, and impact — and for every output and outcome, name the indicator that measures it and the data source. Flag any outcome that is really an output in disguise.
Academy walkthrough → Audit outputs vs outcomes
Audit this logic model: [PASTE OR LINK]. Flag every outcome that is actually an output, every box with no indicator, and every activity that does not connect to a named outcome. Return a corrected five-component model with an indicator on each outcome.
Academy walkthrough → Add the causal layer
From this logic model: [PASTE OR LINK], derive the theory of change beneath it: name the mechanism on each arrow (why this activity produces this outcome) and the assumption each link depends on. Return the causal version the logic model summarizes.
Academy walkthrough → Convert to the funder's format
From this logic model: [PASTE OR LINK], produce a logframe: goal, purpose, outputs, and activities, each row with its indicator, means of verification, and assumption. Keep it consistent with the logic model rather than rebuilding from scratch.
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.
A logic model is a one-page diagram that maps a program from the resources it commits to the results it expects, across five components: inputs, activities, outputs, outcomes, and impact. It describes what a program does and what it should produce. In Sopact a logic model is kept as a live view generated from data — every output and outcome tied to an indicator and a participant ID — rather than a static slide.
The five components are inputs, activities, outputs, outcomes, and impact. Inputs are the resources you commit; activities are what you deliver; outputs are the direct countable products; outcomes are the changes in the people served; impact is the long-term systemic change. The most common error is listing an output like “200 people trained” in the outcomes column instead of a real change like “68% placed in stable jobs.”
Outputs are what the program did — sessions held, people served, credentials issued. Outcomes are what changed in the people served — new skills, behavior change, a job. Outputs count effort; outcomes measure result. A logic model that stops at outputs cannot show whether the program worked; Sopact ties each outcome to an indicator and a data source so the outcome column carries evidence, not assertions.
A logic model describes what a program does in a left-to-right matrix; a theory of change adds the causal explanation — the mechanism on each arrow and the assumption behind each outcome. The logic model is the operational layer for funder communication; the theory of change is the causal layer for evaluation design. Build the theory of change first and derive the logic model from it as the one-page summary.
Yes — a logic model template is a pre-structured canvas with a labeled column for each of the five components, and the Kellogg Foundation and CDC versions are the canonical ones. A template gets a team to a draft quickly, which is the point. The template is not the finished model, though: the team still supplies the indicators, instruments, and data sources that make each outcome measurable. A working template is in the logic model template guide.
Start from what the program already commits and delivers: list inputs and activities, then the outputs they produce, then the outcomes those outputs should lead to, then the long-term impact. For every output and outcome, name the indicator that measures it and the data source. Sopact drafts the five components from a program page and attaches an indicator to each, so the model starts measurable rather than decorative.
Output indicators count what was delivered, such as sessions held or participants completing a workshop. Outcome indicators measure what changed, such as interview confidence or employment retained after 90 days. Sopact records the data source, timing, denominator, and owner alongside each indicator, so the Living Logic Model connects every reported result to its evidence.
Yes. A logic model should record the assumptions and external conditions that could affect whether activities lead to outcomes, even if a theory of change develops them in more detail. Sopact treats these as testable conditions: for a workforce program, local employers continuing to hire is an assumption that should be revisited when employment outcomes change.
A logic model framework is the model made operational: the five-component diagram plus the indicators that measure each output and outcome, the instruments that collect them, and the data sources behind them. The diagram is the picture; the framework is the picture wired to data. Sopact generates the framework view from collected evidence, so a framework without indicators or instruments is just a labeled canvas.
The static diagram drawn once and filed is over. A modern logic model is a live view: the five components are connected to indicators, instruments, and one persistent participant ID, so the model fills itself as data arrives and updates as the program runs. It stops being a picture of the plan and becomes a picture of what is actually happening — which is what Sopact is built to produce, without a separate logic-model tool.
Next: add the causal layer on theory of change, or compare the two on theory of change vs logic model.
