People ask what an instrumentation review looks like on the Tuesday it actually happens. It looks like a desk in Bukit Mertajam, a TestFlight build, a Play internal APK, a test payment method, and a printed list of the three journeys the brief named. Charts stay closed until the walk is done.
We start on a device that is not our daily phone. The app should see a new install. For Android we often use a proxy so we can read payloads even when the in-SDK debug view is fussy. For iOS we use the SDK's debug logging if it is honest, and a proxy when it is not.
The printed journey is the script
Each line on the paper is a human action: enter a delivery address, apply a voucher that should fail, apply one that should succeed, pay. Beside it we leave a blank for the event name we saw, the time, and whether a parameter we care about was present. If the brief says checkout_complete must carry order_id, and the payload arrives without it, that line gets a mark in oxide ink and we do the payment once more to see if it was a fluke.
We do not complete every optional path. We complete the paths the company claims to read. A review that tries to tap every settings toggle is a different engagement, and we will say so rather than quietly skip the checkout that pays the bills.
Why two devices
iOS and Android still disagree about WebViews, about billing sheets, about when an activity dies. A finding that exists on only one store is still a finding. Shipping a 'fix' that was verified on the reviewer's iPhone is how the last Android silence happened.
When the walk is finished we type the paper into the report the same day, while the payloads are still in the proxy history. The readout call is for decisions. The walking is for evidence. Mixing those two on the same call is how findings get argued into softness.