A reminder is a form; remembering is not the whole mechanism
Suppose a program sends appointment texts. The intended function may be helping participants know when and how to attend. A phone call or printed card might serve part of that function in another setting.
But if the text also contains a two-way rescheduling link, replacing it with a static card removes another capability. The form carries more than one function.
Trace the component to the outcome
- What action or experience should this component enable?
- Why is that expected to affect the outcome?
- Which delivery details are necessary for that action?
- What evidence supports the distinction?
This makes the proposed adaptation more testable.
Do not declare everything core after the fact
If a program underperforms, it is easy to label every changed detail essential. That explanation needs evidence. Likewise, calling a component “just packaging” does not establish that it can be removed safely.
Document the assumptions before implementation and examine them during evaluation. A function-based description can give local teams useful flexibility while preserving a clear account of what the intervention is expected to do and which changes may alter that expectation.
