Thread by @DMerigoux

After the #ProLaLa'2022 conference and its wonderful talks, I had the chance to discuss with a lot of #rulesascode luminaries, including @gsileno @mengwong @LThorneMcCarty. With these new insights, here's my take on the state of the art ⬇️ 🧵

[1/15] The logic programming community has probably already discovered all the major challenges, paradoxes and schools of thoughts about translating law into code from the 70's to the 90's. For new PhD students, reading these papers is absolutely necessary!

[2/15] I included a short biblio in my thesis (merigoux.ovh/assets/Brouill…) but you can find a lot of references in Giovani's thesis (gsileno.net/articles/silen…) or @LThorneMcCarty's latest position paper (researchgate.net/profile/L-Thor…).

[3/15] The logic programming community identified some key needs for translating law into code:
- defeasibility (or negation-as-failure)
- unification (for dealing with legal qualifications)
- modalities (or some form of deontic logic)

[4/15] However, the Prolog-like tools derived from this line of reasoning have not quite reached a massive adoption in the relevant industry, even thought people like @RoundTableLaw are still lobbying hard for it :) Why?

[5/15] I'll try give a personal early opinion on it, but am not sure I'm right. Please discuss and let the twitter magic happen!

🔥 My take is that the Prolog-like tools are trying to solve too big a problem with only the resources of the logic programming community.

[6/15] I think that the problem of translating law into code can be split further into smaller sub-problems that each draw from different CS pools of expertise.

My insight about this comes from my experience in formally verified cryptography. 🔐

[7/15] In cryptography, one distinguished between primitives (a function with precise inputs and outputs, that usually involves heavily convoluted arithmetic, run by one person) and protocols (that build on primitives, involve multiple participants, based on messages).

[8/15] The experts and techniques on cryptographic primitives and protocols are completely different. They interact to form a coherent whole but are actually quite independent subproblems. At @ProseccoInria, researchers usually work on one or the other but not both.

[9/15] Back to law ⚖️, I think we can distinguish:
- legal primitives (one actor produces a specific decision from a set of inputs following a legal procedure);
- legal protocols (multiple actors interact according to principles laid out in the law).

[10/15] This distinction is useful because CS-wise, dealing with primitives is WAY easier than dealing with protocols. Plus, legal primitives are widespread in the real world: taxes, social benefits, a lot of administrative decision-making, etc.

[11/15] In retrospect, this is precisely the narrow domain targeted by catala-lang.org. It seems to demonstrate that for legal primitives, you only need defeasability out of the toolkit mentioned earlier. Which brings it closer to functional programming :)

[12/15] Pushing out the unsubstantiated claims, I wouldn't be surprised if modalities were the killer app of legal protocols, in conjunction with classical frameworks coming from distributed systems (pi-calculus, trace-based analysis, etc). With compliance in mind?

[13/15] Concerning unification, ia.urjc.es/GIA/joaquin-ar… recent work about applying c(ASP) suggests that logic programming shines for considering the ambiguity and multiplicity of legal characterization, mapping to adversarial legal uses (trials, etc.)

[14/15] What consequences for the #rulesascode field? If I'm at least partially correct, it suggests that we should better organize as a field and implement division of labor to make more efficient progress.

[15/15] If you had to choose, would you rather be an expert in legal primitives, legal protocols or adversarial legal qualifications?

Tagging more people for fruitful discussions ahead :) @grimmelm @basus @laurencediver @CoHuBiCoL1 @lthomasvb @CorinnaCoupette @nelescher @RobertAKowalsk4