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
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