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.