Rules as Code: translating legislation into executable eligibility & calculation logic

Benefit, tax and fee rules are written as prose and then re-interpreted by each IT project, producing inconsistent implementations and slow reaction to amendments. "Rules as Code" (RaC) turns the law into a formal, versioned, testable model that many systems can share. LLMs now draft this code and its tests from the legal text; lawyers and policy experts verify it. The result is faster, more traceable digitisation of legislation, with the law, not the model, as the authority.

Problem & value

• Today: policy staff write legislation; separate IT teams interpret it in specifications and code (often several times: citizen portal, case system, calculator). Interpretation drift causes wrong decisions, appeals and slow response when a law changes. Formalisation is manual, needs rare hybrid legal/coding skills and is rarely done at scale.
• AI value: LLMs draft rules, parameter files and test cases clause by clause, flag ambiguity, and re-derive code when an amendment arrives. Experts spend time reviewing and deciding on interpretation instead of typing.
• Evidence: the Georgetown Beeck Center's "AI-Powered Rules as Code" experiments (2024) tested LLMs on US SNAP and Medicaid rules and concluded that LLMs can accelerate code generation but complex policy logic needs retrieval of outside knowledge and human review [1]. The OECD OPSI has documented RaC as a government practice with international case studies [2]. No reliable, independent figure for end-to-end time savings exists yet; treat vendor claims with caution.

Variants

• Benefit eligibility and calculation (housing, child, social assistance): the classic case, with household-level simulation.
• Tax and fee calculation: income tax, social contributions, municipal fees; Catala was designed for tax code (e.g. French and US-style computations) [4].
• Ex-ante legislative impact simulation: run draft law on a synthetic population before adoption (LexImpact on OpenFisca-France) [3].
• Citizen-facing checkers: "Am I eligible?" tools sharing the same rule base as the case system (CONV-011).
• Private/corporate compliance: regulatory or contractual rules (sector regulation, collective agreements, insurance conditions) as DMN tables; same pipeline, lower public-law stakes.

How it works

1. legal text (versioned, with citation IDs)
2. segmentation by article/paragraph + definitions glossary
3. LLM drafts formal rules (target DSL) + parameters, each element tagged with citation
4. LLM generates test cases (positive, boundary, negative) from text and official examples
5. automated checks: parse/compile, type check, tests run, coverage of clauses, consistency/conflict checks
6. expert review (lawyer + policy owner): approve interpretation, resolve ambiguity
7. release as versioned rule package (effective dates, amendments)
8. consumers: calculators, case systems, simulations, decision-support APIs

• Target formalisms: OpenFisca (Python, parameter files with effective dates, used by French government services and PolicyEngine-style simulators) [3]; Catala (a DSL designed with lawyers, default-logic semantics matching how exceptions in law work, from Inria) [4]; DMN (OMG standard decision tables, widely supported by Camunda, Flowable, Signavio) [5]; also Prolog/Datalog, Blawx, Drools.
• Key AI components: a reasoning LLM for drafting, retrieval over the statute, definitions and prior rule code, and a separate "reviewer" pass that back-translates code into plain language so non-programmers can check it against the law.
• Human-in-the-loop (mandatory): legal sign-off on every interpretation choice; policy owner approval before release; independent test set written or approved by caseworkers. The LLM never publishes rules by itself.

Data preparation

• Data needed: the legal text itself (statutes, ordinances, administrative guidance), official worked examples and calculation sheets, parameter tables (rates, thresholds, indexation) and a gold set of caseworker-decided cases. The statutes are public and clean; the effort sits elsewhere.
• Where it lives: legislation in gesetze-im-internet, EUR-Lex or the drafting system (XML such as Akoma Ntoso or LegalDocML); guidance and circulars as PDFs on file shares or in a DMS; parameter tables and calculation logic in Excel sheets; historic decisions in the case system or paper files.
• Typical gaps: scanned circulars without text layer, consolidated versions mixed with outdated ones, missing effective dates, rules hidden in spreadsheets or in the heads of caseworkers, and no independent test cases. Real case data used for the gold set carries personal data and access restrictions.
• Preparation steps: (1) fix a versioned, citable source text per rule set (article and paragraph IDs); (2) OCR remaining PDFs (PREP-006) and convert old formats (PREP-007); (3) build a definitions glossary (PREP-012, PREP-015); (4) collect 50-100 caseworker-decided cases as gold standard (PREP-016, PREP-018), pseudonymised (PREP-022); (5) extract spreadsheet logic into tidy parameter tables (PREP-011).
• Effort share: low for the text, but roughly 20-30 percent of the project goes into the gold set and the glossary. See GUIDE-003 for the readiness check.

Implementation paths

Which path for whom

• Public sector (B): the statutes are public, so EU-region or sovereign-cloud APIs are acceptable for drafting; draft laws and case data stay out of the prompts or move to path C where procurement or sovereignty rules demand it.
• Enterprise (B): compliance or contract rules as DMN tables are best drafted with cloud models inside your own repo and CI, because the rules must integrate with your own decision systems and no product fits the process.
• Developer (C): an open-weight coding model with the OpenFisca or Catala toolchain runs locally on HW3 and keeps experiments, draft rules and test data under your control.

Path A — Buy (off-the-shelf)

RaC-specific products are few. Options: business-rules/decision platforms with DMN and AI-assisted authoring (Camunda, Flowable, Sapiens Decision, IBM ODM, FICO, Oracle Policy Automation-style products), government low-code platforms, and civic-tech services around OpenFisca/PolicyEngine. EU/German public-sector context: DigitalService (Bund) works on machine-readable legislation prototypes and the Digitalcheck for new laws [6]. Choose A for modest rule sets (fees, simple entitlements) where DMN tables suffice.

Path B — Build on cloud APIs (recommended)

• Frontier reasoning/coding models (Claude, GPT, Gemini; Mistral as EU provider) in EU regions with structured outputs; prompt with statute text, glossary and 2-3 reviewed example rules.
• Orchestrate as a pipeline in a normal repo: rules in Git, CI running compile + tests + coverage, pull-request review by lawyers (see CODE-002 for agentic coding loops, CODE-003 for review).
• Retrieval over EUR-Lex / national legal databases and previous rule packages.

Path C — Self-host (open source)

• Open-weight models: Qwen3-Coder / Qwen3 reasoning, DeepSeek, Mistral and Devstral, gpt-oss; served via vLLM or Ollama. HW3 (one 48-141 GB GPU) for ~30-120B models; HW4 for the largest.
• Stack: OpenFisca or Catala toolchain, Git forge, CI, vector DB for statutes. Common choice for authorities with data-sovereignty rules (statutes are public, but draft laws and case data are not).

Path D — Custom training

Rarely justified. Fine-tuning on a jurisdiction's drafting conventions and existing rule corpora can improve DSL syntax fidelity (Catala is poorly represented in pretraining data); needs hundreds of reviewed text-to-rule pairs. RAG plus compiler feedback usually gets most of the benefit.

State of the art (2026)

• LLMs reliably produce syntactically valid code in mainstream languages (Python/OpenFisca), less reliably in niche DSLs (Catala); compiler-in-the-loop repair and few-shot examples close much of the gap.
• Strongest results come from test-first workflows: generate tests from the law, then rules, then reconcile disagreements as signals of ambiguity [1].
• Typical failure modes: missed exceptions and cross-references, wrong effective dates or transitional provisions, silent default assumptions, mis-specified rounding and period/aggregation semantics, and tests that merely mirror the generated code (circular validation).
• Interpretation is a legal act: where the text is ambiguous, the tool must surface the choice rather than pick one. Legislation drafted "rules-first" (Digitalcheck-style) reduces the problem at the source [6].
• Benchmarks specific to statute-to-code are immature; evaluate on your own gold set.

Shared resources & combinations

• Same stack as CODE-001/002 (coding assistants and agents), CODE-015 (requirements from stakeholder input), CODE-009 and CODE-004 (CI and test generation).
• Upstream/adjacent: KNOW-006 (legal research), LANG-026 (consultation analysis).
• Downstream: AGENT-026 (case-processing agents calling the rule service), CONV-011 (citizen chatbot that must call rules, not improvise), DOC-003 (form intake), ANOM-019 and PRED-029 (benefit error/fraud and risk profiling: separate, high-risk use cases).

Effort, cost & KPIs

• Path A: weeks for DMN-scale rule sets. Path B: 2-6 months for a first domain (e.g. one benefit) including legal review capacity. Path C: add model hosting and ops. Main cost is expert review time, not model usage.
• KPIs: share of clauses with linked rule and test; test pass rate on an independent caseworker- authored suite; agreement with historic decisions on sampled cases; time from enacted amendment to released rule version; reviewer corrections per 100 rules; appeal/overturn rate once in production.

People & change

• Who and when: involve management and the department head (process owner) first to fix scope and the rule that the law, not the model, is authoritative. Bring legal/compliance in from day one, since they sign off every interpretation. IT integrates the rule service; the DPO joins before real case data enters the gold set (DPIA likely if case data flows through rules that decide on people, Art. 35 GDPR; AVV with every API provider, Art. 28). Caseworkers write or approve the independent test suite.
• Works council / staff council: depends. Drafting rules from statutes does not monitor staff. Once the rule service steers case handling, work processes change, so the staff council (Personalrat under BPersVG or state law) or works council must be informed in good time (§90(1) no. 3 BetrVG) and has co-determination if the system logs caseworker behaviour or performance (§87(1) no. 6). Engaging an AI expert counts as necessary (§80(3)). See GUIDE-004.
• AI literacy: support staff with training on LLM failure modes (missed exceptions, circular tests) and on reading back-translated rules (Art. 4 AI Act, GUIDE-006).
• Communication and pilot: start with one bounded benefit or fee schedule and a small group of caseworkers and lawyers as champions (GUIDE-008, GUIDE-009).
• Typical concerns: fear of automated decisions and job loss, and liability for wrong interpretation. Address them with mandatory legal sign-off, visible traceability from code to citation, human review and appeal paths, and staged rollout with sampling. Humans keep control of every release.

Risks, regulation & compliance

• EU AI Act: generating rule code is itself not a listed use; classification follows the deployed system. Systems that evaluate eligibility for public benefits and services are high-risk under Annex III point 5(a); purely deterministic, rule-based software is arguably outside the "AI system" definition, but an LLM in the decision path is not. Seek legal advice. Art. 5 prohibitions (e.g. social scoring) must not be approached. Art. 4 AI literacy applies. Mark: depends [7].
• GDPR: statutes contain no personal data, but case data run through the rules does. Art. 22 limits decisions based solely on automated processing with significant effects; national law (e.g. German VwVfG sec. 35a for fully automated administrative acts, only where no discretion exists) sets the conditions [8]. Provide explanations, human review and appeal.
• Legality principle: published law is authoritative; the code is a derived artefact. Publish the version, citations and test suite; keep effective-date handling auditable.
• Risks and mitigations: wrong interpretation at scale (independent review, staged rollout, sampling of decisions); automation bias; over-trust in LLM-written tests; supply-chain and model-change drift (pin versions, regression suite on every model change).

Getting started

1. Pick one bounded, well-understood rule set (e.g. one fee schedule or benefit) with a known owner.
2. Build a gold set: 50-100 cases with expected outcomes from caseworkers, kept separate from the LLM.
3. Choose a target formalism (OpenFisca, Catala, DMN) and write 2-3 reviewed example rules with citations.
4. Run the LLM pipeline with compiler/test feedback; review output with lawyers using back-translated text.
5. Release as a versioned service, monitor decisions, and rehearse the amendment update cycle.

Sources

1. Georgetown Beeck Center — AI-Powered Rules as Code: Experiments with Public Benefits Policy — https://digitalgovernmenthub.org/library/ai-powered-rules-as-code-experiments-with-public-benefits-policy/
2. OECD OPSI — Cracking the code: Rulemaking for humans and machines — https://oecd-opsi.org/publications/cracking-the-code/
3. OpenFisca — open-source rules-as-code engine — https://openfisca.org/en/
4. Catala — programming language for law — https://catala-lang.org/
5. OMG — Decision Model and Notation (DMN) — https://www.omg.org/spec/DMN/
6. DigitalService Bund — Digitalcheck / machine-readable legislation — https://digitalservice.bund.de/en
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2016/679 (GDPR), Art. 22 — https://eur-lex.europa.eu/eli/reg/2016/679/oj