by Oliver R. Goodenough, Codex Affiliated Faculty and Michael Genesereth, Stanford Asst. Professor and Codex Research Director
Automation has already brought significant improvements in speed, accuracy, scaling and reach to many sectors of the economy. Other activities – like contracting – are still only in early stages of the journey. Law as a sector has been slow to embrace real automation of its processes. Progressive developments, like enhanced research, word processing, and expert systems, have provided some gains, but the core representation of legal rules – public and private – has remained the word-based, natural language statement. Whether it is the Internal Revenue Code, Supreme Court opinions, or private contractual agreements, words, and their drafting, interpretation and application by lawyers, remain the primary mode for legal formalization. The limits of such a legal specification system are increasingly apparent, and momentum – and knowledge – for making a change to greater automation are both building.
Automating Insurance Contracts
Automation involves the migration of tasks from human-based to machine-based execution. Within law, insurance contracts – and the related tasks such as creation, coverage analysis, explanation, claims administration, and risk analytics – are particularly attractive targets for automation. It is often stated, with some simplification, that for insurance, the contract is the product. The potential benefits of representing that contract in machine executable code affect all corners of the insurance business. (See, e.g., Goodenough & Salkind, 2022). The starting point for insurance contract automation is to make sure that the bargain between insurer and insured is represented by a “computable contract.” At a level of mathematical precision, a computable contract is “one that is specified in sufficient detail to provide unambiguous answers to questions about compliance of clearly specified circumstances with the terms and conditions of the contract.” If the bargains of insurance can be represented precisely, the significant benefits of automation can begin to be realized.
The Insurance Initiative of Stanford University’s CodeX Center for Legal Informatics is tackling a number of choices for formalizing insurance contracts. One key issue, central to many of the choices, is understanding the structure of the bargain type represented by the contract. In insurance, happily, there is a traditional structure involving five key questions:
- Is the contract active and in effect?
- Are there conditions that need to be met on an ongoing basis to keep the policy represented by the contract in effect?
- What is the set of events/state of the world that will trigger a payment by the insurer?
- Are there exclusions, i.e., events or states of the world, that will negate some or all of coverage that would otherwise apply?
- Taking into account the nature of the loss and any deductibles, co-pays and caps, what is the benefit owed to the insured?
In addition to providing answers to these questions on the structure of the bargain, insurance contracts often provide terms for policy and claims administration, payment, and legal points like choice of law.
A second issue, dependent in part on the answers to the structure question, involves the choice of a computational approach that is most suitable to automating contract-related tasks. Lay persons often presume that the coders tackling an automation project just start writing code, with the different programming languages and approaches being pretty fungible. In practice, of course, it is much more complicated than that. It is true that most computational structures – including the structures of computable contracts – can be expressed in a number of different formalisms. This is sometimes called the translation property of computation. But different programming approaches can fit different forms of computational challenges with different efficiency, capability and expressivity. It isn’t one size fits all. And an approach known as “logic programming” fits the needs of representing the insurance bargain uniquely well. To understand this fit, we need to take a short dive into some basics of computer science.
Broadly speaking, programming approaches – and the languages that implement them – fall into two major categories: imperative and declarative. The imperative approach typically breaks the problem down into a series of prescribed questions and answer steps with branching outcomes depending on the answer at a given step in the series. In the insurance context, if determining whether the policy is in effect, this could involve a step asking “is it signed by the insured,” followed by a step asking “is it signed by the insurer,” followed by a step asking “has the premium been paid,” and on from there. Each of these steps is separately programmed, and each has a branch that either leads to further questions or back to some termination point saying “no policy in effect.” Commonly used imperative languages include Java, Python and C.
This kind of programming can get cumbersome in a hurry, particularly if there are variations that let the computation go forward. For instance, the “is it signed by the insured” could have two possible answers, by hand on a hard copy of some kind or electronically through a recognized method. A no answer on one possibility would then lead to a new query on the other, and the answer there is yes, then a further track is necessary to get back to the next question. There are some shortcuts that can used, like creating sub-routines, sometimes called objects or widgets, that solve the multiple possibility problem as a separate routine, and then plug back into the main stream of the program. For a well-defined problem involving a known set of questions and answers, the imperative approach can be a good choice, and it is often deployed in automation projects. But for a problem that may take a number of different forms, or have a number of possible variables all leading back to a single conclusion, imperative programming can explode in complexity.
Imperative programming can be quite effective with automating a particular, well-defined task, such as claim analysis, but it has a hard time supporting related questions, such as comparing one insurance policy with another, or giving an explanation to a customer on the deficiency in a claim.
Declarative programming, by contrast, doesn’t start with a string of steps, but rather first asks, “What are the factors – the events and states in the world – that will matter for coming to the conclusion we are seeking to determine?” Once those are in place, often the problem to be solved can be stated as a yes/no answer to a single, if multi-factor, query. The query could be, “Is one of the following 10 factors present?” It could be, “Are none?” Or, “Are all of them?” A particularly useful version of this kind of approach is called “logic programming.” The name is a bit confusing, because all computer programs depend on – and embody – logic. But the label comes, in part, from the technique of representing the string of factors that are the triggers for the decision as a classic logic statement involving “and,” “or,” “but not,” etc. The facts/events populating that string are drawn from the entries in the database of salient factors set up in step one. If the process of getting to the legally interesting answer, either in whole or in part, can be set up as such a string, then that piece of the computational puzzle can be answered by a single, if multi-part, query, saving on the complexity and time consumption of the step-by-step approach. There are several logic programming languages in current use – they often have the suffix “log” in their title. Prolog is probably the best known – it was developed in the early 1970s. In the CodeX project, we sometimes use a version called Epilog which has advantages over Prolog in expressivity and scope.
Logic Programming and Contracts
The fit between logic programming and law comes naturally: the logic programming approach already commonly provides the underlying structure of word-based formulations of legal rules and contractual arrangements. This is particularly the case for “trigger” contracts, like insurance, letters of credit, or a closing-based purchase agreement, where checking off the necessary boxes – and avoiding checking the disqualifying ones – triggers a payment or some other transactional step. It is also the case with boundary contracts, like non-disclosure agreements or distribution licenses, where crossing beyond permitted uses will trigger negative consequences.
One of the foundational studies applying computational approaches to law recognized this relationship explicitly. The 1986 paper “The British Nationality Act as a logic program” (Sergot et al. 1986) describes how the existing word-based formula of the Act governing British citizenship used the techniques of a logic programming approach. In particular, it shows how the structure of the Act utilizes nested “Horn clauses,” a characteristic technique where one positive answer out of a string of “or” linked possibilities creates the trigger for a positive answer, in this case through a number of pathways to citizenship. The paper also demonstrates that the provisions of the Act can be restated in Prolog.
Logic Programming and Insurance
If we return to the classic insurance bargain, we see that it an example of a trigger contract. If certain necessary facts are present, for instance, whether (i) the contract is in effect, (ii) all necessary conditions are satisfied, (iii) the required elements for a valid claim are present and (iv) the possibly disqualifying facts about an exclusion are absent (or answered affirmatively in a “not …” statement), then coverage is triggered. This is a classic logic programming scenario, and using a logic programming approach to automate questions about the existence of a valid insurance claim is a natural fit. Note that calculating the amount of the coverage once the trigger is validated can also be represented through a logic programming approach.
While logic programming will enable a number of important tasks for customers, insurers, re-insurers, and regulators, the starting point for most in the business is figuring out whether a valid claim has been made under the terms of the bargain between insurer and insured – and logic programming excels at this: the underlying bargain is already in a logic-string format. Making the choice to use a logic programming approach for the valid claim question, however, leads to a number of further questions around implementation. The required data set implicated by the insurance policy and its contract must be identified and then tagged or structured in a way that makes it open to the queries that constitute the policy – i.e., a useful ontology. Defining the query set that is a particular policy needs to be accomplished. The traditional bargain categories set out above can help guide this process, as well as inform the design of interfaces that can be used to allow relatively unskilled coders – or even customers – to build and deploy policies and contracts for actual use.
And once individual policies can be built using logic programming, in addition to giving quick answers on coverage, such an approach opens up a wide universe of further capacities that can be developed and deployed, capabilities that would be difficult or impossible to integrate into an imperative system. We have summarized the potential benefits of contract automation in different papers (e.g., Goodenough & Salkind 2022, Genesereth 2022, Ancellin 2022, Doulcet 2022); almost all of these benefits can be enabled through a logic programming approach.
For instance, logic programming enables a quick explanation of why coverage is unavailable. The identification of the data points that don’t satisfy the query template is a relatively easy, machine-executable step – giving a quick answer to why a particular claim doesn’t trigger coverage. It can also allow a customer to compare coverages quickly, identifying what fits better with that customer’s needs and whether there are redundancies or gaps among multiple plans. Within a company, claims administration can be supported with quick, accurate answers, and portfolios can be stress-tested quickly against exposure to particular events and risks.
The logic programming approach has great promise as the basis for automating computable contracts for use in many of the tasks associated with the insurance business. It is a natural fit with the structure of insurance bargains, informing the word-based formulas of traditional contracts. It also enables a wide range of critical tools and functionalities that can flow from the basic step of individual policy representation in this format. Any project to bring automated functionality to the insurance business should consider a logic programming model as a starting point.
Ancellin, R. (2022). Automating Risk Analysis in Corporate Insurance Portfolios with Computable Contracts. MIT Computational Law Report. Available at https://law.mit.edu/pub/automatingriskanalysisincorporateinsuranceportfolioswithcomputablecontracts
Doulcet, P.-L. (2022). Standardization of Insurance Product Representation. MIT Computational Law Report. Available at https://law.mit.edu/pub/standardizationofinsuranceproductrepresentation
Genesereth, M. (2022). Insurance Portfolio Management. Complaw Corner, Codex: The Stanford Center for Legal Informatics. Available at https://law.stanford.edu/2022/07/30/insurance-portfolio-management/.
Goodenough, O., & Salkind, S. (2022). Computable Contracts and Insurance: An Introduction. MIT Computational Law Report. Available at https://law.mit.edu/pub/computablecontractsandinsuranceanintroduction