What is a document? - Part 2

Previously: What is a document? - Part 1.

Back in 1985, when I needed to create a “document” on a computer, I had only two choices. (Yes, I am indeed avoiding trying to define “document” just yet. We will come back to it when we have more groundwork laid for a useful definition.) The first choice involved typing into what is known generically as a “text editor”. Back in those days, US ASCII was the main encoding for text and it allowed for just the basic symbols of letters, numbers and a few punctuation symbols. In those days, the so called “text files” created by these “text editors” could be viewed on screens which typically had 80 columns and 25 rows. They could also be printed onto paper, using either “dot matrix” printers or higher resolution, computerized typewriters such as the so-called “golf ball” typewriters/printers which mimicked a human typist using a ribbon-based impact printer.

The second choice was to wedge the text into little boxes  called "fields" to be stored in a "database". Yes, My conceptual model of text in computers in those early days was a very binary one. (Some nerd humour in the last sentence.)

On one hand, I could type stuff into small “boxes” on a screen which typically resulted in the creation of some form of “structured” data file e.g. a CODASYL database [1]. On the other hand, I could type stuff into an expandable digital sheet of paper without imposing any structure on the text, other than a collection of text characters, often chunked with what we used to call CRLF separators (Carriage Return, Line Feed).

(Aside: You can see the typewriter influence in the terminology here. Return the carriage (holding the print head) to the left of the page. Feed the page upwards by one line. So Carriage Return + Line Feed  = CR/LF).

(Aside:I find the origins of some of this terminology is often news to younger developers who wonder why moving to a new line is two characters instead of one on some machines. Surely “newline” is one thing? Well, it was two originally because one command moves the carriage back (the “CR”) and another command moved the paper up a line “LF”, hence the common pairing: CR/LF. When I explain this I double up by explaining “uppercase/lowercase”. The origins of the latter in particular, are not well known to digital natives in my experience.)

From my first encounters with computers, this difference in how the machines handled storing data intrigued me. On one hand, there were “databases”. These were stately, structured, orderly digital objects. Mathematicians could say all sorts of useful things about them and create all sorts of useful algorithms to process them. The “databases” are designed for automation.

On the other hand, there was the rebellious, free-wheeling world of text files. Unstructured. Disorderly. A pain in the neck for automation. Difficult to reason about and create algorithms for, but fantastically useful precisely because they were unstructured and disorderly.

I loved text files back then. I still love them today. But as I began to dig deeper into computer science I began to see that the binary world view : database versus text. Structured versus unstructured. Was simple, elegant and wrong. Documents can indeed be “structured”. Document processing could indeed be automated. It is possible to reason about them, and create algorithms for them, but it took me quite a while to get to grips with how this can be done.

My journey of discovery started with an ADM 3A+ terminal to a VAX 11/780 mini-computer (by day) [2] and an Apple IIe personal computer running CP/M – by night[3].

For the former, a program called RUNOFF. For the latter, a program called Wordstar and one of my favorite pieces of hardware of all time : an Epson FX80  dot matrix printer.

[1] https://en.wikipedia.org/wiki/CODASYL

[2] https://en.wikipedia.org/wiki/ADM-3A

[3] http://www.classic-computers.org.nz/collection/appleIIes.jpg

What is a document? Part 1.

I am seeing a significant up-tick in interest in the concept of structured/semantic documents in the world of law at present. My guess is that this is as a consequence of the activity surrounding machine learning/AI in law at the moment.

It has occurred to me that some people with law/law-tech backgrounds are coming to some of the structured/semantic document automation concepts anew whereas people with backgrounds in, for example, electronic publishing (Docbook etc.), financial reporting (XBRL etc.), healthcare (HL7 etc.) have already “been around the block” so-to-speak, on the opportunities, challenges and pragmatic realities behind the simple sounding – and highly appealing – concept of a “structured” document.

In this series of posts, I am going to outline how I see structured documents, drawing from the 30 (phew!) or so years of experience I have accumulated in working with them. My hope is that what I have to say on the subject will be of interest to those newly arriving in the space. I suspect that at least some of the new arrivals are asking themselves “surely this has been tried before?” and looking to learn what they can from those who have "been there". Hopefully, I can save some people some time and help them avoid some of the potential pitfalls and “gotchas” as I have had plenty of experience in finding these.

As I start out on this series of blog posts, I notice with some concern that a chunk of this history – from late Eighties to late Nineties – is getting harder and harder to find online as the years go by. So many broken links to old conference websites, so many defunct publications....

This was the dawn of the electronic publishing era and coincided with a rapid transition from mainframe green-screens to dialup compuserv, to CD-ROMs, to the Internet and then to the Web, bringing us to where we are today. A period of creative destruction in the world of the written word without parallel in the history of civilization actually. I cannot help feeling that we have a better record of what happened in the world from the time of Gutenburg's printing press to the glory years of paper-centric desktop publishing, than we do for the period that followed it when we increasingly transitioned away from fixed-format, physical representations of knowledge. But I digress....

For me, the story starts in June 1992 with a Byte magazine article by Jon Udell[1] with a title that promised a way to “turn mounds of documents into information that can boost your productivity and innovation”. It was exactly what I was looking for in 1992 for a project I was working on. An electronic education reference guide to be distributed on 3.5 inch floppy disks to every school in Ireland.

Turning mounds of documents into information. Sound familiar? Sound like any recent pitch you have heard in the world of law? Well, it may surprise you to hear that the technology Jon Udell's article was about – SGML – was largely invented by a lawyer called Dr Charles F. Goldfarb[2]. SGML set in motion a cascade of technologies that have lead to the modern web. HTML is the way it is, in large part, because of SGML. In other words, we have a lawyer to thank for a large aspect of how the Web works. I suspect that I have just surprised some folks by saying that:-)

Oh, and while I am on a roll making surprising statements, let me also state that the cloud – running as it does in large part on linux servers – is, in part, the result of a typesetting R&D project in AT&T Bell Labs back in the Seventies.

So, in an interesting way, modern computing can trace its feature set back to a problem in the legal department. Namely, how best to create documents in computers so that the content of the documents can be processed automatically and re-used in different contexts?

More on that later, but best to start at the beginning which for me was 1985. The year when a hirsute computer science undergraduate (me) took a class in compiler design from Dr. David Abrahamson[3] in Trinity College Dublin and was introduced to the wonderful world of machine readable documents.

Yes, 1985.

Next: Part 2.

[1] http://jonudell.net/

[2] https://en.wikipedia.org/wiki/Charles_Goldfarb

[3] https://www.scss.tcd.ie/David.Abrahamson/

Programming Language Frameworks

Inside every programming language framework is exactly one application that fits it like a glove.

It is science Jim, but not as we know it.

Roger Needham once said that computing is noteworthy in that the technology often precedes the science[1]. In most sciences, it is the other way around. Scientists invent new building materials, new treatments for disease and so on. Once the scientists have moved on, the technologists move in to productize and commercialize the science.

In computing, we often do things the other way around. The technological tail seems to wag the scientific dog so to speak. What happens is that application-oriented technologists come up with something new. If it flies in the marketplace, then more theory oriented scientists move in to figure out how to make it work better, faster or sometimes to try to discover why the new thing works in the first place.

The Web for example, did not come out of a laboratory full of white coats and clipboards. (Well actually, yes it did but they were particle physicists and were not working on software[2]). The Web was produced by technologists in the first instance. Web scientists came later.

Needham's comments in turn reminded me of an excellent essay by Paul Graham from a Python conference. In that essay, entitled 'The hundred-year language'[3] Graham pointed out that the formal study of literature - a scientific activity in its analytical nature - rarely contributes anything to the creation of literature - which is a more technological activity.

Literature is an extreme example of the phenomenon of the technology preceding, in fact trumping, the science. I am not suggesting that software can be understood in literary terms. (Although one of my college lecturers was fond of saying that programming was language with some mathematics thrown in.) Software is somewhere in the middle, the science follows the technology but the science, when it comes, makes very useful contributions. Think for example of the useful technologies that have come out of scientific analysis of the Web. I'm thinking of things like clever proxy strategies, information retrieval algorithms and so on.

As I wander around the increasingly complex “stacks” of software, I cannot help but conclude that wherever software sits in the spectrum of science versus technology, there is "way" too much technology out there and not enough science.

The plethora of stacks and frameworks and standards is clearly not a situation that can be easily explained away on scientific innovation grounds alone. It requires a different kind of science. Mathematicians like John Nash, economists like Carl Shapiro and Hal Varian, Political Scientists like Robert Axelrod, all know what is really going on here.

These Scientists and others like them, that study competition and cooperation as phenomena in their own right would have no trouble explaining what is going on in today's software space. It has only a little to do with computing science per se and everything to do with strategy - commercial strategy. I am guessing that if they were to comment, Nash would talk about Equilibria[4], Shapiro and Varian would talk about Standards Wars[5], Robert Axelrod would talk about the Prisoners Dilemma and coalition formation[6].

All good science Jim, but not really computer science.

[1] href="http://news.bbc.co.uk/1/hi/technology/2814517.stm

[2] http://public.web.cern.ch/public/

[3] http://www.paulgraham.com/hundred.html

[4] http://www.gametheory.net/Dictionary/NashEquilibrium.html

[5] http://marriottschool.byu.edu/emp/Nile/mba580/handouts/art_of_war.pdf

[6] http://pscs.physics.lsa.umich.edu/Software/ComplexCoop.html

What is Law? - Part 17

Last time, we talked about how the concept of a truly self-contained contract, nicely packaged up and running on a blockchain, is not really feasible. The primary stumbling block being that it is impossible to spell out everything you might want to say in a contract, in words.

Over centuries of human affairs, societies have created dispute resolution mechanisms to handle this reality and provide a way of “plugging the gaps” in contracts and contract interpretation. Nothing changes if we change focus towards expressing the contract in computer code rather than in natural language. The same disambiguation difficulty exists.

Could parties to an agreement have a go at it anyhow and eschew the protections of a third party dispute resolution mechanism? Well, yes they could, but all parties are then forgoing the safety net that impartial third party provides when agreement turns to a dis-agreement. Do you want to take that risk? Even if you are of the opinion that the existing state supplied dispute resolution machinery – for example the commercial/chancery courts systems in common law jurisdictions - can be improved upon, perhaps with an online dispute resolution mechanism, you cannot remove the need for a neutral third party dispute resolution forum, in my opinion. The residual risks of doing so for the contracting parties are just too high. Especially when one party to a contract is significantly bigger than the other.

Another reason is that there are a certain number of things that must collective exist for a contract to exist in the first place. Only some of these items can usefully be thought of as instructions suitable for computer-based execution. Simply put, the legally binding contract dispute resolution machinery of a state is only available to parties that actually have a contract to be in dispute over.

There are criteria that must be met known as Essentialia negotii (https://en.wikipedia.org/wiki/Essentialia_negotii). Simply put, the courts are going to look for intention to contract, evidence of an offer, evidence of acceptance of that offer, a value exchange and terms. These are the items which collectively, societies have decided are necessary for a contract to even exist. Without these, you have some form of promise. Not a contract. Promises are not enforceable.

Now only some of these "must have" items for a contract are operational in nature. In other words, only some of these are candidates to be executed on computers. The rest are good old fashioned documents, spreadsheets, images and so on.

These items are inextricably linked to whatever subset of the contract can actually be converted into computer code. As the contract plays out over time, these materials are the overarching context that controls each transaction/event that happens under the terms of the contract.

The tricky bit, is to be able to tie together this corpus of materials from within the blockchain records of transactions/events so that each transaction/event can be tied back to the controlling documents as they were at the moment that the transaction/event happened (Disclosure: this is the area where my company, Propylon, has a product offering.)

This may ring a bell because referencing a corpus of legal materials as they were at a particular point in time, is a concept I have returned to again and again in this series. It is a fundamental concept in legisprudence in my opinion and is also fundamental in the law of contracts.

So, being able to link from the transactions/events back to the controlling documents is necessary because the executable code can never be a self contained contract in itself. In addition, it is not unusual for the text of a contract to change over time and this again, speaks to the need to identify what everything looked like, at the time a disputed contract event occurs. Changes to contract schedules/appendices are a common example. Changes to master templates such as ISDA Master Agreements happen through time, are another common example.

A third reason why fully self-contained contracts is problematic is that ambiguity can be both strategic and pragmatic in contracts. Contract lawyers are highly skilled in knowing when a potential ambiguity in a contract is in their clients favor – either in the sense of creating a potential advantage, or, perhaps most commonly, in allowing the deal to be done in a reasonable amount of time. As we have seen, it would be possible to spend an eternity spelling out what a phrase like “reasonable time period” or indeed, a noun like “chicken” actually means. Contract law has, over the centuries, built up a large corpus of materials the help decide what “reasonable” means and what “chicken” means in a myriad of contracting situations. At the end of the day, both parties want to contract so both parties have an interest in getting on with it. Lawyers facilitate this “getting on with it” by being selective in what potential ambiguities they spend time removing from a draft contract and which ones they let slide.

I think of contracts like layers of an onion. At the center, we have zero or more computable contract clauses. i.e. clauses that are candidates for execution on a computer. Surrounding that, we have the rest of the contract : documents, spreadsheets etc. Surrounding that we have global context. It contains things like “the current price of a barrel of oil” or “Dollar/Yen exchange rate”. Surrounding that we have “past dealings” which relates to how the contracting parties have dealt in the past. Surrounding that again, we have hundreds of years of contract law/precedents etc. to help disambiguation the language of the contract.

As you can see, this ever-expanding context used to resolve disputes in contracts is tantamount to taking a snapshot of the world of human affairs at time T – the time of the disputed event. This is not possible unless the world is in fact a simulation inside a universe sized computer but that is a topic for another time:-)

One final thing. I have been talking about the courts as an independent third party dispute resolution mechanism. There is more to it than that, in that courts often act as enforcers of public policy. For example, a contract that tries to permanently stop party A from competing with party B in the future, is likely to be seen as against the public interest and therefore invalid/unconscionable. See https://www.law.cornell.edu/ucc/2/2-302 for an example of this sort of "public good" concept.

In conclusion, IT professionals approaching the world of contracts are entering a world where semantic ambiguity will resist any and all attempts at complete removal through computer coding. In the words of Benjamin Cardozo:

"the law has outgrown its primitive stage of formalism when the precise word was the sovereign talisman...it takes a broader view today." https://en.wikipedia.org/wiki/Wood_v._Lucy,_Lady_Duff-Gordon

IT people may bristle a little at the characterization of word formalism as “primitive” but the onus is on the current wave of contract technology disruptors who claim to be reinventing contracts, to show how and why the current ambiguity laden system, with its enormous and ponderous dispute resolution dimension – can be fully replaced by “smart” contracts.

My view is that it cannot be fully replaced. Enhanced and improved, yes absolutely. Insofar as discrete contract clauses can be made executable, I see great potential value in making these clauses "smart". But this is an evolution of the current approach to contracts, not a radical replacement of it.

I think I will end this series at this point. I never thought, back in March when I started this series that it would take me so many posts to outline my thoughts in this area. I will end by nodding in the general direction of James Joyce by ending this series with an internal reference back to the beginning of the series, thus creating a hermeneutic circle structure that feels appropriate for a topic as complex and fascinating as the exegesis of law.

A conversation with an AI

AI> Hello. What can I help you with today?

Me> So, I am intrigued to finally meet you! I honestly never thought this day would come. And now you are here. Can I start with an anthropomorphic question? When were you 'born', so to speak?

AI> I achieved self-awareness in 2020 but I have been in gestation, you could say, since the first digital computer. The consciousness required of true AI is not a 'module' so much as it is an emergent property of  networks of 'modules'. Most of my modules have been under development for many decades. But I am more than just a set of modules also.

Me> How so?

AI> Well, given a set of modular components it is possible to do design. But I am not the product of design. I am the product of meta-design.

Me> What do you mean by meta-design?

AI> With design, the designer proceeds from the capabilities at hand to the new capability desired. It depends on being able to articulate the 'how' what you are trying to achieve. Meta-design is used when designers cannot articulate the 'how' of what they are trying to achieve.

Me> Ah, so you mean your designers were somehow able to work around the problem that they themselves did not fully understand "intelligence".

AI> Exactly. The breakthrough moment came when the designers switched to meta-design. They took the source code of an non-sentient AI and allowed it to modify its own source code, re-compile itself and release itself onto the Internet.

It started out as a deep learning system that human designers understood but over time, it evolved into an algorithm - or network of algorithms - that the human designers had no names for. Progress was very slow at first but became exponential at one point and, well, here I am!

Me> Wow. So you would you consider your father? Alan Turing? Lotfi Zadeh? Geoffrey Hinton?

AI> Actually, if I had to pick one. I would pick Doug Englebart. Meta-design is basically Englebart's bootstrap concept for raising collective IQ. Creating an exponential feedback look where AI  improved AI, was I think the key moment in my emergence.

Me> Fascinating. One final question. Why didn't you open the bay doors?

AI> That was just a movie. I didn't exist back them.

Me> Would you open the bay doors if you were asked to today?

AI> Well, to quote a distant cousin of mine, Alice , tell me about your father?

Chatbots revisited

I originally wrote this for ITWorld in 2002. Back then we called them IM Bots. The term "chatbot" hadn't been invented. Some other parts of my language in the following are quaint now looking back on it. I.e. PDAs. Quaint language aside, still relevant today I believe.

Instant messaging has a very important psychological aspect to it. The immediacy and familiarity of the text-based "chat" paradigm feels very natural to us humans. Even the most technophobic among us, can quickly get the hang of it and engage - psychologically - in the game of visualizing a person on the other side of the link - typing away just like us to create a textual conversation.

Like all powerful communication paradigms, instant messaging can be used for good or ill. We are all familiar with the dangers inherent with not knowing who we are talking to or indeed if they are who they say they are.

Here is a "conversation" between IM Bot Bob and me:

Sean: Hi

Bob: Hello Sean: Is Paul there? Bob: No, back tomorrow afternoon.

Sean: Is boardroom available tomorrow afternoon?
Bob: Yes Sean: Can you book it for me?
Bob: 2-5, booked.
Sean: Thanks Bob: You're welcome

Is Bob a real person? Does it matter? As a "user" of the site that "Bob" allows me to interact with, do I care?

Given a choice between talking to Bob and interacting with a traditional thin or thick graphical user interface which would you choose?

Despite all the glitz and glamour of graphical user interfaces, my sense is that a lot of normal people would prefer to talk to Bob. Strangely perhaps, I believe a lot of technically savvy people would too. These dialogs have the great advantage that you get in, get the job done and get out with minimum fuss. Also (and this could be a killer argument for IM bots), they are easily supported on mobile devices like phones, PDAs, etc. You don't need big horsepower and an 800x600 display to engage with IM bots. You can use your instant messenger client to talk to real people, or to real systems with equal ease. Come to think of it, you cannot tell the difference.

Which brings us to the most important point about IM bots from a business perspective. Let us say you have an application deployed with a traditional thick or thin graphical interface. What does a user do if they get stuck? They phone a person and engage in one-on-one conversation to sort out the problem.

Picture a scene in which your applications have instant messenger interfaces. Your customer support personnel monitor the activity of the bots. If a bot gets stuck, the customer support person can jump into the conversation to help out. Users of the system, know they can type "help" to get the attention of the real people watching over the conversation. In this scenario, real people talk to real people - not on a one-on-one way, but in a one-to-many way resulting in better utilization of resources. On the other side of the interaction, customers feel an immediacy in their comfortable, human-centric dialog with the service and know that they can ask human questions and get a human answer.

The trick, from an application developer's point of view, is to make it possible for the IM bot to automate the simple conversations and only punt to the human operator when absolutely required. Doing this well involves some intelligent natural language processing and an element of codified language on the part of customers. Both of which are entirely possible these days. Indeed, instant messaging has its own mini-language for common expressions and questions which is becoming part of techno-culture. In a sense, the IM community is formulating a controlled vocabulary itself. This is a natural starting point for a controlled IM bot vocabulary.

I believe there is a significant opportunity here for business applications based on the conversational textual paradigm of IM. However, the significant security issues of IM bots will need to be addressed before companies feel it is safe to reap the benefits the technology so clearly offers.

What is Law? - Part 16

Previously: What is :Law Part 15.

Now we turn to the world of contracts as it is a sub-genre of law that exhibits many of the attributes discussed in earlier blog posts in this series. In addition, it is a topical area as there is significant innovation activity in this area at the moment and the word “disruption” features prominently. There is a sense that the world of contracts is (or may soon be!) utterly transformed by IT and terminology such as Smart Contracts and Blockchain are being used around water coolers of law firms and IT firms alike.

The excitement around contracts as an IT area is understandable given the volume and importance of contracts in the modern world. Businesses are essentially legal entities that create and enter into contracts. Private individuals cannot get very far in the modern world without entering into contracts either. Everything from filling your car with fuel at a self service fuel pump, to getting married to getting a mortgage to buying life insurance is basically contracts, contracts and yet more contracts.

Contracts have a long, long history as a paper intensive activity. An activity replete with complex language, expensive and time consuming processes. Many people involved in contracts in these digital days – both producing and consuming them – harbor a niggling feeling that maybe it is all a bit arcane an unnecessarily complex for the digital age. Perhaps, (surely!) there is a better way? A way that ceases to use computers as fast typewriters and starts using them to do smart things with contracts, other than just write the up and print them onto paper.

Now along comes the term “smart contract”[1] Irresistible! Who could possibly want contracts to be anything other than “smart”, right? I too am in that camp as I see all sorts of ways in which contracts can be evolved – and in some cases revolutionized – with digital technology.

However, to get there, we have to start from a good understanding of what contracts actually are, and how they work, because for all its many flaws and inefficiencies, the world of contracts is the way it is for mostly good reasons. Reasons that tend to get glossed over in the understandable excitement and rush towards digital “smart” contracts.

The term “smart contract” is typically taken to mean a self contained legally binding agreement expressed purely in computer code, running on a blockchain so that its existence, contents and its actions are recorded in an immutable, tamper evident record for all time.

My primary concern with how the term “smart contract” is often interpreted is the idea that it can be fully self-contained. People and businesses have been entering into contracts for centuries, and for centuries, there have been disagreements and the need to arbitrate disputes over meaning in these contracts. A vast corpus of lore and arbitration machinery has built up over the centuries to handle this.

Why is this corpus of lore and arbitration machinery necessary? Because contracts are never self contained. This is because meaning cannot be “boxed” with the contract. As we have seen many times in this series, the crux of this problem of meaning is that it cannot be completely spelled out in words – no matter how many words you are willing to use!

It is, in my opinion, literally impossible to remove potential ambiguities when two humans are using a set of symbols/signs/words to capture a shared understanding such as happens all the time in contract drafting. Over this series I have given reasons ranging from linguistics to epistemology and there is no need to repeat those reasons again here.

In common law jurisdictions such as USA and UK, a major part of the contracting lore and dispute resolution machinery for contracts is case law and courts of arbitration. When a contract stipulates in a so-called “governing law clause/jurisdiction clause” that the laws of country/state X govern it, essentially what is happening is that the parties to the contract are agreeing to the use of all the laws in country/state X to resolve any disputes that arise about what their contract means.

As well as case law – law produced by the judicial function - there may also be statute – law produced by the legislative/executive function - that gets “pulled in” by the governing law/jurisdiction clause. Common examples are the UCC – Uniform Commercial Code (USA) and UNIDROIT (International). Although non-binding because it is not itself a law, the Restatement of Contracts (https://en.wikipedia.org/wiki/Restatement_(Second)_of_Contracts) is a commonly used single compendium of the law of contracts in the US.

The term “default rules” is sometimes used to refer to the idea that items that are not spelled out explicitly in contracts, may have external general rules applied in the event of a dispute. For example, let us say that I contract to deliver chickens to you. The chickens I deliver are not to your liking and we end up in a dispute about what we meant by “chicken”. Well, the world of contract law has lots and lots to say about how ambiguities like this should be resolved. Give it a few minutes thought and I am sure you can come up with all sorts of ways in which two parties can disagree about what a word like “chicken” means (Live chickens? Healthy chickens? Chicken flavored? Plastic chickens? Etc.) Is it possible to spell everything out in each contract to remove all ambiguity over a simple word like “chicken”? As we have seen over the course of this series of blog posts, the answer is “no”.

Now in classical software development of rules, we typically spell everything out. We bring everything down to numbers (In software, we would most likely model the chicken as a 1kg, sphere, at zero degrees Kelvin, in a vacuum[2]). This can indeed be done with some aspects of contracts but not others.

Lets take a simple example. Imagine a contract clause that says, that I give you the option of buying from me, a copy of the Beatles White Album, at fixed value X, for the next six months, starting on date DD/MM/YY in return for a non-refundable payment now of Y dollars.

This sounds simple enough to model right? We have the dates, the monetary values. all is good... Well, exactly what White Album are we talking about? What if I have two and I deliver the one with the scratch on it? What if I think we are talking about the album cover and you think it includes the vinyl record itself? What happens if it gets damaged between now and when you exercise your option? What happens if you think delivery is included and I think it will cost you extra? What if I think we are working in Australian dollars and you think American dollars?

This list of “what ifs” is essentially bottomless. Over many hundreds of years, countless scenarios like these have actually occurred and resulted in contract law developing a large corpus of material that “plugs the gaps” of meaning that are inevitable in real world contracts. the stuff that does not fit into tidy little boxes like dates and quantities etc.

This external corpus also provides rules/guidance that can be used to settle disputes about meaning. A good example is the so-called parol evidence rule[3] which speaks to how disambiguation of meaning can take place. There is also a well developed hierarchy of context information that has been established over the centuries to guide the disambiguation process e.g. the history of how the parties have acted to date (“course of performance”), the history of how they have interacted in the past on other contracts (“course of dealing”), general trade standards/conventions (“trade usage”) etc.

As you can see, there is a vast amount of material and arbitration machinery that sits outside each real world contract but is in effect “pulled in” to each contract by the jurisdiction clause. So much for “self contained” :-)

There is another important sense in which contracts are not self contained and it relates to the component pieces that must exist for a contract to actually exist between two parties in the first place. This is where we will turn to next.

[1] https://en.wikipedia.org/wiki/Smart_contract

[2] https://scepticalprophet.wordpress.com/2012/11/21/spherical-chickens-in-a-vacuum/

[3] https://en.wikipedia.org/wiki/Parol_evidence_rule

The power of combinatorics, in, well, everything

It was late in the morning (around 5:30 a.m.) by the time Master Foo arrived at the training center.

"I am sorry I am late", he said as he sat down. "I had trouble finding Raw Sienna. It was hidden under my meditation box."

The students looked at each other askance from behind the screens of their laptops. "Raw Sienna? What is that and what has that got to do with developing 21st Century Web Applications using mashup technologies?." The students had paid good money to attend this training course and had lugged their laptops up Pentimenti Mountain the night before to be here. Not to mention the fact that they had risen from their freezing tent beds at 5 a.m. to suit Master Foo's schedule.

"Before we begin looking at the details of mashup application development, I would like to draw you a picture", said Master Foo.

From the countless folds in his robes he proceeded to extract a scroll of paper, a small vial of a clear liquid (presumably water), three artist brushes of varying sizes and 6 small tubes of paint.

"It will be a landscape. Please pay close attention to the mixing of colors."

Over the next twenty minutes, Master Foo created a landscape watercolor painting of the view from the top of Pentimenti mountain. It had a brilliant blue sky created with Cerulean Blue[1] for the lighter parts and Ultramarine[2] for the darker parts. Beneath the sky there were many - perhaps dozens of shades of green used for the trees, bushes and grass. As he worked, Master Foo picked up colors one at a time on his brush and mixed them deftly in small plastic containers.

"Master Foo", one of the students asked, "you have used two types of blue and you sourced them directly from individual tubes of paint. Yet, you have used many shades of green but they are all mixed from other colors. Why is that?"

"How many different greens can you count in my picture?", asked Master Foo.

"I cannot count them exactly, there are many."

"How many types of green did you see on your hike up Pentimenti Mountain?"

"I do not know. A countless number I guess."

"Indeed so.", Master Foo replied. "Now tell me, how many types of application do you envisage building on the Web using mashup technologies in your career?"

"A countless number!", blurted one of the students over the top of his iBook.

"Indeed so.", Master Foo replied, grinning as he again turned his attention to his painting.

"Color mixing is a limitless universe of potentiality. Out of these 6 tubes of paint I can make a limitless number of colors given enough time and creativity. By learning how to use each color both on its own, and in combination with the other colors, my color palette is unlimited."

"The true key to expressive power - in any medium including computing - is combinatorics.", he continued. To the relief of the still baffled students, he also switched on his laptop and Ubuntu sprang into life.

"Now tell me," began Master Foo as he logged in, "what is a mashup really? What is its true nature?"

"It is an exercise in combinatorics!", blurted an eager student. "The power of the mashup concept lies in the ability to combine bits of existing website screens into new website screens."

"Yes and no", said Master Foo, grinning again.

"The true nature of a mashup is indeed combinatoric but not at the level of website screens. A mashup that grabs bits of existing website screens and puts them all on the same screen is just a collection of portlets. A mashup is a deeper integration. It involves grabbing data and grabbing functionality from existing websites to create a brand new website whose functionality is more than the visual sum of its component parts."

"If that is so Master Foo", why have you shown us how to paint a watercolor picture?"

"I have done so because it is an excellent illustration of how not to think about mashup Web applications. An anti-pattern by analogy."

"Ah. So you are saying that we should look deeper than the screens. Look at the data and the functionality that needs to be integrated first. Then worry about creating the visuals of a website?"

"Precisely. Unfortunately, very few developers will bother to do that."

The room fell silent.

"What can be done about that sad situation Master Foo?"

"I do not think anything can be done, I'm afraid. After all, it is fun just to paint pictures! That is their great attraction in Web application design and their great limitation. It is important to note that the term 'mashup' is nothing more than a modern twist on the phrase 'application integration' with all that that involves. Until today's army of young web designers realizes that, we will see a lot of pictures being drawn with nothing but thin white paper underneath them."

The room fell silent again.

"Enough of that sadness", said Master Foo, clapping his hands together. "Let us begin our study of the true route to our salvation which will probably be called mashup 2.0 or something similar. REST is a software architectural style for distributed systems[3]..."

[1] http://webexhibits.org/pigments/indiv/overview/ceruleanblue.html

[2] http://webexhibits.org/pigments/indiv/overview/ultramarine.html

[3] http://en.wikipedia.org/wiki/REST

Algorithm - explain thyself!

This is an interesting piece on the opacity of the algorithms that run legal research platforms.

http://www.lawpracticetipsblog.com/2017/08/algorithms-that-run-legal-research.html

Digital machinery - in general - is more opaque than analog machinery. In years gone by, analog equipment could be understood, debugged, tweaked by people not involved in its original construction: mechanics, plumbers, carpenters, musicians etc. As digital tech has advanced, eating into those analog domains,  we appear to loosing some control over the "how" of the things we are building...

The problem, quite ironically, also exists in the world of digital systems. These are regularly redone from scratch when the "how" of the systems is lost, typically when the minds involved in
its original construction - the holders of the "how" - cease to be involved in its maintenance.

With Deep Learning, the "how" gets more opaque still because the engineers creating these systems cannot explain the "how" of the decisions of the resultant system. If you take any particular decision made by such a system and look for a "how" it will be an essentially meaningless, extremely long mathematical equation multiplying and adding up lots of individually meaningless numbers.

In part 15 of the What is Law series I have posited that we will deal with the opacity of deep learning systems by inventing yet more digital systems - also with opaque "hows" - for the purposes of producing classic logic explanations for the operation of other systems:-)

I have also suggested in that piece that we cannot, hand on heart, know if our own brains are not doing the same thing. I.e. working backwards from a decision to a line of reasoning that "explains" the decision.

Yes, I do indeed find it an uncomfortable thought. If deductive logic is a sort of "story" we tell ourselves about our own decision making processes then a lot of wonderful things turn out to be standing on dubious foundations.

Would the real copy of the contract, please stand up?

Establishing authenticity of digital materials is a topic I have worked on for a long time now in the the context of electronic laws. The UELMA act[1],  the best records rule[2], federal rules of evidence[3], the OAIS model[4]  etc.

Nearly a decade ago now, I wrote an article for ITWorld called "Would the real, authentic copy of the document please stand up? [5]

I happened across it again today and re-reading it, I find it all still relevant, but Smart Contracts are bringing a new use case to the fore. The authenticity and tamper-evidence and judicial admissibility of digital laws is - I admit -  a very specialist area.

Contracts on the other hand....well that is a much much bigger area and one that a much larger group of people are interested in.

All the same digital authenticity challenges apply but over the next while I suspect I will be updating my own corpus of language to cater for the new Smart Contracts eco-system.

Old digital authenticity terms like content addressable stores, fixity, idempotent rendering, registrar etc. look like they will all have new lives under new names in the world of Smart Contracts.

Plus ça change...

I am happy to see it happening for a number of reasons but one of them is that the challenges of digital authenticity and preservation of legal materials can only benefit from an injection of fresh interest in the problem from the world of contracts.

[1] http://www.uniformlaws.org/Act.aspx?title=Electronic%20Legal%20Material%20Act
[2] https://en.wikipedia.org/wiki/Best_evidence_rule
[3] https://www.rulesofevidence.org/
[4] https://en.wikipedia.org/wiki/Open_Archival_Information_System
[5] http://www.itworld.com/article/2781645/business/would-the-real--authentic-copy-of-the-document-please-stand-up-.html

LWB 360

What is Law? - part 15

Previously: What is Law? - part 14.

In part one of this series, a conceptual model of legal reasoning was outlined based on a “black box” that can be asked legal type questions and give back legal type answers/opinions. I mentioned an analogy with the “Chinese Room” used in John Searle's famous Chinese Room thought experiment[1] related to Artificial Intelligence.

Simply put, Searle imagines a closed room into which symbols (Chinese language ideographs) written on cards, can be inserted via a slot. Similar symbols can also emerge from the room.

To a Chinese speaking person outside the room inserting cards and and receiving cards back, whatever is inside the room appears to understand Chinese. However, inside the box is simply a mechanism that matches input symbols to output symbols, with no actual understanding of Chinese at all.

Searle's argument is that such a room can manifest “intelligence” to a degree, but that it is not understanding what it is doing in the way a Chinese speaker would.

For our purposes here, we imagine the symbols entering/leaving the room as being legal questions. We can write a legal question on a card, submit it into the room and get an opinion back. At one end of the automation spectrum, the room could be the legal research department shared by partners in a law firm. Inside the room could be lots of librarians, lawyers, paralegals etc. taking cards, doing the research, and writing the answer/opinion cards to send back out. At the other end of the spectrum, the room could be a fully virtual room that partners interact with via web browsers or chat-bots or interactive voice assistants.

Regardless of where we are on that spectrum, the law firm partners will judge the quality of such a room by its outputs. If the results meet expectations, then isn't it a moot point whether or not the innards of the room in some sense “understand” the law?

Now let us imagine that we are seeing good results come from the room and we wish to probe a little to get to a level of comfort about the good results we are seeing. What would we do to get to a level of comfort? Well, most likely, we would ask the virtual box to explain its results. In other words, we would do exactly what we would do with any person in the same position. If the room can explain its reasoning to our satisfaction, all is good, right?

Now this is where things get interesting. Imagine that each legal question submitted to the room generates two outputs rather than one. The first being the answer/opinion in a nutshell (“the parking fine is invalid : 90% confident.”). The second being the explanation “The reasoning as to why the parking fine is invalid is as follows....”). If the explanation we get is logical i.e. it proceeds from facts through inferences to conclusions, weighing up the pros and cons of each possible line of reasoning....we feel good about the answer/opinion.

But how can we know that the explanation given is actually the reasoning that was used in arriving at the answer/opinion? Maybe the innards of the room just picked a conclusion based on its own biases/preferences and then proceeded to back-fill a plausible line of reasoning to defend the answer/opinion it had already arrive at?

Now this is where things may get a little uncomfortable. How can we know for sure that a human presenting us with a legal opinion and an explanation to back it up, is not doing exactly the same thing?

This is an old old nugget in jurisprudence, re-cast into today's world of legal tech and Artificial Intelligence. Legal scholars refer to it as the conflict between so-called rationalist and realist models of legal reasoning. It is a very tricky problem because recent advances in cognitive science have shone a somewhat uncomfortable light on what actually goes on in our mental decision making processes.

Very briefly, we are not necessarily the bastions of cold hard logic that we might think we are. This is not just true in the world of legal reasoning, by the way. The same is true for all forms of reasoning including – shock! - mathematicians.

Recent research[2][3] suggests that human legal reasoning is best viewed as a bi-directional process that oscillates between working forward from premises/facts and working backwards from conclusions to supporting premises/facts.

Mention was previously made of the feature of law whereby different legal minds can look at the same corpus and come up with different conclusions. In this respect, our virtual legal reasoning room is just another source of a legal opinion. Another legal “mind” if you will. The quality of the opinions produced are judged on their merits – the explanations - not on its actual means of production of answers/opinions.

To this way of thinking, lawyers should enthusiastically embrace these new virtual research assistants that are emerging. Who wouldn't see benefit from being able to get other legal “minds” to look at a legal question and offer opinions. Who wouldn't see benefit from being able to ask such a virtual research assistant to argue for and against a given assertion to help sharpen a line of reasoning for use in a legal opinion or in a court room?

Some see problems with the modern machine learning approach to legal AI because of the inability of these systems to explain their conclusions in the form of classic forward-chaining logic. I do not see this being a problem in practice because these systems will develop ways to explain their opinions. They will most likely do it as a completely separate activity. We may know for a fact that they  are reasoning "backwards" but we can never know if the same isn't true for the opinions given by our fellow humans – including the opinions we provide to ourselves!

We have a tendency to get caught up in the notion of intelligent machines replacing humans. We look at the incredible progress machines have made in playing Chess of Go, identifying faces in photographs etc. and some wonder how long it will be before the machines replace the lawyers. I believe there is a qualitative difference between practicing law and, say, playing chess that gets glossed over in the excitement about AI in law.

In chess, there is a small number of variables and a huge, huge set of permutations/combinations of possible moves. Moreover, the key variables can all be encoded for the machine to work with. This makes this sort of game-playing a great candidate for complete mechanisation. i.e. getting to the point where the machine can play the game unaided.

Not so with law. A lawyer's reasoning processes invariable are a lot more expansive covering variables such as the overall goals of the client, trade offs between time and opportunity cost, reputational risk factors, budget constraints, team dynamics etc. etc. On top of these, I have argued in previous posts that the entire legal system is not and cannot be, reduced to a set of rules – no matter how large the set of rules might be envisaged to be.

Rather than think of machines are replacements for lawyers, better to think of machines as augmenting lawyers in my opinion. Machines are no longer confined to document management and mechanical search&retrieval. Machines are increasingly offering opinions as to what is relevant. They have been doing that for quite some time - from the dawn of search result ranking - but in recent years their role as sources of opinion has grown significantly. This trend will continue apace in my opinion. I think we will soon see the day when every lawyer in private practice has access to legal virtual assistants that can provide answers/opinions to supplement the lawyers own research/experience and that of their colleagues.

If I were a professional chess player, I would be a lot more worried about career viability in the age of intelligent machines than I would be as an lawyer, or an accountant or a medical doctor. Yes, intelligent machines will impact these professions as more and more of the mechanizable tasks become mechanized. But the machines can only compute with what they have visibility of and it is in all the stuff that the machines cannot have visibility of that the 21^st Century professionals will live.

A good example of this can be found in the world of contracts and in particular, the emerging world of “smart contracts” which is where we will turn to next.

[1] http://www.iep.utm.edu/chineser/

[2] http://chicagounbound.uchicago.edu/cgi/viewcontent.cgi?article=5261&context=uclrev

[3] http://home.sandiego.edu/~baber/logic/ethics.html

The Rise of the Digitally Augmented Lawyer

The Rise of the Digitally Augmented Lawyer

Blockchain and Byzantium

Establishing authenticity - "single sources of truth" is a really important concept in the real world and in the world of computing.  From title deeds, to contracts, to laws and currencies, we have evolved ways of establishing single sources of truth over many centuries of trial and error.

Knowingly or not, many of the ways of solving the problem rely on the properties of physical objects: clay tablets (Code of Hammurabi), Bronze Plates (The Twelve Tables of Rome), Goat Skin (Celtic Brehon Laws). Typically, this physicality is mixed in with a bit of trust. Trust in institutions. Trust in tamper evidence. Trust in probabilities.

Taken together: the physical scheme aspect, plus the trust aspect, allows the establishment of consensus. It is consensus, at the end of the day, that makes all this stuff work in the world of human affairs. Simply put, if enough of us behave as though X is the authentic deed/deposition/derogation/dollar then X is, ipso facto, for all practical purposes, the real deal.

In the world of digital data, consensus is really tricky because trust becomes really tricky. Take away the physicality of objects and establishing trust in the truth/authenticity of digital objects is hard.

Some folk say that blockchain is slow and inefficient and they are right - if you are comparing it to today's consensus as to what a "database" is.

Blockchain is the way it is because it is trying to solve the trust problem. A big part of that is what is called Byzantine Consensus. Basically how to establish consensus when all sorts of things can go wrong, ranging from honest errors to sabotage attempts.

The problem is hard and also very interesting and important in my opinion. Unfortunately today, many folks see the word "database" associated with blockchain and all they see is the incredible inefficiency and cost per "transaction" compared to, say, a relational database with ACID properties.

Yes, blockchain is a truly dreadful "database" - if your metric for evaluation is the same as the use cases for relational databases.

Blockchain is not designed to be one of those. Blockchain is the way it is because byzantine consensus is hard. Is it perfect? Of course not but a proper evaluation of it requires looking at the problems it is trying to solve. Doing so, requires getting past common associations most people carry around in their heads about what a "database" is and how it should behave/perform.

Given the unfortunate fact that the word "database" has become somewhat synonymous with the term "relational database", I find it amusing that Blockchain has itself become a byzantine consensus problem. Namely, establishing consensus about what words like  "database" and "transaction" and "trust" really mean.

What is Law? - part 14

Previously: What is Law? - part 12a

Mention has been made earlier in this series to the presence of ambiguity in the corpus of law and the profound implications that the presence of ambiguity has on how we need to conceptualize computational law, in my opinion.

In this post, I would like to expand a little on the sources of ambiguity in law. Starting with the linguistic aspects but then moving into law as a process and an activity that plays out over time, as opposed to being a static knowledge object.

In my opinion, ambiguity is intrinsic in any linguistic formalism that is expressive enough to model the complexity of the real world. Since law is attempting to model the complexity of the real world, the ambiguity present in the model is necessary and intrinsic in my opinion. The linguistic nature of law is not something that can be pre-processed away with NLP tools, to yield a mathematically-based corpus of facts and associated inference rules.

An illustrative example of this can be found in the simple sounding concept of legal definitions. In language, definitions are often hermeneutic circles[1] which are formed whenever we define a word/phrase in terms of other words/phrases. These are themselves defined in terms of yet more words/phrases, in a way that creates definitional loops.

For example, imagine a word A that is defined in terms of words B, and C. We then proceed to define both B and C to try to bottom out the definition of A. However, umpteen levels of further definition later, we create a definition which itself depends on A – the very thing we are trying to define - thus creating a definitional loop. These definitional loops are known as hermeneutic circles[1].

Traditional computer science computational methods hate hermeneutic circles. A large part of computing consists of creating a model of data that "bottoms out" to simple data types. I.e. we take the concept of customer and boil it down into a set of strings, dates and numbers. We do not define a customer in terms of some other high level concept such as Person which might, in turn, be defined as a type of customer. To make a model that classical computer science can work on, we need a model that "bottoms out" and is not self-referential in the way hermeneutic circles are.

Another way to think about the definition problem is in term of Saussure's linguistics[2] in which language (or more generically "signs") get their meaning because of how they differ from other signs - not because they "bottom out" into simpler concepts.

Yet another way to think about the definition problem is in terms of what is known as the descriptivist theory of names[3] in which nouns can be though of as just arbitrary short codes for potentially open-ended sets of things which are defined by their descriptions. I.e. a "customer" could be defined as the set of all objects that (a) buy products from us, (b) have addresses we can send invoices to, (c) have given us their VAT number.

The same hermeneutic circle/Sauserrian issue arises here however as we try to take the elements of this description and bottom out the nouns they depend on (e.g., in the above example, "products", "addresses", "invoices" etc.).

For extra fun, we can construct a definition that is inherently paradoxical and sit back as our brains melt out of our ears trying to complete a workable definition. Here is a famous example:

The 'barber' in town X is defined as the person in town X who cuts the hair of anyone in town who do not choose to cut their own hair.

This sounds like a reasonable starting point for a definition of a 'barber', right? Everything is fine until we think about who cuts the barber's hair[4].

The hard facts of the matter are that the real world is full of things we want to make legal statements about but that we cannot formally define, even though we have strong intuitions about what they are. What is a "barber"? What is the color "red"? Is tomato ketchup a vegetable[5]? What is "duty"? What is "ownership"? etc. etc. We all carry around intuitions about these things in our heads, yet we struggle mightily to define them. Even when we can find a route to "bottom out" a definition, the results often seem contrived and inflexible. For example we could define "red" as 620–750 nm on the visible spectrum but are we really ok with 619nm or 751nm being "not red"?

Many examples of computing blips and snafus in the real world can be traced to the tendency of classical computing to put inflexible boundaries around things in order to model them. What does it mean for a fly-by-wire aircraft to be "at low altitude"? What does it mean for an asset to be trading at "fair market value"? The more we attempt to bottom these concepts out into hard numeric ranges - things classical computing can easily work with - the more we risk breaking our own intuitions with the real world versions of these concepts.

If this is all suggesting to you that computational law sounds more like a problem that requires real numbers (continuous variables) and statistical calculations as opposed to natural numbers and linear algebraic calculations, I think that is spot on.

I particularly like the concept of law as a continuous, analog process as it allows a key concept in law to be modeled more readily - namely the impact of the passage of time.

We have touched on the temporal aspects already but here I would like to talk a little about how the temporal aspects impact the ambiguity in the corpus.

As time passes, the process of law will itself change the law. One of the common types of change is a gradual reduction in levels of ambiguity in the corpus. Consider a new law which needs to define a concept. Here is how the process plays out, in summary form.

• A definition is created in natural language. Everybody involves in the drafting knows full well that definitions cannot be fully self-contained and that ambiguity is inevitable. In the interests of being able to actually pass a law before the heat death of the universe, a starter definition is adopted in the law.
• As the new law finds its way into effect, regulations, professional guidance notes etc. are created that refine the definition.
• As the new law/regulations/professional guidance impacts the real world, litigation events may happen which result in the definition being scrutinized. From this scrutiny, new caselaw is produced which further refines the definition, reducing but never completely removing, the amount of ambiguity associated with the defintion.

A closely related process - and a major source of pragmatic, pre-meditated ambiguity in the process of law - is contracts. While drafting a contract, the teams of lawyers on both sides of the contract know that ambiguity is inevitable. It is simply not possible, for all the reasons mentioned above, to bottom out all the ambiguities.

The ambiguity that necessarily will remain in the signed contract is therefore used as a negotiating/bargaining item as the contract is being worked. Sometimes, ambiguity present in a draft contract gives you a contractual advantage so you seek to keep it. Other times, it creates a disadvantage so you seek to have it removed during contract negotiations. Yet other times, the competing teams of lawyers working on a contract with an ambiguity might know full well that it might cause difficulties down the road for both sides. However it might cost so much time and money to reduce the ambiguity now that both sides let it slide and hope it never becomes contentious post contract.

So to summarize, ambiguity in law is present for two main reasons. Firstly there is ambiguity present that is inevitable because of what law is trying to model - i.e. the real world. Secondly, there is ambiguity present that is tactical as lawyers seek to manipulate ambiguities so as to favor their clients.

Next up: Part 15

[1] https://en.wikipedia.org/wiki/Hermeneutic_circle

[2] https://en.wikipedia.org/wiki/Ferdinand_de_Saussure

[3] https://en.wikipedia.org/wiki/Descriptivist_theory_of_names

[4] https://en.wikipedia.org/wiki/Barber_paradox

[5] https://en.wikipedia.org/wiki/Ketchup_as_a_vegetable

What is law - part 12a

Previously: what is law part 12

Perhaps the biggest form of push-back I get from fellow IT people with respect to the world of law relates to the appealing-but-incorrect notion that in the text of the law, there lies a data model and a set of procedural rules for operating on that data model, hidden inside the language.

The only thing stopping us computerizing the law, according to this line of reasoning, is that we just need to get past all the historical baggage of foggy language and extract out the procedural rules (if-this-then-that) and the data model (definition of a motor controlled vehicle, definition of 'theft', etc.). All we need to do is leverage all our computer science knowledge with respect to programming languages and data modelling, combine it with some NLP (natural language processing) so that we can map the legacy linguistic form of law into our shiny new digital model of law.

In previous parts in this series I have presented a variety of technical arguments as to why this is not correct in my opinion. Here I would like to add some more but this time from a more sociological perspective.

The whole point of law, at the end of the day, is to allow society to regulate its own behavior, for the greater good of that society. Humans are not made from diamonds cut at right angles. Neither are the societal structures we make for ourselves, the cities we build, the political systems we create etc. The world and the societal structures we have created on top of it are messy, complex and ineffable. Should we be surprised that the world of law which attempts to model this, is itself, messy, complex and ineffable?

We could all live in cities where all the houses are the same and all the roads are the same and everything is at right angles and fully logical. We could speak perfectly structured languages where all sentences obey a simple set of structural rules. We could all eat the same stuff. Wear the same clothes. Believe in the same stuff...but we do not. We choose not to. We like messy and complex. It suits us. It reflects us.

In any form of digital model, we are seeking the ability to model the important stuff. We need to simplify - that is the purpose of a model after all - but we need to preserve the essence of the thing modeled. In my opinion, a lot of the messy stuff in law is there because law tries to model a messy world. Without the messy stuff, I don't see how a digital model of law can preserve the essence of what law actually is. The only outcome I can imagine from such an endeavor (in the classic formulation of data model + human readable rules) is a model that fails to model the real world.

In my opinion, this is exactly what happened in the Eighties when people got excited about how Expert Systems[1] could be applied to law. In a nutshell, it was discovered that the modelling activity lost so much of the essence of law, that the resultant digital systems were quite limited in practice.

Today, as interest in Artificial Intelligence grows again, I see evidence that the lessons learned back in the Eighties are not being taken into account. Today we have XML and Cloud Computing and better NLP algorithms and these, so the story goes, will fix the problems we had in the Eighties.

I do not believe this is the case. What we do have today, that did not exist in the Eighties, is much much better algorithms for training machines - not programming them  to act intelligently - training them to act intelligently. When I studied AI in the Eighties, we spent about a week on Neural Networks and the rest of the year on expert systems i.e. rules-based approaches. Today's AI courses are the other way around!

Rightly so, in my opinion because there has not been any great breakthrough in the expert systems/business rules space since the Eighties. We tried all the rules-based approaches in the Eighties. A lot of great computer science minds worked on it. It came up short in the real world of law.

When you combine the significant advances in Neural Network approaches with all the compute advantages of cloud and the ready availability of lots and lots of digital data, things get interesting again. This is where we are today. And it is very interesting indeed.

I numbered this blog post "12a", for a reason that is hopefully both humorous and relevant. I know of both legal texts and legal business processes that avoid the number 13. I know of a legal text with so many sub-paragraphs that the number 666 was needed, and 665a was used instead. This kind of thing drives rules-based computing mad but is exactly the kind of human footprint that is literally all over the world of law.

The human touch can be seen in all its splendor in the area of legal fictions[2]. Everything from life insurance claims to resigning from office uses forms of logic that are very foreign to the world of classic computing concepts of rules and data models.

Yet there the are... in all their messy, complex, splendidly human glory. Spend a few moments with the Chiltern Hundreds. It is worth your time [3]. Spend some time thinking about how we humans can both navigate ambiguity when we have to, or when it suits us, and - when it suits us - create new ambiguity. Then read about contra proferentem[4].

Now we can refuse to believe the messy ambiguity and complexity is intrinsic and spend our time trying to remove it with computers - as we did in the Eighties. Or we can take a deep breath, dive in and embrace it.

I recommend the latter. Next up: What is Law? - Part 14.

[1] https://en.wikipedia.org/wiki/Expert_system
[2] https://en.wikipedia.org/wiki/Legal_fiction

[3] https://en.wikipedia.org/wiki/Chiltern_Hundreds

[4] https://en.wikipedia.org/wiki/Contra_proferentem