‘I think we need some AI…'
In this post, our Chief Scientific Officer and legal engineer, Dr Ben Gardner, continues a series of articles that are focused on education and legal engineering. This post introduces Wavelength's 'capability model', which provides the basis of a design language for thinking about, and solving, legal engineering problems.
'I think we need some AI…'
This is how many early conversations about legal engineering and innovation begin. Unfortunately, Artificial Intelligence (or AI) is a polysemy or 'suitcase term' – arguably it encompasses too many disparate topics to be a useful starting point for conversations about legal innovation. In our experience, AI is a term that is often used by default to mean 'something happens, which I don't really understand' – pretty much in the same way as the 'miracle' gap depicted in the cartoon below:
Like the character in the cartoon, this situation demands more clarity by unpacking what AI means in more granular terms.
Wavelength has developed a legal engineering capability model that aims to address this issue.
Legal Engineering Capability Model
The objective of this model is to provide a design language for thinking about, and solving, legal engineering problems.
Our approach seeks to address the problem first, instead of forcing a technology led response to the situation. This means we should first seek to understand and define the problem, and then aim to identify the best solution.
In the course of our work, we have collated a range of tools and capabilities on our ‘workbench’ that are available for us to use. The key is to understand how these tools and capabilities can be combined in creative ways to solve the problem at hand.
The output of this process is a design pattern that we can either implement or use to identify potential vendor solutions.
It is worth pointing out that when we assess a vendor product we essentially conduct this process in reverse, so that we end up with a design pattern that represents that product. We can then use this to match to any design pattern we encounter when analysing a client's problem.
In the diagram above we have grouped capabilities into three layers:
- the top layer represents the interactions that take place between people, either within a team, across departments or between a law firm and their clients,
- the bottom layer describes integration of systems and data, and
- in between these two layers are the core capabilities of text analytics and extraction, expert systems, document automation, and data visualisation.
In our experience, many of the legal engineering challenges we encounter require one or more of these capabilities and, as such, we consider these to be the core tools of a legal engineer.
Understanding these tools and what they enable is central to moving the conversation beyond simply 'I think we need some AI…' towards providing the detail needed to develop a useful solution.
Over the next few posts I will examine these capabilities in more detail before explaining, through use cases, how this model can be used to identify a design pattern for problems.