> For the complete documentation index, see [llms.txt](https://ambitious-impact.gitbook.io/ambitious-impact-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ambitious-impact.gitbook.io/ambitious-impact-docs/ambitious-impact-eval/cost-effectiveness-modelling/what-are-the-key-drivers-of-costs-and-benefits.md).

# What are the key drivers of costs and benefits?

## What to model?

* Models are simplifications of the world, that help us understand potential value.
* It is not possible to model all potential costs and benefits.
* Be methodical and open-minded about what potential outcomes to measure

## Brainstorming

### Driver trees

* You can create a value driver tree to quickly visualize and interrogate what the overall contributors to the benefits and costs in your model may be and how they may plausibly be modelled.
* Driver trees can also be useful to communicate the overall shape of the mode

<figure><img src="https://2506280830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqhPAC1IjwI2ikXY72v2S%2Fuploads%2F74yy7AycnXam8DUkuVwZ%2Fimage.png?alt=media&amp;token=5f968318-0162-4e64-82d6-e4bc3922e612" alt=""><figcaption></figcaption></figure>

<https://www.aaronbrooker.com/vdttool>

### Nested Lists

* Using nested lists works better for some people
* Each line nests drivers within overall driver categories

<figure><img src="https://2506280830-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqhPAC1IjwI2ikXY72v2S%2Fuploads%2FjYMcnvl642YAqKkXyMOb%2Fimage.png?alt=media&amp;token=0b756ec5-a0c5-42d4-8c3c-0a717409fabe" alt=""><figcaption></figcaption></figure>

## Outcome selection

* An intervention can lead to a variety of benefits (and harms)
* There are good reasons why we cannot model all possible outcomes from an intervention. Following GiveWell’s old guidance (GiveWell, 2019), we think the main (justifiable reasons) are:
  * Low expected impact on cost-effectiveness
  * Availability of an objective and quantifiable metric to include
  * Ease with which an outcome can be modelled
  * Consistency for comparison with other models
* List all plausible outcomes you have considered in your research and brainstorming, and decide which ones you will include or exclude, noting your reasons transparently.
* It can be useful to rate different options across a few of the above criteria in order to assess whether to include them.

## Cost selection

* You should aim to be exhaustive whenever you have decided within a certain category of costs.
  * For instance, if your model calls for costing all costs paid by a provider, then you should account for all major costs included in that.
* When it comes to costs borne by other actors further apart from your main focus, such as costs incurred by other providers as a result of the intervention you are modeling, it may be sufficient to account for just major costs broadly (E.g., costing additional commodity needs but not minor changes in staffing required) .
  * Follow a similar thought process as with outcome selection.

## References

GiveWell. (2019). *Guide to GiveWell CEAs*. <https://docs.google.com/document/d/1ZKq-MNU-xtn_48uN33L6VvBEZRAduvjwWMeaEffL4K4/edit?tab=t.0>

*Value driver tree generator*. (n.d.). Retrieved December 23, 2025, from <https://www.aaronbrooker.com/vdttool>


---

# 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://ambitious-impact.gitbook.io/ambitious-impact-docs/ambitious-impact-eval/cost-effectiveness-modelling/what-are-the-key-drivers-of-costs-and-benefits.md?ask=<question>&goal=<user_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.