Logic Model (Program Evaluation)¶

A program representation linking resources and activities to outputs, outcomes, and intended impact through explicit assumptions.

Version: v1 · 2026-08-30 · History
Domain-specific #: 2205
Origin domain: program evaluation
Subdomain: program theory
Aliases: Program logic model, Program logic

Core Idea¶

A logic model in program evaluation is an explicit representation of how a program is expected to turn resources into activities, direct outputs, short- and longer-term outcomes, and broader impact. It records the program’s theory and assumptions in a form that connects implementation with intended change. The widely used W. K. Kellogg Foundation guide organizes the basic model as resources/inputs, activities, outputs, outcomes, and impact, while also emphasizing assumptions and external factors.^[1]

The arrows are hypotheses, not proof. A logic model says what must happen, in what plausible sequence, and what could be measured if the program works as intended. Evaluators use it to choose implementation indicators, outcome questions, and places where causal links might fail. Program designers use it to test whether resources and activities plausibly support the desired results.

The abstraction is neither a generic flowchart nor a final causal estimate. Its stable identity is a program-specific results chain with role separation, explicit assumptions, and measurement checkpoints.

Structural Signature¶

Mandatory roles:

The situation or need states the problem, opportunity, or population context.
Inputs/resources identify people, funding, relationships, facilities, knowledge, and time available.
Activities specify what the program actually does.
Outputs record direct products, service counts, or participation produced by activities.
Outcomes state changes in knowledge, behavior, condition, or system over time.
Impact or long-term result names the broader intended change.
Assumptions and external factors state why links should hold and what lies outside program control.

Recognition test. A representation qualifies when it distinguishes action from direct production and downstream change, makes hypothesized links inspectable, and supports indicator selection. A box sequence lacking causal assumptions or program roles is only a process diagram.

What It Is Not¶

It is not formal logic or a logical model in model theory; “logic” here means program rationale.
It is not a theory of change in every convention. The terms overlap, but a theory of change may give deeper causal narrative, actors, preconditions, and alternative pathways.
It is not a project schedule. Time can be included, but the central structure is results logic rather than dates and dependencies.
It is not an organization chart or workflow map. Outputs and outcomes must be distinguished from internal steps.
It is not evidence that the program caused observed outcomes. Evaluation design supplies that inference.

Scope of Application¶

Logic models are used in public health, education, community development, nonprofit programs, public administration, and grantmaking. They can describe a small intervention, a multi-part initiative, or a policy implementation system. Different models may emphasize activities, outcomes, or underlying theory, but the program-to-result linkage remains.^[2]

They are especially useful during design, stakeholder alignment, evaluation planning, and revision. A mature model can attach indicators, data sources, timing, and responsibility to each role. Complex systems may require branching feedback and multiple actor pathways; a single left-to-right row can be inadequate, but it can still serve as a summary if assumptions and dependencies remain visible.

Clarity¶

The structure prevents a common category error: counting services as if they were social change. “Twenty workshops delivered” is an output. “Participants use the taught practice” is an outcome. “Population-level harm declines” is a longer-term impact. Moving between these levels requires assumptions about reach, quality, adoption, context, and persistence.

It also clarifies evaluability. Every arrow invites a question: were resources available, were activities implemented, did intended participants receive outputs, did short-term change occur, and did it persist? Gaps reveal either missing program work or missing evidence.

Manages Complexity¶

A program can involve many staff, services, populations, and intended effects. The logic model compresses them into a shared causal-and-operational map. Teams can locate disagreements, avoid collecting indicators unrelated to decisions, and distinguish implementation failure from theory failure. Funders and communities can inspect what is being promised.

Compression can oversimplify nonlinear causation and feedback. A neat sequence may hide political conditions, participant agency, or unintended effects. Good use treats the diagram as revisable and supplements it with narrative and evidence, rather than mistaking visual order for causal certainty.

Abstract Reasoning¶

The representation supports conditional reasoning. If an activity was not delivered, failure of a downstream outcome does not by itself refute the change hypothesis; implementation broke first. If outputs were delivered but proximal outcomes did not change, the activity-to-outcome link or its assumptions deserve scrutiny. If proximal outcomes changed but impact did not, later links or external factors may dominate.

This staged reasoning also guides measurement. Input and output measures monitor implementation; outcome measures test intended change; contextual measures probe rival explanations. The model does not select a statistical design, but it tells that design which transitions and populations matter.

Knowledge Transfer¶

The role vocabulary transfers literally across program domains. A school attendance intervention and a vaccination outreach program both distinguish resources, activities, outputs, outcomes, and impact, though their content differs. Teams can reuse elicitation questions and validation procedures.

The broader transferable skeleton is Problem Representation or Causal Chain. Outside program evaluation, these parents may organize mechanisms and goals. Calling any product roadmap a logic model is warranted only if it explicitly connects actions to measured outputs and downstream outcomes through assumptions.

Examples¶

Community vaccination outreach. Inputs include staff, mobile clinics, vaccine supply, and community partnerships. Activities include targeted communication and pop-up clinics. Outputs include events held and eligible people reached. Short-term outcomes include increased access and completed doses; longer-term outcomes include higher coverage; intended impact is reduced preventable illness. Assumptions include trust, supply continuity, and access to follow-up.

Mapped diagnosis. If events occur but attendance remains low, the output-to-outcome link may fail because location or trust assumptions were wrong. If coverage rises but illness does not fall, timing, pathogen change, or measurement may affect the later link. The model locates questions without prejudging answers.

Nonexample. A workflow showing “approve budget → hire staff → run meeting” records tasks but no outputs, behavioral outcomes, population impact, or causal assumptions. It is useful project management but not yet a program-evaluation logic model.

Structural Tensions¶

Simplicity versus causal adequacy: a compact chain aids communication but can erase feedback. Diagnostic: can every material pathway and external dependency be represented or narratively attached?
Stakeholder agreement versus testability: inclusive language can become vague. Diagnostic: does each outcome specify whose change, what change, and an observable indicator?
Outputs versus outcomes: programs control delivery more directly than downstream change. Diagnostic: are service counts kept separate from participant or system conditions?
Planning confidence versus evidentiary humility: arrows express intention but can look proven. Diagnostic: is each arrow labeled as assumption, evidence-supported link, or evaluation question?
Standard template versus local causation: fixed columns promote reuse but may impose an ill-fitting sequence. Diagnostic: does the model reflect the actual program rather than merely fill every box?

Structural–Framed Character¶

Logic Model is mixed structural–framed. Its role sequence and inferential checkpoints are structural; the selected outcomes, assumptions, and acceptable impact are value- and institution-framed. Stakeholders partly constitute the model because program purposes and populations are normative choices.

It remains a genuine abstraction because the same roles support diagnosis across programs. It is domain-specific because program, service, indicator, outcome, and evaluation practices are indispensable.

Structural Core vs. Domain Accent¶

Structural core. Connect available means to actions, immediate products, intermediate changes, and longer-term goals while surfacing assumptions.

Domain accent. Inputs, activities, service outputs, outcomes, impact, indicators, stakeholders, and program evaluation determine literal use. Removing them leaves a generic causal or goal representation.

The domain residual is autonomous: it prevents output/outcome confusion and directly structures evaluation questions.

Logic Model specializes Problem Representation by organizing a program’s need, intervention, and intended results. It relates to Causality, Measurement, and Goal, but does not itself establish causal effects or choose measures. Problem Representation is the minimal parent because the model’s direct function is to make a program theory inspectable.

Relationships to Other Abstractions¶

Current abstraction Logic Model (Program Evaluation) Domain-specific

Parents (1) — more general patterns this builds on

Logic Model (Program Evaluation) is a kind of Problem Representation Prime

Logic Model specializes Problem Representation by organizing a program’s need, intervention, and intended results.

Hierarchy path (1) — routes to 1 parentless root

Logic Model (Program Evaluation) → Problem Representation → Representation → Abstraction

Neighborhood in Abstraction Space¶

Logic Model (Program Evaluation) sits in a sparse region of the domain-specific corpus (88^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Results-Based Management — 0.80
Sequence Diagram — 0.80
RDA: Resource Description and Access — 0.79
Entrepreneurship — 0.79
Autocausative Verb — 0.79

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Theory of change: often broader and more explanatory. Tell: is the artifact a compact results chain or a full account of preconditions and mechanisms?
Process map: describes workflow. Tell: are outcomes and impact distinguished from activities?
Results framework: may emphasize indicators and targets at strategic levels. Tell: are program activities and assumptions part of the same model?
Causal DAG: formal graph for identification assumptions. Tell: are variables and conditional independences formalized, or program roles communicated?
Logical model in mathematics: interpretation satisfying sentences. Tell: is the domain program evaluation or formal semantics?

References¶

[1] W. K. Kellogg Foundation, Logic Model Development Guide: Using Logic Models to Bring Together Planning, Evaluation, and Action, updated January 2004, https://www.betterevaluation.org/sites/default/files/2021-11/Kellogg_Foundation_Logic_Model_Guide.pdf. registry ↩

[2] Centers for Disease Control and Prevention, Introduction to Program Evaluation for Public Health Programs: A Self-Study Guide, 2011, Step 2 and logic-model discussion, https://www.cdc.gov/evaluation/php/evaluation-framework/index.html. registry ↩