Hi folks
The upcoming AUSCL Masterclass (June 2021) will be focusing on OpenFisca, which is an open source rules engine based on the Python programming language.
We would love to hear your thoughts and questions about current OpenFisca projects, its use cases and its community!
Discuss!
[Some additional background on OpenFisca]
Who is using it?
Coincidentally, I just tried to find examples of what isomorphism looks like in OpenFisca, especially where there are exceptions or exclusions in other parts of the legal text. Anyone know of any good examples of this to look at for OpenFisca?
@ram_parameswaran any ideas for @markstaples ?
Thanks @markstaples, this is a really good question!
I think there are two morphisms to consider here:
On 1) Iâve gone back and forth in my mind about this. I think that due to the language-specifics of OpenFisca, creating a clause-by-clause mapping from the policy text to code is inadvisable. It becomes unmanageable for sufficiently complex policies, where it actually reduces readability and transparency.
Rather, I think that an âapproximately isomorphicâ mapping from policy to code is sufficient for readability, maintainability and transparency.
On 2) The important thing here is proving that the output of the code is equivalent to the policy intent, and this is ultimately what the OpenFisca test suite does. In fact, I think this is where OpenFisca really excels; in its ability to empirically demonstrate that, for given inputs, certain outputs are reached.
This is a really complex problem space! And I think this question really separates the various rules engines into their respective use-cases.
Thanks Ram. Q2 I see as functional validation - and personally I care more about checking that the code will give the same answers as what a judge would eventually say about the law, rather than whatever the original policy intent might have been. But this issue isnât really tied to language features - instead it depends more on the specific model/code you write.
My inquiry was more about your Q1. I agree you can have various levels of granularity of isomorphism, supported differently-well by different languages. I think one of the huge benefits of the isomorphism (at some scale, perhaps clause level) is that it facilitates scalable modeling of large bodies of law. The key for this is how exceptions and exclusions in the law are handled in the code/model.
How does OpenFisca do that? I canât find examples. Is it just normal programming techniques like nested if-then-else, where you need to put all of the general and special cases together in one place in the code?
It is indeed normal programming techniques where you need to collect all the validation logic together in one function. See this example from an OpenFisca implementation of the NSW Community Gaming Regulation 2020. Itâs not exactly âexceptions/exclusions from other parts of the legal textâ, but it demonstrates the approach.
Iâll chime in with a first impression when checking the Open Fisca system - really clever in how it models the executable interpretation - very impressed. It is however optimised for rules where parameters change frequently or are time bound. In my field of Urban planning this isnât the case and it therefore adds a lot of overhead. The people at Wellington City Council didnât use it for their resource consent checker, from memory this was one of the reasons.
Really glad to see someone other than me asking this question, Mark. 
Isomorphism is so important.
Thanks Jason - I agree! Isomorphism is helpful for validation, maintainability, and traceability, but I think itâs critical for scaling to create and manage large models - both big legal texts and also multiple interdependent legal texts. On the other hand, if youâre just modeling a small piece of legal text or if you are doing law that doesnât have a lot of exceptions and exclusions, youâll probably get away without it.
However, one complication for isomorphism is that it might not neatly interact with predicate logic if you need that to model multiple instances of things in a uniform way.
Iâd love to understand better what you mean about not neatly interacting with predicate logic, because that hasnât been my experience. What sort of issue are you anticipating?
Maybe I just havenât seen a good example of it yet. Would love to be shown The Way!
With predicate logic you want to quantify over things (like, to calculate minimum, maximum, average, distributed conjunction/forall, distributed disjunction/exists, etc). But how does the index variable bind to the right things if there are pieces of clauses distributed all over the place?
Oh, I think I see now.
You can force it to bind to the right things by testing another predicate inside the scope of the aggregation.
Letâs say you have a rule in one place that says things are all good if all the dogs have four legs, but what constitutes a dog is spread out all over the law.
In Flora-2, for example, you could write all_good :- forall(X)^(dog(X) -> legs(X,4)).
Then rules that define dog(X) can appear anywhere else.
Let me know if that answers the question, or not.
The most recent coding that Iâve done is here, in the r34.pl file. It uses a different language with only implicit existential quantification, but it might help to illustrate.
Hi everyone! For those who couldnât attend, the recording for the OpenFisca Rules as Code masterclass is available to watch here.
Iâm sure our speaker @ram_parameswaran would be happy to answer any questions anyone has as well.
Happy viewing!