Computable Contracts and Agreements
Overview
The Conduit Network Conduit OS contains a Computable Contracting Platform that we call a Protocol Engine. A Protocol as defined by Cambridge Dictionary is "the system of rules and acceptable behavior used at offical ceremonies and occasions". The only bit of the definition really left up to interpretaion is what qualifies as an official ceremony or occasion. The most famous (or at least should be the most famous) protocols on The Internet are the TCP/IP protocols upon which nearly the entirety of The Internet is based. The application layer (of protocols) that sits above TCP/IP provide a massive set of functionality that we consider The Internet today: DNS and HTTP for websites and webpages, SMTP, IMAP, POP and others for E-Mail, and the list goes on. The point being that protocols are powerful, first principles rule sets, that enable massive amounts of use case. At Conduit as we set out to design what we see as the missing protocols of The Internet, we found that The Internet would be better served by a Protocol Engine, a framework for authoring protocols and the Computable Contracts that leverage them.
Computable Contracts
The law department of MIT defines Computable Contracts as follows:
A computable contract is one that is specified in sufficient detail and clarity to provide unambiguous answers to questions about compliance of clearly specified circumstances with the terms and conditions of the contract.
There are some strong words in this definition like "sufficient detail" and "unambiguous" that when compiled togther has proven difficult to achieve especially with any flexibility or at scale. There are current "Smart Contracts" that achieve this goal but the majority serve very narrow use cases and are brittle when scaled beyond a purpose built use case. (If you want to know about our approach to this problem keep reading, if you want to know what our solution enables jump to Agreements.)
As Conduit Network considerd an architecture for Computable Contracts we held fast two key design principles. In order to make sure that the solution would scale it would need to have Composability, enabling adaptability to many use cases and emergent reality. In order to satisfy "provide unabmiguous answers" we needed the solution to be able to answer questions, or in other words it needs to be "inspectable".
To accomplish this Conduit Network utilizes State Machines (sometimes called finite-state machines). State machines satisfy making the solution "inspectable" inherently because the machine and data moving through it can only exist in the predefined states making answers to questions about state unambiguous. Composability is really a question of how can state machines can be chained together in many different ways. To facilitate this Conduit Network has created a workflow engine that chains Workflow Milestones together with Predicates that are evaluated based on State Machine states.