Give every security event a consistent meaning
Wildo classifies security events with a shared category and severity. A sign-in, a permission change and an access refusal retain their different meanings as they move from the application’s trail into a customer’s security tooling.
Example — Give events a consistent meaning
A successful role grant is still a warning-level administrative event. A security team can review privilege changes without mixing them into routine sign-in traffic.
For engineers
AUDIT_EVENT_CLASSIFICATION_MAP covers the core event vocabulary. These two actual entries show why successful activity does not always carry the same severity:
[CoreAuditableEventType.USER_LOGIN]: { category: AuditEventCategory.AUTHENTICATION, severity: AuditEventSeverity.INFO },
[CoreAuditableEventType.USER_APP_ROLES_CHANGED]: { category: AuditEventCategory.AUTHORIZATION, severity: AuditEventSeverity.WARNING },
These are selected entries from security-audit-event-envelope.shared.schema.ts, not a complete map. The central audit writer and exported envelope resolve classification from the event type, keeping the interpretation consistent across destinations.
| Level | Reader meaning |
|---|---|
| Info | Routine activity to retain and correlate |
| Warning | Administrative or security-relevant change worth reviewing |
| Critical | A strong security signal requiring attention |
Tune review without changing what happened
Customer export configuration can choose categories, a minimum severity and specific event types. A delivery filter selects events; it does not reclassify them. Correlation and event-specific fields let analysts narrow a noisy pattern without discarding the meaning of each event.
When extending core events, provide the classification and typed payload alongside a wired producer. Application-specific event types use the classification resolver’s documented default when they have no core entry; do not assume adding a string alone gives it a particular severity.