Benefits of a DSL for corporate policy and simple legal agreements

Published on in

Here’s a (somewhat serious) question that’s been on my mind: is it possible to develop a strictly-typed Domain Specific Language (DSL) that can be used for drafting, interpreting and interrogating corporate policy and simple legal agreements?

If the answer to this is yes, then we can repeatedly eliminate subjectiveness and inconsistency in judgements, by adopting computer science principles and proven software development best-practices. Let me explain...

I understand that much of the law is founded in principles of “reasonableness" and can be incredibly subjective at times. However at its core, it is a rules-based system and there remains some kinds of legal documents that can, and should, be strictly defined. For example, corporate policies that require little (or no) moral or ethical interjection (e.g. corporate travel, leave or expense policies), and common service agreements such as those between a customer and their bank, insurer, or internet service provider.

Computers are great for building rules-based systems. At heart, that is what most of computer programming is all about. Yet we still rely on humans to draft and interpret these rule-sets, and as a result repeatedly subject ourselves to inevitable human error and bias.

What I am proposing here is a human-readable computer language, with legal (domain-specific) contextual awareness, that compiles into machine-readable policies and agreements. A strictly-typed DSL would allow us to describe these rule-sets in a world that is aware of strict legal constructs, using a language that computers can understand.

The original idea for this was floated during brunch with Greg and Olga earlier in the year. Since then, I’ve discussed the concept with many people from engineering, law, and even science backgrounds. While I have given thought to the feasibility of what I’m proposing, this post is not directly concerned with answering the question as stated above. Rather it operates on the optimistic assumption that the answer is indeed “Yes! We can develop a strictly-typed DSL for use in corporate policy and simple legal agreements". With that assumption in place, I can now focus on answering the “So what?" question, by exploring the benefits of such a system. Think of this as a funding pitch that showcases the upsides.

The benefits

Let’s break down the benefits into two groups, based loosely on the lifecycle of a legal document. Firstly, creation: drafting the document. Secondly, use: the interpretation and enforcement of the policy or agreement. This is not a comprehensive list of benefits, rather it is a list of some of my favourites.

1. Drafting the policy or agreement

Advantages at this stage come mostly from tooling, such as an Integrated Development Environment (IDE), a DSL-to-agreement compiler, and distributed version control systems (DVCS). It is this set of benefits that demonstrates why it is most generative to use a DSL, rather than a custom-built application for example.

  • The use of an IDE can boost productivity by offering contextual tools such as: code completion, code insight, resource and dependency management, debugging tools, and potentially an integrated compiler or interpreter.

  • Compile time checks can be enabled by using appropriate data-structures, which represent the law in the real world. They allow us to introduce validation checks (e.g. incompleteness, conditions that are not mutually exclusive, or conflicts) at compile time, as opposed to resolving these issues at the time of interpretation or enforcement.

  • Automated testing will allow us to catch (and avoid) regressions, such as the introduction of new conditions that conflict or compromise existing ones.

  • Collaborative development using distributed version control makes it easy for globally dispersed teams, to collaborate on significantly large projects. Adopting this would also enable complete, long-term change history tracking, branching, merging, and traceability.

  • Policy development in the open (i.e. open-source development) engages the community and enables transparency. This means: hosting repositories publicly and being encouraging of pull-requests, issue-tracking and open public discussions.

2. Interpretation

Once drafted, a time will come when the policy or legal document will need to be interpreted and enforced (i.e. "used"). Having a machine-readable document presents advantages, which otherwise would be non-existent.

  • Consistency in judgement, that is free from bias and discrimination, when interpreting the policy. Computers will return the same result every single time, regardless of who is asking or when they are asking. Machines themselves are blind to ethnicity, religion, age, race, or gender. While I acknowledge that bias and discrimination could be programmed into the document itself (by humans), I hope that this is something that we can prevent using compile-time tools such as linting (an example of which is joblint from Code For America).

  • Interpretations need not be definitive or precise every time. Provided that most interrogations return an answer with a confidence of say, 90%+, then we can significantly reduce the need for human intervention. When necessary, computers can still defer to a human by providing best-effort answers with an associated measure-of-certainty for each.

  • A machine-readable agreement, can have interrogation software that is internationalised. This means that a document can be interrogated by people in their native language, regardless of the language used to write the original policy or agreement. In other words, once compiled the document becomes human-language agnostic.

  • As the body of law is consistently growing, it can become difficult for humans to effectively consider all applicable or relevant documents. Machine-readability enables searchability, ergo offering a solution that scales in time. This can be further enhanced by attaching descriptive meta-data to documents. Imagine a world where computers can instantaneously search, read, and interpret corporate policies across an entire organisation or industry-sector.

This is a good idea

In summary, I think we have a lot to gain from bringing more computation into the way we draft and interpret legal documents. I recognise that there will always be areas of the law that require human intervention, typically on the grounds of ethical and moral inquiry. However for use-cases such as standard corporate policy or simple legal agreements, the benefits of machine-readability greatly outweigh the costs and risks. Developing a strictly-typed DSL would be a generative way of enabling the production of machine-readable legal documents, where the process benefits from proven software development best-practices.

For bonus points: I think the answer really is, Yes!

The more I think about it, the more I believe it is actually possible to build this. There will always be a place for human judgement, but a DSL is certainly attainable for simple and common enough use-cases, such as corporate travel policy or an agreement with my landlord.

We are already seeing the programmatic enforcement of terms and conditions. For example, moderating abusive language using bots in Slack or automatically taking down photos (that potentially violate the terms of use) on Facebook. Furthermore, similar tactics are already being used in the insurance sector. Generalising this into a DSL is an evolutionary next step.