Over the past few weeks we’ve been extremely busy here at Clause HQ, working on the Accord Project, the Accord Protocol Template Specification, https://github.com/accordproject/cicero, and the Hyperledger Improvement Proposal for Cicero. Not to mention all the awesome Clause Inc. product stuff we are working on!
I thought it would be useful to unpack all the various efforts, show how they interrelate, and give you an insight into our thinking.
First, let’s start with our vision. We want to bootstrap the creation of an ecosystem of legally enforceable smart contracts and provide the technology to define, edit and execute them. We understand that this will require broad industry consensus however, working with partners across law and technology, including working with potential competitors.
We want these contracts to be grounded in the real-world, to be receiving events of interest from the real-world, and to trigger side-effects on the real-world. For example, a delivery contract may receive an event when you digitally sign the delivery driver’s keypad, and it may automatically move money from your account to the seller’s account.
To realise the vision we need to work on several challenges in parallel:
- Lawyers need to agree which clauses in legal contracts are most amendable to this sort of automation. We are pragmatists and are not trying to automate all clauses in a contract, or pretend that law is code, but we do believe that there is enormous value in making contracts active participants in operational IT, rather than purely documents that languish in a content management system or filling cabinet.
- Legal-Tech professionals need to work with lawyers to standardise the data models that underlie automated clauses. For a “Late Delivery And Penalty” clause there is clearly the notion of an /asset/ being transferred between a buyer and seller /participant/ with attached temporal conditions and financial penalties. To automate clauses we need to capture these data models in a formal way, both to resolve semantic ambiguities, but also to provide the type information required for execution.
- We need to provide a set of software tools that allow people to easily define a new template for a clause and to experiment with using it for editing, execution, testing etc.
We plan to work on all 3 of the above within the Accord Project. (1) and (2) will occur within vertical working groups. We are bootstrapping working groups for Supply Chain, Employment and Services, Digital Marketing etc.
(3) will be worked on in the Accord Technology Working Group, and any code and tools developed will be Open Source (Apache-2 license) and published under the Cicero project. We have requested that Cicero become a top-level project under the Linux Foundation’s Hyperledger umbrella project, so it can benefit from the mature project governance provided by the Linux Foundation. Fundamentally we wish to remain as technically neutral as possible however, enabling the use of Cicero across a wide variety of platforms, from Hyperledger Fabric, to R3 Corda, to Enterprise Ethereum, Cloud SaaS offerings, IoT devices and everything in between.
The code we have published to bootstrap Cicero is far from complete. This was a conscious choice on our part, as we felt strongly that it would be a mistake to develop too much technology in secret and then to release it with a Big Bang. Instead we wanted to build a technical community around these challenges as soon as possible.
The code does however do some useful things, and we hope will allows us as technologists to “get into the details” quite quickly, rather than debating abstract concepts.
A key concept is the notion of a typed data model for a contract/clause. Cicero has adopted the Composer Modelling Language (CML) to capture the data model. This was not a decision taken lightly, however it offers several key advantages:
- Assets, participants, transaction and events are first-class concepts in the meta model. These are all particularly relevant for contracts, where knowing that Customer is a participant ,for example, and not just a class, opens up lots of possibilities for integration with Identity frameworks etc.
- CML models are modular, making it easy to import types from external namespaces
- CML models have an easy to understand text-based serialisation, and are easily versioned, differenced etc.
- CML models can be published easily to the npm global package registry, making it easy to distribute models, either within a private (enterprise) npm repository or the Internet-scale global registry
- CML is expressive enough to capture most business models, but not too expressive that its mapping to an execution target is complex. For example, it is not a document-based Schema language (like XML Schema) or an Ontology like W3C OWL, or a RPC serialisation (Protobuf/Avro) all of which are challenging to support from an editing and runtime perspective.
The template specification enables anyone to define a template model, how it maps to natural language text, as well as the business logic that sits behind the template.
The model-logic-language triangle of functionality is incredibly powerful:
[image:8E3E8430-6CC0-4939-8CB2-262915243713-6880-0000094B1F7169FB/template_triangle.png]
The model and natural language are used to generate parsers that can edit and validate instances of the template.
The model and logic are used to validate the logic, route transaction to the clause based on type information, statically compile the logic using the model and to execute the logic in a suitable container.
Contrast with the current situation which consists of a natural language contract (PDF or Word document), disconnected from any formal model, and disconnected from any business logic that has been written to support the contract.
The template specification is also locale-aware, allowing a single template to be published in multiple languages. The template model for each language would be equivalent, as would the business logic, however the natural language text can be supplied for each supported locale.
Note that at the moments Templates are somewhat primitive (though this is still state of the art!) in that they are chunks of natural language with embedded simple or complex types. In the future we would like to support expressions within the templates to capture more complex logic directly within the template itself.
Templates may be published into a template library. Cicero includes a template library as a GitHub - accordproject/cicero-template-library: Sample Templates for Cicero, allowing for standard collaboration around the specification of a template. We would like to see templates in the library created by the Accord Project working groups, and for an eco-system of closed and open source templates to emerge.
To bootstrap an ecosystem of templates a basic runtime environment has to be provided. Cicero aims to be open to different runtime implementations, so that vendors can experiment with different languages to capture the business logic. This is the least developed part of the specifications and technology at the moment, with just a simple Node.js VM based implementation included at present.
At Clause we strongly believe that there’s enormous utility and value in being able to ground some of the clauses in a contract to events that are occurring in the real-world, and to allow a clause to emit events and transactions that can trigger actions in the real-world.
Please visit http://accordproject.org to sign up to the various working groups, including the technology-wg channel. We will be hosting regular web meetings to advance both the specifications and the code based on the specifications.
We hope you will join us in defining this exciting new chapter for Legal-Tech!