Deep Audit · Triager review queue
Findings the AI couldn't judge with high confidence land in a per-scan review queue with the original JupiterSec payload and the AI's error reason: review, accept, or replay.
Last updated Jun 9, 2026
What it is
The Active Triager judges every JupiterSec finding as confirmed, rejected, or inconclusive. Inconclusive findings (and any the AI couldn’t process at all: model timeout, malformed response, budget ceiling) go to a per-scan review queue rather than being silently discarded.
The queue appears as a yellow card on the scan detail page when non-empty. Click to expand and see each entry:
- Vulnerability type
- Target URL
- The AI’s error reason (why it couldn’t decide)
- Attempt count (how many times this finding hit the queue)
- First seen / last seen timestamps
Why it matters
A “scanner that drops what it can’t handle” loses ~5-15% of real findings in any non-trivial scan. The review queue surfaces those to the operator instead, with enough context to decide:
| Operator action | What happens |
|---|---|
| Review the original JupiterSec payload | Decide manually whether it’s real |
| Accept | (planned) Promote to a normal finding |
| Dismiss | (planned) Mark resolved, hide from queue |
| Replay | (planned) Re-submit to the Triager with a different model |
Today vs roadmap
| Today | Planned | |
|---|---|---|
| Queue visible per scan | ✅ | |
| Original payload + error reason | ✅ | |
| Operator accept / dismiss / replay buttons | next sprint | |
| Audit trail of operator actions | next sprint |
Why this is a real differentiator
Most scanners log dropped findings to stderr and forget them. The review queue makes the operator the final arbiter on the ~10% of findings the AI was unsure about, bringing the recall back without sacrificing precision.