diff --git a/doc/spec_initialValuePropagation.md b/doc/spec_initialValuePropagation.md
index 54300624ce2b041aef111b460f3cc20c5030651f..9398e0542fb75021a1dd5be3e587f3de92f0cb4e 100644
--- a/doc/spec_initialValuePropagation.md
+++ b/doc/spec_initialValuePropagation.md
@@ -176,7 +176,11 @@ All points are also covered by @ref exceptionHandlingDesign.
 - Exceptions are currently thrown in the wrong place (see implementation section for the NDRegisterAccessor). A possible implementation to help backends complying with this rule would be:
   - Introduce non-virtual `TransferElement::readTransfer()` etc, i.e. all functions like `do[...]Transfer[...]()` should have non-virtual pendants without `do`.
   - These new functions will call the actual `do[...]Transfer[...]()` function, but place a try-catch-block around to catch all ChimeraTK exceptions
-  - The exceptions are stored and operation is continued. In case of boolean return values (`doReadTransferNonBlocking()`, doReadTransferLatest()` and `doWriteTransfer()`), the value for success must be returned (`true` for read and `false` for write), to make sure the corresponding post-action is executed.
+  - The exceptions are stored and operation is continued. In case of boolean return values correct values must be implemented:
+    - `doReadTransferNonBlocking()`and `doReadTransferLatest()` must return false (there was no new data)
+    - `doWriteTransfer()` shall return true (dataLost), except for the ExceptionHandlingDecorator.
+        It should return true only if the data of the recovery accessor is replaced and the previous value has not been written to the hardware.
+  - `postRead()` and `postWrite()` must always be called. It currently depends on the boolean return value if there is one. Instead this value has to be handed to `postRead()` and  `postWrite()` as an argument. Only the implementation can decide what it has to do and what can be skipped.
   - With `TransferElement::postRead()` resp. `TransferElement::postWrite()` non-virtual wrappers for the post-actions already exist. In these functions, the stored exception should be thrown.
   - All decorators and decorator-like accessors must be changed to call always the (new or existing) non-virtual functions in their virtual `do[...]` functions. This applies to both the transfer functions and the pre/post actions (for the latter it should be already the case).
   - It is advisable to add an assert that no unthrown exception is present before storing a new exception, to prevent that exceptions might get lost due to errors in the business logic.