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.