diff --git a/docs/alpha/blocks_ops.rst b/docs/alpha/blocks_ops.rst
index 43bf2249a36e92a628aab94503201bd782ee3077..dda150522791eaa148a6cd88cc93e75fd7d1f855 100644
--- a/docs/alpha/blocks_ops.rst
+++ b/docs/alpha/blocks_ops.rst
@@ -32,17 +32,7 @@ operations<manager_operations_alpha>`. This order also specifies the
 of each of these classes. Consensus operations are considered the
 highest priority ones, and manager operations the lowest.
 
-The current protocol implementation enforces the following invariant:
-
-- each kind of operation belongs to *at most one* validation pass;
-- operations whose kind does not belong to any validation pass cannot
-  be :ref:`applied<operation_validity_alpha>`.
-
-.. FIXME tezos/tezos#3915:
-
-   Failing noops don't fit within any of the validation passes
-   below. We need to change the structure a bit to be able to list
-   them here.
+Each kind of operation belongs to exactly one validation pass, except for the :ref:`failing_noop` which belongs to no validation pass and therefore cannot be :ref:`applied<operation_validity_alpha>`.
 
 In the sequel, we describe the different classes of operations, and
 the different kinds of operations belonging to each class.
@@ -259,3 +249,26 @@ Batches satisfy the following properties:
   atomically: all its operations are executed sequentially, without
   interleaving other operations. Either all the operations in the
   batch succeed, or none is applied.
+
+.. _failing_noop:
+
+Failing_noop operation
+~~~~~~~~~~~~~~~~~~~~~~
+
+The ``Failing_noop`` operation is not executable in the protocol:
+
+- it can only be validated in :ref:`mempool mode <partial_construction_alpha>`, by the :doc:`prevalidator component <../shell/prevalidation>`;
+- consequently, this operation cannot be :ref:`applied <operation_validity_alpha>`, and in fact will never be included into a block.
+
+Rather, the ``Failing_noop`` operation allows
+to sign an arbitrary string, without introducing an operation that could be misinterpreted in the protocol.
+
+The Octez client provides commands to sign and verify the signature of input messages by a given key. These commands create a ``failing_noop``
+operation from the message that is being signed or checked.
+
+::
+
+   octez-client sign message "hello world" for <account>
+
+   octez-client check that message "hello world" was signed by <account> to
+   produce <signature>
diff --git a/docs/user/various.rst b/docs/user/various.rst
index 8b00b41767e5907f1c526234ddc29ba37efdf6bc..8175e23ef74b52f41410cd110cefd0fbb37997fd 100644
--- a/docs/user/various.rst
+++ b/docs/user/various.rst
@@ -64,23 +64,3 @@ indicates a recommended course of action.
 +-------------+----------------------------------------------------------------------------------+------------------------------------------------------------------+
 | 255         | like 127 but an error and an error occurred during exit (e.g., ``kill -9``)      | check output/logs, clean-up leftover files                       |
 +-------------+----------------------------------------------------------------------------------+------------------------------------------------------------------+
-
-.. _failing_noop:
-
-Failing_noop operation
-----------------------
-
-Starting with protocol 009 a ``Failing_noop`` operation is added. This operation
-is not executable in the protocol and will always fail when injected. It allows
-to sign an arbitrary string that cannot be misinterpreted in the protocol.
-
-The client has commands to sign a message with a given key or to check that
-message has been signed by a given key. These commands create a ``failing_noop``
-operation from the message that is being signed or checked.
-
-::
-
-   octez-client sign message "hello world" for <account>
-
-   octez-client check that message "hello world" was signed by <account> to
-   produce <signature>