When would you use a RaC approach?

Firstly, it is worth saying that there are, broadly speaking, two types of rules (leg/reg or otherwise): prescriptive and judgement-based.

Prescriptive rules are definitive. For example rules that set thresholds, objective requirements, are numerical or otherwise are not very subjective. Prescriptive rules are not meant to require judgement, but in reality a little interpretation is almost always needed. For example, does “must be over 18” mean from midnight that day, or the end of that day, or from 0+18 years, or 0+17 years, like in countries where people are conssidered 1 at birth versus 0 at birth. In any case, prescriptive rules are most suitable for RaC systems because they help assure consistent application of a rule which is meant to be consistently applied.

Judgement-based rules are ones that require someone accountable to make a judgement. Whether in regulation or legislation, there is a person defined who is directly accountable for the judgement made, which means you should try to preserve the ability for an appropriate person to make a judgement, rather than automating or codifying these rules. Over time judgements accrue, which can provide patterns you can encode, such as “if you meet criteria x, y and z, then the judgement is likely n”, but often judgement-based rules are meant to assure actual human judgement, therefore these types of rules are less appropriate for RaC.

There are three key use cases for creating a Rules as Code repository as part of your stack/system:

1. When you need to demonstrate compliance to laws (regulation, legislation) - for instance you may run software for financial institutions, or a company needing to demonstrate environmental compliance, or you are a government department needing to ensure legality of decisions made in your systems (to be compliant to Administrative Law). In any case where you need to demonstrate compliance, it isn’t enough to say “we have a compliant system”. You need to be able to trace your actions or decisions back to which rules they are compliant with. You can either do this manually, with an army of compliance officers verifying outcomes against the law (which is both expensive and subject to human error or inconsistency), or you can build proactive explainability and compliance into your software. Having the rules you need to comply to available as a utility provides a simplified way to to consume and test against those rules, otherwise compliance becomes a very expensive business, whether in legislation or regulation.
2. When you need to incorporate rules into how your system/service operates - for instance if you want to build a service to help people understand their eligibility to government services, or if you want to create automation of reporting based on regulated triggers (eg, transactions over $10,000), or if you want to create a personalised experience for someone based on rules defined in law or by your organisation. Having rules as a utility helps you ensure you can consume and test against rules without muddying the water with operational policies or system constraints.
3. When you want to design new rules, such as regulation or legislation - Rules as Code helps you model the impact of change from current status to new, and helps you understand the impact more broadly when intersecting with other legislation/regulations. Rules as Code provides a way to run demographic or other bulk data against proposed changes to see whether intended impacts would likely be met, and to identify unintended impacts. It also provides a way to then monitor and measure impact (policy and human) over time, and feed into an interative and agile approach to policy management over time.