A grant logic model template is a planning table that connects the problem, inputs, activities, outputs, outcomes, assumptions, and evaluation evidence for a proposed project. It helps reviewers see how funded work turns into measurable change.
A logic model is not just a nonprofit diagram. In grant writing, it is the skeleton of the argument. The proposal says a problem is worth funding, the work plan says what the team will do, the budget says what resources are needed, and the evaluation section says how success will be measured. The logic model forces those pieces to agree before the application becomes a long narrative.
This matters because many proposals fail in the spaces between sections. The need statement describes one population, the activities describe another, the outputs count tasks rather than evidence, and the outcomes promise impact that cannot be reached during the award period. A grant logic model template catches those gaps early. If a line in the model cannot be defended, it will probably be weak in the application too.
Use this guide alongside grant proposal sections, how to write a grant application, grant budget template, and grant reporting requirements. The logic model sits before all of them. It is the compact version of the application logic.
Quick answer: what a logic model should prove
A logic model should prove that the project has a credible chain from resources to action to evidence to outcome. It should not merely list things the applicant hopes to do. A reviewer should be able to read across the table and understand why each activity is necessary, what it produces, what changes because of it, and how the team will know whether the change happened.
For a deeptech startup, this chain may look different from a community programme logic model. The inputs may include engineers, lab access, regulatory advisors, pilot customers, compute, data, prototype materials, or test facilities. The outputs may include benchmark datasets, validated prototypes, field-test logs, safety files, or customer discovery evidence. The outcomes may be technical risk reduction, commercial readiness, regulatory clarity, or adoption evidence.
- A good logic model is specific enough to audit. Each activity should have an output that someone can inspect, count, test, or review.
- A good logic model separates outputs from outcomes. A prototype, report, workshop, dataset, or pilot is usually an output; changed performance, readiness, adoption, learning, or decision quality is the outcome.
- A good logic model names assumptions. If the whole project depends on a partner delivering samples, a customer allowing site access, or a regulatory pathway staying open, the model should make that dependency visible.
- A good logic model keeps time realistic. Near-term outcomes should fit the grant period. Long-term impact can appear, but it should not pretend that a one-year project will transform a whole market alone.
Copyable grant logic model template
Start with a single table. Do not begin with a visual diagram unless the funder asks for one. A table is easier to edit, easier to test against the proposal, and easier to translate into the evaluation plan. Once the table is stable, you can turn it into a diagram for a slide, appendix, or funder form.
| Field | What to write | Reviewer test |
|---|---|---|
| Situation or need | The problem, opportunity, gap, or technical barrier the project addresses. | Is the need concrete enough to justify funding now? |
| Inputs | People, partners, facilities, data, equipment, materials, funding, and prior work. | Are the requested resources matched to the proposed tasks? |
| Activities | The work the team will perform during the project. | Are the activities specific, feasible, and aligned with the work plan? |
| Outputs | Direct products of the activities: prototypes, datasets, reports, pilots, tests, workshops, deliverables. | Can the funder verify these outputs by the end of the award? |
| Short-term outcomes | Immediate changes in knowledge, readiness, technical performance, customer evidence, or decision quality. | Do the outcomes follow directly from the outputs? |
| Long-term outcomes or impact | The broader change the project supports after the grant period. | Is the long-term claim plausible without overstating what the award can do alone? |
| Assumptions | Conditions that must hold for the model to work. | Are the risks visible rather than hidden? |
| External factors | Market, regulatory, technical, policy, or partner conditions outside the applicant's control. | Does the team understand what could affect implementation? |
| Evaluation evidence | Indicators, data sources, frequency, and ownership. | Can the team measure progress and report it credibly? |
This is the practical version of a fillable logic model template. Put one project outcome per row if the project has several workstreams. For example, a hardware project may have one row for technical validation, one for manufacturing readiness, and one for pilot-user evidence. A biotech project may have one row for assay performance, one for sample handling, and one for regulatory feasibility. The point is not to make the table beautiful; it is to make the causal argument testable.
Filled logic model example for a grant proposal
A filled example is more useful than a blank template because it shows the level of detail. The example below is intentionally simple. It is not a universal model, but it shows how a deeptech applicant can connect technical work, customer evidence, and evaluation without drifting into vague impact language.
| Logic model field | Example for a climate hardware startup |
|---|---|
| Situation | Industrial heat users need lower-emission process heat, but the current prototype has not been validated under customer duty cycles. |
| Inputs | Two engineers, pilot partner site access, thermal test bench, prototype materials, sensor package, external safety review, and grant funding. |
| Activities | Build upgraded prototype, run bench tests, install pilot sensor package, collect operating data, compare performance against baseline, document safety and reliability issues. |
| Outputs | One upgraded prototype, three bench-test reports, one pilot operating dataset, reliability log, safety review memo, and customer-readiness summary. |
| Short-term outcomes | Evidence that the system can meet target heat output, identify failure modes, and define the next design revision for a paid pilot. |
| Long-term outcomes | Reduced technical risk for industrial decarbonization deployment and stronger case for follow-on non-dilutive or investor funding. |
| Assumptions | Pilot partner maintains access, test conditions represent real operations, supply chain lead times do not block prototype assembly. |
| External factors | Energy prices, safety requirements, customer capital budgets, and permitting timelines. |
| Evaluation evidence | Measured thermal performance, operating hours, downtime, deviation logs, customer feedback, and engineering sign-off against milestone criteria. |
Notice that the outputs are not the same as outcomes. The reports, logs, and dataset are outputs. The reduced risk and improved readiness are outcomes. This distinction helps when you later write the evaluation plan, because an evaluation plan should measure both whether the work happened and whether it produced meaningful evidence.
The same structure works for less technical grants too. A workforce programme might use trainees, instructors, curriculum, and employer partners as inputs; training sessions and placements as outputs; new skills and job readiness as short-term outcomes; and sustained employment as long-term impact. The grant context changes, but the logic stays the same.
How to use a logic model in grant writing
The best time to build the logic model is before drafting the proposal. If you wait until the narrative is already written, the model becomes a formatting chore. If you build it first, it becomes a decision tool. It tells you what must be explained, what evidence is missing, what belongs in the budget, and what the application should not promise.
| Proposal section | What the logic model contributes | Common gap it exposes |
|---|---|---|
| Need statement | Clarifies the problem and who or what is affected. | Problem is too broad or not connected to the proposed activities. |
| Work plan | Turns activities into a sequence of tasks and deliverables. | Activities sound useful but do not produce measurable outputs. |
| Budget | Shows which resources are needed for which activities. | Costs appear in the spreadsheet but not in the project logic. |
| Evaluation plan | Connects outputs and outcomes to indicators and data sources. | Outcomes are aspirational but not measurable. |
| Sustainability or commercialization | Explains what happens after the grant output exists. | Long-term impact depends on unproven follow-on assumptions. |
- Use the model to cut scope. If an activity does not produce a needed output or outcome, remove it or explain why it belongs.
- Use the model to strengthen milestones. A milestone should usually correspond to an output or evidence point in the model.
- Use the model to defend costs. If a line item cannot be traced to an input or activity, it may not survive budget review.
- Use the model to align collaborators. Partners should understand which outputs they own and which assumptions depend on them.
Theory of change vs logic model
A theory of change explains why a change is expected to happen. A logic model organizes the operating plan for making that change happen. In practice, funders sometimes use the terms loosely, but proposal teams should keep the distinction clear. The theory of change is the underlying argument; the logic model is the implementation and measurement map.
| Question | Theory of change | Logic model |
|---|---|---|
| Main job | Explain why the intervention should create change. | Show how resources and activities lead to outputs and outcomes. |
| Typical shape | Narrative, pathway, assumptions, causal reasoning. | Table or diagram with columns for inputs, activities, outputs, outcomes, assumptions. |
| Best use | Strategy, program design, funder rationale, impact argument. | Proposal planning, work-plan alignment, evaluation, reporting. |
| Deeptech example | If field data proves durability, customers will accept pilot expansion. | Engineers and pilot partner run tests, produce logs, analyze failure modes, and document readiness. |
| Risk if weak | Impact claim feels unsupported. | Proposal sections contradict each other or promise unmeasurable outcomes. |
For grant writers, the most useful workflow is to write a short theory-of-change sentence first, then build the logic model beneath it. For example: if the project validates prototype performance under real customer conditions, then the company can reduce technical adoption risk and make a credible case for follow-on deployment. The logic model then spells out what inputs, activities, outputs, and measurements make that sentence true.
Turn the logic model into an evaluation plan
The evaluation plan should not be separate from the logic model. It should measure the chain. Start with each output and outcome, then ask what evidence would prove progress. That evidence may be quantitative, qualitative, or both. In technical grants, it often includes test results, user interviews, adoption signals, performance data, safety records, or third-party validation.
| Model item | Evaluation question | Indicator | Data source | Owner |
|---|---|---|---|---|
| Prototype bench tests | Did the upgraded prototype meet the target operating range? | Heat output, efficiency, operating hours, failure events. | Bench-test logs and engineering report. | Technical lead |
| Pilot dataset | Did the pilot produce usable data under real operating conditions? | Completeness, duration, data quality, number of operating cycles. | Sensor logs and QA checklist. | Data lead |
| Customer readiness | Does the pilot partner see a credible path to expanded testing? | Structured feedback, unresolved barriers, next-step commitment. | Interview notes and partner memo. | Commercial lead |
| Safety review | Were major safety risks identified and assigned mitigation actions? | Number and severity of findings; closure status. | External safety memo and action register. | Project manager |
This bridge is where many applications become stronger. The logic model says what should happen. The evaluation plan says how the team will know. The progress report later says what actually happened. If those three artifacts use the same language, the project feels controlled from application through post-award reporting.
Use the logic model to check the budget
The logic model is also a budget test. Every major cost should support an input or activity. If the project needs a subcontracted lab, the lab should appear in the inputs, its tests should appear in activities, its report should appear in outputs, and the measurement it enables should appear in the evaluation plan. If that chain is missing, the budget narrative will feel arbitrary.
This is why a logic model belongs before the grant budget justification. The budget justification explains costs line by line, but the logic model explains why those cost lines exist at all. A proposal team that can trace cost to activity to output usually writes a cleaner budget narrative and avoids last-minute scope confusion.
- Personnel should map to activities. If a person is budgeted, the model should show what work they perform and what output they help create.
- Subcontractors should map to evidence. External testing, evaluation, clinical, regulatory, or manufacturing partners should produce a defined output.
- Equipment and materials should map to feasibility. A reader should understand why existing resources are not enough.
- Indirect costs should not distort the model. Administrative support matters, but it should not be confused with project outputs.
Common logic model mistakes
Most weak logic models are not wrong because the template is bad. They are weak because the project logic is underdeveloped. A clean table cannot save a proposal that has vague outcomes, unsupported assumptions, or activities that do not produce evidence. Treat the model as a stress test rather than a decoration.
| Mistake | Why it hurts | Better move |
|---|---|---|
| Listing activities as outcomes | Reviewers cannot see what changed because of the work. | Separate completed work from measurable change. |
| Using impact claims too early | The grant period cannot plausibly produce the stated impact. | Name near-term outcomes and describe long-term impact as a path. |
| Hiding assumptions | Risks appear only when reviewers infer them. | Name partner, market, regulatory, data, and technical assumptions. |
| Leaving evaluation until the end | Outcomes may not be measurable. | Add indicators and data sources while building the model. |
| Copying a generic template | The model fails to reflect the actual grant, field, or applicant. | Customize inputs, outputs, and evidence to the opportunity. |
The easiest final review is to read the model from right to left. Start with the outcome and ask what output proves it. Then ask which activity creates that output. Then ask which input makes the activity possible. If any link is weak, fix the model before writing more prose.