To familiarise readers with the Typology and demonstrate its potential use, below are two tutorial exercises that demonstrate various interactions with the tool, and the kinds of question it both raises and helps to answer.
- First exercise: an exploration of the systems (apps/papers/datasets), a.k.a. tokens, represented in the Typology.
- Second exercise: challenging the reader to explore broader patterns in the legal technology landscape.
These tutorial exercises can be used in a training or educational context, but note that the Typology is not intended as an exhaustive catalogue of the state of the art in legal technologies (there is a good reason for this; see Our approach & methodology for details). Students and those with an interest in legal technologies are nevertheless encouraged to consider how their legal tech of choice would fit into the framework we have presented here.
Our approach & methodology contains a deeper exposition of our choices, and the value we hope the Typology will have as (i) a source of primary material gathered from legal technology providers, (ii) an educational tool, and (iii) a methodology.
The Typology is intended for legal professionals and academics from both Computer Science and law. It is also relevant for legal tech developers and entrepreneurs. This exercise gives a sense of how different audiences might interact with the tool, and what they might learn from it.
Pick one of the following professional personas:
- Entrepreneur in the legal tech industry
- Software developer
Imagine yourself in their position, and think about how and why you might, from that perspective, be interested in forecasting court decisions.
Find a system in the Typology that best connects with your persona’s interest in forecasting court decisions. Consider the following questions:
- What solutions does the system offer, and for whom?
- What assumptions are they based on?
- What problems might it present?
- Are these existing problems, or does the system introduce new ones?
- Are the problems legal, technical, or both?
- Could they be surmounted? If so, what (new) assumptions would need to hold?
Sample outcome (spoilers!)
Those in the Judge persona end up using the following two filters to select systems:
- End-user: courts
- Functionality: Litigation: prediction of judgment
Based on these filters, you may have explored app tokens (Jus Mundi, Westlaw Edge, JURI SAYS and Moonlit), and found the paper token Predicting Brazilian court decisions (Lage-Freitas et al. 2019) in the overlap between the two filters.
You may not find that these apps and this paper provide a satisfying solution to their investigation – as a judge – into the task of forecasting court decisions. In fact, under the substantiation section of each token, they might encounter (potential) legal effects, and (potential) technical issues that may discourage a judge from integrating that token in their professional practice.
Now consider if these issues also come in play with the legal techs you might already be using, and if the exploration of the Typology affects the sort of questions you might ask a provider of legal tech.
The Typology’s interface affords not only a deep dive into individual tokens, but also their high-level comparison. This should not only help readers find relevant tokens faster, but may also expose broader patterns among the various legal technologies.
Using the filters, select and compare two or three apps that may be relevant for the automated application of tax laws.
To add a token to the comparison, clicking on the check box next to the compare icon!
Once you’ve selected the systems you’d like to compare, scroll to the bottom of the page to see them side-by-side.
Sample outcome (spoilers!)
Note the similarities and differences between the tokens.
Do these align with your expectations?
Consider: both of these tokens aim to automate tax calculations, and fit in to the goals of the Rules as Code community. However, neither the code nor the application of RegelSpraak can be accessed. This raises the question: which legal technologies should be available and open-sourced? What other tokens also are not accessible? What are the motivations for making apps or code unavailable?