legal engineers


The Legal Engineering Capability Model in Practice – Use Cases

In this post, Dr Ben Gardner, Legal Engineer and Chief Scientific Officer at Wavelength.law Limited, continues a series of articles that are focused on education and legal engineering. This post explores the capability model in more detail, specifically how we use it in practice, by applying it to a number of legal 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.

Wavelength’s legal engineering capability model was previously introduced in this series of blog posts. We use the 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.

In this post I will use a couple of case studies to illustrate how it is possible to produce a design pattern for a client problem and construct a solution.

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 that had 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:

blog pic 100.png

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.

The result: 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

Background: 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:

  • a relational database to support the search capability; and
  • a graph database to support visualisation of the entities and relationships between them.

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:

blog pic 200.png

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.

We'd love to talk to you about the themes discussed here and the work we do. Please get in touch here

Ben Gardner