Rules as Code (RaC) transforms laws and policies into machine-consumable formats. This approach empowers governments and third parties to design and build compliant digital services for citizens, businesses, and other stakeholders. It bridges the gap between policy and technology, creating systems that are more transparent, efficient, scalable, compliant, and explainable(1).

RaC is not new in concept—every new application or digital service already translates laws into code. However, ad hoc and opaque(2) methods introduce problems: 

• Interpretation chaos: Multiple teams interpreting policies differently lead to inconsistencies and unintended outcomes.
• Limited transparency: Rules buried in programming code or proprietary systems result in “black-box algorithms” that hinder validation and accountability.
• Fragmented knowledge: Siloed approaches prevent the sharing of rules and insights across teams.
• Compliance-process overlap: Merging compliance and process rules reduces adaptability and collaboration.
  These challenges slow innovation, waste resources, and diminish public trust.

The problem lies in the lack of a transparent, standardized process for converting policy into software. The intermediate steps—analyses, formalizations, and algorithm assumptions—are often hidden, leaving critical decisions opaque. Without a consistent framework, the resulting digital services fail to meet the demands of modern governance.

A Better Approach: Open RaC

An Open RaC framework addresses these issues by:

1. Establishing a transparent and inclusive middle layer for analyzing and formalizing rules.
2. Leveraging powerful and usable standards-based artifacts for cross-team alignment and collaboration.

Implementing governance structures to ensure ongoing accountability and compliance.

The Big Picture

RaC is more than a technical strategy—it’s a shift in how governments deliver public services. By adopting Open RaC, governments can reduce inefficiencies, drive innovation, and rebuild trust, creating efficient, equitable, and adaptable systems for all.
 

Rules as Code is, basically, an approach to turning policy and relevant law into maintainable machine-consumable(3) versions that can be used by government and third parties to design(4) and create compliant digital and other(5) services for citizens, businesses, and other stakeholders. It also facilitates the enhancement of research and monitoring services, ultimately providing governance with high-quality, detailed insights.

Why care about RaC?

We should care about RaC because (a) done right, it can become a powerful component for transformation, and (b) we already translate "law and rules into code" every time we create a new or change an existing application or digital service to support a new or updated policy, benefit or other public service.

Numerous software systems, digital services, and operational procedures embed compliance directives, decision-making, and other rules in programming code.

However, we usually do it the wrong way, thus creating immediate and strategic problems for citizens and other stakeholders, as well as for governments and public servants.

Here are some of the core challenges(6) we see because of ad-hoc and opaque approaches to translating policy and laws into programming code:

• Interpretation chaos — Translating law into software code requires several interpretations by different teams, inevitably creating complexity and unintended consequences.
• Limited transparency — "Interpretation chaos", along with the fact that rules are written in programming code(7) and, often, released as proprietary software, create so-called black-box algorithms(8) which hinder explainability and validation.
• Fragmented knowledge — Each "policy to software" project uses an ad hoc and/or proprietary approach to analyze and algorithmize the relevant rules, which makes it enormously difficult to share knowledge within and between policy teams.
• Blurring of compliance and process rules—Ad hoc and/or proprietary RaC compliance rules get mixed with process specifics, hindering systems' ability to work together effectively and adapt to change quickly and efficiently.

What is the core issue?

As mentioned earlier, the main problem lies in the multitude of ad hoc and/or proprietary RaC approaches used for projects that require translating legal rules into software rules.

When designing and creating software to support a particular benefit, rebate, incentive, or other policy, we see the relevant legal documents and the software per se(9).
 

However, we often overlook or never see the intermediate analyses, formalizations, and algorithm assumptions that legal experts, software analysts, and developers collaborated on throughout the project. This process stage is the heart of any software, and the opaque way it is performed is a core problem in today's "policy/law to digital service" projects and, even more so, a serious impediment to government transformation(10).

The lack of a standard and transparent middle layer between policies/laws and production-grade software creates and propagates problems for governance and change management, impedes digital service innovation, and hinders government transformation.

Unfortunately, as mentioned earlier, most government digital services are designed and produced using obscure analysis and formalization middle layers with little to no rule governance frameworks. A good guess is that this is due to mainly three reasons:

1. Political and administrative leaders worldwide either do not recognize or underestimate the benefits of transparent, standards-based RaC analysis and formalization.
2. Vendors can use the tools they already know to work on and deliver "policy/law to software" projects more easily and quickly.
3. It's also easier for each team (legislative, administrative, process, development) to pass a task to someone else with little or no follow-up and let the other side deal with it.

While convincing government leaders and vendors to adopt a standard RaC middle layer(11) is achievable, the more significant challenge is redesigning and implementing a more open and collaborative "rules as code" production process.

Like most transformation projects, the challenge often stems not from technology but from people and processes. To state it more precisely, this issue is anchored in organizational sociology, and a beneficial approach to addressing it involves applying Donella Meadows’ systems-thinking principles(12).

Toward Open RaC approaches

Before we discuss applying systems-thinking principles to design and operate an "Open RaC approach," we should give a working definition of what it looks like(13).

An Open RaC approach:

1. A transparent, standards-based middle layer should be employed for (a) analyzing, interpreting, and validating rules derived from a given law and (b) formalizing, algorithmizing, testing, and verifying those rules before they are committed to production-grade software(14).
2. It could also (a) be based on open-source software code and RaC-specific libraries (such as OpenFisca) and (b) employ more formal change management and governance processes.
3. Finally, an Open RaC approach could (a) provide open sharing of formalized/algorithmized rules and (b) access to an open RaC API.

Now that we have a working definition, let's see how we can apply systems-thinking principles to design and operate an Open RaC approach for all our "policy/law to software" projects:

The first step is determining a "leverage point(15)," where minor changes can significantly impact speed and quality.

• The leverage point for most RaC-based projects lies in the middle layer (between policy/law and working software), specifically in the formalization and algorithmization stages.
• This is where we can reduce interpretation chaos and potential errors downstream by catching and preventing interpretive mismatches early.
• In Meadows's terms, this changes the information flow and tightens feedback loops so that each stakeholder sees and validates how policies and laws become algorithms.

The second step is to use powerful, usable, inclusive, and standards-based "boundary objects(16)," which are artifacts or frameworks that multiple groups (lawyers, coders, analysts) can all use without losing their separate domain perspectives.

• These artifacts and/or frameworks must be powerful enough to express rules, decision-making criteria, formulae, terms, vocabularies, and compliance-related processes that stem from relevant policies and laws.
• They must also be as usable and understandable as possible for all individuals, regardless of their domain expertise and/or team affiliation.
• Finally, boundary objects must be based on open standards for anyone to learn and use.

The third step is instituting an overall governance process and structure to validate interpretations and assumptions, handle required changes, and ensure that rules and working software are deployed and tested for full compliance at all times.

• The critical aspect is to keep relevant policy/legal "owners" in the digital service implementation loop so that they are ultimately engaged and accountable for all compliance-related decisions and testing.
• It is also essential to make the tasks mentioned above as simple and automated as possible because policy and legal experts are not expected to be technology savvy, let alone developers. They should, for example, set the basic requirements for compliance testing and be the ones to accept (or not) the results, but should not be expected to define and write them.

Summary

By embedding compliance in digital systems, RaC can enable faster innovation, enhance transparency, and build trust among governments, citizens, and businesses. Nonetheless, current methods for converting policy to code face inefficiencies and challenges.

Today’s approach to implementing laws and rules in digital services is essentially ad hoc, resulting in significant challenges:

• Interpretation chaos arises when multiple teams interpret policies differently, leading to inconsistencies and unintended outcomes.
• Fragmented knowledge compounds the problem. Each project follows its own methods, making it nearly impossible to share rules and insights across teams.
• Compliance rules are frequently interwoven with operational processes, reducing systems’ flexibility to adapt and collaborate effectively.
  Misaligned interpretations of legal directives lead to service disruptions, while the lack of standardized approaches stifles collaboration and adaptability. This wastes resources and impedes governments’ ability to evolve in response to societal needs.

An Open RaC approach can help alleviate the problems by providing a transparent, standards-based framework for systematically analyzing, formalizing, and validating policies and laws before implementation.

Furthermore, structured governance processes involve policy owners throughout the development lifecycle, ensuring accountability and compliance.
RaC is more than a technical solution—it’s a strategic imperative for creating efficient, equitable, and adaptable public services.

Footnoots: 

1. Key values include Compliant, Consistent, Adaptive, and Explainable. Additionally, the FAIR principles—Findable, Accessible, Interoperable, and Reusable—also relate to information sharing about rules. It’s crucial not only to establish and uphold these values in agreements but also to implement processes for correcting mistakes and facilitating continuous improvement, incorporating feedback during both design and operational phases.
2. For example, only applied locally and internally within single organisations.
3. In this context, machine-consumable goes beyond the traditional "readable" and "parsable" formats to mean that once ingested, it is also immediately "semantic" and/or "executable" by a given software.
4. RaC can also support other parts of the policy life-cycle, including the analysis and design phases (e.g. deliberation, simulation, etc.).
5. Ad-hoc and/or opaque RaC approaches deny the public & government of remarkable transformation potential. — RaC can drive multiple benefits for citizens, businesses, and other stakeholders, as well as for the government and public sector organizations that utilize such approaches correctly. By providing an official source of coded rules, it becomes possible to understand and track how those rules are embedded and used, making them visible and trackable. RaC also enables rules to be more easily discoverable and decipherable.
6. See "The thing with the rules" blog post for more.
7. Rules and algorithms expressed directly in software are incomprehensible to non-programmers.
8. In this context, we mean both traditional software algorithms and those employed for AI applications and services.
9. For rules to work well together, it’s important to clearly explain how they relate to the agreements they are based on, including how these rules were created and why. This information is often missing from the rule’s metadata, which can make it hard to reuse, connect, or maintain the rules. Thus, traceability is crucial. However, it’s important to find a balance in how much detail is provided, and standardization can help keep things clear without becoming complicated.
10. Imagine the multitude of policies and laws supported by software and other digital services to understand the strategic scope of not having a standard and open way to analyze, formalize, and validate compliance and process rules.
11. In this context, a middle layer includes processes such as analysis, algorithmization, interpretation, validation, and governance of rules derived from relevant legal documents.
12. Donella Meadows’ principles of systems thinking focus on comprehending complex systems by acknowledging the interconnections, feedback loops, and leverage points within them. She emphasizes the significance of stocks and flows, delays, nonlinearity, and self-organization in determining how systems behave. Important takeaways include prioritizing relationships over isolated components, accepting uncertainty, and pinpointing high-impact interventions that can lead to significant change. Her work promotes a holistic and dynamic viewpoint, urging for adaptive, long-term strategies instead of seeking quick solutions.
13. Please note that this is a work-in-progress, not an authoritative, definition of an Open RaC.
14. This layer should help document ongoing analysis, interpretation, and formalization through formalized metadata. It aims to support collaboration and allow for correcting, changing, and improving processes during operationalization.
15.  Leverage points: In complex systems and organizations, identifying small changes that produce outsized impacts (e.g., introducing transparent data-sharing or cross-functional teams) can address sociological friction—like poor communication or territorial behaviors.
16. Boundary objects (or artifacts) in systems thinking are a way to address system complexity by improving connectivity and collaboration; they insert a new structure that helps teams self-correct or reorganize more transparently.