More updates from code review

docs/source/caching/cache-key-resolution.mdx

@@ -60,15 +60,23 @@ You can also use `@typePolicy` on interface types. Doing so specifies a default
 extend interface Node @typePolicy(keyFields: "id")
 ```
 
-> **Note:** If an object type has a type policy of its own, it will take precedence and the type policy on an interface it implements will not be applied.
+<Note>
+
+Overriding type policies is not currently supported. If an object type has a `@typePolicy`, it must match any type policies of any interfaces the object type implements.
+
+</Note>
 
 ## Caveats and limitations
 
 Declarative cache key resolution has a few limitations you should be aware of while implementing your `@typePolicy` directives:
 
-- If any type implements two interfaces with conflicting type policies, Apollo iOS throws a validation error when executing code generation. You can correct this by applying a type policy to the type directly to disambiguate the conflict.
+### Conflicting Type Policies
+
+If any type implements two interfaces with conflicting type policies, Apollo iOS throws a validation error when executing code generation.
+
+### Cache Inconsistencies
 
-2. When an object is returned for a field of an interface type where the interface has a `@typePolicy`, Apollo iOS will first attempt to find a `@typePolicy` for the concrete type by using the `__typename` field of the returned object. If the type does not have an `@typePolicy` of its own, the interface's `@typePolicy` will be applied.
+When an object is returned for a field of an interface type where the interface has a `@typePolicy`, Apollo iOS will first attempt to find a `@typePolicy` for the concrete type by using the `__typename` field of the returned object. If the type does not have an `@typePolicy` of its own, the interface's `@typePolicy` will be applied.
 
 If the same object is returned for multiple fields of different interface types with conflicting type policies, it is possible that the same object is resolved with two different type policies, leading to cache inconsistencies.
 

docs/source/caching/programmatic-cache-keys.mdx

@@ -21,31 +21,31 @@ The information needed to construct a **cache key** is represented by a [`CacheK
     An optional **group identifier** for a set of objects that should be grouped together in the normalized cache. This is used as the first component of the **cache key**.
 
     <Caution>
-    
+
     To ensure cache key group uniqueness, all objects with the same `uniqueKeyGroup` must have unique `id`s across all types.
-    
+
     </Caution >
 
     To prevent cache key collisions, cache keys will always have a **group identifier** component. When the `uniqueKeyGroup` is `nil` (the default value), the [`__typename`](https://spec.graphql.org/draft/#sec-Type-Name-Introspection) of the response object is used as the **group identifier**.
 
     If multiple distinct types can be grouped together in the cache, the `CacheKeyInfo` for each `Object` should have the same `uniqueKeyGroup`.
 
     <Tip>
-    
+
     By grouping objects together, their **keys** in the normalized cache will have the same prefix. This allows you to search for cached objects in the same group by their cache `id`. To learn more, read about [direct cache access](./cache-transactions)
-    
+
     </Tip>
 
 2. `let id: String`
 
     The unique **cache ID** representing the object. This is used as the second component of the **cache key**.
 
-    <Warning>
-    
+    <Caution>
+
     To ensure cache ID uniqueness, the `id` must be deterministic and unique for all objects with the same **group identifier** (`__typename` or `uniqueKeyGroup`).
-    
+
     That is, a response object for the same entity will always have the same key in the cache.  Different objects, even with the same group identifier, will always have distinct keys.
-    
+
     </Caution>
 
 The normalized cache constructs cache keys with the format: