 Welcome, everyone. This is the agenda for today. So the agenda is essentially I'll do a very quick intro. Then we'll talk about what is rules as code, or RAC, as we call it. Then I'll be talking about proof of concept that we did for RAC. And this was done for GalCMS. I'll be talking about GalCMS as well. We also did another RAC website called BenefitMe, which is actually a New Zealand website. And then I'll be talking about the process and how Drupal comes in. And then we'll be having a Q&A session. For the Q&A, we have an app. So if you have any Q&A, and if you put your questions in the app, that would be great, because my colleague here will be able to see the questions, and we can answer them as and when they pop up. Or otherwise, we can do a one-on-one as well. But doing it on your app would also work. So it would be great if you could do that. So a bit about me. My name is Suchigar. I'm a technical manager at Salsa. I've been working for 25-plus years with open source. I've been working with Drupal since 2006. Yes, 4.6 was a Drupal version at that time. I have been a dev, tech lead, solution architect, mentor, project manager, you name it. I've done it. Treino, yeah. In this particular project, the one I'll be talking in detail, I was actually a dev. It was a very interesting change of pace for me, because this was a POC, as I said, proof of concept. And we had to do it very, very quickly, two weeks, three weeks, when we were done. So we needed somebody who could really push code through. So it was very interesting for me, because I worked really hands-dirty after a long time. OK, so before we start anything, let's talk about what is rules as code? So as the diagram implies, the rules as code is a very emerging trend. It has started gaining a lot of traction. And it basically takes the legislation, regulation, and policies. And it converts that into machine-readable code. So it's not only a technocratic solution, but rules as code actually represents a shift in how governments create some types of rules and how different parties, third parties, can consume them. What are the benefits? All of us are tech people here, developers here. So I don't think I need to really spell out the benefits, but still, let's do that. There are several benefits in having a single source of truth that can drive many, many applications. The first one is, of course, reducing of ambiguity. Rules as code makes it really, really clear what the rules are and makes it more accessible and easy for citizens to access and easy for them to find the information they're looking for. It makes the whole rules very, very reusable. So once the rules are coded, they can be reused by a website, Alexa, or any third party engine, JetBots, anything. There, of course, they become very easy to manage. Once they are coded, they are easy to maintain and change. So we know exactly where the change of need to go. Revisioning also happens very easily. They become very transparent. If anybody has any interaction with government rules, they are seriously, seriously long and they are very, very difficult to understand. So converting them into code makes it much more transparent. And of course, rules as code then can be used to inform policy and model changes and how they will impact people down the line. So now in terms of the two projects, so I'm from Salsa Digital, as I mentioned, we did two projects with rules as code. The first one was a PLC, which was for GOVCMS. The other one was BenefitMe, which was for the New Zealand government. Before we talk about the project, let me talk about what GOVCMS is actually. So GOVCMS is Australia's whole-of-government website management platform. It is built on Drupal. It was designed to make it easier for agencies to create modern, affordable, and responsive websites. So GOVCMS is actually managed by the Department of Finance, which is a federal government entity. And it has actually increased the usage of Drupal in the government sector considerably. So some sort of background or context about the project. So GOVCMS actually had an expression of interest around DXP. Salsa responded to that expression of interest for digital experience platform solutions. We were successful in that. And GOVCMS asked us to create a proof of concept. Specifically, they wanted us to look at COVID vaccinations. This was in mid-2022. So at that time, COVID vaccinations were very, very relevant to help the citizen understand if their COVID vaccination status is up to date or not. So that is the journey that we picked. And that is the journey we created in the rules of code POC that we did. There were actually six potential user journeys. And only one journey really, really stood out for us. That's where the citizen is figuring out what's happening. I need some information. I'm trying to access an entitlement or trying to comply with a government policy, but I don't know what to do about that. And that's where rules is code and our POC came in. So as I say, GOVCMS wanted to look at the COVID vaccinations. It was initially when the project started, the POC started, we said, COVID vaccination, whether I need a COVID vaccination or not, that should be a very, very easy thing to do. We were very wrong. We were so wrong because going through all the legalities, going through all the rules that have been defined in pages and pages of text was not easy. So the two main journeys that we covered in our POC, one, as I mentioned, am I up to date with my COVID vaccination? And the second one was, do I have to be vaccinated from my work? Because in Australia, each different state has its own rules about different sectors. So if you're in NSW, for example, and if you're working in health sector, you have to be vaccinated, but if you're in NSW and some other sector, you may not need to be vaccinated. So we did a POC for that one as well, that particular journey as well. And this was the final product. Now, if you look at the final product, there are actually two websites that we are showing. And the reason why we are doing two different websites was to showcase the fact that the rules were coded at one central place, but those rules could be accessed by two different websites. The first one was for the general public. The second one, if you look at it, it was for the indigenous, aboriginal tourist people of Australia. And it was configured in a way that whenever they say information, that was more related to their own situation. Also, aboriginal and tourist people had different rules configured, according for the COVID vaccination policies, even the booking links that we provided them, they get a priority if they go to a booking website. So this was configured accordingly, but we created two websites. I will not be showing you the second one, I'll just be showing you the first one. This is the website either side, and these are some of the sample scenarios. A 55-year-old adult was at five doses, last dose was in June. This is DDMMYYYY, just to clarify, and that can be a confusion. A 30-year-old who was at three doses, last was third of May. A parent looking for a five-year-old immunocompromised child was at two doses, and parent looking for a four-year-old child. These are the few different scenarios or user journeys. I'll be picking up the first one to do a demo. And before I do that, I'll pray to the demo gods for a sacrifice or something. All right, so, sorry, give me a minute. Before we start, I just want you to know that this was just a POC that we created. We specifically made sure we have an alert at the top that says this is not reliable information because things keep on changing and we were not keeping up to date with the changes. But this is just a proof of concept to tell you, yes, that, yes, this thing can work. All right, so let's look at, as I said, there were two. Am I up to date with my COVID vaccinations? And the second one was, do I have to be vaccinated for my work? All right, so let's go with the first one. The first page gives us some information, keeping a COVID-99 vaccination up to date. Is why is it important, et cetera, et cetera? And then there's a button. This is all Drupal content. Nothing very specific going on here. So when we start, the way this particular POC was implemented, that it was a series of web forms. So, first web form, we input some information. When the web form gets submitted, it actually goes to the rules as code engine, which was actually coded not in Drupal, but in OpenFisca. It goes there, it gets the information back. And based on whatever information comes back, it goes to either one page or another page. That's how the whole journey was created. So for example, here, if I input something like two-year-old, now as per the rules, at least the rules at that time, a two-year-old does not have a vaccination. So if I input two-year-old here, it will actually go to a page, it will say, sorry, you're not eligible for a vaccination. And actually, let's go ahead and do that. So the moment I submitted, it actually pulled the OpenFisca engine. It sent out the information that the age is two, and the return came back saying, no, you're not eligible. Now, because this was a POC, we were able to make it ugly as well. And that is why, if you see that five is actually highlighted in yellow. So this is actually the information that is coming from the rules as code engine. This is not something that is hard-coded in Drupal. So it says that you have to, and these were the tokens that we were using in Drupal. So it says that you need to be five years old and over to be a vaccinated. And how does that help? Tomorrow, if the age changes from five to three, we have to make that change only in the rules as code engine. We don't have to make any change here, and it will automatically get reflected here. Let's start over. Okay, how old are you? I'll put 55, I am not 55. So the moment I said that I am 55, now it went to the rules as code engine again, and when it came back, it says, hmm, you're eligible, let me ask you more questions. And what are the questions? Are you immunocompromised? Because, as for those treated laws, if you're immunocompromised, the rules are slightly different, and if you're not, the rules are slightly different. So that's why it's asking the question. I'll say no. And based on this one, it again goes to a next form. And then in the next form, it asks you how many doses have you already had, and what was the date of your last one? So I can say something like five, four, whatever. And let me just put in not a 2022 date, maybe this year date, 16th of, or 18th, 16th, 18th, 16th, 16th of February. And I do a summit. Oh, what is the error? Sorry, I forgot. This was, this POC was created last year, so we have to, I have to put the date, which is less than the last year. So I'll put something like 8th of December. So it said 8th of December, which was more than six months. So as for those treated laws, which we read, which we went through, it says that if you are six months or over, then you are eligible for your next dose. So that's what it says currently you're not up to date because it has been more than six months since your last vaccination date. Again, if you look at the highlighted parts, those are all the things that are actually stored in OpenFesca. They are not stored in Drupal, so everything is coming from there. And we are just displaying them as tokens. And because this is Drupal content, we were actually able to add a lot more information here. And what are the kind of information? So this was a make a booking link. And as I was saying, for the Aboriginal and the Torres Strait website, the make a booking was slightly different. It had a parameter which says that this is priority booking. So we were able to make that change. And it also gives you more information. And again, if you have had COVID in the past three months, then you are not eligible for a vaccination and you will have to have your vaccination three months later. It also gives you information about what are the recommended vaccinations for you based on your age. Again, these are all rules that are actually defined by the Department of Health in Australia. And this information, as I said again, this was coming from the rules as code. And we are just showing it up on the Drupal website. So that was the one that we did for, am I up to date? The other one that we did was, do I have to be vaccinated for my work? And as I said, this was very state-related, state-specific. In this one, there is actually not a flow of waveforms. This was just one conditional waveform. And when I said something like, okay, I am in Victoria, just to show you that there are so many states and union territories in Australia, but we did the POC only for three of them. New South Wales, Victoria and Western Australia. So I'm from Victoria. Which sector do you work in? I worked in, let's say, healthcare, healthcare. Again, this is pulling the rules as code and trying to get information from there. Because I am working with healthcare, I have to be vaccinated, and I have to have at least three doses. I could actually go back here and say some other sector. Again, Victoria, I'm thinking maybe education. Do you work in a specialist school? And that's where the conditional form actually comes in. It's not a specialist school, so you don't need to be vaccinated. There's no government requirement to be vaccinated. All right, going back to our... The other one that we did, as I was telling you, was benefit me for New Zealand. Let me actually do a very quick demo for that as well. Okay, yep. It doesn't work, sorry. The website, maybe the internet connection is not working or something. I'll come back to the demo if there is time. If time permits, I'll come back to this demo. Let's go back to our presentation. So that was, as I said, we did a rules as code for New Zealand. The rules as code thing that we did for New Zealand was essentially about benefit me. It was around what all, what am I entitled to as a person from the government? So things like, am I entitled to a household benefit? Am I entitled to an unemployment benefit, a family benefit, et cetera? So that's benefit me.nz is actually not a PLC. It's an actual website which people are using. So it was, as I said, it was around New Zealand social security benefits. And we worked with the digital AOTORA collective, sorry, it's a tongue twister. If nobody knows, it's the name of New Zealand actually. And we fed the learnings of GovCMS POC into this project as well. So that was the demo, a bit of demo, et cetera. Now let's talk about some technical aspects of it. I'll not go into deep into technical stuff, but something. So the rules as code engine that we picked for the POC and for our project was OpenFisca. Now what is OpenFisca? OpenFisca is actually an open source API first rules as code framework. And it was developed in 2011 for the French government. So we are at the right place for OpenFisca. It standardizes the way in which rules are written and provides a common request response pattern to use in connected clients. This allows integration to different systems. In this case, we chose Drupal, but it can be any other system. It can be something like a voice thing or a chat board, et cetera, et cetera. At the moment, many rules as code projects in France, New Zealand, Australia, Canada, and other jurisdictions, they use OpenFisca. Also, OpenFisca is pattern based, yeah, it's written right there, and it's open source, the most important thing. So broadly, this was our solution architecture. Nothing very technical going on here. So all the rules were coded in OpenFisca. Then we used Drupal as a content API and we used Drupal. We actually created a module which integrated web forms with OpenFisca. So we created web forms which integrated with OpenFisca, which we're able to call OpenFisca, and that's how we created our POC, or our benefitme.nz. But the whole purpose of this solution architecture was that because Drupal is a content API, this can feed into mobile apps, into voice devices, et cetera, or even rules as code, the OpenFisca engine directly feed into the voice devices, other system interfaces, et cetera, and websites as well. Now let's start with the whole process. How did we do the POC? Because the technical parts, yes, they are important, but there was a whole process associated with it. The process can be divided into, broadly, into five steps. The first step was, I would say, the most difficult one. We had to look at the rules, analyze them, and map them, and then they went into the OpenFisca and they were coded as configuration slash coding. We'll talk about that a bit later. Then, so OpenFisca was configured. Then we had a Drupal OpenFisca module, which was actually a web form OpenFisca module, using which we created web forms, which integrated with the rules as code engine, and we also used Drupal as content, using which the results pages were set up. Those were broadly the five steps. Let's talk about the first step. This is, in terms of rule mapping, this was the initial part, and it was actually really, really important because traditionally, rules and legislation tend to be written in a very, very complex way. It can be written in very complex languages. It can be written in 20 different pages, and you have to really make sure that you're going through each and every one of them to convert them into plain English. Initial rules, and as you can see, if you look at the screenshot, we actually used Miro to do our rules analysis, and we were able to do something like this using Miro. So we basically, what we did was that we get a high level model capturing the entities, the legislative requirements, the logic, the calculation, and then that was converted into machine consumable legislation. So using these kinds of, and I'll show you if you can see those clearly, you can have a look at them here, one of them. So if you look at this one, yeah, so in this case, this was a special case for where your age is greater than five, but less than 12, because that had a very different rules as compared to less than five, in which there were no rules because you're not eligible, and if you're greater than 12, you are considered an adult and they had a different rule set. So this was the flow for greater than five, greater than equal to five, and less than equal to 12, and this is an example to figure out whether you're up to date or not. So as you can see, if you're up to date or not, there are so many things that you have to capture, and yeah, again, so in this one, we were actually able to define the calculations as well. If this is this, and this is this, and this is this, then the output should be this. That is how we started to analyze our rules. So next then is the process of looking at these, and then we had to quantify and put them into the OpenFisca solution, and how did we do that? We had to, we started with creating some test scenarios. We had to then create entities, and I'll talk about entities in a minute, parameters, variables, which had inputs and outputs. So the way OpenFisca works, this is an example of a test case. Yeah, this is an example of a test case. Now the way OpenFisca works is that it has to have an entity. I'll show you in here. So to give an example, in this case, so entities could be something like an individual. It can be a household. It can be a company, an organization, based on the different rules that you have to follow. So in this case, we're talking about vaccination, right? So vaccination needs to be applied on a per person basis. So that's why our entity was a person. But if you look at the benefitme.nz example, there we were talking about entitlement, this is social security entitlement. And in that case, that entitlement is not actually on a per person basis. If you are in a family, if you have a spouse, if you have children, it becomes a household thing. So in that scenario, our entity was household. So OpenFisca plays on it. Entity is a super important thing to configure. So in this case, we configured the entity to be a person. The next step was to define parameters. So parameters, all of us, I'm hoping many of us are from a dev background, yes, no. So we do understand what are parameters, what are input variables, what are output variables. So I don't really need to explain that to you in detail. But parameters as the examples shows here is a minimum age of COVID vaccination eligibility. We actually also, because we were doing a PLC, we wanted to show how flexible the rules as code PLC is. And we wanted to also show how easy it is to maintain. So rules as code is actually versionable as well. So if you look at this one, it says that from 1st of August, 2022, the value is five. But because we were doing a PLC, and this is not an actual number, but from 1st of January, 23, the value is three. So when we were doing our PLC, if I did it today, for example, it would take the value three. So if I put five, it would actually allow me to go and say, yes, you're eligible. But if I had done this PLC demo last year, it would, if I have put my age as four, it would have said you're not eligible. So we can easily change the parameter values, and these are all date-based. So it allows us to revision stuff as well. Does anybody have questions? I'm okay with pausing and answering any questions. All right. Either I'm making it very clear, or either I'm making it very, very difficult. Nobody's understanding anything, but okay, let's go ahead. So the next thing is the variables. Variables, property of a person, or entity, whatever. So in this case, the input variables were, are you immunocompromised, which was Boolean. How many doses have you had? Right, and the second, and the third one is, what was the date of your last vaccine dose? And based on these three inputs, and of course the age was another one, you actually, let's talk about that next. So whenever we are defining the variables in OpenFisca, it actually has a value type, entity, definition period, label, and reference. And as you can see from the example here, so vaccine doses, it's of type integer. Last vaccine is of the type date, as we can see. Are you immunocompromised? It's of the type Boolean, because it can be either yes or no. It also has, of course it has a label, but it also has a definition period. Definition period is very important as well, because these things are defined on a per day basis. So that's where the definition period is here is there. The whole POC that we created is very, very defined on a per day basis. In benefitme.nz, it was on a per week basis, because all the calculations are done on a per week basis, but in this case it was based on your date, and et cetera, et cetera. So that is why the definition period here is there. And then there's a formula which then calculates an output variable. So this is an example. If this is this, this is this, is up to date, is the output formula, are you up to date? Yes, no. And as you can see, COVID vaccination up to date, the value type is Boolean, because yes and no, that's the only answer that you get. All right, so now let's come to the, so we configured everything into OpenFisca, which is an open source Python-based thing. It's totally independent. It was actually hosted on a different server altogether, because we wanted to showcase that part. And what happens now on the Drupal end? Now Drupal end actually has two parts. One is the rules part, and one is the related content part. So before I go ahead, as I was mentioning, we actually went ahead and created a web form Fisca module. Sorry that module is not yet open source, because POC time, budget, money, and also this was very, very specific to the POC we created. So what that module allowed us to do, and I'll show you some images as well there, it allows us to say, when we are creating a web form, it allows us to say, yes, this is an OpenFisca thing. It allows us to put in the URL for the API, the OpenFisca API, and the moment we start doing that, the API sends us a list of variables. So when we start creating our web form and we create each and every field, we can actually map it with one of the OpenFisca fields. So for the first form, which was very, very, the most simplest of the forms, where I set age, when I set age as an integer field, I could actually map it and say that this maps to the age variable on OpenFisca end. There might be some form elements which don't need to be mapped. We are just showing it for information purposes or whatever, and that's perfectly fine, but we were able to do the mappings. Also this module allows us to create, then once the web form is submitted, it allows us to send a query to the OpenFisca and we were able to configure what are the variables that we want as output, because those are the variables that then decided whether we want to go to a page or whether we want to go to a web form page. Again, first form, for enter three or two, the return would be no, you're not eligible for vaccination, so you go to this particular page, that's it, and so on and so forth. So web forms, and then we notes which actually, so even this branching rule which says that, okay, if the value returned is this, go here. If the value returned is this, go here. We actually made sure that this was also content-editable. We did not want to hard-code them, so we created a very simple content type which could be attached to a web form, and we could actually say if the return value, return variable x is true, go here, x is true and y is false, go here, and so on and so forth. So that was the rules content. So this is an example, and just showing you this was the rules content, so first one, as I was explaining to you, how would I use, if you submitted more than, greater than five, the rules content said, okay, you can now go to the second web, second step. The second step is, are you immunocompromised? The third step is, how many vaccination doses? When was your last dose? And accordingly, it will line to a results page. Now the results page, there were several pages which were created as results based on the different combinations and permutations. So that was the rules content flow. This particular screenshots, combination of screenshots, actually shows you how we can attach a web form and how we can do settings within the web form. So here when we go to add handler, we could actually add the openfisca journey handler which we created, and we could put the openfisca endpoint, the return value that we wanted, and you don't need to worry about this one because this is automatically calculated when we are creating the form. So this is a screenshot of when we are creating a web form, and as I was mentioning, in the first screenshot, you can see that I have created a new field, and when we go to edit the field at the very bottom, we have, because it's Fisca enabled, I have another field where I can actually see all the variables which are available in openfisca, and then I can map it here. So this was age one, this is part of the list, and I can select that, yes, this particular field is the age field. And when we create these, when we are doing this form, the UI, and when we save the web form, if you remember in the last one, so this is automatically calculated based on what we create in the UI. So that was how we created the web forms, but we also had to create the journey, so we created, this was very simple, again, POC, quick and dirty, quick and dirty. So we went ahead and created a content type called rules. It had one field which was for the web form, and then within that we could have multiple things. So this is the simple one which says if the return value of COVID vaccination eligibility is false, redirect to this page. If it is true, redirect to this page. This is the simplest one, this is a more complex one. So this is the last one, the last form. So we get so many return values and we could put in a combination of this is true, this is false, this is true, go here. This is false, this is true, this is true, go here, and so on and so forth. So we created, in Drupal we created a lot of result pages based on the requirements. As I said, Drupal part had two parts, one was the rules content, we just talked about the rules content, and this is about the related content. And related content is actually the content we created in Drupal, and we, as I was mentioning, we used tokens a lot. So whatever was being returned, we showed them as tokens, and all the results page that you see here, they're all rules pages. And these are the pages that we are being redirected to using the earlier one, using this one. So you're not eligible for a vaccine is a page. And similarly about your COVID vaccination history, it's another page. Right, actually I'm very, very early. All right? I'll take questions here. All right, so we have two questions. So the question is, is it possible for a client to change the rule themselves, or it has to be done by a developer? The rules themselves, they need to be done by a developer because they are the ones that are coded in OpenFisca. The rules is code engine, so that needs to be done by a developer, but the whole flow, et cetera, that can be done by clients. And so the question is, I think the strength is the web form slash OpenFisca integration module. And so maybe the community help and create a dev branch. I totally agree. But I'll tell you, one of the reasons were of course, time and money that we didn't have time to make it a... The other reason was also the fact that, not always we did not need that, we needed that module, yes, but not always we were using the same flow. So in the benefitme.nz example, we did not have a flow of web forms. It was one big huge web form. And then once that is submitted, so web form OpenFisca module, yes, it is needed. And yes, we can talk about, I can go ahead and create a dev branch or something on, we had plans about making it open source. So if anybody of you is interested, please contact me and we can talk about that and we can make it open source, at least a dev version, so people can take and plan accordingly. But I'll have to warn you, it's very dirty at the moment, but that's how everything begins. So yes, we can do that, yes. Which, so the question is, are the YAML files stored in your repository or the OpenFisca? Are you talking about the rules YAML files? They are, so the rules engine is a totally separate thing and the Drupal part is just an integration. So rules engine is stored, everything is stored. The YAML files that we show, the examples that we show that we saw, they're all in that OpenFisca, they are not in Drupal. The question is, is this only to be used for legislation or can it be used for brands, et cetera? It can be used anywhere. It's just a PLC we did for legislation and government, but if brands need, yes, I can understand what you are talking about, that if you have a huge organization and you have different brands, but there are some rules that need to be followed for all brands, yes, it can be used there as well. So the question is that rules are in a book or on a website, et cetera. That was actually covered in the first part of my presentation. So yes, that is a manual process. The rules have to be read through and I can actually show you the diagram very quickly if possible. So we use Miro to extract that information and try to convert it in a way that it could be then coded. So that is, yes, that is a manual process. Any more questions? Thanks all for joining. Goodbye.