diff --git a/src/ptrmask-integration.adoc b/src/ptrmask-integration.adoc
index a7ef0d5c..695fb674 100644
--- a/src/ptrmask-integration.adoc
+++ b/src/ptrmask-integration.adoc
@@ -1,18 +1,28 @@
 [#section_pointer_masking_integration]
 == Integrating {cheri_base_ext_name} and {cheri_default_ext_name} with Pointer Masking
 
-The pointer masking extensions Smmpm, Smnpm, SSnpm, Sspm and Supm are compatible with {cheri_default_ext_name}.
+The pointer masking extensions Smmpm, Smnpm, SSnpm, Sspm and Supm are compatible with both {cheri_base_ext_name} and {cheri_default_ext_name}.
+Whenever pointer masking is enabled, all bounds decoding and bounds checks are affected.
 
-For instructions using integer addresses (e.g. loads/stores in {cheri_int_mode_name}), they
-are interpreted as being XLEN-wide, and may be subject to pointer masking.
-All data accesses are checked against <<ddc>> which is unaffected by
-pointer masking. Therefore no capability bounds encoding is affected.
+NOTE: The suggestion in this section is based on the pointer masking approach from Morello but with changes
+to sign extension and to address the dynamic nature of bit masking.
+Further evaluation on RISCV, especially for {cheri_cap_mode_name}, is still required.
 
-For instructions using capabilities (e.g. loads/stores in {cheri_cap_mode_name}), the final access address is subject to pointer masking, but the computed bounds are not. The entire address field, including any bits representing the pointer mask, are used
-for bounds calculation. When pointer masking is enabled, the dereferenced address has the masked bits replaced by sign
-extension before the bounds check.
+When bounds are <<section_cap_encoding,encoded or decoded>>, a masked but _not_ sign extended address is used.
+Changing how many bits are masked can therefore change the interpretation of the bounds of a capability,
+both for the purpose of implicit accesses via bounds checks and any instructions that report the bounds of a capability.
+Apart from treating high address bits as 0, there are no other changes to bounds decode,
+which are still based on MXLEN, not the new effectively addressable space.
+That is, the maximum length of a capability does not change, and
+it is not invalid to have a capability that covers a longer range than could be actually be addressed with pointer masking enabled (such as one that covers the entire MXLEN address space).
+For the <<section_cap_representable_check, representable range check>>, both the original and new address
+are masked.
+Bounds setting instructions also mask the address in the same way.
 
-NOTE: This scheme doesn't seem very useful, but the problem is the dynamic configuration
- of pointer masking which can arbitrarily update the meaning of the address within the capability,
- so the full address field must be used to calculate bounds.
- There is future work required to determine a more useful way of applying pointer masking to capabilities.
+NOTE: Because dynamically changing the number of masked bits changes the interpretation of a capability,
+software must take the same care when sharing capabilities between address spaces with differing pointer masking
+as it generally must when sharing capabilities between address spaces with different page mappings.
+
+Any address that is checked against a capability (whether via loads/stores in {cheri_int_mode_name} or {cheri_cap_mode_name}),
+is also first subject to the same masking as bounds decode (masking without extension).
+After any CHERI operations, the final access address is still subject to as much sign extension as the masking extensions mandate.