Encoding the law

The question sounds simple. What is a household's real income—after taxes, after benefits, after the way the two collide? A lending platform needs the answer to underwrite a gig worker. A benefits screener needs it to tell a family what it qualifies for. An AI assistant asked how much someone would receive from the Child Tax Credit needs it to answer without inventing the number. And through the mid-2020s none of them could simply buy the answer, because the market sold only slices of it.

Income-tax filing had well-funded specialists—April, embedding returns inside other companies' apps, and Column Tax, which had filed more than a million returns through its API and built an AI agent to help maintain the engine as the law shifted year to year .^[1] Sales tax had Avalara, acquired for $8.4 billion in 2022 .^[2] Payroll had ADP and Gusto. Benefits screening had MyFriendBen and Benefit Kitchen .^[3][4] Policy research had PolicyEngine, EUROMOD, and Tax-Calculator. Every slice existed somewhere; the integration existed nowhere. The global tax-tech market was climbing toward $60 billion ,^[5] and all of it was balkanized into verticals that each re-encoded the same overlapping rules behind their own walls.

The full-stack question—income tax plus benefits eligibility plus the population-level simulation that turns one household into a national estimate—had no home. And it is the question that matters, because benefits and taxes are not separable. SNAP falls as earnings rise while the Earned Income Tax Credit climbs; the net depends on household composition, state of residence, and a dozen interacting thresholds. Answer only the tax half and you mislead every low-income user you touch. And because no one sold the whole, every company that needed it rebuilt the overlapping rules privately—the same EITC phase-in, the same SNAP deductions, encoded again and again behind incompatible walls, each copy a fresh chance to be wrong.

Priya—a composite drawn from real fintech engineering teams—ran the problem to ground. Her company advanced cash to gig workers who needed to know their true take-home pay before borrowing against it. A tax library pulled from GitHub handled federal brackets and nothing else, missing low-income users by thirty to forty percent. A commercial tax API charged per call and could not touch benefits. Prompting a frontier model produced a hallucination rate no financial product could ship. Building it in-house penciled out to eighteen months of engineering before the first law changed underneath it. Every path led to the same place: a partial, fragile solution, rebuilt privately by every company that hit the wall.

Why this can't be trained away

The tempting response is to wait for the models to get good enough. They won't, for reasons that are structural rather than a matter of time. Tax law changes every January, so last year's training data encodes rules that no longer apply, and a model cannot extrapolate to a bracket it has never seen. Fifty states each run their own income taxes, credits, and benefit programs—a combinatorial sprawl beyond what pretraining reliably memorizes. Eligibility turns on dozens of interacting variables, where a single wrong input silently yields a wrong result, and language models compress exactly that kind of exact logic into statistical approximation. And financial calculation tolerates neither 95 nor 99 percent: a model right nineteen times in twenty is a model that files one return in twenty wrong. Column Tax's own engineers put it flatly—today's language models "cannot 'do taxes' on their own because tax calculations require 100% correctness" .^[1]

The benchmarks keep confirming it and stubbornly refuse to improve on schedule. On PolicyBench, a public board that scores language models on complete household tax-and-benefit calculations, the best 2026 models still get roughly one in six households wrong by more than a dollar; most miss a quarter or more, and the misses are structural—a blown Medicaid determination, a wrong SNAP amount—not rounding .^[6] The answer was never a better prompt. It was a tool: a deterministic, auditable engine the model can call, that computes the number while the model explains it. Which raises the real question—what would it take to build that engine for all of tax and benefit law, and to make anyone believe its numbers?

Administrative quality is part of the product

Before the build, a correction to what "quality" even means, because the hardest problems in benefits software turn out not to be mathematical. Whether a formula is legally correct is one question. How fast a rule change becomes publishable, how many misunderstanding loops open between policy experts and engineers, how much hand-holding a partner developer needs before making a correct API call, how often a tool hands a household a misleading answer because its interface cannot express a real-world exception—those decide whether the software is any good, and none of them is a math problem. They surface as operational metrics: time to publish, discrepancy rates against authoritative examples, onboarding time, the rate at which a support ticket exposes an assumption no one had written down.

Households experience policy through administration. A tax credit that exists in statute but takes six months to reach a screener is not, from where the household sits, fully real. A calculator that silently misses an immigration rule or a state-specific exception is not merely imperfect; it erodes trust, burns caseworker time, and suppresses the very take-up the program was built to produce.

The stakes turn visible when the administration fails at scale. During the 2023 Medicaid unwinding, CMS ordered states to restore coverage for roughly half a million children and families after finding a defect in the automatic-renewal logic of their eligibility systems .^[7] That is administrative quality seen from outside: the entitlement exists, the renewal process exists, and a software error grows large enough that federal officials have to command a mass correction. Up close it is more concrete still. KFF Health News documented how fixes in Deloitte-run eligibility systems can take months or years—in Kentucky, one limitation that cost a resident his Medicaid coverage took about ten months, more than 3,500 hours of work, and over $500,000 to resolve; in Georgia, officials were still untangling a defect affecting more than 25,000 SNAP and TANF cases nearly two years after it was first reported .^[8] Deloitte-built eligibility systems span roughly twenty-five states and some $6 billion in contracts citation pending. Benefits screeners carry a quieter version of the same danger: Virginia Eubanks and colleagues have shown that a screening tool can look authoritative while its logic stays opaque, so people act on wrong predictions without ever thinking to challenge them .^[9] What these failures share is opacity: a defect buried in a vendor system that no outside party—and often no inside one—could inspect, trace to a rule, or fix quickly. The eligibility logic was right in statute and wrong in software, and the gap between the two stayed invisible until it produced a headline.

And in 2025 policy began to price administrative accuracy directly. Under the One Big Beautiful Bill Act, enacted July 4, 2025 ,^[10] states will for the first time—beginning in fiscal 2028—pay a share of SNAP benefit costs pegged to their own payment error rate: nothing while the error rate stays under 6 percent, then 5, 10, or 15 percent of benefits as it crosses 6, 8, and 10 percent. The national payment error rate for fiscal 2025 was 10.6 percent citation pending, an average that would put many states straight into the top penalty tier. The state share of SNAP administrative costs rises from 50 to 75 percent in fiscal 2027 ,^[10] and Medicaid's new work requirements oblige states to stand up verification systems by the end of 2026 citation pending. A payment error rate used to be an audit statistic; it is now a line in the state budget—which is exactly the cost that verified, provenance-carrying rules infrastructure exists to lower. A state that can trace every determination back to the governing rule, and check it against an independent calculator before the payment goes out, has a mechanism for driving that error rate down. Accuracy priced as a penalty is accuracy that infrastructure can help buy back.

The downside is not hypothetical, and the precedents are sobering. Australia's Robodebt scheme raised automated debts against welfare recipients on faulty income-averaging, was unwound in the courts, and put ministers before a royal commission citation pending. Michigan's MiDAS system issued tens of thousands of false fraud determinations against unemployment claimants citation pending. Arkansas replaced a nurse's judgment with an algorithm for allocating Medicaid home-care hours, cut care for disabled residents, and drew litigation citation pending. In each case the arithmetic was automatable and the judgment was not—and automating the judgment without a check caused real harm.

The administrators drawing the lines seem to know it. USDA's Food and Nutrition Service has held that AI may not replace state merit personnel in SNAP eligibility determinations citation pending—a boundary that falls exactly where this book does. The infrastructure is decision support, not decision replacement: a human makes the determination, and the tool's job is to make that determination checkable.

The Axiom Foundation

This is the gap the Axiom Foundation exists to close, and by the middle of 2026 the closing was well underway. Axiom is a Delaware nonprofit, fiscally sponsored by the PSL Foundation, anchored by funding from Ballmer Group; Ariel Kennan became its president on July 1, 2026, and it launches publicly on July 28 .^[11] Its charter is narrow and immodest at once—encode the law itself, exactly, as open infrastructure. PolicyEngine had proved that tax and benefit rules could be encoded accurately at all; Axiom is the attempt to encode all of them, in a form anyone can run and anyone can check. The ambition is larger than any single government's analytical office attempts, and the wager is that agent-drafted encoding behind merge-blocking checks is what makes that scope tractable for a nonprofit at all. Its sibling institute, Thesis, takes the other half of the problem—forecasting what government will actually do—and belongs to later chapters; this one is about the rules.

An Axiom encoding is not a program in the ordinary sense. Its format, RuleSpec, is a set of YAML files that hold the law's logic and the law's numbers apart, each file versioned, each testable, each stamped with the dates over which it takes effect. The logic that computes a credit lives in one place; the parameters it reads—a rate, a threshold, a phase-out amount—live in another, so that when an agency publishes next year's inflation adjustment, a parameter value changes and the logic does not. An act of Congress changes the logic; an annual revenue procedure changes only the numbers; and because both are versioned files with effective dates attached, an encoding can answer not merely "what does the law say" but "what did it say last March, and when did we learn it had changed." Take the Earned Income Tax Credit. The statute defines a credit that climbs with earned income at a set rate up to a ceiling, plateaus, and then phases out above a higher income threshold that shifts with filing status and number of children. In RuleSpec that becomes a formula referencing named parameters—the phase-in rate, the earned-income ceiling, the phase-out rate and threshold—each carrying its own citation, effective date, and source link. A reader can see, for any date, which value was in force and which line of the encoding produced it.

Beneath the rules sits the corpus—the source text itself. Axiom ingests statutes, regulations, agency manuals, and sub-regulatory guidance as anchored provisions, each clause individually addressable, organized against a registry of roughly 41,000 legal concepts to verify. The corpus is what makes provenance possible. An encoding earns trust not because its author was careful but because it points back to the exact governing words, and those words live in a service anyone can open and read. Anchoring matters because law does not live only in statute. The rule a caseworker actually applies is often buried in an agency manual or a guidance letter, and an encoding that could cite only its enabling statute would miss where the binding detail sits. The corpus is built to hold all of it—primary law and the sub-regulatory layers beneath it—at clause resolution.

The encoding pipeline

Encoding law by hand is slow and does not scale; a team can keep one country current or attempt fifty, not both. The reason Axiom can aim at the whole of it rather than a corner is a pipeline called axiom-encode, which turns encoding from a task measured in analyst-months into one measured in agent-runs. It runs in stages. It pulls the relevant provisions from the corpus. It scaffolds a prompt around them—the statute text, the concepts they touch, the shape of the encoding to produce. It hands that to a language model, which drafts the RuleSpec. Then, before anything merges, the draft runs a gauntlet in which every gate can block the merge: the code must compile, its tests must pass, a proof step must validate the logic's internal consistency, the output must be compared against independent reference calculators, and every monetary obligation must be grounded in the source. Only a draft that clears all of them yields a signed manifest—a cryptographic record of what was encoded, from which sources, having passed which checks—so a later reviewer, a skeptical agency, or a court can reconstruct the provenance rather than take it on faith. And the human review sits deliberately at the top of the stack, not the bottom: the machine drafts and the gates screen, while a person adjudicates the judgment calls the statute leaves open, the cross-references and exceptions no gate can settle.

The gates are not redundant; each defends a different failure. Compilation catches an encoding that does not run at all. The tests catch a change that breaks a case that used to work. The proof step catches logic that contradicts itself. Comparison against an independently built calculator catches an encoding that runs, passes its own tests, and is still wrong—the failure no self-check can see, and the one the next chapter is about. And the last gate catches the failure particular to machine-drafted law: a number with nothing behind it. None of these gates trusts the model that wrote the draft, which is the point. The pipeline runs several language-model backends and stays indifferent to which one produced a given encoding, because the guarantee lives in the gates, not the generator. A better model drafts faster and trips fewer checks; it never earns the right to skip them.

One of those gates deserves its own name, because it is the emblem of the whole method. The money-atom gate demands that every monetary obligation an encoding produces—every dollar figure the law commands—trace to a quoted excerpt of the governing source. Not a section number dropped in a comment, but the actual authorizing words, pulled from the corpus. There is a reason the gate targets money rather than every clause: a wrong eligibility flag is a bug, but a wrong dollar figure is a household underpaid or a program overexposed—the failure mode with a face on it. Grounding every commanded amount in the words that command it puts the tightest check where the damage is largest. If a figure cannot be grounded that way, the build does not warn. It fails.

Provenance stopped being a promise and became a merge condition.

That is a mechanical fact with an outsized consequence. Ordinary software cites its sources in documentation that drifts out of date the instant someone edits the code; a merge-blocking check cannot drift, because nothing merges until it passes. The claim that every number traces to the law is therefore not a virtue the project professes but a condition its build enforces—and the machinery that holds that line, and keeps the encodings from quietly going stale, is the subject of the next chapter.

What counts as law

By July 2026 the corner Axiom had turned was not a small one. The US repository held on the order of 3,000 rule files with matching tests, covering federal law plus twenty-eight state codes, absorbed with their full git history to verify. Absorbing a state code with its history rather than retyping it means the encodings inherit years of prior fixes and the reasoning behind them—a change of representation, not a fresh start with fresh bugs. Separate monorepos carried the United Kingdom, Canada, New Zealand, and Belgium, alongside a set of African lanes validated against established reference models that a later chapter takes up in full. The point is not the tally. It is that a single pipeline produced all of it, which puts the marginal cost of the next jurisdiction in units of agent-time rather than institution-years.

And the scope is deliberately, almost provocatively, total. Axiom's charter is not "the parts of law that compute a number." It is all public policy—statutes, regulations, agency manuals, statutory guidance, grant conditions, and the eligibility scheme of a single London borough. Among the early UK encodings is the council-tax-reduction policy of the Royal Borough of Kingston upon Thames: a local scheme binding on a few tens of thousands of residents, encoded with the same machinery as federal income tax. That is not reach for its own sake. A resident of the borough is governed by its council-tax-reduction scheme as concretely as by any act of Parliament, and a stack that encoded only national law would be blind to the rule that actually sets her bill. Encoding the small, the local, and the merely-binding-on-a-few-thousand is the point, not the exception. The principle behind that choice is stated as a rule of its own.

Bindingness is metadata, never a scope filter.

Whether a provision is hard law or soft guidance is recorded as a property of the encoding, never used to decide whether it is worth encoding—because a household is governed by the manual a caseworker actually follows as much as by the statute behind it. That is also why Axiom models authority explicitly, representing the chain by which a statute delegates power to an agency and an agency binds itself through its own published policy. The doctrines are old—in US law an agency must follow its own regulations; in English law it must follow its own stated policy absent good reason citation pending—and encoding them lets a model answer not only what a rule computes but whether the body applying it had the authority to. All of it ships under permissive licenses, Apache 2.0 for the code and Creative Commons Attribution for the content, so that no one need ask permission to run, fork, or build on the encoded law.

Much of law, in fact, is not "compute an amount" at all. It is "does this conclusion hold, fail, or remain undetermined, given a history of events?"—whether a notice is valid, whether a deadline was met, whether an agency followed the procedure it bound itself to. A stack that could only multiply rates by thresholds would capture the arithmetic of policy and miss its logic; modeling authority, delegation, and legal judgment is what lets the encodings represent that second shape. It is the difference between encoding a calculator and encoding the law.

Governing a commons

Building this as a public good removes the sharpest objections—no shareholders, no paywall on the law—without removing the need for governance. A shared rules layer has failure modes of its own, and they are worth naming plainly.

Whose rules come first. Funders and large institutional users have priorities, and the risk is a roadmap that tracks whoever pays the bills rather than where accurate rules matter most; when a database project deprioritizes a feature the stakes are uptime, but when a rules project deprioritizes a jurisdiction's benefit code the stakes include whether vulnerable households get accurate answers. The guardrails are the ordinary ones for a commons—transparent governance, a published roadmap, and the standing fact that anyone can fork and encode what they need.

Capture. Even a nonprofit can be captured—by a dominant funder, or by a maintainer monoculture—until "open" is a brand rather than a fact. Independent governance and a genuine plurality of contributors are the only durable defense.

Staleness. Public goods are chronically underfunded, and the characteristic failure is not bankruptcy but quiet drift, encodings falling out of date as laws change while no one notices. This is the fear the method answers most directly: the conformance ratchets of the next chapter turn "keep it current" from an aspiration into a gate, one under which coverage can only rise and unexplained gaps can only fall.

Openness is not incidental to these defenses; it is the mechanism behind them. A fintech integrating the encodings can read exactly what they compute, an agency can confirm they match statute, and a citable, inspectable rule is far more defensible than a model's unexplained output when a regulator or a court asks for the audit trail. The ability to fork is the ultimate check on capture: a commons no one can leave is not a commons.

The deeper commitment is structural. The encoding of law is reference infrastructure—closer to a dictionary or a map projection than to a product—and it is not well served by a private gatekeeper sitting between the public and the statute. So the rules layer is a commons, and the commercial activity that will grow around it—managed runtimes, service-level guarantees, applied products—is built on the commons, never owner of it. One such operator already exists in formation, organized around graded simulation; it is not yet public.

The line the foundation commits to publicly is plain: the commercial service tier will always be a separate entity, so the foundation never competes with builders on its own commons. The law stays free to run; the convenience of not having to run it yourself is the only thing with a price.

An honest failure

A method is worth only as much as the tests it is willing to fail, so here is one Axiom failed. In July 2026 it ran an experiment on a seductive premise: that encodings are essentially cache. If every rule is deterministically derived from source text, the reasoning went, no encoding needs to be a durable artifact—you could discard any module and regenerate it from the corpus on demand, cheaply, whenever it was wanted. The experiment, known internally as the B1 probe, put that premise to twenty-five modules.

It failed, and the way it failed is the useful part. Regeneration was genuinely cheap—about eight cents of compute per module—but in twenty-three of the twenty-five cases the original encoding was the correct one, and the freshly regenerated version introduced naming instability that would have broken every downstream consumer. Same source, same pipeline, different output; the difference was silent damage. The conclusion Axiom adopted cuts against the elegant version of its own story: encodings are not disposable cache. They are durable artifacts with provenance, and regeneration, at the current configuration, is not yet trustworthy enough to lean on. The finding changed how encodings are treated—as artifacts to be stored, versioned, and migrated with care, not outputs to be discarded and re-derived—and regeneration went back on the shelf as a research problem rather than a shipping feature.

That is the discipline working, not failing. A project convinced of its own story would have shipped regeneration and met the breakage in production. A project that runs the probe, reads the result, and writes the negative finding down is one whose other claims are worth more for it.

Which leaves the question this chapter has circled without answering. Encoding all of public policy at agent speed is worth nothing unless the encodings are right, and "a language model wrote it and the tests passed" is not, by itself, a reason to trust a number that decides whether a family makes rent. Compilation proves the code runs. The money-atom gate proves each dollar traces to the law. Neither proves the encoding matches the world.

That proof is a separate discipline, and it is where the real confidence in this method is won or lost: comparison, case by case, against independent calculators built by other people with other tools—and the harder practice of explaining, rather than waving away, every place the two disagree. How to trust law encoded by machines is the subject of the next chapter.