Ever since the adventing of computing, there has been lots of different pushes to be able to "compute" the law. The benefits are very clear and simple, code is verifiable and, in a certain way, enforceable. But most of all, code connects with code, which connects with code, in a eternal chain to achieve goals once thought impossible.
The Crypto ecosystem got their own take on it: Smart Contracts. Unfortunately, a real world contract is not like a Smart Contract, it's not exactly deterministic, if this then that. It is diffuse, complex, and based more on "rules" that are not meant to be broken, but to be "reasoned" with.
Let's take this article from a fictional Income Tax law as an example:
1. The income tax for an individual is defined as a fixed percentage of the individual's income over a year.
2. The fixed percentage mentioned at article 1 is equal to 20%.
3. If the individual is in charge of 2 or more children, then the fixed percentage mentioned at article 1 is equal to 15 %.
On the law, there isn't a flow, from one to another. It looks like code, but it isn't. But, we could express this logic in this python-like language:
define income_tax:
with entity individual as i:
rule amount:
count(i.children) >= 2 => 15%
_ => 20%
consequence i.income(now.year) * amount
This fantasy programming language encodes everything we need to know from the law, both for ourselves and computers. But, as it is, it doesn't help us too much.
Enters PLANNER Programming. Very much like Prolog and other logic programming languages (for my fellow nerds out there), it optimizes to gather a series of facts, and infer a conclusion from it. Usually this means yes or no, but Planner programming languages like Picat went a lot further with it, allowing us to deduce a path with a goal of either minimizing cost/steps, or minimizing/maximizing a variable.
This seems complex, but let's add another rule to our tax code:
4. Individuals which donate 10% of their income every month to private charities have their fixed percentage set 2-basis points lower.
Becomes something like this definition:
define income_tax:
with entity individual as i:
rule fixed_amount:
count(i.children) >= 2 => 15%
_ => 20%
rule amount:
i.donation(now.year) >= i.income(now.year) * 10% => fixed_amount - 2%
_ => fixed_amount
consequence i.income(now.year) * amount
Each of those rules have costs, which are factored in the consequence. Taking this rule, we assign a "cost" for each action.
We assume then that the yearly cost of having each child is 10% of the individual yearly income, for 2.5 basis points removal in income tax, or donating 10% for 2 basis points less.
So, to minimize tax, we only need to know one constraint, how many children the user is willing to have.
This is a very simple example, with only one constraint. Another article can add not one, but an exponential number of different rules that iteract with different ways, with different costs.