Creating a data schema for legal analysis involves plunging into abstraction. How deeply abstract the schema becomes probably depends more than we want to admit on the temperament of the person creating the schema. The more abstraction, the more powerful and expressive the schema can be, but also the greater the risk the schema will crumple under the pressure of the analyst’s assumptions or unprovable metaphysical beliefs. At the Singapore Management University Center for Computational Law, Principal Investigator Meng Weng Wong, Jason Morris, and the rest of their team went extremely deep to create an extension to Docassemble called Docassemble-L4. I salute their bravery.

Like most Docassemble extensions, Docassemble-L4 uses Python code to create an interactive interview to help apply a legal standard to a user’s fact pattern. What makes Docassemble-L4 unique is that it lets you create that Python code by translating it automatically from a different language called s(CASP), which appears to be closely related to Prolog. The intended way to get that S(CASP) code is by translating it automatically from L4. I understand L4 is a programming language that hasn’t been released yet, but it will leverage the Z3 theorem prover. To use Docassemble-L4, you must provide not just the s(CASP) code, but also a YAML document in a special format called LExSIS (no relation to the legal publisher), which tells Docassemble how to create an interview interface to elicit information relevant to the declarative logic statements in the s(CASP) code.

And the data input syntax is verbose. It suffers from a degree of combinatorial explosion since s(CASP)’s inference rules don’t seem to have a proper “or” syntax, as shown in this excerpt from the example data:

business_entity(X) :- carries_on(X,Y), business(Y), company(X), not law_practice_in_singapore(X), not joint_law_venture(X), not formal_law_alliance(X), not foreign_law_practice(X), not third_schedule_institution(X).
business_entity(X) :- carries_on(X,Y), business(Y), corporation(X), not law_practice_in_singapore(X), not joint_law_venture(X), not formal_law_alliance(X), not foreign_law_practice(X), not third_schedule_institution(X).
business_entity(X) :- carries_on(X,Y), business(Y), partnership(X), not law_practice_in_singapore(X), not joint_law_venture(X), not formal_law_alliance(X), not foreign_law_practice(X), not third_schedule_institution(X).
business_entity(X) :- carries_on(X,Y), business(Y), llp(X), not law_practice_in_singapore(X), not joint_law_venture(X), not formal_law_alliance(X), not foreign_law_practice(X), not third_schedule_institution(X).
business_entity(X) :- carries_on(X,Y), business(Y), soleprop(X), not law_practice_in_singapore(X), not joint_law_venture(X), not formal_law_alliance(X), not foreign_law_practice(X), not third_schedule_institution(X).
business_entity(X) :- carries_on(X,Y), business(Y), business_trust(X), not law_practice_in_singapore(X), not joint_law_venture(X), not formal_law_alliance(X), not foreign_law_practice(X), not third_schedule_institution(X).
business_entity(X) :- carries_on(X,Y), business(Y), not law_practice_in_singapore(X), not joint_law_venture(X), not formal_law_alliance(X), not foreign_law_practice(X), not third_schedule_institution(X).

So Docassemble-L4 is very challenging to use. But still, it’s a significant accomplishment because it moves Docassemble farther from single-purpose interviews, and toward generating conclusions by searching a large collection of legal rules derived from legislation. This is the same idea suggested by the Best Practices section of the Docassemble documentation, which suggests distributing the “mandatory” block that defines the objective of a particular interview separately from the file that defines the rest of the rules, so that the parts of the interview that are more likely to be reusable are easy to find in a separate module. Another benefit of Docassemble-L4’s roots in logic programming is that it can generate explanations for its conclusions, with links to the relevant passages of legislation. Maybe more of Docassemble-L4’s workflow can be automated in future versions.

Although I’ve been critical enough already, I have one more quibble with Docassemble-L4’s design philosophy. I think Docassemble-L4 was written with the idea that each rule written in s(CASP) will correspond to a separately-numbered section of the published legislation. I think that’s a little bit of an artificial restriction, and I think it resulted in the example data containing a lot of shorter rules connected by meta-rules about how one rule “overrides” another. If instead the legislation was thought of as containing larger rules that could span multiple numbered paragraphs, it would no longer look like there were so many contradictions within the same legal code, and there would be less need for the user to create meta-rules about which rules take precedence over others in the event of a conflict. A really expressive schema for legal analysis should include a rich syntax to describe the relationship between a legal rule and the legal documents that enable it.