Hi all, Sorry to have been MIA, thanks to Eve and Scott for the template. Using it, and retaining its paragraph sequence but not retaining its metadata, :( , I suggest this draft: [*CommonAccord*]? · Adopting the vocabulary of the work of Nobel laureates Hart and Holmström, contracts are "incomplete." There are many particulars and contingencies that are not specified in contracts. In many contexts, efforts are made to reduce incompleteness by including "boilerplate" - standard or lightly customized provisions. This boilerplate is often handled by only one party to the transaction - the one for whom the transaction is recurring, the one that has most negotiating power or the one that is most diligent. This has numerous disadvantages: - The cost of validation of common provisions is very substantial. In many transactions, this cost is so high that parties skip reading altogether. - Party-proposed boilerplate is of course commonly shaded in favor of the proposing party, particularly in high-velocity transactions. - Even in those relatively few, high-value, low velocity transactions where there is rough parity of interest and sophistication, the cost of ping-pong negotiation, in time, money and bad feeling, is substantial. - The learning that accumulates from negotiation and performance experience is not widely fed back into improving the system. Experts and advocates have difficulty making their views known and actionable. · CommonAccord.org is a data model for codified boilerplate. Codification and sharing let boilerplate be both more "complete" in the sense of the work of Hart and Holmstrôm, and less intrusive. Codification permits greater levels of certainty and reduced differentials in knowledge. · The traditional platforms for boilerplate include form documents, web-based terms, and word-processing documents. These suffer from isolation and party-domination. New approaches - many of them under the rubric of "smart contracts" - seek to use coding paradigms and big data tools to reduce uncertainty. These are to be encouraged and leveraged, but most suffer from extreme reductionism - they manage complexities by assuming them away. · The strengths of CommonAccord are: - Extreme simplicity in the paradigm: i) a record (parameters) references its context of ii) prior relevant events iii) code, and iv) boilerplate. - Ability to handle complexity: - The context can be extremely complex, including long codified model documents and an arbitrarily large set of code functions and circumstances. - Complex relationships can be modeled as collections of objects. - Extensibility: Any record or solution can be extended by overriding (also called prototype inheritance). - Risks/Challenges: CommonAccord is mature as a paradigm and has many demonstration materials, but all of the code implementations are only at the demonstration phase. We have very good object models for complex legal documents, but objects for persons, properties, places and the like are improvised. · Blockchains, IPFS, UMA and other technologies of peer-to-peer and identity management are a natural fit with the record-code-prose "smart contract" paradigm of CommonAccord. They can complement current platforms such as git. On Tue, Oct 11, 2016 at 11:44 AM, Eve Maler wrote:

I just sent this to Phil W. for Sovrin. Here is a generic version for others assigned to case studies to use, if they like...

====

Hi [*name*]-- Thanks for being willing to help the Blockchain and Smart Contracts group understand what [*name of group/effort/company*] is doing in the context of our analysis efforts!

If you look at the first paragraph of our draft report's introduction http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockcha..., you'll see a statement of our scope:

- Solving use cases for *empowering traditionally disempowered parties* (such as individuals) - taking part in *transactions* (such as entering into contracts and information-sharing agreements) - with *parties that traditionally hold greater power* (such as companies and large countries) - in the context of *decentralization technologies and techniques* (such as blockchain and smart contracts) - and their mixture with *identity* (both in the course of conducting business/legal transactions and to solve digital identity use cases).

Our Discussion Group is time-boxed to six months, and so we plan to go into only as much depth as can be covered in this time frame. (We started in July!)

With all of this in mind, could you please comment on the following aspects of [*name of group/effort/company*]?

- Deficits and benefits of how the problem space was/is being solved - Proposed benefits of the new solution space - Different approaches being taken in the new solution space, e.g. if other approaches are being taken outside of [*name of group/effort/company*] - Strengths, weaknesses, risks, and open issues being seen in practice - Whether other technologies and techniques are being brought to bear (you can see a list of technologies and techniques we are analyzing in our report http://kantarainitiative.org/confluence/display/BSC/Report+from+the+Blockcha... TOC)

Many thanks! If you have any questions, or would like to discuss responses in a phone call, don't hesitate to let me know.

====

*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl *ForgeRock Summits* are coming to http://summits.forgerock.com/ *London and Paris!*

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

-- @commonaccord