Computable law, in practice: Sonia applies for benefits

Sonia opens the mailbox after another long night shift. Sitting at the bottom is the official envelope she’s been waiting for — the letter from the social services agency. She rips it open, hoping this is finally regular money for groceries.

DENIED.

She can hardly believe her eyes. She’d first done some research using a chatbot that told her she was eligible and stated the hundreds of dollars her family would receive. The community navigator who helped her apply was confident she’d be eligible. The caseworker at her interview assured her help was on the way.

She can’t wait to get to sleep, but knows it’s her only chance to call the agency. She dials, expecting the long wait on hold. 45 minutes later she gets a call center representative. They pull up her case, but can only see the determination and a high level description that she didn’t qualify. They tell her she needs to apply again.

She’s devastated. The application was hard, had so many questions, and now it will be another month waiting.

Sonia’s story is just one of thousands of possible stories in the current status quo of opaque government systems that have consequential outcomes for families across the country at their moments of highest need. What might this story look like if open, computable rules powered it? Here is what each of those systems could do differently.

People are asking chatbots questions about government assistance, such as whether they are eligible, how much they might receive, how new policies might impact them. The systems answer fluently and, when the answer is a number someone is owed, often wrongly. On PolicyBench, our open benchmark, we score 32 models against 100 household scenarios. On SNAP, models handle the zero-benefit cases well (96.5% within $1). Where a family qualifies, they land within 10% of the right amount 24% of the time and on the exact amount almost never: one answer in 640 across the 32 models.¹ Models are good at saying “you get nothing” and bad at saying how much when you are eligible. Structured, open rules from the Axiom Foundation change that. A lab wires its assistant to compute benefits and tax answers from the Axiom encodings. This makes the calculation visible and checkable, and by citing the source, makes it clear it’s up to date to the current law. For Sonia, the chatbot would have told her the same number the agency computed, and shown her where it came from.

Benefits screening tools and navigators are core services for helping people understand the breadth of programs they may be eligible for and assisting them in the arduous application processes. Navigators need tools that stay up to date with policy changes and allow them to focus on their core mission — serving their community. The Axiom Foundation will soon offer an application programming interface (API) and Model Context Protocol (MCP) that allow the builders of navigation and screening tools integrated access to the rules so they are not having to re-create them for every tool. Sonia’s benefits navigator would be able to share a recommendation and calculation grounded in the latest policies.

Government systems for accessing and administering benefits run on those same policies, encoded again. It’s not that no code exists for these policies; it’s that vendors keep it locked away in proprietary systems that the government licenses, but may not have access to read or edit.² For the applicant, this means entering detailed information into the system and not being sure what happens to it. For caseworkers, it means seeing a determination and a calculated amount they cannot trace, and errors they cannot catch or fix.

An application powered by Axiom could calculate in real time as the applicant adds information, showing traceable calculations and the citations behind them. It could also fundamentally change what applying looks like — for Sonia, that could mean a process closer to a conversation about her family, with the eligible amount and the reasons behind it appearing as she went. It would have helped her catch the extra digit she entered with her latest tip income. More importantly, it would have prevented the upstream interpretation error that misapplied a deduction — the mistake that actually caused her denial. The system should catch these errors long before a determination letter reaches a mailbox, and when it doesn’t, it gives the call center rep a way to see which input drove the error. Sonia’s month-long re-application becomes a five-minute correction.

For benefits administering agencies, an open, computable Axiom rules layer makes determinations and amounts transparent. Today nothing comprehensively exists to check a proprietary rules engine against — not for the public, not for the agency, and not for the vendor that built it. An open commons, from federal statute and regulation down to state-specific policy, lets agencies stop paying to re-implement the same rules, compare their reading against other jurisdictions, and verify the source behind every number. They can also model policy changes before those changes take effect, so the systems are ready when the law is.

Publishing the code isn’t enough on its own. The Axiom Foundation checks its encodings against external engines and datasets, such as PolicyEngine, TAXSIM, and real SNAP quality-control data, provision by provision, every time the code changes. When two engines built by different teams land on the same number, that’s evidence the encoding is right. When they don’t, either the law is unclear or someone made a mistake — and either way, the disagreement goes on the public record. Coverage grows provision by provision, and each encoding carries the date it was checked, so an agency can see exactly what exists for its state instead of taking a claim on faith. Agencies can run the same play on their own systems, testing prior case data and sample cases against the rules at a scale manual review can’t reach.

For legislators making policy decisions about benefits, computable rules change a debate from intuition to evidence. The Axiom rules layer provides the current law, and enables modeling of possible changes to understand impact. Legislative staff can now model the before and after delta for a family like Sonia’s.

While this may feel like internal machinery in the bureaucracy of government, it has a direct impact on the benefits people like Sonia and her family receive. All of these systems should run on the same set of rules — openly available so that nobody duplicates the interpretation, the cost, or the implementation.

Sonia opens the mailbox after another long night shift. Sitting at the bottom is the official envelope from the social services agency, and she already knows what it says. She rips it open anyway, because some things you want to see in writing.

APPROVED and her new EBT card enclosed.

She had watched the amount take shape while she applied, shifting as she entered her hours, her wages, her rent, the ages of her kids. The chatbot she asked weeks ago, the navigator who sat with her, the caseworker at her interview, and the letter in her hand all named the same figure, because all four ran the same published rules.

An open rules layer would not have made Sonia eligible if she weren’t. What it does is make the answer explainable — to her, to the navigator, to the caseworker, to the agency’s own staff, and to the legislator who wrote the rule and has never seen it run. Sonia’s family needed groceries. The least the system owes her is the ability to see how it is calculated.

Get in touch to discuss how the Axiom Foundation is building on open, computable rules: hello@axiom.org

Disclosure: This blog was written by a human, edited by humans and with AI, and images generated by AI.

1. PolicyBench board snapshot captured Aug 22, 2026.
2. Kennan, Elizabeth Bynum Sorrell, Rachel Meade Smith, and Jason Goodman. “Implementing Benefits Eligibility + Enrollment Systems: Insights on State Approaches and Processes,” Beeck Center for Social Impact + Innovation, February 4, 2025.