Consistent event classes help teams discuss the same conditions accurately. Detection, enforcement, service errors and uncertain outcomes require distinct records.
Evaluation approach
Retain normalized type, original code, policy version and confidence where useful. Unknown events must not silently enter a safe category.
Application example
When grouping root events from two products, preserve differences in coverage and certainty.
Limits and considerations
The same label can describe different detections across suppliers.
Make event names meaningful
Define source, type, severity, time and decision fields. Do not lose platform-specific meaning by forcing distinct Android and iOS claims under one broad label. Expose schema changes through versions.
Detection, delivery failures and policy rejection are different events. Combining them into one attack counter misleads readers. Analysts should know whether a record contains verified evidence or a client observation.
Checks and decisions
- Version the schema
- Preserve original codes
- Separate unknown events
A taxonomy should aid comparison without hiding technical differences.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.