Use this logic model template to trace a proposed program from its resources to a change you can investigate. The filled example keeps planned delivery, intended outcomes, and unanswered questions visible together.
Start with a complete proposed model
This original fictional program would help participants practice proofreading archive labels. Its practice materials are invented for teaching; they are not real archive records. The program has not run, and no attendance or participant results are supplied.
| Part of the model | Worked planning entry |
|---|---|
| Inputs | Three hours of facilitator time; a set of eight original practice cards; a room still TO CONFIRM. |
| Activities | Prepare and run two small practice sessions using modeled checks, participant practice, and feedback. |
| Planned outputs | Two sessions and up to ten participation places across those sessions. Actual delivery and attendance are unknown. |
| Intended short-term outcome | Participants can distinguish required label fields in a later practice record. The required fields, check task, indicator, baseline, and actual results are TO CONFIRM. |
| Intended later use | Participants apply the check to authorized real work. Permission, opportunity, and support for that use are TO CONFIRM. |
The three hours are a proposed resource for the program, not a promise of three hours per session. The eight cards are part of the planned materials. The model does not supply a finished card set or an approved archive procedure.
Ten participation places also does not mean ten different people. Someone might attend both sessions. Keep places offered, attendances, and unique participants separate if you later collect those counts.
Give each connection a question
CDC's logic-model guidance connects resources, activities, outputs, and intended outcomes through a series of if–then statements. It also asks planners to identify assumptions and challenges. Those general planning distinctions are useful here; the archive-label exercise is our own nonclinical example.
Read the model from left to right, asking what each arrow depends on:
| Connection | Question to resolve |
|---|---|
| Inputs → activities | Is the room available, and can the facilitator prepare and deliver the proposed work within the available time? |
| Activities → outputs | What will count as a delivered session, and how will actual participation be recorded? |
| Outputs → short-term outcome | What will participants practice, what feedback will they receive, and what later check could reveal the intended ability? |
| Short-term outcome → later use | Will participants have permission, a relevant opportunity, and support to use the check in real work? |
Choose a connection in the example to inspect its question beside the relevant model entries. A missing room affects delivery. An undefined check affects what you could learn about the outcome. They need different decisions, even though both remain unresolved.
Fix the leap from sessions to competence
The unsupported version says:
Two sessions → participants are competent.
A session count cannot establish that conclusion. Even after delivery, you would still need evidence of what participants can do and a clear meaning for “competent.”
Choose Revised connection to inspect a more useful planning statement:
Two planned sessions with modeled checks, practice, and feedback → intended ability to distinguish required label fields in a later practice record. Actual ability has not been observed.
The revision keeps the two sessions and the same capacity of up to ten participation places. It makes the learning activity and the intended change explicit, while retaining the unanswered assessment questions. It does not turn the arrow into proof that the program will cause the change.
Use the model to find the next planning decision. Here, the team needs to specify the required label fields and a suitable later practice task before it can decide what evidence to collect. Do not invent a baseline, a pass threshold, or successful results to fill the outcome cell.
Decide what you would need to observe
Keep a delivery question separate from an outcome question. “Did the two sessions take place?” concerns an output. “Can participants distinguish the required fields in the later record?” concerns the intended short-term change.
Then decide how the second question could be investigated. Which record will be used? What must the participant distinguish? What support is allowed? What would the team record, and who will review it? Leave those details TO CONFIRM until the program team supplies them.
A later correct response would need to be interpreted in its actual context. Without an appropriate evaluation design and evidence, it would not establish how much change occurred or that these sessions caused it. The model helps expose those questions before anyone starts reporting success.
Copy a prompt for your program model
Create one complete self-contained HTML logic model review page.
Program purpose, audience, and scope: [PASTE]
Available and proposed resources, with confirmation status: [PASTE]
Planned activities and immediate outputs: [PASTE]
Intended participant changes and later use: [PASTE]
Assumptions, external conditions, and unresolved questions: [PASTE]
Permitted evidence, indicator definitions, baseline, review owner: [PASTE]
Use only my supplied information. Separate inputs, activities,
outputs, intended short-term outcomes, and intended later use.
Identify the assumption or question at each connection. Keep
planned counts distinct from actual delivery and participant
results. Do not invent attendance, baseline, thresholds, learning,
approval, effectiveness, or causal evidence. Mark gaps TO CONFIRM.
Include this separate original fictional archive-label proofreading
program as a worked planning model. No program has run and no
actual participants, archive records, attendance, or results exist
in this exercise.
Inputs: three hours of facilitator time for the program; a set of
eight original practice cards; room TO CONFIRM. Do not claim the
cards are supplied here or represent an approved archive procedure.
Activities: prepare and run two small practice sessions with
modeled checks, participant practice, and feedback.
Planned outputs: two sessions and up to ten participation places
across the sessions. These are not ten confirmed attendees or ten
unique people. Actual delivery and attendance remain unknown.
Intended short-term outcome: participants distinguish required
label fields in a later practice record. Required fields, task,
indicator, baseline, and actual results are all TO CONFIRM.
Intended later use: apply the check to authorized real work.
Permission, opportunity, and support for that use are TO CONFIRM.
Keep the complete model readable. Selecting a connection shows:
Inputs to activities: confirm room and feasible preparation/delivery
within the available facilitator time.
Activities to outputs: define a delivered session and how actual
participation will be recorded.
Outputs to outcome: identify practice, feedback, and a later check
that could reveal the intended ability; its definition is unresolved.
Outcome to later use: confirm permission, relevant opportunity,
and support in real work.
Provide Unsupported connection and Revised connection controls.
Unsupported: Two sessions -> participants are competent.
Revised: Two planned sessions with modeled checks, practice, and
feedback -> intended ability to distinguish required label fields
in a later practice record. Actual ability has not been observed.
Explain the missing evidence. Keep all original resource/output
counts fixed in both views. No automatic evaluation or success score.
Add a separate blank scaffold with seven fields: Inputs, Activities,
Planned outputs, Intended changes, Assumptions, Measurement
questions, Review notes. Keep typing across connection/version
changes. Ask before clearing all seven fields; cancel preserves
them and clear leaves the worked model unchanged.
Use readable connected records with textual arrows and labeled
native buttons. Show selected states and visible keyboard focus.
Use at least 16px text; stack at 360px without horizontal page
scrolling. Inline CSS/JavaScript only; no external assets, network,
storage, submission, or fake export. Typing lasts in the open page
only. Return the full HTML and unresolved planning decisions.
Read the generated connections against the supplied information. In this example, both versions must retain three facilitator hours, eight planned cards, two sessions, and up to ten participation places. No view should quietly convert capacity into trained people.
Review the disputed label with a colleague
A sanitized HTML model can put the planned counts beside the assumptions a colleague needs to question. Open that copy in your NOS workspace when the team is ready to review the proposed chain.
If an output heading says “Ten trained people,” revise the static heading in visual editing mode to “Up to ten participation places planned.” Save the correction so the colleague reopening the existing link can see the intended meaning. Correct the maintained program model too; editing a heading does not create attendance records or change the underlying evidence.
Before delivery, settle the room, the practice task, and the questions the team can actually investigate. After delivery, record what happened and what was observed in their separate places.