The three ingredients

Every microsimulation model rests on the same three foundations: rules encoded as executable logic, microdata constructed into a population, and dynamics — the assumptions about how people respond. You will not find that trio stated in the textbooks, which organize around techniques rather than architecture ,^[1] but it is what every team building such a model must solve, and each ingredient fails in its own way. Get the rules wrong and the calculations are incorrect. Get the data wrong and the estimates are biased. Ignore dynamics and the projections miss how people respond. PolicyEngine, Tax-Calculator, EUROMOD, and TAXSIM each answer the same three questions differently, and the differences are the most revealing thing about them.

The trio also explains why this chapter sits where it does. Each ingredient has become a separate construction project — a layer that AI agents can increasingly build at a fraction of its former cost. That changes nothing about the standard each layer must meet, and everything about who can meet it. A cheaply built layer is worth nothing if you cannot tell whether it is right, so the question that matters for each ingredient is the same: what can its output be checked against?

The rules

The first ingredient is encoding policy rules as something a computer can evaluate — every tax rate, benefit threshold, eligibility condition, and phase-out schedule.

This sounds simple. It isn't.

Take the Earned Income Tax Credit, one credit among dozens. Its phase-in rate depends on the number of qualifying children — and "qualifying child" carries its own age, relationship, residency, and joint-return tests. The credit depends on earned income, which excludes some income types and includes others. The phase-out threshold differs for single and married filers. Many states layer their own EITCs on top, each with its own conformity rules citation pending. Encoding this one credit takes hundreds of parameters and dozens of functions, and a single misreading produces wrong answers for millions of households. A comprehensive US model must do the same for federal income tax and its brackets and credits, payroll taxes, fifty state income tax codes, SNAP, Medicaid, SSI, TANF, housing subsidies, WIC, school meals, and more — on the order of a few thousand parameters citation pending, each traceable to a legislative or regulatory source, each changing on its own schedule. And because programs interact — eligibility for one benefit often turns on income as defined by another — a change to a single rule ripples through the rest. It is the edge cases and the interactions, far more than the headline rates, where encodings go wrong: a model can get every bracket right and one definition of earned income wrong, and it will be wrong for exactly the families the credit exists to serve.

How to encode the rules is the interesting question, and the field has produced three answers — three architectures, of rising vintage. They share more than their partisans admit: each separates the logic from the parameter values, and each has to answer for time, because policy is a time series and last April's threshold is not this April's. Where they part ways is in who writes the rules, who can read them, and what the encoding is checked against.

Three architectures

The first architecture is a structured document behind a graphical interface, and EUROMOD is its most developed example .^[2] Policy rules live in XML: parameters, a "spine" defining the order of calculation, switches for which policies are active. Researchers edit them through EUROMOD's own application, which presents each policy as an expandable tree with dialogue boxes for the values. The advantages are real. A researcher with no programming background can change a rate or a threshold; the interface enforces structure; the files are openly licensed. The costs arrive at scale: the country models run large citation pending, navigating them depends on knowing where in the tree to look, tracking changes across versions means comparing XML, and the skill a contributor builds is EUROMOD's tooling rather than anything transferable.

The second architecture is code-native, the approach Tax-Calculator and PolicyEngine take. Policy rules are ordinary source code — readable in any editor, browsable on GitHub, changed through the same version-control workflow developers use for everything else. A calculation is literally a function you can step through in a debugger and cover with unit tests. In PolicyEngine's design the logic lives in Python and the values live separately in YAML, keyed by their effective dates. Here is a UK National Insurance contribution, whole:

def formula(person, period, parameters):
    earnings = person("employee_earnings", period)
    ni = parameters(period).gov.hmrc.national_insurance
    pt = ni.class_1.thresholds.primary_threshold
    uel = ni.class_1.thresholds.upper_earnings_limit
    main_rate = ni.class_1.rates.main

    liable_at_main = max_(0, min_(earnings, uel) - pt)
    return liable_at_main * main_rate

gov:
  hmrc:
    national_insurance:
      class_1:
        thresholds:
          primary_threshold:
            values:
              2024-04-06: 242  # weekly
        rates:
          main:
            values:
              2024-04-06: 0.08

The separation is the design: when a new tax year changes the threshold, you edit the YAML and the code never moves; the code changes only when the structure of the policy does. Both this and the EUROMOD approach are genuinely open — what differs is the experience and the mental model. One says "use this application to view these configurations"; the other says "read this code like any other software project." That is a community difference, not a verdict. EUROMOD serves researchers who work inside its ecosystem for years, where investment in its tooling pays off in depth; code-native tools serve people who might contribute once, work across many projects, or wire microsimulation into other software, where investment in general programming skill pays off in breadth.

The last of the chapter's opening four tools sits outside this axis entirely, and it matters for what comes next. TAXSIM — maintained by Daniel Feenberg at the National Bureau of Economic Research since the early 1980s ^[3] — is neither a spreadsheet nor an open repository. It is a compiled program behind a web interface, and its distinguishing feature is decades of validation against actual IRS return data, which made it the benchmark other tax calculators are measured against. You cannot step through its code. You can trust its answers. Opaque internals, validated outputs: hold that combination in mind.

The third architecture is the newest, and at first glance it looks like a small variation on the second. Rules are still versioned, testable files — a YAML format called RuleSpec, in which the logic and the parameters carry their own effective dates — but the author is usually an AI agent rather than a person, and nothing the agent writes merges on its say-so. The agent drafts against a corpus of the actual source law — statutes, regulations, and agency guidance ingested as anchored provisions — rather than from its training memory, and its output is treated as a proposal, not a result. Every proposal passes through merge-blocking gates. The code must compile and the tests must pass, as in any software project. Then come two checks specific to law. First, money-atom grounding: every monetary amount in the encoding must trace to a quoted passage of the governing statute or regulation, or the build fails — no dollar figure floats free of a source. Second, oracle comparison: the encoding's outputs are compared, case by case, against a reference calculator — an independent implementation of the same law, TAXSIM for US federal tax, EUROMOD and UKMOD abroad, official calculators where they exist — and mismatches block the merge until they are explained. Human review sits on top of the automated gates, not in place of them. The Axiom Foundation is building this layer, and at the time of writing it spans US federal law plus dozens of state codes and several other countries to verify, each encoding carrying a signed manifest recording what was built and how it checked out.

What makes machine-written law admissible — what lets you trust an encoding no human wrote — is not the agent and not the YAML. It is the criterion the gates enforce: every unit's output is checkable against ground truth. A statute has a fact of the matter; an encoding either reproduces it, household by household, or it doesn't, and on every case you put to them, the reference calculators say which. TAXSIM earned trust through decades of validation; the third architecture generalizes that bargain and runs it before every merge.

Agent scale without it is just confident fiction at volume.

How the verification actually works — the oracles and their tolerances, the conformance gates that only ratchet toward correctness, what happens when the reference model itself turns out to be wrong, the countries encoded in days rather than years — is the subject of Part III. Here it is enough to name the criterion, because the same criterion is about to reappear in a place it is much harder to satisfy.

The data

Rules encoding determines what the model computes. Microdata construction determines who it computes for. A microsimulation calculates for tens of thousands of records standing in for the whole population, each needing a realistic income, family structure, location, and program participation, and the model sums the weighted results into national estimates — so every revenue score, poverty rate, and distributional table inherits whatever is right or wrong about the records underneath.

Most records start life in a household survey: in the US, the Current Population Survey — the annual supplement of seventy-five to ninety thousand households that chapter 6 weighted into a country ^[4] — in the UK the Family Resources Survey, across Europe EU-SILC. No survey has everything. The CPS captures wages well and capital income poorly; people under-report dividends and gains, the very wealthy rarely land in the sample, and very high earnings are top-coded ^[5] — compressed into a ceiling exactly where high-earner policies bite. It omits tax-relevant detail like itemized deductions and retirement contributions entirely, and benefits go unreported at the rates chapter 3 measured. The blind spots are survey-specific: the Family Resources Survey lacks the council-tax detail UK local-tax modeling needs; EU-SILC misses the within-year timing that drives benefit calculations. Whatever you want to model, the survey you have is missing part of it.

So the data ingredient is a pipeline, and its stages deserve to be understood, because national statistics ride on them. For decades this was the least glamorous work in the field — done separately inside every modeling shop, rarely published, seldom reused — which is precisely why it repaid being rebuilt as shared machinery.

Statistical matching combines surveys. Take a CPS household — $80,000, two children, California — and find a similar record in the Survey of Consumer Finances, which carries the wealth and asset detail the CPS lacks; merge their characteristics into one richer record. The craft hides in the word "similar." Match on too few variables and you weld a tech worker's income to a retiree's asset portfolio; match on too many and no two households ever pair. Tax-Data, part of the Policy Simulation Library, pioneered this for US tax modeling by matching CPS records to IRS Public Use File data, recovering the capital-gains realizations and itemized-deduction patterns the CPS alone would miss. Matching recombines existing information rather than creating any; its validity rests entirely on whether the matching assumptions hold.

Imputation predicts a missing value from observed ones. The traditional version fits a regression and applies its average relationship, so every $100,000 earner in California receives roughly the same predicted deduction — a tidy fiction. Quantile regression forests instead estimate the whole distribution of plausible values and sample from it, so a high-income California household might draw a deduction anywhere from $15,000 to $50,000. That spread does real work: a reform that caps itemized deductions has winners and losers only if the model's households actually vary, and mean imputation quietly deletes the variation the reform turns on.

Calibration adjusts the weights — each record's stand-in count, from chapter 6 — so that weighted totals reproduce known aggregates. If the survey implies $9 trillion in wages and IRS records show $10 trillion, calibration re-solves the weights until the total comes out right. The mathematics is optimization: define a loss measuring how far the weighted aggregates sit from the targets, add a penalty for moving any weight too far from its survey value, and minimize the sum. The targets are specific and numerous — federal income tax by bracket, SNAP benefits by state, Social Security payments by age group, wages by industry — and the penalty is what keeps the reweighting honest, holding the new weights close to the survey's original design instead of letting a few records balloon to carry the country.

Aging moves the snapshot forward, because the 2023 survey describes 2023 and the policy question is usually about next year or the next decade. The simple version scales by indices — wages by projected wage growth, investment income by projected returns, everyone a year older. The sophisticated version models who retires, who enters the workforce, how individual incomes evolve, buying accuracy at a much higher build-and-check cost. PolicyEngine takes its projection factors from the Congressional Budget Office's forecasts, so its estimates line up with the baselines Washington already argues over .^[6]

These stages used to live as one-off scripts inside each modeling team, which meant every result depended on code nobody else ran. They are now reusable libraries — imputation methods behind a common interface ,^[7] weight calibration with holdout checks and diagnostics ,^[8] synthesis and projection alongside — consolidated into populace, the calibrated-microdata commons chapter 6 introduced. The methods are the point; the name just means they ship as tested, versioned infrastructure rather than as the private appendix to somebody's model.

One risk survives every stage, and it is the data ingredient's version of the edge-case problem in rules. Calibration matches margins: after it runs, the published totals come out right by construction. Nothing in that guarantees the joint structure — that the right households hold the right combinations of income, assets, and benefits. A population can reproduce every published total and still assemble those totals out of people who don't quite exist. Joint structure is exactly what many reforms turn on: a benefit that phases out with income but only for households above an asset threshold depends on how income and wealth are paired, not on either total alone. Testing the pairing — holding a synthesized population against ground truth it was never fitted to, rather than against the totals it was — is per-unit verification work again, in harder terrain, and Part III returns to it.

The dynamics

Rules handle the arithmetic and data handles the who; the third ingredient is how people respond. Raise a marginal tax rate and some people work less. Cut a benefit phase-out and some work more. Tax carbon and some drive less. These responses move revenue, distribution, and effectiveness, and they are harder to model than everything above, because they are not written down anywhere.

Most microsimulation is static: compute what each household owes and receives under current policy, compute it again under the reform with behavior held fixed, and report the difference as the day-one effect. Static analysis answers who gains and who loses and by how much — answers that barely depend on behavioral assumptions — but it misses responses that change the totals. A carbon tax scored at $100 billion on the assumption that nobody drives less will raise less than $100 billion, because people drive less. The static-versus-dynamic gap is largest exactly where behavior is most sensitive, which is also where honest estimators most disagree.

The most-studied response is labor supply :^[9] how much hours and reported income shift when the after-tax wage changes, summarized as an elasticity. The broadest summary number is the elasticity of taxable income — the ETI — which folds in not just hours worked but tax planning, income shifting, and avoidance. Carina Neisser's meta-regression of the literature — 1,720 estimates from 61 studies — finds a mean around 0.30, meaning a 10 percent rise in the net-of-tax rate raises reported income by roughly 3 percent .^[10] The mean is the least interesting thing about it. The estimates spread from near zero to above 1.0, varying with income level, tax system, time horizon, and method — and the spread is money: raising the top federal rate from 37 to 39.6 percent brings in something like $50 billion more per year under a low elasticity than under a high one. Within the spread, some patterns hold. Primary earners in married couples barely move. Secondary earners and single parents respond more. The reported income of the very wealthy moves most of all — though much of that is tax planning rather than any change in actual work, as the post-2017 restructuring surge chapter 3 described made vivid, when a new 20 percent deduction redrew business forms within a couple of filing seasons.

PolicyEngine's answer to the spread is to refuse to bury it. A user scores a reform with no behavioral response, with CBO-style elasticities, or with parameters of their own choosing, and watches the revenue estimate move as the assumption does. The same machinery carries the other margins: capital-gains realizations respond in their timing, swinging revenue between years as holders wait out a high rate or cash out under a low one; taxpayers restructure around new rules, shifting income between years or reclassifying its type; and program take-up — already well below 100 percent for SNAP and the EITC — rises and falls with generosity and complexity, so a reform can change costs as much by moving enrollment as by changing the benefit.

There is a more ambitious road. Structural models do not take elasticities as given; they specify what people maximize — utility from consumption and leisure, under a budget constraint — and let behavior fall out of the optimization, so that changing the tax schedule and re-solving produces the new behavior directly. The appeal is reach: a structural model can price a 90 percent marginal rate no one has observed, where an elasticity estimated at lower rates may not carry. The price is assumption — that people truly maximize, that the chosen functional forms are right — plus a steep climb in computational complexity. PolicyEngine does not yet implement structural responses; the architecture leaves room for them as modules over the same household data. But no amount of structure changes what kind of claim a behavioral response is, which is the last thing this chapter has to say.

The seam

Everything in this chapter up to the behavioral response is deterministic. Given the rules and a household's inputs — under a stated reading, where the statute admits more than one — the tax owed and the benefits due are computed, exactly, and they can be checked household by household: against the statute, against a reference calculator, against what a caseworker actually determined. There is a fact of the matter, verifiable now, per unit, before the policy ever takes effect. Chapter 6's standing caveat — estimates, not determinations — marks the domain's outer wall: past the encoded rules lie documentation, discretion, and local practice, where administration takes over from arithmetic.

Ask instead how people will change their hours, their portfolios, or their take-up, and you have left that domain. No statute contains the answer; no reference calculator can adjudicate it; the only test is to wait and watch. Structural models do not escape this — their outputs still land on the prediction side of the line, answerable only after the behavior happens. The same model wears two epistemic hats: one output verified against the rules as written, the other against outcomes as they arrive. Chapter 6's reliability tiers were this seam wearing budget clothes — household calculations on the deterministic side, behavioral adjustments to a revenue estimate on the other. Keeping the two straight — being exact where exactness is possible and honestly uncertain where it isn't — is most of what separates a trustworthy model from a merely confident one.

The three ingredients also supply the questions to ask of any microsimulation model, including every one this book profiles: whether the calculations are right, checked against authoritative sources and legible enough that you can see why they produce a given answer; whether the microdata represents the population, with missing variables filled defensibly and weights calibrated to real totals; and what behavioral assumptions are in play, stated or hidden, and how much the results move when they change. Held together, the trio explains why building this took years. The rules you want dictate the data you need: model capital gains and you need assets; model childcare subsidies and you need childcare expenses. The data you have bounds the rules you can honestly simulate: without deduction detail, you cannot credibly score a deduction reform. Dynamics reach into both, since a behavioral response changes effective rates and effective rates change the distributional story. Different models are strong in different columns — TAXSIM in rules, validated against decades of returns ;^[3] Tax-Data in microdata construction; OG-USA in dynamics, with a full model of overlapping generations behind it — and PolicyEngine's aim was to be strong across all three at once, which is precisely what made it hard. No single tax formula is difficult. What takes sustained engineering is making comprehensive rules work with realistic data while supporting explicit dynamics, all at once, across the whole system.

Now run the chapter backward with the agent question in mind. Rules: an agent can draft them, and gates can check every unit against statute and reference calculators. Data: agents can build the pipeline, and calibration can be checked against administrative totals — with the joint structure still waiting on harder tests. Dynamics: agents can implement the responses, and reality grades them, later, on its own clock. Each ingredient is a layer an agent can build and a machine can check; no single ground truth serves all three, and the verdicts do not arrive together. That decomposition, and what happened when it met a frontier model with a corpus of law, is the story Part III tells.