Rules as Code, ?, Profit

Long time no blog! There have been lots of big, exciting changes to Blawx over the last while. I’m now working on getting the documentation caught up. When that’s done, I promise I’ll come back and do a big post about Blawx.

Today, I just want to talk about an idea I’ve been developing over the last few days.

What’s Phase 2?

When we talk about Rules as Code, we tend to talk in abstract terms. We say “you encode your rules, and you get these benefits.” This is like the gnomes from South Park who say

Phase 1: Steal Underpants
Phase 2: ?
Phase 3: Profit

So I’ve been working on trying to be clearer in how I talk about Rules as Code, and to speak about concrete steps that you can actually take with tools like Blawx, and how those concrete steps get you the purported benefits.

Here’s the story I’m telling.

Practical Rules as Code

  1. Encode your interpretation of the legislation. When this becomes difficult, investigate why:

    (a) Is the problem in your code? Fix the code.

    (b) Is there a bug in the legislation? Fix the legislation.

  2. Encode your expectation of how the legislation behaves as tests. When the tests give unexpected results, investigate why:

    (a) Is the test incorrectly written? Fix the test.

    (b) Is your expectation incorrect? Fix the test.

    (c) Is there a bug in your encoding? Fix the code.

    (d) Is your interpretation of the legislation incorrect? Fix the code.

    (e) Is there a bug in the legislation? Fix the legislation.

  3. When the tests succeed:

    (a) Publish the code and let people build apps with it.

    (b) Use the code to do simulations. If the simulations give unexpected or undesired results, investigate why:

        (i) Is the simulation faulty? Fix the simulation.

        (ii) Does the legislation not implement the policy? Fix the legislation.

        (iii) Does the policy not have the desired outcomes? Fix the policy.

How Does Rules As Code Improve Legislative Drafting?

Rules as Code improves legislative drafting by giving you information you can use to improve your legislative drafting at phases 1(b), 2(e), and 3(b)(ii).

When you are in phase 1(b), the sorts of legislative bugs that tend to become visible are syntactic ambiguities, unintentional semantic ambiguities, contradictions, and under-specifications. When you are in phase 2(e), the sorts of legislative bugs that come to light also include unintended consequences of complex interactions between different rules. In phase 3(b)(ii), you can find evidence that the legislation does not achieve the policy objective.

How Does Rules as Code Improve Application Development?

At phase 3(a), you have reliable, executable representations of your legislation that can be re-used across multiple applications. Depending on the technology that you used to do the encoding, some of those applications include:

  • The simulations used in 3(b).
  • Automated legal services
  • Data analysis on the legislation
  • Legal analysis on the legislation
  • Automated compliance-checking tools
  • Automatically generate software tests for legal conformance in other software
  • Tools to check whether legacy and replacement systems have identical legal reasoning
  • Process automations
  • Visualizations
  • Available move inputs for zero-shot game learning systems, to discover dominant strategies
  • etc…

That you can build these things is not where the value arises. All of them are already possible. The unique value of Rules as Code is that all of these things can be built on the basis of the same encoding. There is a reduction in the duplication of effort, and an improvement on the inconsistency of interpretation and implementation that exists now. And that benefit is magnified the more frequently the rules change.

How Does Rules as Code Improve Policy Design?

At phase 3(b)(iii), you can learn from simulations that your legislation does not achieve the intended policy outcomes, or has unintended and undesired policy outcomes, and find a different policy intent, and different legislation, that achieves the outcomes better.

What’s Next

This is a work in progress, so I’d be interested in any feedback you might have. It is also written in what I hope is a technology-agnostic way, with the exception of the list of types of applications that your code can support.

Part of the reason for creating Blawx is to make it possible to demonstrate these processes. Today I did a demo for the Canada School of Public Service in Blawx that covered all of phase 2 and 3(a). That demo could be expanded to cover Phase 1. And Blawx can be improved to make it easier to demonstrate 3(a), and make it possible to demonstrate 3(b).

Those will probably be the feature design priorities going forward, once I’m done writing documentation and testing the version we have now.