Application to Reclassify Volume Button Uncertainty

I.

The phone was taken out of the pocket. The podcast app was opened. The play button was pressed.

Before the first word of audio arrived, the volume button was pressed.

Not to raise the volume. Not to lower it. The volume button was pressed once, downward, in a test that would establish what the current volume level was and whether that level would be appropriate for a crowded train.

The volume readout appeared: 63%.

The volume was pressed up twice to 70%. Then down once to 67%. Then down again to 63%. The audio began. It was fine.

II.

63% is the volume the subject uses for podcasts. It has been 63% for most of the last year, adjusted situationally to 50% for quiet rooms and 80% for windy streets. For a moderately crowded train with ambient noise around 70 decibels, 63% is the correct level.

The subject knows this. This knowledge does not prevent the check.

Under the governing rule, any volume button uncertainty performed twice must be repeated until the phone provides emotional certainty.

The volume was not wrong. The volume was checked because it could have been wrong, which is a different condition, and one the phone cannot resolve.

III.

The check has its own internal logic. The phone was last used for music, which runs at different levels than podcasts. The phone might have been used by someone else, theoretically, who changed the volume. A previous podcast might have ended loudly and the volume might have been raised and left there.

None of these things happened on this occasion. They have happened before, which is what keeps the check funded.

IV.

The podcast played at 63%. The subject arrived at their destination. The volume button was pressed once upon leaving the train, checking the level before returning the phone to the pocket.

The level was 63%.

The threshold moved again. The device supervised. The check was filed.