Proof of concept

The state of play, 2019–2021

For a few years around the turn of the decade, open-source policy modeling went through a quiet boom—and I spent most of it unable to answer a simple question.

In October 2019, UKMOD became the first freely available tax-benefit microsimulation model of the United Kingdom .^[1] Britain already had proprietary tools—the Institute for Fiscal Studies had run TAXBEN since 1983, the Treasury had IGOTM, its internal tax and benefit model, the Department for Work and Pensions had its Policy Simulation Model—but UKMOD, built on EUROMOD's UK component and funded by the Nuffield Foundation, was open to anyone who asked.

Then COVID-19 arrived, and everyone needed policy analysis at once. The CARES Act, expanded unemployment insurance, recovery rebates—the rules changed weekly. NBER updated its TAXSIM calculator for the new provisions; Tax-Calculator shipped a pandemic release, version 3.2.1, in August 2021 citation pending. In December 2020, EUROMOD—the backbone of European tax-benefit modeling for two decades ^[2]—went fully open source, with the European Commission's Joint Research Centre taking over the following month. The International Microsimulation Association convened a conference that December devoted entirely to pandemic policy responses, and the open-source Policy Simulation Library kept adding models. The ecosystem was growing fast, and almost none of it was usable by anyone who couldn't write code.

That was the gap I kept falling into. I had started the UBI Center in 2019 out of a specific frustration: I wanted to know what various universal basic income proposals would cost and whom they would help, and no public tool could answer with any specificity .^[3] The UBI Center published open-source analyses of basic income proposals using whatever existed—mostly Tax-Calculator and custom Python scripts running on Census survey data.

The work taught me two things. The tools existed only in fragments. Tax-Calculator handled federal income tax beautifully but ignored benefits; TAXSIM handled state taxes but ran in batches; nothing captured the full interaction between taxes and benefits that decides whether a basic income comes out progressive, regressive, or poverty-reducing. Fund a basic income by tapering an existing benefit, for instance, and you could lift some families while stranding others at a cliff—and no available tool would show both effects at once. And the audience for policy analysis was far larger than the audience that could run the tools. When I published a UBI Center analysis, people wanted to explore it themselves—vary the parameters, change the household, model the version their local group was actually pushing—and they couldn't, because the analysis lived in a Jupyter notebook.

Building the application

By late 2020, Nikhil Woodruff and I had a working microsimulation model of the UK tax-and-benefit system, built at the UBI Center. Nikhil was an undergraduate at University College London reading mathematics and computer science, and the stronger engineer of the two of us; he could turn a tangle of policy rules into clean, fast code. Our model—OpenFisca UK—could calculate taxes, simulate benefits, and estimate the effect of a reform. But it lived in Python scripts only a programmer could run.

We had seen that pattern everywhere: powerful tools locked behind technical barriers. TAXSIM wanted batch files; Tax-Calculator wanted Python; UKMOD was built for academics; TAXBEN was proprietary. The fix was obvious and ambitious—put the full power of microsimulation in a browser, so that anyone could design a reform, see its cost and its distributional effect, and check what it meant for their own household, without writing a line of code.

We called it PolicyEngine.

The hard part was turning a fundamentally computational process into something that felt like a form you could fill out. We built it in layers. The model layer ran in Python on cloud servers: feed OpenFisca UK a household and a reform, and it returned the exact tax and benefit before and after the change. The API layer wrapped that model in HTTP endpoints, so the interface could improve without touching the rules and the rules could improve without touching the interface. The application layer was a React web app that let users describe a household by answering questions—income sources, number of children, housing costs—and specify a reform by moving sliders and toggles, then turned those choices into API calls and drew the results.

The architecture encoded one decision that mattered more than any other: the model had to be usable without the interface. The API was the product, and the web app was merely its first consumer. Anyone—a researcher, a journalist, another program—could call the same engine that ran the website. At the time it felt like overengineering. In retrospect it was the choice that made everything else possible, because when developers later wanted PolicyEngine's numbers inside their own tools, the API was already there.

Nikhil handled most of the engineering—API design, the React front end, state management—while I worked the policy logic: which parameters to expose, how to present results, what comparisons mattered. We argued endlessly about how much complexity to show. Exposing every parameter in the tax-benefit system would drown a user; there are thousands. Hiding too many would gut what anyone could model. We settled on a compromise—a curated set of frequently debated parameters, income tax rates and benefit levels and credit amounts, with the option to reach any parameter in the model for users who knew what they were after—and on progressive disclosure for the output: headline numbers first, net cost and poverty change, then breakdowns by income decile, household type, and region for anyone who wanted to dig. The output was contested for the same reason as the input—show a household its budget change, its poverty impact, and its place in the distribution all at once and the screen collapsed into noise—and deciding what to lead with was an argument we re-ran for every view.

We launched PolicyEngine UK in September 2021 .^[4] Enter a reform—raise income tax, increase child benefits, introduce a carbon dividend—and see the effects: the cost to the Treasury, the change in poverty, the shift in inequality, and, critically, what it would mean for your own household. Within weeks, advocacy groups were using it to design proposals, and when the Chancellor's Autumn Budget changed Universal Credit, we published distributional analysis within a day .^[4]

In October 2021 we spun PolicyEngine out as a separate nonprofit, and the mission statement shifted from "make everyone a policymaker" to "help people understand and change public policy." The second verb was the point: understanding is passive; changing takes agency. Incorporating as a 501(c)(3) was itself a design choice about trust. We wanted a progressive group modeling a basic income and a conservative group modeling a flat tax to have equal confidence the engine wasn't tilted toward the other—so the code stayed open for anyone to inspect, and the organization had no shareholders whose interests could bend the results. Behind it were two people, a rotating cast of volunteers and interns, and a website that kept going viral faster than we could fix the bugs the attention exposed. When the Autumn Budget analysis took off, we weren't a media operation—we were two people with a model, fielding interview requests with one hand and patching the code the traffic had broken with the other.

Crossing the Atlantic

We launched PolicyEngine US in March 2022 ,^[5] and it was a different kind of problem—not just different policies, but a different shape of complexity. The UK has one national tax system, though Scotland sets its own income tax rates, and Universal Credit had folded most means-tested support into a single program. The US has fifty states with separate income tax codes layered on a federal system of bewildering complexity, and its benefits are scattered across agencies: SNAP at the USDA, SSI at the Social Security Administration, Medicaid at HHS, housing vouchers at HUD, childcare subsidies at the states. Each program defines income its own way, counts the household its own way, sets eligibility its own way. Modeling the US wasn't harder than modeling the UK by some constant factor; the complexity grew multiplicatively rather than additively.

We started with what we could model—federal income and payroll taxes, SNAP, the EITC—and shipped the household calculator first. In July 2022 we added population-level impacts using the Current Population Survey, the same microdata foundation behind official government estimates .^[5] State coverage came one state at a time. Some states piggyback on federal adjusted gross income and fall into place once the federal model exists; others, like New York with its multiple income tax schedules, city taxes, and supplemental credits, were miniature ecosystems of their own. Each had its own structure, its own EITC variant, its own quirks, and what a contributor learned encoding one rarely transferred to the next. By the end of 2022 we had modeled six states. Forty-four remained.

The gap between ambition and capacity was constant. We wanted comprehensive coverage and had a small volunteer team encoding rules on weekends. We wanted models that updated the moment a policy changed and struggled to keep them current—a contributor might encode Oregon's working-family credit only to find the legislature had amended the eligibility rules mid-session, with no updated documentation to work from. The contributor model was open source in the truest sense: anyone could submit a pull request encoding a state's rules, and our team reviewed it for accuracy and code quality. That worked where a local expert cared enough to volunteer, and failed where no one did, which left coverage that tracked contributor geography rather than policy importance. The proof of concept held—people wanted accessible policy analysis—but scaling it would take more than enthusiasm and weekends.

Who used it

The most revealing users were the ones who changed how they worked because the tool existed. A congressional aide could use PolicyEngine to check whether a proposed child tax credit expansion would actually reach the families a member cared about—finding, say, that a credit phased in over the first few thousand dollars of earnings missed exactly the poorest households the office meant to help—and then use that to reshape the legislative language before requesting a formal score from the Congressional Budget Office. The informal tool didn't replace the formal process; it changed the questions that arrived at it. Instead of leading with "what does this cost?", staff could walk into CBO with a proposal already refined for distributional impact.

The other pattern was democratization. Advocacy groups and academic researchers who had relied on government estimates or expensive consultants could now run their own simulations—test a specific variant, compare alternatives, model the reform their organization was actually proposing—and argue with numbers rather than narratives .^[5] A volunteer-run outfit like UBI Lab Northern Ireland could model a recovery basic income on its own, without commissioning a think tank; an organization that had once needed a consultant's retainer to put a number on a proposal could now generate its own distributional table before a meeting. And increasingly, developers built on the API rather than the website: the Fund for Guaranteed Income, for instance, wired PolicyEngine into a tool that showed cash-pilot participants how their other benefits would change as their income rose. We had set out to build a product and were turning into infrastructure.

The validation challenge

Open source meant anyone could inspect the code, but inspection is not correctness. We invested heavily in validation, comparing PolicyEngine's output against official calculators and published statistics, and the results were mixed in an instructive way. Each model carried a test suite checking outputs against official calculations across hundreds of household scenarios, and every discrepancy raised the same three-way question: was the bug in our code, in the official calculator, or in our reading of an ambiguous rule?

Some were simple. An outside contributor comparing our results against IRS tables caught a transposed phase-out rate—21.60 percent entered where the EITC's two-child schedule specifies 21.06 percent to verify. Others were genuinely ambiguous. When a regulation says income is figured "net of applicable deductions," which deductions apply? Different official sources sometimes gave different answers, and we kept a running log of these cases—places where reasonable readings of the same statute produced different numbers. The log was itself a finding: the tax-benefit system is complex enough that the agencies administering it sometimes disagree about its own rules.

For the UK model, HM Treasury eventually ran its own evaluation and found that 60 percent of National Insurance calculations fell within 0.5 percent of its internal model .^[6] Income tax proved harder to compare—the two systems had trouble even identifying which variables corresponded—and edge cases surfaced everywhere: housing benefit interacting with legacy benefits, Scotland-specific provisions, transition rules for households moving between programs. The lesson was that validating against a government model is hard not because the arithmetic is difficult but because two systems can define "income," aggregate units, and handle household composition in quietly incompatible ways.

And we volunteered the limitation we couldn't code our way out of. PolicyEngine ran on household survey data; governments run on administrative tax records. Surveys under-sample the very rich—the CPS might hold a few hundred households above $500,000 where the IRS has vastly more—and because high earners generate a disproportionate share of revenue, that sampling gap cascaded into totals. Our revenue estimates ran about a third below official ones. This was not a bug we could fix in code; it was a structural constraint of survey-based microsimulation, one that only better data could ease. So we learned to lead with relative impacts—how much a reform raised or lowered revenue against current law—because the survey's sampling error moved baseline and reform alike and largely cancelled. Sophisticated users still wanted absolute numbers, and we couldn't always explain the gap with CBO without a short lecture on survey methodology.

From tool to infrastructure

In 2024 the National Science Foundation awarded PolicyEngine a Pathways to Enable Open-Source Ecosystems grant citation pending, a sign that open-source microsimulation had come to count as infrastructure worth funding. That year we finally closed the gap that had frustrated me at the UBI Center: in April 2024, PolicyEngine launched income tax modeling for all fifty states and DC, the work of more than a hundred open-source contributors citation pending parsing the country's patchwork of tax codes. The final push was a campaign in itself—finding a contributor with local expertise for each missing state or recruiting an engineer willing to parse an unfamiliar code, then validating each implementation against whatever official calculator or published table existed. Flat-tax states with a handful of credits took days; New York, California, and Hawaii took weeks of iterative debugging. What I couldn't find in 2019, we had built by 2024.

The data improved in parallel. In August 2025 we launched the Enhanced Current Population Survey, integrating five datasets and calibrating to 9,168 administrative totals; the pipeline paired Quantile Regression Forests for imputation with gradient-descent reweighting, and cut our deviations from official statistics by 97 percent .^[7]

That data line was later rebuilt as populace, the open commons of calibrated microdata this book returns to.

The strongest validation, though, came from who wanted to build alongside us. In September 2025 we signed a memorandum of understanding with the National Bureau of Economic Research to build an open-source emulator of TAXSIM, the tax calculator that had powered academic research since the 1970s; more than 1,200 papers had relied on it citation pending. Daniel Feenberg, TAXSIM's creator, joined our advisory board and served as external mentor under the NSF grant. We were building the emulator partly to guarantee researchers kept these capabilities, and partly to build something larger—a framework in which several independently developed models could cross-check one another.

A month later, we signed a second MOU with the Federal Reserve Bank of Atlanta. Their Policy Rules Database covered benefits—SNAP, Medicaid, housing vouchers, childcare subsidies—complementing TAXSIM's focus on taxes. The database powered the Atlanta Fed's CLIFF tools, which Colorado's Workforce Development Council and New Mexico's Caregivers Coalition used to help families understand how earning more would affect their benefits.

The three-way validation approach was deliberate. When independently developed models agree on a calculation, researchers can trust the result. When they diverge, the differences reveal important questions about policy interpretation or implementation details. Having three models—PolicyEngine, TAXSIM, and the Policy Rules Database—helped isolate where discrepancies originated.

We were positioning PolicyEngine as more than another microsimulation model—as an integrator that could cross-validate across Python and R, across taxes and benefits, across academic and government implementations.

And then came the UK.

In March 2025, HM Treasury published an Algorithmic Transparency Record disclosing that it had piloted PolicyEngine UK as a possible supplement to IGOTM, the closed model that had produced government policy estimates for decades. The Treasury singled out our machine-learning approach to survey error—combining multiple years of the Family Resources Survey, imputing missing income with random forests, reweighting households with gradient descent—the same techniques we had built for the Enhanced CPS, now under evaluation inside the government. The Times reported that the tool could more accurately predict the outcomes of ministers' decisions and was expected to be used mainly in budget periods .^[6] Nikhil Woodruff, PolicyEngine's co-founder, has since joined the UK government at 10 Downing Street to verify—the co-founder I had recruited off a subreddit, now working inside the machinery an outside tool had helped pry open.

The significance ran past validation. Government microsimulation had been closed by default—proprietary code, restricted data, results that could be doubted but not reproduced. An outside model good enough for the Treasury to pilot put pressure on that default: if an open tool could even partly reproduce the government's internal estimates, and the government thought it worth testing, the case for keeping the models closed weakened. In 2019 I couldn't find a tool to answer a basic question about a universal basic income; by 2025, HM Treasury was piloting one we had built.

Rules, data, and prediction

By late 2025 the tool was real and still plainly unfinished—household calculations sharp, unusual cases still exposing gaps, revenue still running below official totals. But the most useful thing building it gave us wasn't a feature; it was a distinction. A policy question that looks like a single question is really three, and they come apart cleanly the moment you try to compute them. What does the law say—the exact tax owed and benefit due for a specific household, in a specific place and year? Who are the people—how many households look like that one, and how do they sum to a country? And what will happen—how will people respond, how will the economy move, how will next year differ from this one?

Each of the three is answerable, and each is checkable, but against a different kind of truth. An encoded rule is right or wrong against the statute, and against another calculator built from the same statute; you can prove it to the dollar. A population estimate is right or wrong against a survey and against administrative totals; you calibrate it and measure what remains. A prediction is right or wrong only when the future arrives and the official number lands; you commit, you wait, and then you grade. Three concerns, three verification loops, three different clocks.

For years we ran all three inside one engine and one organization, because that was how the tool had grown. But the seams were already showing: the revenue gap was a data problem, not a rules problem; the rules stayed exact precisely where the data was uncertain; the behavioral responses belonged to neither. What we had built as one thing was, underneath, three things—each buildable, each checkable, each trustworthy on its own terms. Pulling them apart would come later. First, though, the engine has to show what it can do: for a single household, and then for a country.