Violation of an agreement condition indicates that the source of the operation is not behaving correctly according to the specification of the app; for example, it has been replaced by malware (with or without the user's knowledge). The condition check is therefore made for incoming remote agreement operations, not for a local write marked as an agreement – it is the responsibility of the app (and its constraints) to ensure that preconditions are met for a local write.

The consequence of a violation is that the operation is ignored, and also any further operations from the same remote clone. This causes a permanent divergence which can only be recovered by creating a new clone for the violating remote user/device.

It is therefore imperative that agreement conditions only consider inputs that are known to be consistent for all clones. Generally this does not include the local clone state, because clone state on receipt of an agreement operation may not be the same as the prior state at the originating clone, per normal m-ld behaviour. Examples of valid inputs include:

1. Clone state which is known not to have changed since the last agreement, for example if access controlled so that it cannot change without agreement.

2. External state known to have strong consistency, such as the content of a ledger or database. In this case it may be necessary for the operation to reference some immutable data such as specific block in a blockchain, or an append-only table row.

see

{@link WriteOptions.agree}

todo

clone status notification on receipt of a violating remote operation

experimental