Ready.
frozen@mid80 is dynamically displaying the liveness & properness status of a submacro, at the left of the macro ID, in menu-listings (of a few menues) while monitoring. What such is telling, is the discussion next.
A [sub]net is considered live, if one or more transitions within that [sub]net is/are [pseudo-]enabled.
The "not live" status is not necessarily permanent, but until a token would come from a remote section of the net, to this subnet/submacro. Neglecting what is happening out of this subnet (beyond the peripheral-locations). That is the familiar net-test method, taken to modules. Trivial.
If not live, there is no asterisk ' * ' at the left of that subnet/submacro ID.
The (up, down, or up&down) arrow at the left, is telling the properness vs. not properness. A [sub]net is proper if after a period of liveness, when returning to not-liveness, the [sub]net is identical to the state of that [sub]net when this monitoring session started. If the [sub]net has not been live yet, then there is no arrow at the left hand.
If all the time that [sub]net has finished at the proper (the first) state, the listed arrow points up.
Down-arrow, if was not-proper once, or all the time.
Up&down-arrow, if after some not-proper finish, the subnet was proper one or more times.
This handful of information is obviously not a lot, nor truly flexible. Good for alerting, though. If we would need more information for debugging, one may keep statistics of the specific portion, through the transition functions there. For example, logging the count of the pass-throughs, to x1.
The term is mostly for well-formedness. If proper, that subnet/submacro is (hopefully) consistent, all the time -- not quirky. But, if there is (environmental) data that is influencing the submacro, the behavior may be different, although the control state is the same. The properness is sometimes not necessarily the most-appropriate nature. For example, if that is a state-machine (like flip-flop), bistable/multistable behavior may be the wanted.
For more, I may think exposing system-hooks, to facilitate plugging your transition logic right into the proTest (properness-test) portion in the frozen@mid80 (system) logic. The "SYSTEM" is the term the SARA people used, for essentially the similar of what Noe & Nutt were referring to as the "environment." That is trivial to expose/hook the system-internals through Nutt-style transition-functions, because such functions work strictly locally, transforming from the inbound token attributes, to the outbound. (Data in xi/memory variables are modifiable, but they are totally avoidable while coding & exposing the system. The token-travel style is presumably sufficient for the system work.) That is, unlike the Windows device-driver vulnerability when the device-driver is allowed to function at the kernel level. (Vista WinUSB is not kernel mode, not to risk the system thus.)