Does Structural Isomorphism Matter?

I’d like to get people’s thoughts on structural isomorphism, which is the best name I have come up with so far for the following idea:

When encoding legislation, it is better if there is a 1:1 correspondence between the smallest possible sections of code, and law.

Here’s my argument in favour of tools that maintain high structural isomorphsim between laws and encodings. This is based on intuition more than evidence, so think of this as a “weakly-held view strongly stated.”

First, if I am working on encoding a piece of legislation, structural isomorphism means I can go section by section through the legislation, and encode each section one at a time. That makes it easy for me to know what I have and have not encoded. It also makes it easier to divide up the labour of doing the encoding, making the task more scalable. If the entire act is going to turn into a single function, for example, then really only one person can do the work, and it’s harder for them to track what they have and haven’t taken into account.

Second, if the legislation changes, finding the places that it is necessary to make changes to the encoding is simplified. Just find the corresponding section of code, and change that. If a section was added to the law, just add a section to the code. If a section was repealed, delete the corresponding code. Particularly if you are trying to amend an encoding that was originally done by someone else, this seems like a big deal.

Third, tools that are structurally isomorphic inherently have information about the structure of the law, in addition to its meaning, and can use that structure in things like user-facing explanations (“this answer was calculated on the basis of section 3”), or to facilitate other language features like scoping (“for the purposes of this part…”), or defeasibility (“despite section 3, and subject to section 5”).

Fourth, structurally isomorphic encodings are easier for non-programmer subject matter experts to review for accuracy, because they know what meaning each small section of code is trying to express - the meaning of the corresponding section of law. That also allows the task of quality review to be divided among multiple subject matter experts in a way that wouldn’t otherwise be possible, increasing the scalability of doing encodings.

Fifth, the smaller the parts that correspond with one another, the greater the likelihood that we could use good structurally isomorphic encodings of legislation as a rosetta stone to train machine learning tools to “translate” between legislation and semantic encodings of that legislation. That in turn potentially makes semantic encodings of legislation exponentially more scalable. (This isn’t 100% hypothetical. A friend of mine with access to GPT3 tried it for me once, and the results were generally bad (very small training set), but also promising.)

The downside of structural isomorphism in encoding laws is basically that you have to use languages that support it, and they are all (as far as I am aware) based on logic programming. I’m a huge fan of logic programming, but I readily acknowledge that most people have never done it, so the supply of people who know how to do it is much smaller. Pushing people into a new technological paradigm is risky and costly, and creates change management problems. So whether or not using structural isomorphic tools in any given use case is “worth it” is an open question that would need to address other practical factors.

But in an imagined world where there was a structurally-isomorphic Rules as Code tool that was affordable and easy to learn, do you think those benefits would hold? Do you think they would matter? Are there any other downsides?

  • It matters!
  • It doesn’t matter.

0 voters