diff --git a/docs/architecture/psa-shared-memory.md b/docs/architecture/psa-shared-memory.md
index cdcccd9..82f4bd0 100644
--- a/docs/architecture/psa-shared-memory.md
+++ b/docs/architecture/psa-shared-memory.md
@@ -525,14 +525,7 @@
 
 The PSA copying function must then have test hooks implemented as outlined in [Validation of copying by memory poisoning](#validation-of-copying-by-memory-poisoning).
 
-For test implementation, we may choose one of two approaches:
-
-* Use transparent allocation-based memory poisoning.
-* Use memory poisoning functions and a new testsuite.
-
-As discussed in [the design exploration](#validation-with-existing-tests), the transparent approach is preferred.
-
-We will specify the particularities of each approach's implementation below.
+As discussed in [the design exploration](#validation-with-existing-tests), the preferred approach for implementing copy-testing is to implement it transparently using existing tests. This is specified in more detail below.
 
 #### Transparent allocation-based memory poisoning
 
@@ -560,8 +553,6 @@
 #define psa_aead_update(...) mem_poison_psa_aead_update(__VA_ARGS__)
 ```
 
-#### Memory poisoning functions and a new testsuite
-
 #### Configuration of poisoning tests
 
 Since the memory poisoning tests will require the use of interfaces specific to the sanitizers used to poison memory, they must be guarded by new config options, for example `PSA_TEST_COPYING_ASAN` and `PSA_TEST_COPYING_VALGRIND`, as well as `MBEDTLS_TEST_HOOKS`. These would be analogous to the existing `MBEDTLS_TEST_CONSTANT_FLOW_MEMSAN` and `MBEDTLS_TEST_CONSTANT_FLOW_VALGRIND`. Since they require special tooling, these options should not be enabled in either the `default` or `full` configurations. Instead, as with the constant flow testing options, they should be enabled in a new component in `all.sh` that performs the copy testing with Valgrind or ASan.