The heck is CommonAccord?

[HazardJ]

In response to general confusion (now roughly five years of maturity) and to conversation on Slack with @Ludachrispeed and @eli-oat, and live yesterday with @dazzaji:

Dazza:

Good talking yesterday. Following up on our discussions, herewith an attempt at an overview:

CommonAccord has a number of threads, including:

A. This repo of legal boilerplate - clauses and forms - that render into documents and can be manipulated like source code. The materials are organized using the format we call Cmacc ("smack"). The materials are human-readable. Cmacc provides native versioning (a document or clause library can be versioned or repurposed by making a new list that "includes" the existing one and overrides elements individually and in groups). In addition, the canonical repo is on Github and can be forked, backtraced and proved using git.

Actual transactions take the form of lists of deal points, overrides and links to objects (again, lists of lists) for the document form, the persons, places, properties and other objects in the graph of law. These objects can be complex, such as courts, cases, and deals, compositions of other objects. Each list can be as private or public as the participants desire.

As a result, a persons' record of their position and history is a repo (personal data store) of lists of facts, events and links.

This repo of legal boilerplate is of course not exclusive, and others are encouraged (one small company has begun) to create their own repos of forms and clauses. The nature of law (and social relations?) is that solutions will gravitate towards standards and it is the goal of CommonAccord to foster convergence and diversity.

The short path to codification is to propose excellent forms for common transactions organized with clause-level modularity, then iterate. This is the legal equivalent of open source's "running code," with it's emphasis on immediate value and incremental improvement enabled by granularity.

Contract boilerplate is, substantively, distributed legislation - rules the parties adopt for self regulation, often displacing actual legislation and case law. Contract as a method is currently broken (as is legislation), notably by word processing and other blob-based approaches. It can be fixed by source methods, enabling social knowledge to work efficiently, just as it does in open-source projects. The disjointed way-points of the current legal ecosystem - rule adoption that runs from contract (two-by-two or many-by-one of sign or click to consent) at the one extreme to legislation (all-for-all-by-a-few), with some more functional intermediate points such as association rules, can be turned into a continuum of adoption like open-source. (This sentence needs a rewrite.)

B. Cmacc is the name we give for the data model. The data model is a graph composed of ordered lists of labeled text snippets (a "map" of key/values). At its core, Cmacc is the function that parses the graph to render texts. We have not fully explored the critical feature set of that function. I believe that the function expresses a general principle and there must somewhere be a body of knowledge that would enlighten us as to the other features of this function. So far, we (I) have developed it iteratively.

A hugely effective system (and all that is needed for legal codification) is comprised of:

1. In a record specified by URI or otherwise, treat the content as an ordered list of key/values.

1.0. The values are treated as:

1.1. text snippets, in which case the key is the label for the snippet, or

1.1. if the value is wrapped in [], the value is treated as the name of another list, in which case the key is a "prefix" to each key in the included list, and to each {variable} in each value in the included list. The prefix of an included list may be null, in which case the keys and variables in the included list is not prefixed. (More or less include vs include as.)

1. The lists are recursive, so an included list may include other lists. The prefixes are recursive. Duplicate instances of a particular key/name are permitted (indeed are the native method for versioning and repurposing).
2. Rendering a list, (rendering is always relative to a particular list) consists of:

2.1. Starting with a baby text consisting of a variable - (often, by default "{Model.Root}"), scan the list for a key that matches the variable, then, if not found, scan the first included list that might (considering the application of prefixing) possibly have a corresponding key, then any list included in that list (again only exploring lists whose prefix does not exclude a possible match), recursively, depth-first.

2.2. If the key is found, then:

2.2.1. the value is substituted for the "{variable}" and

2.2.2. the resulting string of text is scanned again for any {variable expressions}. (The variable, and matching key may include nearly any set of chaacters and spaces except a carriage return or close of curly brace, with some difficulties around leading and trailing spaces.)

2.2.3. This continues until all {variables} have been replaced or left in place because there is no corresponding key.

2.2.3. A {variable} in an included list will be evaluated with prefix. So {Name} in a value in a list that is included with the prefix "P1." would be evaluated as {P1.Name}. The search for a matching key will begin (as always) at the list that is being evaluated (not the included list). So if the evaluated list (or any other included list with higher priority) has a key "P1.Name" that will be used in priority over a key in the included list called "Name". (Of course when evaluating the included list, "{Name}" would be matched with its own key called "Name.")

2.2.4. If the prefixed form of the variable does not match any key in the list being evaluated and any included list (the name space of the list) then the prefix will be stripped off and the function will search again for a match. Where there are multible levels of prefixing (common) then the right-most (most deeply nested) prefix will be stripped first, then the second-right-most, etc.

2.2.4. There are some obvious extensions of the function that have never been implemented. For instance, a reference to an included list should be able to evaluate the included list with de-prefixing (e.g., reference a list of parties to a transaction or members of a group and use the list only for a particular person). And the name of an included list should be replaceable by overriding, e.g., [List_1]=[List_1A]. These seem to be part of a broader principle and it would be great to tap into what that principle was so that we don't have to invent by trial and error.

Cmacc is in theory independent of the parser and the list sugar. Our current version of the parser, by Primavera, is in perl, and the lists are flat files where key/value is extracted by looking for (NewLine)some string = some other string(CR). This makes the files extremely readable and a natural fit with a git repo. But these are only implementations. The parser for instance is completely compatible with lists expressed in one of our oldest systems, on Mediawiki).

Implementations that seem obvious extensions of the ecosystem include the blockchain, Personal Data Stores, JSON, XML and graph databases. Browser-based or light-weight app-based rendering seem to have the potential to onlock many "semantic web" distributed authoring and content models.

C. CommonAccord applies Cmacc to the legal domain, but Cmacc can also be used in education and other domains that could repurpose open source methods of connecting knowledge and sustained collaborative creation.