diff --git a/core/test/config/config.cpp b/core/test/config/config.cpp
index 59e06dfb589..163f6936de2 100644
--- a/core/test/config/config.cpp
+++ b/core/test/config/config.cpp
@@ -35,8 +35,7 @@ class Config : public ::testing::Test {
         : exec(gko::ReferenceExecutor::create()),
           mtx(gko::initialize<Mtx>(
               {{2, -1.0, 0.0}, {-1.0, 2, -1.0}, {0.0, -1.0, 2}}, exec)),
-          stop_config(
-              {{"type", pnode{"stop::Iteration"}}, {"max_iters", pnode{1}}})
+          stop_config({{"type", pnode{"Iteration"}}, {"max_iters", pnode{1}}})
     {}
 
     std::shared_ptr<const gko::Executor> exec;
diff --git a/include/ginkgo/core/config/config.hpp b/include/ginkgo/core/config/config.hpp
index 01a1a339cc1..4a0730751c7 100644
--- a/include/ginkgo/core/config/config.hpp
+++ b/include/ginkgo/core/config/config.hpp
@@ -38,11 +38,11 @@ class pnode;
  *    that is not defined will fallback to the type_descriptor argument
  * 2. The new `"type"` key determines which Ginkgo object to create. The value
  *    for this key is the desired class name with namespaces (except for
- *    `gko::`, `experimental::`). Any template parameters a class might have are
- *    left out. Only classes with a factory are supported. For example, the
- *    configuration `"type": "solver::Cg"` specifies that a Cg solver will be
- *    created. Note: template parameters can either be given in the
- *    configuration as separate key-value pairs, or in the type_descriptor.
+ *    `gko::`, `experimental::`, `stop::`). Any template parameters a class
+ *    might have are left out. Only classes with a factory are supported. For
+ *    example, the configuration `"type": "solver::Cg"` specifies that a Cg
+ *    solver will be created. Note: template parameters can either be given in
+ *    the configuration as separate key-value pairs, or in the type_descriptor.
  * 3. Factory and class template parameters can be defined with key-value pairs
  *    that are derived from the class they are referring to. When a factory has
  *    a parameter with the function `with_<key>(value)`, then the configuration
@@ -101,8 +101,8 @@ class pnode;
  * "type": "solver::Gmres",
  * "krylov_dim": 20,
  * "criteria": [
- *   {"type": "stop::Iteration", "max_iters": 10},
- *   {"type": "stop::ResidualNorm", "reduction_factor": 1e-6}
+ *   {"type": "Iteration", "max_iters": 10},
+ *   {"type": "ResidualNorm", "reduction_factor": 1e-6}
  * ]
  * ```
  * then passing it to this function like this:
diff --git a/include/ginkgo/core/config/registry.hpp b/include/ginkgo/core/config/registry.hpp
index 1cb7e40cf80..2efa160ee65 100644
--- a/include/ginkgo/core/config/registry.hpp
+++ b/include/ginkgo/core/config/registry.hpp
@@ -175,7 +175,9 @@ class registry final {
      *
      * @param additional_map  the additional map to dispatch the class base.
      *                        Users can extend the map to fit their own
-     *                        LinOpFactory.
+     *                        LinOpFactory. We suggest using "usr::" as the
+     *                        prefix in the key to simply avoid conflict with
+     *                        ginkgo's map.
      */
     registry(const configuration_map& additional_map = {});
 
@@ -194,7 +196,9 @@ class registry final {
      * ```
      * @param additional_map  the additional map to dispatch the class base.
      *                        Users can extend the map to fit their own
-     *                        LinOpFactory.
+     *                        LinOpFactory. We suggest using "usr::" as the
+     *                        prefix in the key to simply avoid conflict with
+     *                        ginkgo's map.
      */
     registry(
         const std::unordered_map<std::string, detail::allowed_ptr>& stored_map,