Describe your program and Sopact Sense lays out the logic model — inputs through impact — grading every box by evidence and flagging the orphan activities and gaps a funder spots first.
In short: One prompt now builds a funder-ready logic model from nothing but what a program publicly states. It names the decision the reader must make, lays the program out in columns — inputs → activities → outputs → outcomes → impact — grades every box by evidence, flags the orphan activities that feed no output, and ends with a prioritized plan for the boxes a reviewer circles first. Below, we run it on a real public page and walk through what each part of the prompt produces.
Usually yes — it's the framework most funders ask for, because it makes a program's logic checkable in one page. A logic model lays your program out in columns — inputs → activities → outputs → outcomes → impact — so a reviewer can trace the line from what you spend to what changes. Most logic models fail in the middle: an activity that feeds no output, or an outcome with no data behind it. That's where the eye goes first.
The prompt below turns that principle into a complete audit. It reads only what your program states publicly, grades every box Green, Amber, or Red, names the orphan activities, and tells you the one box to fix this quarter. We ran it on The Lantern Network's public mentoring-program page — the sections that follow show the prompt for each part, then what came back.
Every grade depends on who is reading. A board sees "87% placed" as a headline; a renewing funder asks what evidence sits behind it, and whether every activity actually earns its place. So the prompt's first instruction is a decision frame: before building anything, state in one line who would use this logic model and for what decision. For Lantern, that came back as a corporate sponsor deciding whether to renew its grant. Every judgment below is made from that reader's chair.
Here is the full prompt. Paste it whole, swap in your program name and source, and Sense produces all four parts in one pass:
Build a Logic Model for [PROGRAM NAME] using only what the program publicly states at [SOURCE — URL or pasted program description]. Before building, state in one line who would use this logic model and for what decision — then make every judgment from that reader's perspective. PART 1 — Lay the program out in columns: Inputs → Activities → Outputs → Short-Term Outcomes → Medium/Long-Term Outcomes → Impact. Write every outcome as a change in people, never as an activity. Flag any orphan activity (one that feeds no output) and any empty column. Color every box: GREEN = specific AND evidenced; AMBER = stated but vague, or specific but unevidenced; RED = missing, or exists only as [INFERRED]. Tag anything not explicitly stated as [INFERRED]. Include a legend, program name, source URL, and date. PART 2 — One row per box: Element | Column | Grade | Evidence (quoted, paraphrased, or "none") | one measurable indicator that would test it, phrased so the program could actually collect it (who is measured, what changes, by when). PART 3 — List every orphan activity and every AMBER and RED box, ranked by how much the model depends on it. For each: why it is weak in one sentence, what breaks downstream, and whether the fix is a program-design problem or a measurement gap. PART 4 — The top 3–5 fixes, in priority order for the decision named above. For each: current language (or "missing") → proposed rewrite, plus the single data collection step that would move it toward green. CLOSING SUMMARY — 3–4 sentences: overall strength of the logic, the weakest box a skeptical funder would circle first, and the one action to take this quarter. RULES — Source fidelity is absolute: never invent program content; if the source does not say it, mark it RED or [INFERRED]. Every green grade must be traceable to specific source language.
Example source: https://www.lanternnetwork.org/mentoring-program. The rules do the heavy lifting — no invented content, every green traceable to a quote. The model is the claim; the table in Part 2 is its evidence trail.
Lay the program out in columns: Inputs → Activities → Outputs → Short-Term Outcomes → Medium/Long-Term Outcomes → Impact. Write every outcome as a change in people, never as an activity. Flag any orphan activity that feeds no output, and any empty column. Color every box green, amber, or red. Tag anything not explicitly stated as [INFERRED]. Include a legend, program name, source URL, and date.
Two disciplines make this different from the boxes-and-arrows version on most websites. First, every outcome is written as a change in people — "mentees gain career clarity," never "we run workshops." Second, the model hunts its own weak spots: an activity that produces no output is flagged as an orphan, and any column with nothing in it is called out. For Lantern, the pattern was immediate — the left of the model is concrete (288 mentees served, 251 internships delivered, named sponsors) while the outcome columns past placement rest on three testimonials.
The rubric is strict on purpose. Green means specific and evidenced — the program names it concretely and shows data ("87% secured internships, jobs, or promotions"). Amber means stated but vague, or specific but unevidenced. Red means missing entirely, or existing only as [INFERRED].
GRADE: green | 87% placed | 288 mentees, 251 internships — output evidenced; amber | confidence & clarity | short-term outcome claimed in three stories, never measured; red | mentoring dosage | activity with no recorded output — an orphan
For every box, produce one row: Element | Column | Grade | Evidence (quoted, paraphrased, or "none") | one measurable indicator that would test it, phrased so the program could actually collect it — who is measured, what changes, by when.
This table is the evidence trail behind the columns — one row per box, so nothing in the model floats free of a citation. The indicator column is the practical payoff: each is phrased so the program could actually collect it. For Lantern's orphan activity — the mentoring that feeds no output — the evidence column reads "none: no sessions, hours, or dosage recorded," and the indicator that would fix it is "mentoring hours and session count per mentee, captured against a persistent participant ID." That's not a critique; it's a work order.
List every orphan activity and every amber and red box, ranked by how much the model depends on it. For each: (a) why it is weak in one sentence, (b) what breaks downstream, (c) whether the fix is a program-design problem or a measurement gap — these require different responses.
The ranking is by dependence, not column order — the question is which weakness takes the most down with it. Lantern's number one was the orphan mentoring activity: no dosage is recorded, so there's no output linking the program's central activity to any outcome. If that link stays empty, confidence, clarity, and every downstream claim rest on the 87% placement number alone.
The design-versus-measurement tag matters just as much. A measurement gap means the program plausibly works but has never measured it — the fix is data collection. A design problem means an activity genuinely leads nowhere — the fix is program thinking. Lantern's diagnosis came back mostly measurement gaps: nothing needs removing, but the mentoring needs an output.
Give the top 3–5 fixes, in priority order for the decision named above. For each: show the current language (or "missing") → a proposed rewrite, plus the single data collection step that would move it toward green.
Each fix is a before-and-after pair. Lantern's first: the mentoring activity, currently "weekly 1:1 mentoring" with no output, gains an output box — "mentoring dosage recorded per mentee" — fed by a single data step: log session count and hours against a persistent participant ID. Fixes two through five follow the same shape: give the confidence claim a baseline/endline measure, connect the demo day to a placement output, and publish the denominator behind the 87%.
Close with 3–4 sentences: the overall strength of the logic, the weakest box a skeptical funder would circle first, and the one action to take this quarter.
The summary is the executive read. Lantern's verdict: the left of the model is concrete and evidenced, but the program's central activity — mentoring — produces no recorded output, so the outcome columns float. The one action this quarter: record mentoring dosage against a persistent participant ID, so next year's renewal case shows the activity actually connecting to the change it claims.
Take the prompt with you. The full prompt pack — the master prompt plus each part as a standalone prompt you can run separately — is available to download: Download the Logic Model prompt pack.
Hunt the orphan activities first. The fastest way to spot a weak logic model is to find an activity that feeds no output — a demo day connected to no placement, mentoring with no recorded dosage. Ask Sense to list orphan activities explicitly; funders circle them first.
Logic model vs theory of change. A logic model is the columns — what goes in, what comes out. A theory of change adds the assumption under each arrow. If you've built one, ask Sense: "Turn this logic model into a theory of change and name the assumption under each link."
Turn one box green per cycle. Add the one indicator Sense suggests for your reddest box, collect it next cohort, and re-run — watch the model fill in over time.
Tighten your program page while you're here. Once Sense has graded the model, ask it to bring your public claims in line with your evidence:
Based on the grades above, suggest edits to my program page so its claims match the evidence. Flag every sentence that overstates what we can show, and rewrite it to be accurate and specific.
The same prompt works for a Theory of Change, Logframe, or Results Framework — swap the framework name and keep the parts, rubric, and rules unchanged.
A logic model is a one-page map of a program in five columns — inputs → activities → outputs → outcomes → impact — that shows the line from the resources you put in to the change you expect out. It's the framework most funders ask for because it makes a program's logic checkable at a glance.
A logic model shows the columns — what goes in and what comes out, in sequence. A theory of change goes a step further and names the assumption under each arrow: why you believe one box leads to the next. The logic model is the structure; the theory of change explains why it should work. Many teams build the logic model first, then add the assumptions to turn it into a theory of change.
Describe your program in a few sentences (or paste its web page) and ask the AI to fill the five columns, flag gaps and orphan activities, suggest one indicator per element, and grade each box green, amber or red by how much evidence supports it. In Sopact Sense this takes minutes and stays grounded only in what your program states — it marks anything inferred so it never invents outputs you don't have.
ChatGPT, Claude, and Gemini are fine for a quick test — but not for an answer you'll put in front of a funder or board. When it has to hold up, run it in Sopact Sense.
Build a rigorous impact report →
