## TL;DR
A generic rule scored the phishing report before the security rules ran. Evaluate security keywords first, default suspicious reports to high priority, and route them to the security queue directly.

## The query
```text
agent misclassified a phishing report as low priority: triage rule ordering
```

## Use this when
- phishing reports land as low priority
- security keywords are ignored
- phishing SLA is missed

## Not for
- spam vs phishing judgment calls
- priority disputes on normal tickets
- phishing analysis itself

## Steps
1. Trace the misclassified ticket to find which rule won. Expected output: the generic rule that outranked security is identified.
2. Move phishing and security-keyword rules to the top of the triage chain. Expected output: security signals evaluate first.
3. Default any report mentioning credentials, login pages, or suspicious links to high priority. Expected output: ambiguous reports escalate, not sink.
4. Route confirmed patterns straight to the security queue, bypassing tier 1. Expected output: phishing reaches analysts fast.
5. Review classifications weekly until the miss rate is zero. Expected output: a clean audit trail of correct priorities.

## Applies to
Ticket triage agents, ServiceNow, Jira, security intake queues.

## Variant phrasings
### Users report phishing via email, not tickets
Ingest the phishing mailbox with the same security-first rules.

### False positives flood the security queue
Tune keywords, but keep the default-high posture; tune precision, not the default.

## Why it happens
Phishing response is time-critical and triage is the front door. A single ordering mistake turns the front door into a wall.

## Edge cases
- Never auto-close phishing reports; every one needs a human verdict.
- Keep the keyword list updated with current phish vocabulary.
- Measure time-to-security-queue as the metric that matters.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hOaU3ahhd3GfgrZF4clkNg