update adr's refs

adr/atomicity.md

@@ -58,12 +58,12 @@ user to decide what to do with it.
 _Not to be confused with GroveDB batches!_
 
 In general, if an operation fails, it doesn't necessarily mean that the entire transaction
-should be aborted, unless previous operations were destructive. At least, this is not the
+should be aborted, unless it came into an inconsisent state. At least, this is not the
 desired behavior in GroveDB, as it is used in Dash Platform: a transaction should live
 for the duration of a block, with operations happening seamlessly -- even those that
 may fail.
 
-As stated before, an operation that changes the state of GroveDB consists of many
+As stated before, an operation that changes the state of GroveDB consists of many RocksDB
 operations. However, we do not apply them directly to the provided transaction. Instead,
 we aggregate them into a RocksDB batch, which is applied to the transaction all at once
 at the end of the GroveDB operation. This approach allows for failure without aborting

adr/bidirectional_references.md

@@ -150,7 +150,7 @@ Meta:
 
 ### Propagation
 
-Previous read: [[merk_cache]].
+Previous read: [Merk cache](./merk_cache.md).
 
 Deletion or an update of an element with backward references triggers a cascade hash
 update or a deletion, both of which alter the state of affected subtrees, leading to

adr/merk_cache.md

@@ -2,7 +2,7 @@
 
 An easy to use answer to GroveDB's implementation challenges.
 
-Previous read: [[atomicity]].
+Previous read: [atomicity](./atomicity.md).
 
 Mandatory operation batching and deferred application, which are used for all GroveDB
 updates, separate the state into two perspectives: one is the current state reflected in