Rule as Code in the Age of LLMs: From Consensus to Execution
How RaC pioneered consensus-as-code, why it was both visionary and limited, and how LLMs push the paradigm toward a hybrid future.
If laws are society’s source code, can they be modeled, tested, and deployed like software? This provocative question has haunted legal engineers, policy-makers, and technologists for decades. Rule as Code (RaC) was the first serious attempt to give an answer.
RaC proposed that rules—whether laws, policies, or institutional regulations—should not exist only as text open to interpretation, but also as machine-executable logic. In its most radical form, RaC imagined a world where welfare eligibility, tax compliance, or regulatory enforcement could be encoded into decision engines that run like software systems: testable, auditable, and deployable. Instead of endless interpretive debates about what a law “really means,” the law could be expressed directly as a program, complete with test cases and version control.
But RaC was conceived in a very specific era: a pre-LLM world. At the time, natural language processing was too brittle to handle the complexity of real legal or policy texts. Ambiguity had to be eliminated by design. This is why RaC invested so heavily in deterministic standards: DMN for decision tables, SBVR for business vocabularies, LegalRuleML for statutory logic, domain-specific languages for tax, health, or finance. The goal was not just automation—it was precision. If the machine couldn’t “understand” ambiguity, humans had to painstakingly translate consensus into code.
This made RaC both visionary and limited. Visionary, because it introduced a new paradigm: consensus as something that could be compiled. For the first time, rules were treated like software artifacts, subject to lifecycles, testing, and deployment pipelines. But limited, because the process was heavy, expert-driven, and slow. Few RaC projects moved beyond pilots. The cost of modeling laws into code was enormous; the political and institutional buy-in was fragile.
Now, the landscape has changed. Large language models (LLMs) have rewritten the boundaries of what is possible. Suddenly, machines can parse natural language at scale, extract rule-like structures, and even generate executable representations. What once required months of human modeling can now be bootstrapped in hours. The tension is obvious: RaC’s original vision assumed deterministic, hand-crafted modeling; LLMs offer probabilistic, data-driven interpretation.
This is why RaC looks today both prescient and incomplete. Prescient, because it foresaw the need to treat rules as executable primitives, not just paper artifacts. Incomplete, because it imagined only one path to get there: formal logic. The rise of LLMs shows that another path exists: probabilistic interpretation, capable of scaling in ways RaC’s original frameworks could not.
The future may not be about choosing one or the other. Instead, the next paradigm is likely to be hybrid: RaC providing the deterministic backbone of legitimacy—clear, auditable, verifiable rules—while LLMs provide the interpretive muscle—scaling discovery, usability, and reasoning. RaC gave us the first glimpse of “consensus as code.” LLMs remind us that consensus is also fuzzy, contested, and evolving. Together, they point toward something larger: not just automating rules, but building the runtime of civilization itself.
Why RaC Matters: From Consensus to Execution
At its core, rules and policies are the language of consensus. When a society agrees that “contracts should be honored,” “data privacy matters,” or “AI must be safe,” these shared values are encoded into laws, regulations, or institutional rules. Rules are how consensus is written down. But for most of history, rules have lived as text—in statutes, policy papers, or organizational handbooks. They are interpreted by humans (judges, regulators, administrators), debated in context, and executed unevenly.
This textual nature makes rules inherently ambiguous. A sentence in legislation may be read differently by different stakeholders. Two regulators may interpret the same clause in opposite ways. Enforcement is inconsistent; auditing is complex; compliance costs are enormous. In short: consensus expressed as text is fragile and inefficient.
Rule as Code (RaC) is the first serious attempt to change this paradigm. It asks: What if rules could be expressed in a format that machines can read, test, and execute—while still being legible to humans?
RaC is not about “legal automation” in the narrow sense of replacing lawyers with software. It is a methodology that aims to compile consensus into code. Instead of a rule being only a paragraph in a policy document, it is also a piece of executable logic in a decision engine. Instead of leaving compliance entirely to human interpretation, rules can be tested like software, audited for consistency, versioned, and deployed in real time.
Concretely, RaC involves:
Identifying rules from legal or policy texts.
Modeling them in formal languages or notations (like DMN, SBVR, or LegalRuleML).
Encoding them into decision engines or DSLs (domain-specific languages).
Validating them to ensure “the code = the rule.”
Deploying them so that compliance systems, apps, or government platforms execute them consistently.
Why does this matter? Because it tackles one of the most pressing problems of modern governance: the gap between consensus and execution. When rules are only text, the chain is fragile: lawmakers write → agencies interpret → organizations implement → auditors review. Every step introduces ambiguity and delay. RaC compresses this chain. Consensus, once agreed, can be modeled, tested, and executed in near real time.
Imagine:
Tax rules codified directly into a public decision engine, so taxpayers and auditors both rely on the same logic.
Welfare eligibility calculated instantly through transparent, published code that anyone can audit.
Climate regulations encoded into industry compliance systems, automatically flagging violations.
In each case, RaC does not replace the political process of reaching consensus—it translates the outcome of that process into an executable form.
The key idea: RaC is not “legal automation”; it is consensus compilation. It treats consensus as the primitive input, and code as the runtime output. In doing so, RaC opens the door to a new paradigm in both rule execution and computer engineering: a world where the boundary between social agreement and executable logic becomes porous.
Why RaC Matters: From Consensus to Execution
At its core, rules and policies are the written form of consensus. When societies agree that “contracts must be honored,” “taxes must be paid,” or “privacy should be protected,” these values are encoded into legal texts, regulations, and institutional policies. In that sense, law is society’s source code. But unlike machine code, this “source code” has always been written in natural language: statutes, clauses, policy papers, regulatory notices.
That creates a fundamental problem. Text is inherently ambiguous. One clause can be read differently by regulators, lawyers, judges, and citizens. Rules can conflict across jurisdictions or even within the same document. Compliance becomes costly, interpretation inconsistent, and enforcement unpredictable. In other words, the chain between consensusand execution is fragile.
This is the gap Rule as Code (RaC) was designed to bridge. Emerging from legal informatics and e-government experiments in the 2010s, RaC proposed a bold shift: instead of leaving rules purely as text, why not express them directly as executable logic? A tax rule could exist both as legislation and as a snippet of code in a public decision engine. Welfare eligibility could be tested against a set of machine-readable rules that anyone—citizen, auditor, or government—could query.
The goal was not to replace lawmakers or lawyers, but to compile consensus into code. RaC framed rules as artifacts that could be:
Tested, to ensure consistent interpretation.
Audited, so that anyone could verify whether the execution matched the intent.
Deployed, as APIs or rule engines that plug directly into digital government platforms or enterprise systems.
A Short History of RaC
RaC was shaped by earlier efforts in standards and formal modeling:
DMN (Decision Model and Notation, 2014): Standardized how decisions could be represented in tabular form, bridging business rules with execution engines. Widely used in finance, insurance, and government systems.
SBVR (Semantics of Business Vocabulary and Rules, 2008): Developed under OMG (Object Management Group), it aimed to give organizations a precise, machine-processable way to express business rules while still being human-readable.
LegalRuleML (2013): An OASIS standard that extended RuleML to handle the complexity of legal norms, including obligations, permissions, exceptions, and temporal aspects. It was one of the first attempts to encode the subtleties of legislation in a machine-processable format.
DSLs (Domain-Specific Languages): From taxation to healthcare, DSLs were designed to let experts encode rules in highly specialized syntaxes, ensuring that critical policies could be executed deterministically.
All of these initiatives shared one assumption: machines could not “understand” natural language reliably. Therefore, rules had to be painstakingly translated by humans into deterministic, formal logic. RaC inherited this worldview. It treated ambiguity as a bug to be eliminated, not a feature to be managed.
RaC Before LLMs
This context is critical. RaC’s origins were pre-LLM. It was designed in an era when AI was brittle, symbolic, and incapable of parsing the full messiness of law. If rules were to be machine-executable, they had to be handcrafted into precision standards.
This made RaC both visionary and constrained. Visionary, because it reframed rules as executable artifacts rather than static texts. Constrained, because it required massive expert labor to encode even small parts of a legal system, and struggled to scale beyond pilots.
Today, with LLMs rewriting the boundaries of natural language processing, RaC looks both prescient and incomplete.Prescient, because it anticipated the need to treat consensus as something executable. Incomplete, because it assumed determinism was the only path.
The future may not be deterministic or probabilistic, but hybrid: RaC providing the formal backbone of legitimacy and auditability, while LLMs provide the probabilistic interface and reasoning needed for scale and usability.
Conclusion
Rule as Code was never just about automating law—it was about rethinking what rules are. In a pre-LLM world, RaC showed us that consensus could be compiled: transformed from ambiguous text into precise, executable logic. It was a radical idea, backed by deterministic standards like DMN, SBVR, and LegalRuleML, that imagined rules as software artifacts—testable, auditable, and deployable.
But RaC’s very assumptions—determinism, handcrafted formalisms, expert-driven encoding—also limited its reach. Most projects never escaped pilot stages, and the labor of translation proved too heavy. That was its paradox: prescient in vision, incomplete in execution.
With large language models, the boundaries have shifted. Machines can now parse and generate legal-like structures directly from text, offering a probabilistic complement to RaC’s deterministic backbone. Where RaC promised auditability and legitimacy, LLMs offer usability and scale. The next paradigm is not about choosing one or the other, but about combining them: RaC as the hard spine of formal rules, and LLMs as the soft muscle of interpretation and reasoning.
Together, they point toward something larger than legal automation. They gesture at the possibility of consensus-as-code—a future in which social agreements, once reached, can be compiled into systems that are both verifiable and adaptive. This is no longer just about bridging law and software. It is about building the runtime for civilization itself.
