@7: In a production line at several points the item has to be inspected, so that the controlling software can decide how to treat the specific item. Easy decisions are quality checks like "go on" or "recycle". The parts themselves don't decide, but the software controlling the production line decides according to the measurements of different detectors taken from that part. Speaking of user perception, it is the specific detector which decides whether the part is to be recycled or not.
In some cases there is more than one measurement taken. PhotoCell and TemperatureSensor were replacements of real sensors in that line. But to make it clearer I give another (faked) example:
A weight can be measured by a scale and by calculating the volume via optical recognition. The logic says that the item is recycled if one of the two values falls below a certain threshold. If you know that the volumetric analysis is unreliable, you can configure that, if the scale gives a signal "OK", it doesn't matter what the volumetric analysis says. "ADetermines" therefore would not be strong enough, as a "Fault" signal of A determines this condition in both settings, that's why I thought about that "solely" in the parameter name.
BTW: #6 is generally right, as these are parameters for the decision of ZZZ the name of the parameter should contain that. But in this case the specific configuration parameter is assigned to the process step deciding over condition ZZZ by its configuration context, so the namespace of that configuration setting already includes the assignment to its usage.
