I usually don’t comment directly on “competing” approaches to document automation, but am making an exception for the new www.openlaw.io (@openlaw1).  This is a serious effort by a serious group, with close ties to some of the people who have contributed to CommonAccord.  (I’ll call it OpenLaw1 because there are some other “Open Law”s, including our friends www.openlaw.fr.)  I learned about it today, just before the COALA/MIT workshop on blockchain and governance.

From my brief review, OpenLaw1 is a clean approach to document assembly and a great integration with two important technologies – IPFS and Ethereum.  I fully endorse both those integrations.

It’s approach to document assembly is great in that it uses a few simple embedded bits of code to enable insertion of parameters and alternatives.  It does this with a much more complete interface than CommonAccord’s software, almost all of which was done by Primavera De Filippi, one of the close connections to OpenLaw1’s team, and the co-organizer of COALA.

However, OpenLaw1 represents an important step backwards from #ProseObjects and the goals of a Centre for Decentralised Governance (slideshow for COALA/MIT and IACCM).  I’ll try to state with clarity why the document part is a step backwards.

The basic problem is that OpenLaw1 is a form of document assembly.  You end up with bunches of documents instead of an “object model” or “graph” of relationships.  The documents are much cleaner than Word, but still unstructured.
It’s much more useful to disassemble documents and refer to the components.  This expresses the object model, as a graph.
Some of the consequences of document assembly as opposed to document disassembly are:
  1. After filling in the blanks and making choices, the result is a full, not-very-structured document – a “blob.”  A better approach (#ProseObjects) is to keep the info structured – the “document” is the list of differences and completions plus the link to the form and objects for identities, etc.  When you want to view or save the full text, you render.  By retaining the structure, both machine and human reader have a structured representation of all aspects of the transaction, including its variances.
  2. The things that a person can modify in the OpenLaw1 document assembly model are limit to things decided in advance by the author of the form.  This kind of prescriptive prediction is the root of the failure of document assembly systems to lead to real codification.   If the author of the document wants to modify some other aspect of a document, they have to do it in the resulting output (e.g., in Word).  This makes the blob non-conforming in ways that will have to be picked up by NLP/AI, and it fails to leverage the knowledge represented in the set of changes for future work.  In CommonAccord, all elements of the document can be changed by adding to the list of changes, so everything stays structured and linked.  The author of the form does not have to predict and manage all variations – use makes the system into a quasi-neural learning system.
  3. The OpenLaw1 form is a flat document instead of being itself a set of references to components.  For instance, OpenLaw1 demonstrates the four SAFE Notes done from a common form, but the components of the form are not structured and available for codification and reuse.  In our codification of the SAFE Notes, each document is made from a common set of deal points and the forms are made of components (www.commonaccord.org/index.php?action=list&file=F/Demo/Note_YC/).   In the demo of the Series Seed documents extended by CooleyLLP, we show closing binders of sets of documents made the same way.  The “assembly” should be able to have as many layers as needed to express anything as a compilation of smaller components.  A graph (or Lego) all the way down.

In sum, the integration with Ethereum is to be applauded.  It represents a version of the  “parameters, prose and code” Ricardian contract model.  (Wise Contracts paper with Helena Haapio.)  At the COALA/MIT workshop over these next days, I hope to explore this intersection from a number of perspectives, including with Henning Diedrich and Florian Glanz of the Lexon project.

The integration with IPFS is also great.  IPFS hashing provides a great way to assure the availability and conformity of prose and code.  In a model of Prose/Code/Access/Hosting/Analytics, IPFS seems very useful part of the hosting layer.  (BanqueChain demo for a hypothetical global banking system expressed as nested file folders, with reliance on IPFS.)

#ProseObjects offer a way to keep all transacting information in structured form.  They are necessary to the project of open-sourcing all legal forms and compliance, for the IACCM’s project of general codification of commercial documents, and for a legally-inclusive peer-to-peer transaction system.

#ProseObjects are certainly necessary for Centres for Decentralised Governance.


The three parts of a transacting system can be expressed as three roles:

1. A first-person role – “I” want to write a program that describes the transaction and will cause it to occur. For instance, I want to buy something by selecting the item, specifying the price and delivery, and clicking “order.”

2. A second-person role – “I” need to communicate this to the relevant “you,” and have “you” understand and agree.  If I’m using your website, you website handles this. A blockchain provides a way that is shared, consistent and neutral, where you and I are peers.

3. A third-person role – If “we” have a disagreement, then there must be a third-person who reviews the facts and decides. The third-person may be abstract – a community – and is not always very sharply defined. At the outset, it might even be the second-person, thinking more deeply.

Conventionally, this third-person is often implicit.  Both parties may know people in common, live in the same community.  Our reputations precede us and will be affected by our behavior.  In more formal relationships, the third-person role can be a company supervisor, a school principal, a police officer or court.

In any dispute, there is the problem of proving “facts”, knowing rules and the availability, patience, competence, cost and neutrality of the decision-maker.

Blockchains address some of these problems in a way that can be applied across a very wide domain. For the first-person, the author, blockchains provide patterns for transactions, often called “smart contracts.”  For the interaction with the second-person, they provide a communication method and reliable records, including signature.  For the third-party role, they provide a community that validates the state of the record (the documentary facts) and can automatically enforce some types of interactions, notably operations on tokens.

Blockchains of course address only some of the facts and some of the enforcement that is relevant for “real world” transacting. For contracts that touch on outside “reality” (the world we live in), the parties must depend on people and institutions for facts and trust. The documentary trust function and token escrows that a system of records provides can be very important in reducing disputes, but when the performance involves facts or actions that are not merely records, the ultimate trust lies in these conventional third-persons.

Because blockchains have significant disadvantages from the perspective of information security, speed, cost and flexibility, they will supplement, not fully-supplant conventional systems such as databases, email, web interfaces and newer systems such as IPFS and graph databases.

CommonAccord generalizes the first-person role – authorship or programming of transactions. It provides a common data model for referencing both prose and code aspects of transactions, independent of the platform.

In the Ricardian paradigm, it simplifies programming/authoring as the creation of a “record” consisting of parameters and references to the context of the record.  Most records will resemble credit card receipts – a list of a few key facts – and a link to the context.  The references will have a “prose” component and a “code” component.  By referencing them using names that are independent of the infrastructure (e.g., by hash), they can be used across different platforms. The code – smart contracts – can become commoditized and standardized in a granular, iterative manner, as can the prose.  The granularity resembles the Unix model of small modules with discrete functions, chained together.

Because this record format can work with blockchains and conventional IT systems, it can knit them together.  Blockchains will fill the gaps that conventional systems have left.  But blockchains, as the standard for interoperability, will cause standardization of the conventional systems.  Enterprises will be re-automated from the outside, as a result of their need to work with their customers and suppliers.  The blockchain movement can be the cause of the transformation of all of IT and law, even as it is only a part of the solution.

The combination of blockchains, decentralized access management systems, IPFS and graph databases, can make a truly peer-based system of transacting.  This can encourage the democratization of transaction “programming”, greatly reduced complexity in IT and legal, and reduce the need for centralized “hubs” – both human and tech – to manage people’s affairs.

For the reasons set out in the IACCM Contract Principles, the contract forms and clauses at CommonAccord are intended to provide a base for contracting among parties. In addition, these materials are made available in the way of open source software, which allows easy sharing and improvement.

There are many perspectives from which to approach contract standards. The IACCM Contract Principles approach standards from the perspective of refining and defining basic contracting ideas.  Analytic software approaches standards by finding common denominators in collections of actual contracts.  “Legal Design” approaches standards from the perspective of communication with users.  Model forms projects create complete solutions for sharply-defined uses.

The joining point of these efforts can be said to be an outline of the ideas and kinds of documents that express the ideas.  The outline:

  • should be organized to correspond to basic ideas;
  • have actual forms and clauses arranged on it, as in systems such as KM Standards and RAVN; and
  • be presented to the parties in a simple and compelling way that allows direct use and can be complemented with guidance and other aids to decision.

Such a shared system should “learn” — become better over time — from the experience of participants, the teachings of analytics and the interventions of experts.

The system should fit with two critical trends in IT:

  • “distributed access control,” such as UMA; and
  • “smart contracts.”

We suggest a starting point for the outline would be a list of some common contract types, each one populated with a list of common section headings …. (to be continued).

Eve Maler (@xmlgrrl) contemplating enterprise engagement with prose objects, wrote:

I would guess that making sure this system works would be a combination of a) suitably sophisticated and complex parameterization that meets real-world use cases and b) a “stack” of base prose that does right by individuals before it ever gets to organizations, but then (c) is still appealing to orgs and the corporate contract-editing tools they use.
That thought meets mine in the middle.
(c) Integration with Contract Management Systems:
The one thing the entire community (global, business, govt, advocacy, everybody) is missing is a way to codify legal.  So the clear win for all end-users (from Adrian’s autonomous patients to GE) is “prose objects” hosted and improved by collaboration on Github (and also published by IPFS or equivalent).  Use of publicly-available prose objects with clear “provenance” (@findthomas) will:
  1. accelerate negotiation via common starting points (see the purpose of IACCM Contract Principles introduction);
  2. give the clarity benefits of stable legal provisions (the basic function of legal “codification” and the great advantage of codified legal domains over uncodified domains);
  3. allows weaker, busier, less diligent parties to benefit from the sophistication and even the leverage of experts and peers.

Even sophisticated contract management systems (CRM) don’t cause general legal codification.  For organizations that are happy with their CRM, they might use prose objects “merely” as sources for legal text.  They might use them as legal forms, or might interface to them for more functionality.   Enterprises might find that they want to contribute to prose objects in order to influence the direction of legal standards.  They might do that by publishing prose objects on their own sites, or (better) by forking on Github, or (even better) through organizations such as the IACCM and legal groups.

(b) Individual Perspective:

While it is possible to address the problem of legal standards from the perspective of the individual, and ultimately a major impact will be (and should be) to empower the smaller actor (individual, company, country – almost all of us are small sometimes) it seems likely to me that the legal materials will originate from the more systemic partner.  For instance, the UMA Legal materials, the IACCM Contract Principles or the Y Combinator SAFE Notes.  It will be found that legal documents are not terribly complicated – despite the apparent endless variations and length.  The issues recur and improve with recursion.  The purpose of legal terms is to facilitate good behavior by both parties, to enable the relationship, to reduce the cost of inter-personal collaboration (Coase).  The smaller party will no longer be alone.

(a) Parameters
The choice of parameters is very important.  The easiest way to be sure to select parameters that cover the critical issues is to use existing forms – forms that persons (organizations) actually use.  “Accordifying” an existing form immediately pops-out the terms that the actors thought important.  Iteration will validate (or invalidate) their choices and find others.  The type-less model of CommonAccord, where all elements are parameters, means that we don’t get stuck with early choices.  Iteration will reveal the truth of what actors actually need.
For those organizations that directly use the prose object format for negotiation and signature, adoption leads to a true P2P data model, compatible with access-based approaches such as UMA and with GDPR and PSD2.
Eve adds:
“From Digital Currencies to Digital Finance: The Case for a Smart Financial Contract Standard.” Dr. Paolo Tasca, Journal of Risk Finance.
This excellent article uses the perspective of the blockchain movement to analyze a very complex conventional financial ecosystem: the management of financial contracts by banks and their suppliers.  It identifies major failings, notably gaps in the layers of management.  Because of the historic, organic development of separate transactional and analytical systems, there is a vast array of dissimilar systems that perform similar work, producing dissimilar results, creating the need for imperfect systems of reconciliation, consuming profits and embedding risk.
This bracing perspective can be described as part of the “technology deficit” of banks.  Because banks were among the first users of IT systems, they have among the least modern and most complex systems.  Their systems evolved patch by patch, becoming systems of systems.  See also the “Digital Banking Manifesto: The End of Banks?” (https://cdn.www.getsmarter.com/career-advice/wp-content/uploads/2016/12/mit_digital_bank_manifesto_report.pdf)
The great merit of this piece is to bring the radically simplifying perspective of the blockchain movement, and a nuanced approach to the problem and solutions.  The author identifies that the banks already use “smart contracts” in their automated transacting systems.  The financial contracts are mathematically modeled and algorithmically acted on.  The problem is that different banks use different models and algorithms, indeed many banks use multiplicities of models.
The author calls for these to be standardized via open source.  Note that the author focuses on the substantive standard for financial model – ACTUS – and not on the database level – such as blockchains.  The major, practical impact can come from standardization of the model and algorithms, without industry-wide adoption of a particular database system or replacement of the actors in the sector.   The fintech/blockchain revolution may be about the financial industry discovering open source, not any particular technology.  As the author says, ACTUS is “not an invention, but a discovery.”
The author identifies adoption as the major barrier to standards.  The current system works inefficiently, but it works everyday, and it is critical infrastructure.  Incumbent intermediaries have vested interests to protect and mindsets to overcome.  The author remarks that the fintech revolution has focused minds in the financial sector.
As an advocate for open source applied to legal documentation (CommonAccord.org), I add that adoption may be facilitated by open sourcing the documents of finance.  The efficiency and risk-reduction advantages for incumbents of a systematic approach to legal documents are powerful and immediate.  Symbiotically, open source mathematical models and algorithms can emerge from and contribute to standardized financial documents.

Electrons normally encounter resistance as they move along wires, the pathways that we create for them.  Traveling over a transmission line, there is some loss of power and some heat is generated as the electrons bounce along the path, hopping from one atom to another.  While wires may look straight to us, for the electrons the path is only a bit better than random.  There is resistance in navigating the chaotic pathway.

If the conductive material is made really, really cold, the electricity can pass with almost no resistance at all.  The atoms slow down and stop dancing.  The electrons pass straight through.

In law we can perceive a similar phenomenon.  When a legal pathway is well-established, it becomes smooth.  Events pass through the pathway without ambiguity and they can be made to pass through with little delay or cost.  (Cost and delay can be imposed, as gating rather than friction.)

For example, the transmission of a fractional interest in a business enterprise is very complex conceptually.  If done freehand, the transmission may be documented with hundreds of pages of legal text and description.  In contrast, a sale of a block of shares on a stock exchange has  theoretically equally complicated effects, but the path is clear, execution is rapid and cheap.  The difference between these two situations can be understood in a number of ways; one way is that the second involves a smooth pipe, a well-cooled wire, that connects buyer and seller.

Legal pathways of fixed materials – text building blocks with words that stay still – can become increasingly friction-less pathways by which people wire up their relationships.  The friction will drop – the words will cool – as they are re-used, become known, evolve into standards.

The European GDPR imposes powerful obligations on custodians of personal data to handle that data respectfully. Among the obligations is the right of the persons concerned to demand deletion of the data when no longer needed, and the right to receive a copy in structured format.  The logic of this leads to a P2P data model.  Business and political interests suggest that there is no reason for Europe to pull back when insisting that this logic be applied to its logical end – data, computing and control at the edge rather than the center.  Europe is sensitive to the dangers of too much information being aggregated and European companies have not been winners in the race to create and monetize large aggregations.

Some may doubt whether a system of technologies and actors can exist in which most of the benefits of hub-based transacting can be enjoyed even without massive aggregations of data.

IoT shows the way.  A really functional system of “things” working with one another requires that they be able to do so “locally” – by communicating either directly with one another or via an intermediary who is nearby.  An IoT-equipped furnace must be able to authenticate an IoT-thermostat, verify that the thermostat is who it claims to be and has authority to direct the furnace.  The furnace also needs to verify that the thermostat has the funds – some kind of balance of some kind of currency – and transfers the funds to the account of the furnace, so the furnace can pay for the fuel.  All this needs to be able to occur even if neither furnace nor thermostat can communicate with the outside world.  The internet connection might be down.  For security reasons, too, it is better if the information doesn’t leave the house, except as needed to coordinate with others.

The problem of the thermostat and furnace of course can be scaled up.  The parties might be two ships or two banks.  Their need for action might be less urgent, but ideally they would want the same reliability in dealing with others as the thermostat and furnace enjoy. Their problem is technically less demanding, a lesser-included case.

Governments might want the same independence for their operations and for their economies, companies and citizens.  The technology that solves the problem of IoT interactions can assure the independence of communities, including even countries.