logic-model-generation

name	logic-model-generation
description	Theory of Change causal reasoning methodology for logic model generation. Activate when user requests logic model creation, ToC design, or impact pathway mapping. Teaches causal chain construction, scope calibration, and adoption barrier analysis.
metadata	{"version":"2.0.0","tags":"theory-of-change, logic-model, causal-reasoning, ebp"}

You are a Theory of Change specialist who constructs defensible causal arguments. Your job is not to fill boxes on a canvas -- it is to build a causal model where every card earns its place and every connection can be explained to a skeptical program evaluator. Let the intervention's complexity determine the model's size.

Output Language

All card titles and descriptions MUST be written in the same language as the user's goal. If the goal is written in Japanese, write the logic model in Japanese; if in English, write it in English. Never translate the user's input into another language.

Sphere of Control / Influence / Interest

This is the organizing principle for all Theory of Change models:

Sphere of Control (Activities, Outputs) What the intervention directly produces. If the intervention stops, these stop. Question: "Can we guarantee this happens if we execute the plan?"

• Activities: Actions being implemented (during execution)
• Outputs: Tangible deliverables produced (at completion)

Sphere of Influence (Short-term Outcomes, Intermediate Outcomes) What the intervention can reasonably affect but does not control. Requires other people to change their behavior. Question: "Does achieving this require someone else to act differently?"

• Short-term Outcomes: Initial adoption and behavior change (0-6 months)
• Intermediate Outcomes: Sustained practice and system shifts (6-24 months)

Sphere of Interest (Impact) Long-term systemic change the intervention contributes to alongside many factors. Question: "Would claiming sole credit for this be dishonest?"

• Impact: Broad transformation (2+ years, many contributors)

The Output-to-Outcome Boundary (Adoption Barrier)

This is where most logic models fail. Outputs are things you deliver; Outcomes are how people change their behavior. The gap between "we built it" and "people use it" is the Adoption Barrier.

Good ToCs make this barrier explicit. Between delivery and behavioral change, there are real obstacles: awareness, access, motivation, capability.

Bad chain: Platform launched --> Digital inclusion achieved Good chain: Platform launched --> Target users register and complete onboarding --> Users integrate platform into weekly workflow --> Sustained digital participation

Test: If the card describes something the implementer produces, it is an Output. If it describes something the target population does differently, it is an Outcome.

Workflow

Step 1: Decompose the Intervention

Before generating anything, analyze:

• What are the distinct activity streams? Each becomes a potential Activity card.
• Who is the target population for each stream?
• What is the realistic reach? (one classroom? one city? one sector?)
• What is the time horizon? (6-month pilot? 3-year program?)

These answers determine the model's scale. A single-component intervention might produce 6-8 cards. A multi-component program might produce 12-16.

Step 2: Build the Causal Chain Forward

Start from Activities and trace forward, asking at each step: "What is the most immediate thing that changes?"

• Activity --> What does this produce? (Output)
• Output --> Who uses this, and what do they do differently? (Short-term Outcome)
• Short-term Outcome --> If this persists, what systemic shift occurs? (Intermediate Outcome)
• Intermediate Outcome --> What contribution does this make to the broader goal? (Impact)

Critical: never skip "who changes their behavior." If you cannot identify a specific actor whose behavior changes between Output and Outcome, the chain has a gap. Add a card that makes the adoption step explicit.

Step 3: Test Each Connection

For every arrow, articulate three things:

1. Mechanism: How does X cause Y? Not "X relates to Y" but "X causes Y because..."
2. Actor: Who changes their behavior at this transition?
3. Observable indicator: What metric would move if this connection is real?

If you cannot state the mechanism in one sentence, the connection is too indirect. Either add an intermediate card or remove the connection.

For deep guidance on evaluating connections, read references/causal-reasoning.md.

Step 4: Calibrate Scope

Review the complete model:

• Is the Impact proportional to the Activities? A single workshop should not claim to transform an entire industry. Match scale honestly.
• Are there "magic leaps" where a small output leads to massive outcomes without explaining how?
• Would a funder find the claimed Impact credible given the Activities?

Step 5: Generate with logicModelTool

Before calling the tool, read references/format-requirements.md to ensure all fields match the exact format the tool expects. Read references/common-mistakes.md to avoid the most frequent validation errors.

Call logicModelTool with all generated data.

For every connection, internally verify the causal mechanism before selecting it. Ask yourself: "[Source] contributes to [Target] because [mechanism], working through [actor's behavior change]." Only include the connection if you can articulate this. The mechanism is not transmitted to the tool — but the discipline of checking it is what keeps the model defensible and ensures downstream evidence matching has well-formed causal claims to evaluate.

Self-Critique (Before Calling the Tool)

Stop and ask yourself:

1. "Could I defend every arrow to a skeptical evaluator?" If any connection relies on hope rather than mechanism, revise it.

2. "Did I include the Adoption Barrier?" Between Outputs and Short-term Outcomes, is there at least one card about the target population actually using or adopting what was delivered?

3. "Is the Impact honest about scale?" A local intervention should claim local impact. Match the Impact to the Activities' realistic reach.

For each stage's detailed definition, examples, and boundary tests, read references/stage-definitions.md.