Findings, the dashboard & SIEM routing

What a finding is

A finding is scored metadata, never raw content: a timestamp, channel, sender, the matched concept and severity, a risk score, and the policy attribution. The raw message or action payload never leaves your tenant and never appears in a finding.

The operations dashboard

The scanner serves a security-operations dashboard in your tenant:

Put the dashboard behind Microsoft Entra ("Easy Auth") or your own front door for production.

The review loop

Analysts Confirm (true positive) or Dismiss (false positive) each finding. That decision:

This feedback is what tunes thresholds to your environment over time.

Case dedup & linking

Near-duplicate findings are linked into a single case rather than paging your SOC twice for the same thing. When a finding is elevated, its embedding is compared against recent findings; a match above the dedup threshold is routed as a case update (not a fresh alert) and shown in the queue as "N related." Dedup is keyed on the finding's embedding — no raw content is stored — runs in-tenant, and can be tuned (COMPILED_DEDUP_THRESHOLD) or turned off (COMPILED_FINDING_DEDUP=off).

SIEM / SOAR routing

Elevated findings route to your SOC on detection, and review decisions route as feedback events. Set a collector URL (COMPILED_SIEM_WEBHOOK) and findings are POSTed as structured JSON — Splunk HEC, a Microsoft Sentinel / Logic-App endpoint, ServiceNow, etc. With no webhook set, the same events are emitted as structured log lines for your log pipeline. No raw content is ever routed.

A finding routed to your SIEM looks like:

{
  "type": "finding",
  "message_id": "…",
  "channel": "teams",
  "sender": "…",
  "timestamp": "2026-06-30T10:00:00Z",
  "risk": 0.91,
  "top": { "concept": "insider_trading", "severity": 0.9 }
}