Text decision tree
Adapted from Appendix AL of Decision Trees: Frameworks for Technology Choices. Sources reviewed 2026-11-11.
START: A detection needs evidence, tests, ownership and an operational feedback loop.
Q1. Threat behavior and goal defined?
Yes -> Describe the detection hypothesis. Specify expected evidence and limits. [Q2]
No -> Otherwise refine the threat hypothesis before writing a rule. [STOP]
Q2. Required events and fields available?
Yes -> Implement the detection logic. Telemetry schemas affect detections. [Q3]
No -> Otherwise fix telemetry and field mappings before claiming coverage. [STOP]
Q3. Representative detection tests pass?
Yes -> Review a staged deployment. Validate expected matches and benign cases. [Q4]
No -> Otherwise revise the rule or its assumptions and repeat the tests. [STOP]
Q4. Live alert quality is acceptable?
Yes -> Maintain the detection. Deployed rules need tuning and updates. [END]
No -> Otherwise use operational feedback to revise or roll back the detection. [STOP]
END: Version the logic, retain test evidence and review coverage as the environment changes.
AI-generated chapter illustration
Conceptual illustration for Build and maintain detection logic
The factory metaphor broadly illustrates specification, data, tests and maintenance. Its sample rule ID/date and approval stamp are invented illustration details, not actual approval evidence. Switches, pipes and return paths do not define exact yes/no routing; use the authored text and deterministic graph for that.
The illustration was generated in BookWriter. Its visual arrangement is interpretive; use the explicit nodes and routes in the graph and text tree for the decision.