Tax and Benefit Rules in the AI Era: A Look at Axiom Foundation

Sept 7, 2026

The Axiom Foundation is taking on two problems at once: policy rules are repeatedly reimplemented across systems and can be difficult to inspect, while AI is increasingly answering tax and benefit questions without reliable computational ground truth.

Launched in July 2026 as a U.S. nonprofit, it is responding by creating open, machine-readable, and executable encodings of those rules, tied back to statutes, regulations, and policy guidance so others can use, audit, and verify them.

Generative AI Does Not Always Rely on Government Sources

The Open Data Institute (ODI) published its “CitizenQuery-UK” report this year. It says that when questions about tax, benefits, immigration, and employment were asked, the models generated incorrect answers instead of returning “I don’t know”. In some cases, information from non-government sources on the internet contributed to incorrect answers. ODI calls for more AI-ready mechanisms that make official government information more likely to be prioritized.

PolicyBench, a U.S. benchmark for evaluating AI performance on tax and benefit questions, asked frontier models to calculate tax amounts and determine benefit eligibility, then compared their answers with reference outputs from PolicyEngine-US. In Axiom Foundation’s July 28 snapshot, the benchmark covered 100 households, 18 programs and 27 frontier models, with an overall accuracy rate of around 90%. Roughly one out of every ten answers was wrong.

Source: Axiom Foundation, July 28, 2026 snapshot.

AI Is Part of the Problem — and Part of the Solution

Axiom’s approach can be summarized in two points:

Develop policy encodings at scale and make them available to a wide range of systems, including LLMs and AI agents.
Publish those encodings openly so they can be inspected and validated by cross-checking them against existing implementations and datasets.

It is starting with tax and benefit policy and aims to cover rules from jurisdictions around the world.

New Zealand’s “Better Rules – Better Outcomes” is an example of an upstream approach, bringing policymakers and programmers together from policy development through legislative drafting. Axiom takes a more downstream approach, using AI to help encode existing laws and policy guidance into machine-readable and executable rules at scale.

What Is RuleSpec?

Within the “AI-driven pipeline,” RuleSpec is the specification used to represent executable policy rules. It is defined as the “canonical authoring and interchange schema for Axiom Rules Engine rules,” but “schema” here does not mean a single file. It defines how the Axiom Rules Engine represents and executes rules, including file structure and expressions, rule types, effective-date versioning, and rounding.

An encoding is a concrete representation of policy rules written according to RuleSpec. Axiom CEO Max Ghenis compares the relationship between RuleSpec and an encoding to the relationship in OpenAPI between the Specification and an individual Description.

By launch, more than 3,000 provisions had already been encoded and released under an open license, along with test cases. The foundation has also published demos built on these encodings, including a chatbot, form generation, and microsimulation tools that estimate how policy changes affect individuals and households.

How It Relates to OpenFisca and Other Implementations

The idea of an executable layer of policy rules between the authoritative sources layer and the application layer is not new. OpenFisca and PolicyEngine are earlier examples of modeling tax and benefit systems in machine-executable form for calculation and simulation.

If a policy system has already been modeled in a machine-executable form using tools such as OpenFisca, and that implementation can be reused across multiple applications, there may be no need to re-encode it in Axiom’s format.

Axiom does not appear to be trying to replace every existing implementation. Rather, it is addressing a broader problem: policy rules are often reimplemented separately across systems and can be difficult to inspect or compare. Its aim is to create shared, open infrastructure for machine-readable and executable rules, while allowing independently built implementations to be checked against one another.

Validating AI-Assisted Encodings

Axiom describes a multi-step validation process for AI-assisted encodings. The process includes deterministic checks, for example, whether numerical values in the source material match those in the encoding — as well as reviews by independent AI agents. When judgment is needed to interpret how laws, regulations, or guidance relate to one another, human experts may also be brought in to review the encoding.

Another unique feature is that Axiom compares its encodings with existing implementations and government data wherever possible.

Conceptually, the relationship looks like this:

Rule A → Implementation X → Output X
Rule A → Implementation Y → Output Y
Output X ≠ Output Y

If the outputs differ, the underlying code, input mappings, and source material can be examined to understand what caused the discrepancy. A mismatch does not automatically mean that one implementation is wrong.

What is particularly interesting is that different implementations can be compared while continuing to run in their native environments, using what Axiom calls a “thin adapter.” As a result, the comparison framework does not require every system to use the same rules engine or depend on a single vendor.

I asked Max Ghenis whether this mechanism could eventually serve as a broader testbed for independently developed rule implementations. He described the goal as a “shared testbed where independently built implementations check each other,” rather than simply comparing every system against Axiom’s own encodings.

Axiom currently validates its encodings against external implementations and datasets such as PolicyEngine, TAXSIM, and UKMOD/EUROMOD. These comparison targets are referred to as “oracles.” He also said that OpenFisca-based implementations are particularly well suited to this kind of comparison, while platforms such as Blawx can be connected through a thin adapter.

So, How Does Axiom Connect Encodings to AI?

Axiom’s MCP Server Reference describes its MCP server as a “thin adapter” between an AI agent and the Axiom Rule API. The AI client calls tools such as search_rules or calculate_household, and the MCP server sends those requests to the Axiom Rule API. With this setup, an AI agent can search encoded rules and run calculations through MCP without directly calling the Axiom Rule API.

Source: Axiom Foundation, “Axiom MCP Server Reference” (Accessed September 5, 2026)

Different Approaches to AI and Policy Rules Are Emerging in Japan

In the U.S., organizations outside government are playing a visible role in building open technical infrastructure that governments can also use.

Japan looks somewhat different: much of the visible experimentation is being led by public-sector organizations, with different approaches emerging around AI models, external data and APIs, and reusable rule logic.

In 2024, Digital Agency launched a Data for AI sub-unit to make government data more machine-readable and easier for AI to use. The Law API is also being enhanced, and the agency is working on MCP support to make government systems more accessible to AI agents.

The Tokyo Metropolitan Government and GovTech Tokyo, together with Tohoku University, are taking a different approach. They are developing and testing an AI model specialized for public administration and trained on laws and other domain-specific knowledge.

In its “Open Source Promotion Report 2025,” IPA (Innovation Platform Agency, Japan), points to an ecosystem in which public administration publishes reusable components — such as data models, rule logic, and API components — as open source, so that they can be reused and extended by the private sector and citizens, both within Japan and internationally.

The More Shared the Infrastructure, the More Governance Matters

As AI agents take on tasks that were previously hard-coded into applications, a broader design question emerges: What should the model learn, what should it retrieve from external data, what should remain as explicit executable policy rules, and where should human judgment remain?

Axiom’s approach makes these governance questions more explicit rather than leaving them buried inside individual systems. Authority remains with the underlying sources, but a shared executable layer still needs clear mechanisms for maintenance, handling differences between implementations, and determining when governments or public services can rely on it. The more widely such infrastructure is shared and reused, the more important those mechanisms become.

References

English titles of Japanese sources are informal translations by the author.

The Foundation’s Launch Materials (The Axiom Foundation)
About Code Verification (The Axiom Foundation)
Encodings and technical resources for its policy-rule infrastructure（The Axiom Foundation ー GitHub）
MCP Server Official Reference (The Axiom Foundation)
CitizenQuery-UK: Evaluation Report on LLM Answers to Administrative Information (Open Data Institute)
PolicyBench, a benchmark by PolicyEngine for evaluating AI performance（PolicyEngine）
Better Rules Better Outcome official website (New Zealand Ministry of Business, Innovation and Employment)
OpenFisca official website (OpenFisca Association)
PolicyEngine US official website (PolicyEngine)
Blawx official GitHub (Lexpedite)
Data for AI Subunit Launch Material (The Digital Agency, Japan)
Japan-developed AI model specialized for public administration (Tokyo Metropolitan Government Bureau of Digital Services)
FY2025 Open Source Promotion Report Part III: Addressing the Gap (Information-technology Promotion Agency, Japan [IPA])
“Law × Digital” Initiatives (The Digital Agency, Japan)
The 12th Digital Society Concept Council (The Digital Agency, Japan)
Author Interview with Axiom Foundation, August 2026 — covering the relationship between RuleSpec and encodings, the use of thin adapters to validate different policy implementations, and the concept of a “shared testbed” for comparing independently developed implementations.