LitCon, DocaCon, ICLP, Event Reasoning

LITCon 2023

On Monday I had the opportunity to participate in LITCon 2023, a conference put on by the Legal Innovation and Technology Lab (LITLab) at Suffolk Law.

LITLab is run by David Colarusso, who was the person who first introduced me to declarative logic programming for legal knowledge representation years ago.

Perhaps my favourite part of the conference was the presentations done by LITLab students on the projects that they had built. Most of them used Docassemble, but one or two were built with other tools.

We also got a deep dive into some of the work that the LITLab has been doing with their Assembly Line set of tools, which helps you to take existing PDF court forms and turn them into online interviews, in Docassemble.

Very cool stuff. I hope someday to have students like those at the LITLab working in tools like Blawx. Let’s aim for LITCon ‘26, maybe. If you’re interested, the entire conference is available on LITLab’s YouTube page.

DocaCon 2023

Docassemble’s user conference skipped a year, last year, and this year it was a half-day attached to LITCon, which is pretty much how things ought to be. Some of the most advanced Docassemble work in the world is being done by people like David and my friend Quentin Steenhuis at LITLab.

I had the opportunity to do a little presentation on how you can combine Docassemble and Blawx to use Rules as Code in your Docassemble interviews.

If you want the 5-minute video version, here it is.

The way the demo is built is actually pretty interesting. You can check it out on github.

Basically, you start with a docker-compose.yaml file that looks like this:

services:
  blawx:
    container_name: blawx_server
    build: https://github.com/Lexpedite/blawx.git#main
    ports: 
      - "8000:8000"
    expose:
      - 8000
    networks:
      - docablawx
  docassemble:
    container_name: docassemble_server
    image: jhpyle/docassemble
    expose:
      - 80
    networks:
      - docablawx
    env_file:
      - .env
    restart: always
    stop_grace_period: 6m
    ports:
      - "80:80"
    volumes:
      - dabackup:/usr/share/docassemble/backup

volumes:
  dabackup:
    driver: local

networks:
  docablawx: {}

You then take the following steps:

  1. Run docker compose up.
  2. Go to localhost:8000, log into Blawx, and create the “Old Age Security Act” example.
  3. Once Docassemble has started (it can take around 5 minutes), log in at localhost:80 and create a playground file with the following content:
metadata:
  title: Old Age Security Act Demo
  short title: OASA Demo
  comment: This is to demonstrate Blawx & Docassemble for DocaCon 2023
---
mandatory: true
code: |
  import requests
  def interview_request(payload):
    url = "http://blawx:8000/1/test/generic_eligible/interview/"
    r = requests.post(url,json=payload)
    return r.json()
  
  def display_tree(tree):
    output = "<ul>"
    for entry in tree:
        if isinstance(entry,list):
            output += display_tree(entry)
        elif entry.startswith("The global constraints hold"):
            break
        else:
            output += "<li>" + entry + "</li>"
    output += "</ul>"
    return output  
---
objects:
  - people: DAList.using(object_type=Individual,complete_attribute="complete")
---
code: |
  people[i].name.first
  people[i].pensioner
  people[i].complete = True  
---
question: |
    Is there a person?
yesno: people.there_are_any
---
question: |
    Is there another person?
yesno: people.there_is_another
---
question: |
    What is the person's name?
fields:
  - Name: people[i].name.first
---
question: |
    Was ${ people[i] } a pensioner in July of 1977?
yesno: people[i].pensioner
---
code: |
  people.gather()
  payload = {'facts': []}
  for person in people:
    new_person_fact = { "from_ontology": False,
      "type": "true",
      "category": "person",
      "object": person.name.first}
    payload['facts'].append(new_person_fact)
    if person.pensioner:
      new_pensioner_fact = {"from_ontology": False, 
        "type": "true", 
        "attribute": "pensioner_july", 
        "object": person.name.first}
    else:
      new_pensioner_fact = {"from_ontology": False, 
        "type": "false", 
        "attribute": "pensioner_july", 
        "object": person.name.first}
    payload['facts'].append(new_pensioner_fact)  
---
code: |
    blawx_answers = interview_request(payload)
---
mandatory: True
question: |
    Eligibility Response
subquestion: |
  % if len(blawx_answers['Answers']):
  % for answer in blawx_answers['Answers']:
  % for model in answer['Models']:
  ${ display_tree(model['Tree']) }
  % endfor
  % endfor
  % else:
  There were no eligible individuals.
  % endif

And that’s it! I was impressed with how easy it was to get Blawx and Docassemble to cooperate inside a docker compose configuration. You can see that inside the docassemble interview, you just give the service name “blawx” as the name of the target server, and it works great.

Event Reasoning

When not attending conferences I’ve been trying to implement event reasoning in Blawx. The process has been a bit of a slog, because the simplest thing that could possibly work frequently didn’t, and so I’ve been implementing increasing less-simplest things for nearly three weeks. But the good news is that the basic mechanism is working, and now I’m just debugging and fixing some presentation issues.

Getting it working did mean that I had to re-implement the date library, and we have both gained and lost some features as a result of that. But I think the tradeoffs are worth it.

What is Event Reasoning? Why Do We Care?

If you look at the Old Age Security Act example, one of the first attributes defined in there is a true / false attribute that defines whether a person was a pensioner as of a certain date. That pattern, where what you are interested in is not whether a thing has always and will always be true, but what you are interested in is whether or not it was true at a given point in time, is very common in legal rules. The basic example is a deadline. There is some thing that if it is going to be done, it needs to be done before a certain time. After that time, it is no longer available to do. If we want our tools to be able to say “this opportunity no longer exists as of now”, and be able to explain why, the system needs to have a model of what things are true, and when, and why.

The main obstacle, here, is encoding these things in a way that takes into account the things that human beings intrinsically know, but which are not obvious to computers, about the passage of time. For example, if I was alive on a given date, then I probably stayed alive until something else happened to make me not alive. That idea, that things tend to stay the same until actually changed at some point in the future, is called the “frame problem.” Event Calculus is a logical technique used to overcome the frame problem, and let computers reason about the effects of events over time without the person doing the encoding needing to constantly repeat long blocks of code that mean “and nothing else changed”.

s(CASP) provides some new opportunities for doing event calculus efficiently, because it has the ability to deal with numerical constraints over infinite domains. So if we represent time as a number, s(CASP) can easily reason about what was true when. Or at least more easily than would be possible in many other systems.

What does it look like?

Adding event reasoning to Blawx, because of the way s(CASP) handles it, actually only requires introducing a very small number of blocks. Here’s what it looks like if we want to encode the concept that “a person is alive after they are born”. You can see that we have wrapped the “person is alive” block in a “from date” block. That’s how you use event reasoning in the current version: you specify what things are true as of the start of time, what things are true at the end of time, and what things became true when in between.

Then you can ask questions about whether something is true as of a certain time, or more broadly, when it was true.

People are alive after they are born

If in addition to that code, you express the idea that people are no longer alive when they die:

People are not alive after they die

And the idea that no one was alive in the beginning:

No one is alive initially

And the idea that ultimately, no one lives forever:

No one is alive ultimately

Then you have told Blawx everything it needs to know to reason about how the attribute “alive” changes over time. You can create a test that describes a person’s date of birth, and their date of death, and then ask when were they not alive, like this:

when was bob not alive

And when you run that code in the scenario editor, Blawx knows that bob was not alive prior to his birth, and was not alive after his death.

bob not alive answers

The explanation will now point to events in time, such as bob’s birth and death, to explain why conclusions were true or false at a given point in time. Likewise, you can model legal deadlines this way, or set out legal processes where it doesn’t matter when things happen, it merely matters that they happen in a particular order.

I’m sure that there is a lot more semantic sugar that could be poured on this to make it easier to set out legal processes, and we’ll get there. But reasoning about events over time is the last major language feature missing from Blawx, so I’m very excited to get it done, and demonstrate that it is possible to have a tool that does all the things Blawx does, at the same time.

Upcoming

A paper by myself and Joaquin Arias, one of the authors of s(CASP), introducing Blawx, has been accepted for publication as a technical paper at the International Conference on Logic Programming in London later this year. That the editors and reviewers thought it worthwhile to share with that audience is a great honour. I’m not sure if I’ll be able to attend the conference in person, but I’ll be looking forward to that, either way. I’ll be working on the final edit of that paper in the coming weeks.

I have a short list of bugs and display problems in the version of Blawx that will eventually become v1.5.4-alpha, so I will be continuing to try to nail down those. Once that’s done, I need to update all the examples, create new examples to show off the new features of the date library and the event reasoning features, plus write a bunch of documentation about all the things that have been changed and added. I’m optimistic I can get all of that done by the end of next week, and have a fully-featured version of the Blawx language working almost exactly 3 years after I submitted my LLM thesis describing it.

Request for Demo Requests

If you have an audience, or are a single solitary person, who would be interested in a deeper-dive demonstration of Blawx. Let me know. I’d love to do more demos.