Object-level trigger inputs
Detector trigger choices come from the effective detector model for that source, with the runtime mapping raw detector classes into stable live trigger IDs such as `PERSON` and `BAG`.
Trigger Library
The Trigger Zoo describes the event types that the Rules page can convert into alerts and downstream actions. It sits between raw model output and the operators or systems that need to respond.
Trigger Families
The current docs describe detector-driven and anomaly-driven triggers as the primary examples, with room for more trigger families to appear after restart.
Detector trigger choices come from the effective detector model for that source, with the runtime mapping raw detector classes into stable live trigger IDs such as `PERSON` and `BAG`.
Anomaly object and activity choices come from the saved anomaly prompt settings, and each anomaly rule now owns its own `1-10` cutoff.
The web UI presents saved rule choices as stable operator-facing options instead of making the browser parse registry files directly.
Why it matters
The Trigger Zoo controls when the system decides something important happened. It is deliberately separate from model selection and connector delivery so each concern can evolve independently.
The docs explicitly call out that Trigger Zoo entries are plugin-backed, which keeps the UI contract stable even as the runtime grows new event types.
Current Semantics
For the default COCO-trained YOLOX detector family, raw detector classes are broader than the live trigger IDs the runtime emits. That is intentional.
Detector choices come from the active model metadata for that source, while anomaly choices come from the saved prompt payload rather than from the browser reading YAML.
Read the runtime’s catalog explanation and the separation between the three zoos.
Read the guideReview how rules, prompts, and detector class options appear in the control plane.
Read the guide