Basic properties, assumptions, recommendations, and general statements about decision trigger include:
- 1. A decision trigger is a conditional expression that triggers an action. A decision trigger's outputs can control actuators and transactions. . . . Decision triggers abstractly define the end-purpose of a NoT.
- 2. A NoT, may or may not control an actuator (via a decision trigger).
- 3. A decision may have a binary output, but there will also be situations where the output of a decision trigger is a non-discrete output, i.e., a continuum of output values.
- 4. A decision trigger may have a built-in adaption capability as the environment element . . . changes.
- 5. A decision trigger will likely have a corresponding virtual implementation, i.e., code.
- 6. A decision trigger may have a unique owner.
- 7. Decision triggers may be acquired off-the-shelf or homegrown.
- 8. Decision triggers are executed at specific times or may execute continuously as new data becomes available.
- 9. Decision trigger results may be predictions.
- 10. Analytics could be implemented within decision triggers, however analytics could also be implemented within aggregators (that are executed by eUtilities).
- 11. If a decision trigger feeds data signals into an actuator, then the actuator may be considered as a eUtility if the actuator feeds data back into the NoT. Also, an actuator can and often should be considered as a component of the environment element (see Section 3). This model treats actuators as “consumers” of the outputs from decision triggers. Actuators are ‘things,’ but not all things are primitives in this model.
- 12. A decision trigger may feed its output back into the NoT creating a feedback loop4 (See Figure 4).
- 13. It is fair to view a decision trigger as an if-then rule, although they will not all have this form.
- 14. The workflow up to decision trigger execution may be partially parallelizable.
- 15. Failure to execute decision triggers at time tx may occur due to tardy data collection, inhibited sensors or eUtilities, inhibited communication channels, low performance aggregators, and a variety of other subsystem failure modes.
- 16. Economics and costs can play a role in the quality of the decision trigger’s output.
- 17. There may be intermediate decision triggers at any point in a NoT’s workflow.
- 18. Decision triggers act similarly to aggregators, and can be viewed as a special case of aggregator.
- 19. Security is a concern for decision triggers (malware or general defects). Other possibilities here might be indirect manipulation of input values to the trigger by tampering with or restricting the input values.
- 20. Reliability is a concern for decision triggers (general defects). Decision triggers could be inconsistent, self-contradictory, and incomplete. Understanding how bad data propagates to affect decision triggers is paramount. Failure to execute decision triggers at time tx may have undesired consequences.
- "Overview" section: NIST Special Publication 800-183, at 11-13.