Blawx Development Update and Other News

It’s been a while since I did a blog about the changes to Blawx, so let’s get you caught up!

Spans

For reasons that will be clear shortly, we needed a way to delineate and name parts of a paragraph of text. So I made some changes to CLEAN so that you can use the following format to be able to treat spans of legal text as though they were a sub-part of the law. The format looks like this:

Bird Act

1. Penguins are birds.
2. If a thing is a bird, it flies, [penguin]{unless it is a penguin}.

That code will generate sections named BA, BA 1, BA 2, and BA 2.penguin, each of which can be selected in the navigation window, and referred to in the interface.

Exceptions

Exceptions are critical to maintaining the one-to-one relationship between small chunks of law and corresponding chunks of code. Laws use defaults and exceptions all the time, and if you Rules as Code tool doesn’t know how to deal with them, you are going to have to take multiple parts of the law and combine them into a single piece of code. That’s going to make everything harder for your users, but in particular it makes the resulting code much more difficult to maintain when the rules change.

We now have defaults and exceptions implemented in Blawx. If a section of law reaches a conclusion “defeasibly” (that is, subject to contrary conclusions elsewhere), you can use the “according to” block in order to say what conclusion is reached and by which section. A new Rule block with an “according to” block pre-filled with the currently-selected section of law has been added to the Primary drawer of the toolbox, to ensure this requires no additional work.

Then, if two sections reach opposing conclusions, you can use the “overrules” block to indicate which of the two sections should get priority. Importantly, this block can be put anywhere in the code, which means you can accurately reflect the difference in placement of “despite” and “subject to” statements in legislation.

If it’s not obvious that two conclusions oppose one another, you can make it clear to the reasoner by using the “opposes” block.

Finally, there is a “holds” block, that allows you to query whether a defeasible conclusion was found to be true, and not defeated by any other rule. Again, a new question with the holds block included has been added to the Primary drawer, so that using the defeasibility method requires no additional work except for setting out the “overrules” blocks.

The current method of determining whether or not a rule is defeated is very simple, but it will be made more sophisticated in future versions.

Why did we need spans? Sometimes, the default and the exception appear in the same section. In the Bird Act example that comes with the new version of Blawx, based on the statute text above, section BA 2.penguine overrules section BA 2. We needed to give section BA 2.penguin a name to be able to say that.

Explanations

A lot of changes have been made to how explanations are displayed inside the tool. The first is that rather than returning a list of “models”, Blawx now divides the results into a numbered list of “Answers”, with each answer having one or more “Explanations”. The Answers now also explicitly display the bindings that were used in that answer - the value that was found for each of the variables in your question.

Explanations are now also displayed as a collapsible tree, making them easier to read, and allowing the user to navigate to the part of the explanation that is relevant to them without being confronted with a wall of text.

Legislative Text in Explanations

When the name of a section appears in an “according to” entry in an explanation, Blawx will now translate the name of the section from it’s machine-readable ID to a human language name, and link the name. The link doesn’t go anywhere, but if you hover over the link it displays the text of the section of the law that was referred to in the “according to” block.

In this way, the natural language explanations now refer back to the legislative text from which the encoded rules were derived.

It’s possible to expand this capability further, but the point, for now, is to demonstrate the ability to link the explanations to the legislative text that was used in generating them.

Examples

I have expanded the Rock Paper Scissors example, re-added the Mortality example, added the Bird Act example to demonstrate defaults and exceptions and spans.

Work has also started on a Rule 34 example. It is based on code I wrote in a project undertaken at Singapore Management University Centre for Computational Law last year. The project used s(CASP) to debug a small piece of legislation. I’m hoping to be able to recreate that experience in Blawx, to show how it can be used for legislative drafting tasks.

API Changes

All of the changes to explanations required changing the format of the data that is returned by the API version of a Blawx test. Implementing links to statutory text also involved the creation of a new API end point that allows you to grab either the plain-text or Akoma Ntoso representation of a named section of a rule, for use in explanations and anywhere else you like.

Video Demo

All the things discussed above are shown in this video. Remember that you can click on the gear icon and play it at a higher speed to make it shorter.

Acknowledgements

I ran into a problem that made some of the tests in Blawx appear as though they were going into an infinite loop. In fact, they were only failing to display the results. The problem was complicated, but in the end there was a bug in my code, and a feature missing from a SWI-Prolog library. Thanks to Jan Wielemaker and Eric Zinda for help in diagnosing and resolving that problem.

What’s Coming Up?

In the near term, I’m going to be continuing to implement the Rule 34 demonstration, adding dates as a datatype, and modifying the format used when submitting data to the reasoner over the API, to make it more user friendly.

Once those things are done, the next challenge is to automatically generate user-facing interviews on the basis of a Blawx test.

Other News

Blockly Conference

I had the absolute pleasure of attending the Blockly Summit 2022 and doing a lightning talk on Blawx while I was there. I learned a lot from the various people using Blockly, in particular a number of ideas that will be directly applicable when it comes time to generate tutorials and other training material.

yscript

DataLex is currently the best tool in the world for demonstrating the power of Rules as Code. Unfortunately, it has not been a viable option for deployment in a lot of scenarios because it was not publicly available. I’m delighted that just today, I received, by email, source code for yscript the coding language that powers DataLex.

I’m hoping that the availability of yscript will increase the options that are available for real-world deployment of Rules as Code. More personally, I’m hoping to learn from what they did in terms of the API for powering expert systems online, and see if those lessons can be applied to Blawx.

I understand that a public repository is en route, but if you are looking for source code in the mean time, I can point you in the right direction.

Canada School

I have been continuing to work with the Canada School of Public Service on their Rules as Code projects, and have been targetting Blawx development at the needs of some of the projects currently under consideration at the school.

It has been very rewarding to, in the last few weeks, be able to screen share Blawx with technologists in the government, and do a quick demonstration of what it is, and how it works. Usually, peoples’ eyes light up when you demonstrate that every “test” in Blawx is also an API endpoint that can be used to automate any number of other tools.

There is still more to learn than we know, but CSPS is committed to learning it, and I feel extremely lucky to be along for the ride.

Conversations continue with departments on other possible Rules as Code projects, and I’ll pass along details when I can.