> For the complete documentation index, see [llms.txt](https://research.ambitiousimpact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://research.ambitiousimpact.com/ambitious-impact-eval/cost-effectiveness-modelling/what-are-the-key-temporal-dynamics-in-the-model.md).
# What are the key temporal dynamics in the model?
## Static vs. Dynamic Modelling
*Note: static and dynamic also refer to approaches to model epidemiological dynamics. These are related and broadly similar to the descriptions below, but for the avoidance of doubt, we are focusing on timing here.*
**Static models look at a point in time**
* Analyses outcomes at a single point in time or with fixed parameters that don't change based on population dynamics
* Disease/risk exposure probability is constant over time and unaffected by interventions
* Individuals/Actors do not influence each other's disease/effect risk
* Not strictly appropriate for transmission dynamics (e.g., communicable disease) because of static assumptions.
* More transparent; easier to follow logic and communicate results; suitable for simpler problems7
**Dynamic models map out cost-effectiveness over a period of time**
* Tracks how disease and intervention effects change over time, with parameters that evolve based on population /dynamic states
* Disease/risk exposure probability changes dynamically based on intervention coverage and population immunity
* Individuals/Actors influence each other's disease/effect risk
* More complex; can be harder to validate and communicate, but necessary for problems with substantial heterogeneity or history-dependence
### When is it appropriate to use each approach?
* Most cost-effectiveness analyses in prioritization research are static. This is largely appropriate for these purposes.
* It is important to understand the limitations implied by that simplification.
* In particular models that attempt to engage with communicable disease (like models of vaccination programs) are likely to undercount benefits in static models (e.g., no population dynamics).
* Consistency in modelling is important to assist with comparability. Therefore it is worthwhile to have guidelines on how to model things. These distinctions are largely judgment calls.
**By default, use static models that ascertain either:**
* What a certain amount of money spent towards an intervention can buy.
* What the costs and benefits of an intervention delivered at scale are.
*When using static models, we may still use consider some costs and benefits in the past or future. For instance, we may account for initial up-front investments need to reach scale, or benefits accrued over several years as a result of the intervention. The point is that the intervention largely needs to be delivered on an ongoing basis to keep generating benefits.*
**Consider longer-term dynamics when**
* Policy interventions or hits-based interventions that need some probabilistic thinking
* You want to model population dynamics or epidemiological dynamics
*Temporal and dynamic models are useful for interventions where population, policy, or disease dynamics are of large relevance. We’d usually avoid doing these for disease modelling for convenience. In policy cases, dynamic modelling can be useful to approximate how several years of work towards a policy implementation, can set in a policy for a longer time-horizon.*
| **Type of intervention** | **Model as** |
| ------------------------------------------------------------------------------------------------ | ------------------------------------------ |
| Direct delivery intervention that generates benefits on an ongoing basis (e.g., vaccine clinics) | Static model at large scale |
| Policy advocacy intervention | Dynamic model mapping odds of intervention |
| Training of trainers expanding coverage through clinical practice | Dynamic model mapping expanding coverage |
### How to build a dynamic model
* Figuring out how to make a dynamic model in a sheet is a literal nightmare. Keep it simple as far as you can.
* Mapping out values as a timeline is the easiest way of doing this, but it usually involves some messy-looking formulas.
* Best practice on managing dynamic models:
* Do not overcomplicate the model. It’s messy enough because of the timeline work.
* The timeline should be a stand-alone tab
* Do not hard-code unless absolutely necessary
* Explain the formula you are using with notes
* Graph the timeline to visually inspect that the formula is doing what you expect it to do
## Marginal vs. Total
* **Marginal models** look at the value of additional resources - the value of an incremental change. For instance, GiveWell models how much value an additional amount of philanthropic donations can generate.
* These make most sense to understand the true counterfactuals of an intervention or program, especially when accounting for the marginal utility of extra money.
* Work on marginal models, especially around the counterfactuals of donations, can be right one second and wrong the next.
* **Total models** look at the overall costs and benefits generated by what is being modelled.
* Simpler models to make, that allow us to capture most of the valuable information about a program.
*Note - even in total models, we have to look at changes between endline and baseline caused by the intervention*
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://research.ambitiousimpact.com/ambitious-impact-eval/cost-effectiveness-modelling/what-are-the-key-temporal-dynamics-in-the-model.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
