Assumption

Every causal pathway rests on beliefs the project team is taking for granted. An assumption is one of those beliefs, made explicit rather than left silent.

The workbook builds its worked Theory of Change example as a three-column table: Assumptions, ToC, and Risk. Each row pairs a stated assumption with the part of the causal pathway it supports, and the risk that follows if the assumption turns out to be wrong.

Its own example: the assumption "Young individuals are motivated to attend and complete the training programs" sits opposite the risk of "Low youth engagement." Made explicit like this, an assumption becomes something the project can actually monitor and test, rather than an unspoken hope.

The workbook treats assumptions as a structural part of Theory of Change, not an optional footnote:

1. Assumptions are explicitly identified and tested. Building a causal pathway involves "identifying and testing the assumptions underlying these causal pathways."
2. Assumptions include context, not just behaviour. The workbook notes that a Theory of Change "explores the underlying assumptions about the context and how it interacts with the program" — assumptions can be about how people will behave, or about how the wider environment will hold steady.
3. Assumptions are paired with risk. In the workbook's own table structure (Assumptions | ToC | Risk), each assumption sits directly opposite the risk that materialises if the assumption does not hold — making the two column headings a matched pair, not independent categories.

This differs from a plain Logic Model, which the workbook says "may not delve as deeply into the underlying theories and assumptions" — a Logic Model tends to leave assumptions implicit, where a Theory of Change insists on stating them.

Illustrative example, extending the workbook's own youth-employment case.

If the project later finds enrolment has fallen from an expected 300 trainees to just 190, the assumption table tells the team exactly where to look first — motivation to attend — rather than leaving them to guess whether the problem lies in curriculum design, employer demand, or something else entirely. That is the practical value of writing assumptions down rather than leaving them as background belief.

Chapter 6, section 6.1.1, presents Assumptions as one of three columns (with ToC and Risk) in the workbook's worked Theory of Change example, and repeatedly ties assumption-testing to what distinguishes a Theory of Change from a plainer Logic Model. Expect a question asking which framework — ToC or Logic Model — makes assumptions explicit, and a matching question pairing a stated assumption with its corresponding risk.

• Assumptions and risks are presented as a matched pair in the workbook's table, not as separate, unrelated lists — a question may give one and ask for the other.
• Theory of Change makes assumptions explicit; a Logic Model tends not to — this is one of the workbook's most directly tested contrasts between the two frameworks.
• This singular "Assumption" concept (the ToC table column) is distinct from the plural "Assumptions" heading used elsewhere in the workbook as a section label inside SIA report components — this page covers the Theory of Change concept specifically.
• An assumption is about conditions the project does not control — motivation, market demand, context — not about the project's own planned activities, which belong to the ToC or Logic Model column itself.