AI-Assisted Pre-Triage Signals for Report Quality (aligns with Q – Toasty Triage & E2 – Security Scan)

[Aashik1701]

Background

After running BLT locally and exploring the report → triage → reward workflow using seeded data, I noticed that the platform currently relies heavily on reporter-supplied information before human validation.

This means reviewers must manually determine:

• whether a report is meaningful
• whether severity claims are reasonable
• whether the submission is spam / scanner-generated / low effort

My goal is not to automate security decisions, but to reduce reviewer effort by surfacing helpful signals before triage begins.

This seems aligned with:

• Q — Toasty Triage (AI-powered triage assistant)
• E2 — Security Scan (triage guidance & explainability)

---

Objective

Provide pre-triage assistance signals that help reviewers evaluate report quality faster.

The system should:

• never auto-reject submissions
• never auto-judge vulnerability validity
• only assist human triagers

In short:
Improve reviewer confidence and efficiency, not automate vulnerability assessment.

---

Proposed Signal Categories

1) Low-Effort / Spam Indicators

Detect patterns commonly seen in noisy submissions:

• duplicated payloads across accounts
• template or copied descriptions
• extremely high submission frequency
• incomplete explanation with high severity claim

---

2) Metadata Consistency Checks

Highlight logical inconsistencies:

• payload unrelated to target domain
• unrealistic severity vs provided evidence
• missing reproduction clarity
• invalid vulnerability category selection

---

3) Suspicious Technical Patterns

Identify non-meaningful technical reports:

• generic scanner output pasted as manual finding
• random parameter fuzzing without reasoning
• non-executable proof-of-concept
• vulnerability class mismatch with payload structure

---

Output to Reviewers

Instead of blocking the report, BLT would display hints such as:

• possible duplicate / repeated payload
• likely automated scanner submission
• severity may be overstated
• insufficient reproducibility evidence

These are signals, not decisions.

---

Proposed Implementation Path

• define simple deterministic rules first
• document a lightweight threat model for malicious or low-effort reporters
• surface hints in triage interface
• optionally extend to ML-assisted scoring later

---

Expected Benefit

• reduces reviewer fatigue
• improves report quality awareness
• makes rewards/reputation more reliable
• keeps humans in control of security judgement

[DonnieBLT]

We need to rename Q. We have a Toasty already

[Aashik1701]

Makes sense 👍
The goal is more of a signal layer before triage rather than the triage assistant itself.

Possible names:

Report Signals, Pre-Triage Signals, Report Quality Hints, Intake Analyzer...

Happy to align with whatever naming fits the BLT architecture best.