How ThirdEYE decides an alert: rules and memory before models

Calling a language model for every alert is expensive, slow and hard to audit. ThirdEYE analyses an alert in a fixed order, and a model is only one step.

The order

  1. Correlation reuse. The alert is compared with correlated alerts from the last 24 hours. A close match reuses the earlier conclusion. A guard stops verdicts that came from a fallback path from being reused.
  2. Security AI. The built-in engine matches the alert against the rule catalog and against analyses a human has confirmed. By default this covers high and critical severity. Sigma-based resolution is available but off by default.
  3. Investigation. Indicators are extracted, enriched from the threat-intelligence providers you configure, and mapped to MITRE ATT&CK techniques.
  4. Model analysis. If a verdict is still needed, a configured provider is called. A daily token budget moves this step to a lighter prompt, or skips it, before a quota runs out.
  5. Decision. Configurable thresholds choose between block, escalate, investigate and triage. The justification is stored with the verdict.

What this buys you

  • Repeat alerts are cheap, because they never reach step 4.
  • The reasoning is inspectable at every step.
  • Running with only local models, or with no model, still produces triage.

What it does not do

It does not guarantee a correct verdict. The quality of step 4 depends on the model you configure, and high or critical alerts are never closed automatically.

See it on your own alerts.

Book a walkthrough with the team. We will show the platform end to end, tell you what is production-ready and what is not, and discuss how it would sit next to your existing SIEM.