On the PDM (all flavors), the physical input pins are called GPIs, and the physical output pins are called GPOs. You can configure any physical GPO you like to indicate PDM state; you can configure any physical GPI you like to control PDM state. Configured thusly, you trigger an action on the PDM by changing a GPI pin; to monitor its state you watch a GPO pin. Easy and obvious.
But, how do you use Livewire GPI and GPO pins (e.g. using LWRP)? Here, the senses are switched: to trigger an action on the PDM you change one of its Livewire GPOs; to monitor PDM state you watch one of its Livewire GPIs. It's as if there was a separate GPIO xNode inside the PDM chassis, with its GPOs wired to PDM's control lines, and its GPIs wired to PDM's status lines.
The reason for this flip is to be compatible with multicast GPIO. A PDM would naturally be an endpoint device, often talking to a console. When a PDM uses multicast GPIO, its Livewire GPIs have their values sent out by multicast, to be read and acted on by a console. Similarly, its Livewire GPOs watch for messages from a console, and react to them by changing their state. Thus, the GPIs must be used to report PDM state, and the GPOs must be used to control PDM state.
Note that on the webUI Configuration page's "Livewire GPIO" section, just as on the page's "Hardware GPIO" section, the control lines are labeled "Inputs" and the status lines are labeled "Outputs". These perhaps could be labeled "Inputs (GPOs)" and "Outputs (GPIs)" to make the reversal clearer, but at the cost of making the labels themselves more confusing.
We may want to relabel the "Inputs" and "Outputs" columns in the "Livewire GPIO" configuration section to better represent this.