diff --git a/89.md b/89.md
index 358e2782..a661827d 100644
--- a/89.md
+++ b/89.md
@@ -29,6 +29,14 @@ The client then broadcasts an event such as
 }
 ```
 
+#### Example of steps taken by the client on input
+
+- allow the user to specify a list of `payment_target_type` and `authority` value pairs (labeled as preferred by the client) of their choice
+- for each pair of `payment_target_type` and `authority` values specified by the user
+    - *optionally* do some minimal validation on those fields in a generalized way that applies to any payment network
+    - *optionally* warn users if a specifid `payment_target_type` is not [*recognized*](#recommended-payment-target-types) by the client
+- broadcast the event in the format specified above
+
 ### Recommended Payment Target Types
 
 This is a list of recommended payment target types for clients to recognize and store icons and stylization configurations for.
@@ -44,11 +52,11 @@ This is a list of recommended payment target types for clients to recognize and
 
 On observation of events of kind `0` (`set_metadata`), the event *may* specify the key `"payto"` with a value consisting of a list (one or many) of "payment target" values, each specified as a pair of values `payment_target_type` and `authority` as specified in the [RFC-8905 (payto:) URI scheme](https://www.rfc-editor.org/rfc/rfc8905.html) for payment targets.
 
-For each pair of values in the list, the client *should* assemble a full `payto://` deep link URI and render it as a button or link in the user's profile, posts, chats, or elsewhere, in the format of `payto://<payment_target_type>/<authority>`. 
+For each pair of values in the `payto` list, the client *should* assemble a full `payto://` deep link URI and render it as a button or link in the user's profile, posts, chats, or elsewhere, in the format of `payto://<payment_target_type>/<authority>`. 
 
-The client *should* store a map of [recognized payment target types](#recommended-payment-target-types) along with a corresponding icon and/or stylization configuration (to be defined by the client).
+The client *should* store a map of [recognized payment target types](#recommended-payment-target-types) along with a corresponding icon & stylization configuration (to be defined by the client).
 
-For ***recognized*** `payment_target_type` values, the client *should* render a button or link using the associated icon and/or stylization. 
+For ***recognized*** `payment_target_type` values, the client *should* render a button or link using the associated icon & stylization. 
 
 For ***unrecognized*** `payment_target_type` values, the client *may* chose to either ignore them or use a generic stylization, perhaps using the `payment_target_type` value directly for the button or link.
 
@@ -73,6 +81,14 @@ for each payment target it will assemble a deep link payment invocation URI, as
 `payto://nano/nano_1dctqbmqxfppo9pswbm6kg9d4s4mbraqn8i4m7ob9gnzz91aurmuho48jx3c` (*recognized*)
 `payto://unknowntype/l7tbta5b9xze6ckkfc99uohzxd009b0r` (*unrecognized*)
 
-The client chooses to ignore the third *unrecognized* `payment_target_type`, and only embeds the first two payment target deep links in the user's profile, posts, chats, or elsewhere as buttons, links, or a dropdown selector using the corresponding icons or stylizations for the [*recognized* payment target types](#recommended-payment-target-types).
+The client chooses to ignore the third *unrecognized* `payment_target_type`, and only embeds the first two payment target deep links in the user's profile, posts, chats, or elsewhere as buttons, links, or a dropdown selector using the corresponding icons & stylizations for the [*recognized* payment target types](#recommended-payment-target-types).
 
 *Optionally*, the client may have chosen to render the third payment target using the text `unknowntype` rather than ignoring it.
+
+#### Example of steps taken by the client on observation
+
+- for each pair of `payment_target_type` and `authority` values in the `payto` list
+    - *optionally* do some minimal validation on those fields in a generalized way that applies to any payment network, and filter out invalid pairs
+    - *optionally* filter out any pairs with an [*unrecognized*](#recommended-payment-target-types) `payment_target_type`
+    - assemble a full `payto://` deep link URI in the format `payto://<payment_target_type>/<authority>`
+    - render a button, link, or dropdown in user profiles, posts, chats, and elsewhere using the assembled deep links and the corresponding icons & stylization configurations for *recognized* `payment_target_type` values