Wavelength's Legal Engineering “Capability Model”
The Legal Engineering “Capability Model”
In this White Paper, our Chief Scientific Officer and legal engineer, Dr Ben Gardner, explains Wavelength's Legal Engineering “Capability Model”, which provides the basis of a design language for thinking about, and solving, legal engineering problems.
Understanding the Capability Model’s tools and what they enable is central to the development of well-engineered and useful solutions.
About the author
Dr Ben Gardner is Chief Scientific Officer at Wavelength where he is responsible for the application of technology to legal process. He specialises in developing data strategies that enable clients to exploit structured & unstructured information sources. His previous role was Data and Information Architect for a UK headquartered magic circle law firm, where he drove innovation and adoption of technologies to enable advanced analytics and improved Information Discovery.
Before specialising in the legal sector, Ben worked in the area of Information and Knowledge Management for Pfizer R&D. During this time, he led unification of data access and mining, developed a global data/information governance team, introduced Enterprise 2.0 tools and delivered knowledge management frameworks that enhanced collaboration and communication.
“I think we need some AI …”
"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 this cartoon:
Like the character in the cartoon, this situation demands more clarity by unpacking what AI means in more granular terms.
This cartoon may be copied or redistributed under a Creative Commons CC-BY-NC 2.0 UK licence, attributing Wavelength.law Limited and linking to this White Paper: https://creativecommons.org/licenses/by-nc-nd/2.0/uk/
Wavelength has developed its Legal Engineering Capability Model that aims to address this issue.
The 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 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.
In the diagram 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.
Explaining the Legal Engineering Capability Model
Explaining the Legal Engineering Capability Model
We like to think of the capabilities within our model as the tools on our workbench. More accurately, these are activities (or groupings of related activities) that can be combined to solve a problem at hand.
As legal engineers, our first task is always to understand and define a problem. The output of this process is a ‘design pattern’ that we can either implement ourselves or use to identify the best potential vendor products for a client.
The difference between a capability and a vendor product can be illustrated if we consider document automation as a capability i.e. as the core activity of creating draft documents by populating a template with input data. A vendor product that centres around a document automation capability may also include other capabilities including workflow, negotiation, and expert systems to support the additional activities of data capture, reviewing, and signing.
Any given vendor product will likely combine multiple capabilities into a solution. We cannot really know its relevance to you until we first understand your problem. Wavelength’s capability model provides the basis of a language for thinking about, defining, and solving legal engineering problems.
Text Analytics And Extraction
Text analytics and extraction capability breaks-down into three sub capabilities; text extraction, document clustering and document comparison.
Text extraction tools provide the capacity to extract pieces of text from an unstructured source, and to create a structured set of information (such as a database or Excel table). These tools use supervised machine learning to train algorithms to recognise patterns in the documents. A pattern could be as simple as a date or a company name, or more complex such as a specific clause.
In all cases, a user needs to provide the extraction tool with examples of each pattern he or she wants it to extract. This is done by manually tagging and marking up several documents and then using this tagged set of documents to train the extraction tool to recognise the pattern. In addition to extracting text, these tools can be used to automate application of metadata to a document, or drive automated redaction based on pattern recognition.
Document clustering is the capacity to sort a set of documents into ‘similar’ groupings. Document clustering tools sort the documents based on the overall similarity in structure of the documents (e.g. headings, sections, clauses, etc.) as well as commonality of the content. This means that documents of a similar type can be grouped together.
Examination of each cluster by a user is required to determine the type of document in each cluster. For example, in the diagram below, after one round of clustering four document types have been identified:
Subsequent rounds of clustering can be performed on a grouping to identify sub-clusters e.g. different types of resolutions or variations in the template used to draft consulting contracts. It should also be noted that clustering techniques can be used to group extracted clauses as well as whole documents.
Document comparison with respect to text analytics refers to the ability to compare and analyse differences across a whole set of documents as opposed to the more traditional document-to-document comparison.
The ability to compare across a whole portfolio at once allows the identification of representative standard documents based on the actual working practices of those who drafted the documents (as opposed to a comparison against an idealised ‘gold standard’).
The degree of variance compared to this standard can also be calculated and visualised. As with clustering, this collection-wide comparison can also be applied to clauses enabling more granular analysis.
Expert systems first became popular in the late 1980’s, early 1990’s. These tools allow the user to construct a decision-tree or similar model that describes a process. Typically, this would be composed of a series of bifurcating decisions and conditional logic statements i.e. “if this, then that”. Users answer a series of questions and, based on their response, are directed down the appropriate path.
In addition to using the data captured in response to the questions asked, these tools can pull in data from other sources and perform calculations before providing the user with a response.
A classic application of expert systems is to build automated triage systems that allow scaling of decision-making processes where demand outstrips available human resources. More recently, these tools can be found providing the back-end logic that drives many chat-bots.
Document automation solutions are probably the most pervasive of these capabilities in the legal sector, with many law firms and legal departments already using various document/contract automation products.
This capability helps to streamline and scale the creation of standard documents, while enforcing best practice and enabling the creation of self service solutions.
At a high level, these solutions require a subject matter expert to create a template into which data is inserted to create a first draft of a document. This can be simply the auto population of specific terms e.g. party names, dates, etc., or selecting optional clauses and in some case selecting between version of the same clause. The data and choices can be gathered via a question-answer interface or via a spreadsheet or equivalent.
Data visualisation represents the ability to display information in a visual fashion. A good visualisation helps to turn raw data, e.g. a spreadsheet, into accessible information that supports making actionable decisions. Data visualisation as a discipline is widely used by those working with data, for example in financial reporting functions.
Within the legal sector, however, such tools have not been widely used, one reason for this maybe that valuable legal information is often trapped within unstructured Word or pdf documents. However, text extraction capabilities can enable data to be extracted and placed into alternative formats (e.g. spreadsheets and data bases) that data visualisation tools and techniques can be applied to.
This offers the opportunity to provide new insights into a portfolio of documents. For example, from a set of real estate lease agreements it would be possible to visualise how rent revenues will change over time, or to provide insight into the types of restrictions present, or to display where the real estate properties are geographically located on a map.
From a legal engineering perspective, interactions between people within teams, across departments or between a firm and a client fall into three broad categories: collaboration, workflow, and negotiation.
This is a well-established capability that centres around providing teams with shared working spaces where they can coordinate, share documents and manage day-to-day/week-to-week activities.
This capability covers the ability for a team to connect the various tasks that make up a process. It provides the capacity to both automate a process and to monitor progress of individual tasks. Workflows are particularly powerful where a process crosses business lines or group boundaries.
This is an emerging capability that is focused on helping overcome the challenges associated with the back and forth of negotiating. This is a broad category and covers many scenarios from document review through to facilitated online dispute resolution.
Data Structure & Integration Layer
The capabilities in this layer represent different ways that systems and data can be connected. The focus is on how the output of one step can be used as the input to the next. There are a large range of approaches that can be applied but of particular note are enterprise knowledge maps, robotic process automation and service-oriented architecture.
Enterprise knowledge maps
This is a new approach to aggregating data from multiple sources. An enterprise knowledge map groups data around key concepts that are of interest to a business. For a law firm, this means clients, matters and people, and the relationships that connect them. In essence, an enterprise knowledge map connects data with context.
Robotic process automation
This is a class of technology that can be used to connect systems and automate the execution of a process across multiple systems. For example, automating a matter-opening process could involve opening a matter, creating entries in a practice management system, creating new folders in a document management system and creating a new time code in a time management system.
Service oriented architecture
This is an approach for connecting applications, enabling information to be passed from one application to another, typically via application programming interfaces (APIs). From the legal engineering perspective, the ability to extract information from one source and feed it into another is critical to realising synergies by combining solutions with different capabilities.
The Legal Engineering Capability Model in Practice – Use Cases
The Legal Engineering Capability Model in Practice – Use Cases
People who are apprehensive about choosing the right technological tool, to address a problem or to enable innovation, find it all too easy to become fixated on the technology alone. Although technology choices are necessary, it is the broader, design-led solution (in which they sit) that is crucial.
It’s the entire designed solution that exploits a vendor product’s potential and leverages the impact of the technology.
We use the Legal Engineering Capability Model in a number of ways, such as to identify the ‘capabilities’ of a vendor product i.e. to understand the activities (or groupings of related activities e.g. document automation and data visualisation) of which it is capable.
Chiefly, we use the model as a framework for analysing and addressing client problems - by understanding their issues, identifying the capabilities that are required, and mapping these to the underlying process so as to define a solution or ‘design pattern’ that we can either implement ourselves or use to identify the best potential vendor products for a client.
Engineering the analysis of several hundred employee contracts for a client
An example client’s problem (based on a real engagement undertaken by Wavelength):
The client hired a new CEO with a mandate to restructure its business quickly. The HR department was tasked with providing summarised content to the CEO from the employment contracts of the organisation’s several hundred employees, and supplementing this with financial data to support forward planning.
Understanding the issues:
Hundreds of contracts had to be analysed in a short space of time. This process had to begin identifying key information in the contracts, such as restrictions on when an individual’s annual leave may be taken etc., being classified, interpreted, and extracted. The data from the contracts needed to be ‘cleaned’ as it had a variety of formatting and uncommon nomenclature, with even simple elements such as dates being written differently across the data set. Data from different sources had to be integrated as the information from the employment contracts needed to be supplemented with information from the company’s payroll, and any redundancy pay available to each individual needed to be calculated in accordance with tax authority rules. The resulting data then needed to be presented to the client with data visualisations that would support the CEO’s strategic decision making.
Identifying the required capabilities:
The client needed a solution with the following capabilities:
Text Analytics & Extraction: to extract key information e.g. employee name, start date, holiday entitlement and restrictions, IP protection, etc. whether discreate pieces of information e.g. dates, hours, etc. or whole clauses e.g. holiday entitlement, IP restrictions, etc.;
Data Mapping / Storage: to provide a repository where the extracted data could be stored, manipulated and supplemented with additional data;
Expert Systems or System to System Capabilities: to clean the data, categorise it using rules based on legal interpretation, add new data sets, and perform calculations; and
Data Visualisation: to create dashboards and reporting across the whole data set.
Creating a design pattern:
If we imagine a workbench onto which we have pulled various tools or capabilities, then we end up with the following:
Implementing the design pattern:
Breaking the problem down in this way helped the client understand that the data generated during this analysis was extremely valuable and that there were opportunities to reuse it to perform additional analysis such as for gender pay gap reporting, or to support downstream activities such as re-contracting. This lead to a wider discussion with the client around how they could make better use of their data and become more data driven.
In the real-life matter that this example is based upon, our client was delighted at the results. The analytics surpassed all expectations and the rich insights gained meant that she could make confident, well informed strategic plans. Also, because we created a structured data set, it is possible to build on additional reporting, automation etc as needed.
Deconstructing how journalists investigated the Panama Papers
The Panama Papers provided insight into the operations of Mossack Fonseca a firm, headquartered in Panama, involved in incorporation of offshore entities. The papers were a giant trove of data consisting of 11,500,000 leaked documents, covering approximately 40 years of records, which included information about more than 210,000 companies in 21 offshore jurisdictions. To find the stories in this 2.6 terabytes of data, the International Consortium of Investigative Journalists (ICIJ) effectively built their own eDiscovery solution.
The ICIJ’s problems:
The ICIJ had to solve two problems. The first was how to provide journalists with the capacity to search the leaked documents for significant information. The second, more crucial problem was how to visualise the web of companies and beneficial controllers described across multiple disparate documents.
Deconstructing their solution:
The ICIJ started with a remarkably large collection of documents of various types and in various file formats. Their output was a data set with search and data visualisation capabilities. Based on this we can hypothesise that the ICIJ would have used optical character recognition and text analytics to initially cluster documents by type, and then use named entity recognition models to extract the information they were interested in from each document.
This extracted data will have been placed into a database which would have been used to drive the search and data visualisation of their solution.
There have been several reports describing the ICIJ’s solution, here for example. From these reports, we can see that they in fact used two different types of database:
Mapping their solution into a design pattern:
If we invoke our imaginary workbench in order to examine their solution within the context of our capability model, then we end up with a design pattern that describes a 'home grown' eDiscovery service:
Applications of the capability model:
Just as we have deconstructed the ICIJ’s solution to tackling the Panama Papers, we can use the capability model to breakdown and understand any vendor product, or digital legal services provided by a law firm etc.
In each case we end up with a design pattern that describes the solution. We use these design patterns as shorthand descriptions which we then use to match against design patterns created in response to a client’s needs when they ask us to solve a problem. This allows us to quickly identify potential products or services (or combinations of products and/or services) which could be used to solve their problems.
Conversation that revolves around comparisons of technologies, rather than focusing on the problems at hand, continues to be one of the biggest challenges hampering innovation.
At Wavelength, we have developed the legal engineering capability model as a way of keeping discussions problem focused and technology agnostic. We find the framework helps client to move away from catch-all terms such as AI and talk about their innovation needs at a level of granularity which helps us to define and truly understand their problem.
Once a problem has been defined in this way, we are often able to expand the conversation to think about how changes to their current processes could deliver additional efficiencies and improvements.
Our clients have responded so positively to the legal engineering capability model, and to the additional benefits gained, that we now use it on all our engagements with clients. We have developed a well received, simple introduction to legal engineering based around the model for use with clients. We have also presented it at a couple of law schools, and have integrated it into both our training and workshop offerings.
It is my hope that, having stuck with me throughout this series exploring legal engineering capability model, you now feel more equipped to participate in shaping the future of law.