diff --git a/docs/architecture-decisions/2024-12-10_arrays.md b/docs/architecture-decisions/2024-12-10_arrays.md
index 282dfb2af..5628c63dd 100644
--- a/docs/architecture-decisions/2024-12-10_arrays.md
+++ b/docs/architecture-decisions/2024-12-10_arrays.md
@@ -29,7 +29,7 @@ The developer experience with Puya Arrays will depend on the API design (mutable
 
 -   [AlgoKit Guiding Principles](https://github.com/algorandfoundation/algokit-cli/blob/main/docs/algokit.md#guiding-principles) - specifically Seamless onramp, Meet developers where they are, Leverage existing ecosystem
 -   [Algorand Python Principles](https://algorandfoundation.github.io/puya/principles.html#principles) - specifically Least surprise and Leverage existing ecosystem by maintaining semantic compatibility.
--   [Algorand TypeScript Guiding Principles](https://github.com/algorandfoundation/puya-ts/blob/main/docs/README.md#guiding-principals)
+-   [Algorand TypeScript Guiding Principles](https://github.com/algorandfoundation/puya-ts/blob/main/docs/README.md#guiding-principals) - specifically TEALScript compatibility and minimise Algorand Python disparity.
 
 ## Options
 
@@ -230,7 +230,7 @@ someFunctionThatMutates(structs, structs2)
 
 ## Preferred option
 
-In an ideal world being able to fully support option 4 would be great, however due to the constrained nature of the AVM it's not really feasible. The other options on their own will work, however there is some differences to what developers would be used to. As a result we feel that a combination of both option 2 and option 3 would give developers the familiarity and control they would expect.
+In an ideal world being able to fully support option 4 would be great, however due to the constrained nature of the AVM it's not really feasible. The other options on their own will work, however there is some differences to what developers would be used to. As a result we feel that a combination of both option 2 and option 3 would give developers the familiarity and control they would expect. If the front-end language authors choose to leverage a native collection type, having both options available also allows them to choose which implementation makes the most sense.
 
 ## Selected option