Triage pipeline
The states a submission moves through, how overlap is resolved, and how the SLA policy engine keeps response commitments visible.
Triage is where most security programs fail: reports arrive faster than a team can classify them, duplicates consume budget, and the reporter hears nothing for weeks. On AXUM SEC triage is a first-class workflow with explicit states, visible to everyone involved.
The pipeline
A submission moves through a defined sequence of states:
| State | What it means | Who acts next |
|---|---|---|
| Submitted | Report received and acknowledged automatically | Triage team |
| In review | Being classified, reproduced and checked for scope | Triage team, sometimes the reporter |
| Needs more information | Blocked on detail, reproduction steps or evidence | Reporter |
| Validated | Confirmed as a real, in-scope issue with an assigned severity | Program owner |
| Duplicate / merged | Overlaps an earlier or concurrent report | Triage team |
| Rewarded | Reward approved and queued for payment | Finance / payout run |
| Remediation | Fix in progress, linked to the engineering ticket | Engineering |
| Verified / closed | Fix confirmed; disclosure decision recorded | Program owner |
Every transition is timestamped and attributable, so "what happened to this report" is answerable months later.
Working the queue
- Severity, status and lifecycle filters let the team work the urgent set without reading the whole queue.
- Reviewer guidance attaches internal notes and decision rationale to a report without exposing them to the reporter.
- Task and milestone boards carry the work that follows validation — ownership, deadlines and completion state.
- Report-to-remediation tracking keeps one record from submission to verified fix, rather than a report in one tool and a ticket in another.
Overlap and duplicates
Duplicate handling is a policy question as much as a technical one. The platform supports the policies programs actually use:
- Merge — combine two reports of the same issue into a single record while preserving both reporters.
- Duplicate marking with attribution — the earlier or more complete report is credited.
- Reward segmentation between reporters — where a program's policy splits a reward, both sides of the decision are recorded.
- Duplicate intelligence — semantic similarity, including across programs, flags likely repeats at submission time before effort is spent. See Duplicate intelligence.
The SLA policy engine
Response and resolution commitments are configured per program and enforced rather than remembered:
- First response — the window in which a submission must be acknowledged.
- Triage decision — the window in which a validated/duplicate/out-of-scope decision must be recorded.
- Remediation target — the window in which a validated finding should be fixed, by severity.
- Breach visibility — items approaching or past an SLA are surfaced to the program owner instead of silently ageing.
Contracted SLA response guarantees are Enterprise-tier; lower tiers use standard response windows.
Keeping reporters informed
Researchers disengage when they hear nothing. The pipeline is designed so that the reporter can always see the state of their own report, and so that the platform's own notifications do the chasing:
- Automatic acknowledgement on submission.
- State-change notifications through in-app notifications and email.
- Requests for information that are explicit about what is missing.
- A recorded reward decision with the calculation shown before payment.
Availability and limits
- The triage pipeline, states, filters, merging and SLA configuration are available on all tiers.
- AI-assisted classification and duplicate intelligence are Professional-tier.
- Contracted SLA response guarantees and dedicated tester pools are Enterprise-tier.
Related docs
- Duplicate intelligence — how semantic overlap is detected
- Remediation and verification — what happens after validation
- AI assistance — where automation is applied in triage
- Payouts and KYC — from reward approval to money received