diff --git a/docs/source/tutorial-observer-nodes.rst b/docs/source/tutorial-observer-nodes.rst
index 6a77cc1fa7..ecb5f04089 100644
--- a/docs/source/tutorial-observer-nodes.rst
+++ b/docs/source/tutorial-observer-nodes.rst
@@ -33,4 +33,10 @@ the transaction to the regulator. There are two important aspects to note here:
    we do want to passively observe states we can't change. So overriding this behaviour is required.
 
 If the states define a relational mapping (see :doc:`api-persistence`) then the regulator will be able to query the
-reports from their database and observe new transactions coming in via RPC.
\ No newline at end of file
+reports from their database and observe new transactions coming in via RPC.
+
+.. warning:: Nodes which act as both observers and which directly take part in the ledger are not supported at this
+   time. In particular, coin selection may return states which you do not have the private keys to be able to sign
+   for. Future versions of Corda may address this issue, but for now, if you wish to both participate in the ledger
+   and also observe transactions that you can't sign for you will need to run two nodes and have two separate
+   identities.
\ No newline at end of file
diff --git a/node/src/main/kotlin/net/corda/node/services/api/ServiceHubInternal.kt b/node/src/main/kotlin/net/corda/node/services/api/ServiceHubInternal.kt
index 345766ee41..81ad1d57dd 100644
--- a/node/src/main/kotlin/net/corda/node/services/api/ServiceHubInternal.kt
+++ b/node/src/main/kotlin/net/corda/node/services/api/ServiceHubInternal.kt
@@ -108,6 +108,40 @@ interface ServiceHubInternal : ServiceHub {
 
         if (statesToRecord != StatesToRecord.NONE) {
             val toNotify = recordedTransactions.map { if (it.isNotaryChangeTransaction()) it.notaryChangeTx else it.tx }
+            // When the user has requested StatesToRecord.ALL we may end up recording and relationally mapping states
+            // that do not involve us and that we cannot sign for. This will break coin selection and thus a warning
+            // is present in the documentation for this feature (see the "Observer nodes" tutorial on docs.corda.net).
+            //
+            // The reason for this is three-fold:
+            //
+            // 1) We are putting in place the observer mode feature relatively quickly to meet specific customer
+            //    launch target dates.
+            //
+            // 2) The right design for vaults which mix observations and relevant states isn't entirely clear yet.
+            //
+            // 3) If we get the design wrong it could create security problems and business confusions.
+            //
+            // Back in the bitcoinj days I did add support for "watching addresses" to the wallet code, which is the
+            // Bitcoin equivalent of observer nodes:
+            //
+            //   https://bitcoinj.github.io/working-with-the-wallet#watching-wallets
+            //
+            // The ability to have a wallet containing both irrelevant and relevant states complicated everything quite
+            // dramatically, even methods as basic as the getBalance() API which required additional modes to let you
+            // query "balance I can spend" vs "balance I am observing". In the end it might have been better to just
+            // require the user to create an entirely separate wallet for observing with.
+            //
+            // In Corda we don't support a single node having multiple vaults (at the time of writing), and it's not
+            // clear that's the right way to go: perhaps adding an "origin" column to the VAULT_STATES table is a better
+            // solution. Then you could select subsets of states depending on where the report came from.
+            //
+            // The risk of doing this is that apps/developers may use 'canned SQL queries' not written by us that forget
+            // to add a WHERE clause for the origin column. Those queries will seem to work most of the time until
+            // they're run on an observer node and mix in irrelevant data. In the worst case this may result in
+            // erroneous data being reported to the user, which could cause security problems.
+            //
+            // Because the primary use case for recording irrelevant states is observer/regulator nodes, who are unlikely
+            // to make writes to the ledger very often or at all, we choose to punt this issue for the time being.
             vaultService.notifyAll(statesToRecord, toNotify)
         }
     }