Policy Difference Engine: Motor Vehicle Operator Hours of Work Regulation

Knowledge Base Examples
, ,
#1

From the website:

The Canada School of Public Service, Employment and Social Development Canada, the Community of Federal Regulators, drafters from the Department of Justice, and the Labour Program applied the Rules as Code process to the existing motor vehicles operators hours of work regulation regarding overtime.

In a 3-weeks sprint the team completed concept models, decision trees, source code for the regulation in Openfisca and has published it publicly as an API on Github for all to connect to. That referenced API is used here under the hood to power this Policy Difference Engine to test possible changes to this regulation through microsimulations.

The code, written in OpenFisca, is available on GitHub.

The app allows you to set out a driver’s weekly time sheet, then change 6 parameters in the legislation, and see how those changes affect what constitutes overtime for the driver.

It was built as part of a real-world process for reviewing the regulation in question.

The prototype is currently publicly accessible at https://policy-diff-main.dev.dts-stn.com/.

1 Like
#2

Great achievement!! Really exciting to see realworld examples, and in the policy modelling area too!!

1 Like
#3

Hi Jason! Very interesting, it would be great to see the logic flows too.
What’s the most interesting part from my point of view is this fragment:
“Other” hours worked are hours that do not fall into either the CMVO or HMVO categories, and are thus regulated by the Canada Labour Code, some parts of which have been encoded into this system.".
I wonder what is the best way to represent whole legal acts in form of the code to model the possible relations between them. Have you discussed it during the sprint? Please forgive me if it’s a newbie question, I’m not that familiar with OpenFisca.

#4

Everyone who is doing Rules as Code is a newbie, Patryk. :slight_smile:

I wasn’t a part of the sprint that generated this tool, but it’s something I’m sort of abstractly aware of.

Regardless of whether it’s OpenFisca or anything else, there are two issues. First, there is a lot of variation in how useful it is to encode different parts of the legislation. Typically, the app is targeted at answering a specific question, and the encoding of the legislation is limited to the sections of the law that are relevant to answering that question.

But in a tool like OpenFisca, even if you had a really short law that calculated your benefits, and the entire law was relevant, you could encode the “entire law” in such a way that if you give it the relevant factors it can calculate benefits. But it can only execute the formula in one direction. If the formula is A+B=C, and you give it A and B, it can calculate C. If you give it C and B, it can’t calculate A.

You could revise your OpenFisca encoding to be able to do things like that, but that task quickly grows in size to be infeasible.

So most encodings of the “entire law” would actually be a reformulation of an entire law as an algorithm for calculating a limited set of outputs, as opposed to a declarative expression of the relationships between the variables.

Really encoding the “entire law” requires using completely different tools, I think.

The other issue with encoding multiple pieces of legislation and having them interact with each other is that they would need to have a shared data structure and mapping to real-world concepts that can be re-used inside the encodings of multiple laws. I have seen a few technologies that facilitate incorporating data from ontology languages. The work happening in Finland is also focused on tools for that end of things. But I haven’t seen any actual encodings that are actually using that sort of shared ontology.

#5

Thanks, I get the point. This shared data structure you’ve mentioned is an interesting concept certainly worth taking a closer look. There are some publications on drafting legislation that could provide the needed inspiration. Also, it could be fun to search for design patterns that could improve legal drafting. But that’s another story, I guess.