procedure design. if you want to design your own approach procedure, for example. or if you are designing a takeoff/landing facility.

a relative of mine was involved in developing the eSIM standards, working with a consortium of telcos and phone manufacturers.

For whatever reason, docs like that one are something he just loves to both read and produce. Diving in deep to a topic, finding every rough edge, corner case, undefined bit of behaviour and getting consensus from involved parties. I think I'd rather bash my head repeatedly against a brick wall, but somehow he finds it a lot of fun.

I'm a Solutions Architect -albeit in software- and I LOVE documentation like that. I will spend days and weeks consuming esoterica on even the most "simple" of specifications (looking at you JSON). I'll spend hours just ruminating after reading a single concept for a protocol. Partly because I enjoy it and partly because it's my job. I need to understand not just how the code works, but the implications and implementations of it. I also need to be able to explain all of it at varying levels of detail in both technical and non-technical terms.