Though "Blockchain" is in the title of this discussion group, it need not be in all of the solutions. "Blockchains" have large privacy and data security challenges built into maintaining consensus on the state of the ledger (database). Most real life situations have available a range of alternative means of validating the state of the ledger. For instance, a regulator.
So, we might view it as a bug, rather than a feature, if a "smart contract" solution requires execution on a blockchain.
Organizations and humans will want to be able to efficiently manage large numbers of ledger entries, in efficient databases (SQL, graph, IPFS), not blockchains. They will need to be able to run the smart contracts on those other platforms.
Data replication should be minimized, and temporary to the extent possible. This will, I think, also be required by GDPR.
The necessary point of agreement, the waist of the Zittrain hourglass, is very small - a format for ledger entries. CommonAccord asserts (I assert on its behalf) that the key to this is ... key/values, a way of resolving references, and inheritance. For good reasons, JSON is a likely to be the most common "punctuation" (Eve's word) for exchange of ledger entries. Our current rendering engine uses plain text and carriage returns. That is the lightest "punctuation" and may be the best for collaboration on big texts, notably for collaboration among lawyers and regulators on Github. It closely parallels the presentation of software source code. But this barely matters. What matters is a common approach to linking and inheritance.