How this works

Models are files you can read

Each charity is one JSON file in a public git repository. A model is a list of rows, like a spreadsheet: inputs with a value, and calculated rows with a formula over other rows. Every input says what kind of number it is (observed from data, an estimate made elsewhere, or a judgment), where it comes from, and why it has the value it has. The file's git history is the model's changelog.

Models imported from an evaluator have to reproduce that evaluator's own numbers. Every calculated row records the value the original spreadsheet shows, and the build fails if the model drifts from it. Where we disagree with a source, we say so in an explainer or a separate variant rather than quietly changing its numbers.

Models can build on each other

A model can extend another and override only the rows that differ. GiveDirectly in Malawi extends GiveDirectly in Kenya and changes eight inputs; everything else, including the explanations, is shared. The same mechanism lets a new charity reuse the structure of a well-reviewed one, which keeps comparisons like for like.

Two views of every charity

Each model first reproduces its evaluator's analysis exactly, with their moral weights and accounting. That is the evaluator view. The charityevals view starts from the same model and applies your assumptions plus two accounting choices evaluators make differently. Where we disagree with an input, the page shows both values and says why.

Two accounting choices

Salary sacrifice. Staff who earn less than they could in comparable for-profit jobs are paying part of the cost of the work. We count that forgone salary as an in-kind donation, so your dollar is credited with its share of the impact, not all of it. Evaluators usually credit everything to cash.

Credit for shared outcomes. A corporate pledge usually follows several organisations' campaigns. By default each charity is credited with its estimated share, as ACE does. Switch to full credit to count the whole outcome for each organisation that was necessary to it. That inflates totals across charities but answers a different question: what would be lost without this one.

Shared facts and history

Data that several models need, such as a country's child mortality rate, lives in one shared file, so two models working in Kenya can't silently disagree about Kenya. Every change to a model is a git commit, and each charity's history page recomputes the result at every version.

Ranges, not simulations

Every input can carry a low, best and high value, taken from the source wherever it gives one. We report three numbers: the central estimate, with every input at its best guess, and a joint low and joint high, with every input at whichever end of its range lowers or raises the result. These bounds are deliberately pessimistic and optimistic, not a 90% interval. Rankings use the central estimate, the typical case.

The chart on each charity's page moves one input at a time from low to high. The longest bars are the numbers worth arguing about.

Comparing causes

Each cause keeps its own unit: GiveWell's units of value (one unit is doubling one person's consumption for a year), suffering-adjusted days for animals. To put them on one list we convert to GiveWell units using exchange rates you control, and express everything as a multiple of GiveDirectly. Those rates are judgments with no agreed answer. The site shows you which of them would change the ranking.

Flags

A model is flagged when its joint range spans more than 100×, when more than half of its uncertainty comes from judgment calls and shared assumptions, when inputs on the result's path have no range, or when the source analysis is more than 18 months old.

What this is not

Not an evaluator's recommendation, and not endorsed by GiveWell, Animal Charity Evaluators or any charity listed. Cost-effectiveness is one input to a giving decision; room for more funding, organisational strength and track record matter too and are not modelled here yet.