In my book, that's a match. It may not match anyone else's notion of a Ricardian contract but I've got all that I need from it. For his kind of Ricardian contract to be considered complete by the parties prepared to commit to abiding by it, you need i) a formal description of the domain ii) a script to execute the described instructions and iii) a metadata representation scheme capable of making statements in the domain about outcomes of the script.
Cheers
Graham
Thanks for taking the the time to respond, always appreciating your posts. I see a subtle, yet, in my opinion, very important issue when the storage of the contract is referenced in another realm which is not enforceable by the same rules, or by the same source as the proof of the contract (the hash of the transaction). For instance, I can create a contract and store it on IPFS, on a torrent hash or even on an URL. But, apart from IPFS, the latter two are not enforceable, the content at the location can be changed. In my understanding, only a blockchain based storage solution can enforce the immutability of the data. For publishing content, which is a one to many broadcasting operation, the immutability of the data is not that important (sometimes it's a burden, because you would like to amend some content you wrote, hence a bit of versioning). But for a contract, I think the immutability of the storage is fundamental and, if it's broken, the contract may be broken too.
I'm very keen to use OP_RETURN too, and by looking extensively at the source code of Slimcoin (and a few other colored coin derived from the intial Bitcoin code base) I see it can be tweaked, at least in size. I even did my attempt at creating an identity proof, by inscribing my own name using it, and it kinda worked. The transaction id is 7a343510f4c1b1d42c9ed585b03a35e488194658642e8502f825b611e91ed408 and the OP_RETURN block has been correctly filled. It also shows in ACME, by the way, it's the second inscription after your article.
I also briefly looked into go-ethereum, which is the ethereum evm implementation in GO, just to have a gist of what it does. It seems way too complex (which also means quite a big attack surface) but it has interesting features. I can see a similar machine, with a much lower set of operations, implemented as a plugin on Slimcoin. A very simple use case would be a basic e-commerce functionality: adding/removing/editing products and selling them. This type of behavior can be modeled with a much simpler vm than the one in ETH. In this case, OP_RETURN will serve a signaling switch, informing the reader about the type of the operation, and the hash of the contract owning that operation.
Increasing the size of OP_RETURN would be obviously necessary, but not more than 160 bytes.
Another interesting approach observed in evm is the requirement for payment to use the vm (it's in Slimcoin inscription too, as I saw). Other implementations (like the Steem blockchain) are using a "bandwidth" metaphor, but the idea is the same: limit usage to prevent abuse.