Many in these circles know about our work to simplify tech and law. Both are text exercises, each has developed complexities that prevent cross-fertilization. Legal tech can be recast on the principles of software engineering, without complexity. The result will be better transacting, relationships, management and law.

The Tech of Law inhibits efficiency.

The tech of law is horribly complicated, therefore inefficient. The root of the problem is that the legal profession works with compiled code — word processing documents. It is impossible to be efficient using compiled code. In addition to the intrinsic problems, very complex technology work-arounds have arisen for negotiation, management and post-hoc structuring (e-discovery).

Tech of Tech is Excellent

The tech of tech is much more efficient. This is not surprising since the producers of tech-tech are also its consumers. Software engineers use source code. Fundamentally, that means stating things once, with modularity, linking and versioning. State text snippets with structure. Give each structure a name. Reference (“include”) the structure to make the snippets available. Snapshot each meaningful moment by stating how it differs from a specified prior moment. The associated tools and methods, such as error-tracking, are equally rigorous and efficient.

Tech-Tech is overkill

Software engineers deal with problems so complex that their tools offer and demand more of users than is necessary in law. The full set of programming functions are not important in the legal domain. The text of law is short and repetitive as compared to computing. We rarely actually “run” the full code, often only when facing litigation. The participants almost always just want the diff, not the doc. 

Programming with a Single Button

A correct tech of law would retain the power of tech-tech while shedding the inessential. Ideally, a programming language with a single instruction. Metaphorically, one-button programming. Simplicity for the casual user (deal-maker), power for the expert (a lawyer codifying a field of expertise) and gradations in between.

That single button is “include.” In a phrase a {field} can be included. In a document a [Set_Of_Facts] can be included as a parent, making all of its facts available. Prefixing and priority do the rest. This is quickly learned with use. It can structure very complex relationships and resources. Object-oriented transacting.

Records, not Documents

Going further, the best “diff” is a bookkeeping entry — a diff on the relationship among the stakeholders. For example, a trade on the NYSE is a few data points. It does not need to be a complete closing binder because the trade has a context: the rules of the exchange, the disclosure documents of the company and the relationship of the participants to the exchange (hence to one another). The inventory of a person’s transactions should resemble a bank statement instead of a shoebox of documents where deal points are fused with re-restatements of law. In a typical shoebox (document management system), the great bulk is repetitive and inconsistent statements of rules. Some is repetitive and possibly inconsistent statements of facts. Only a tiny minority is deal points. They are untagged and buried in cruft.

Relationships, not Documents

If each relationship looks like a bank statement, the set of relationships should look like a Rolodex. Each participant has a list of other persons. The participant has a complete record of {her-his} history with those others. {She-He} also has as much information about the others and their relations inter se as those others have made public or shared privately.

Standard Non-Standards

Because the issues are repetitive while the medium (word processing) invites reinvention, there has arisen an odd but pervasive practice of very skilled lawyers reviewing long texts to verify that only familiar things were said. The problem is captured beautifully in a discussion from the recent “Future of Law” conference. See the “open source” link at, go to minute 40. Julio Avalos of GitHub kicks off the discussion, and Tim Stanley of Justia finishes it. (See also the discussion of computable contracts.)

The alternative — object-oriented transacting

All of this can be implemented in a simple knowledge management paradigm. A minimal set of objects in this environment is: persons, places, things, transactions (deal points and facts), operations (precedents for transactions), and relationships (the integral of past transactions).

Contact to see more.