- Audience
- Reviewers and senior members responsible for moderation.
- Read first
- Incident reporting — you are evaluating output of that process.
- Read next
- Incident records for what happens after verification.
- Mindset
- Every decision is recorded. Move deliberately and preserve the reason.
Purpose
The review queue is the operating surface for reports that need human judgment before they move wider. The queue helps reviewers focus on severity, status, report quality, and whether the selected audience is appropriate. Review actions happen on-page with success or error feedback, so reviewers should wait for the visible confirmation before moving to the next decision.
Reviewers do three jobs at once: verify the facts are believable and complete, ensure visibility is appropriate, and preserve enough context that a later reviewer can understand the decision.
Moderation states
| State | Meaning | Can transition to |
|---|---|---|
| Submitted | The report has entered the workflow but is not yet claimed or resolved. | Under review (via claim). |
| Under review | A reviewer has claimed or reclaimed the report and is evaluating it. | Changes requested, verified, rejected. |
| Changes requested | The report needs clarification or correction before verification. | Under review (when the reporter resubmits). |
| Verified | The report is accepted for the selected visibility scope and becomes part of the durable record. | Under review (via return to review). |
| Rejected | The report should not proceed as an operational incident record. | Under review (via return to review, rare). |
Reviewer actions
| Action | Use when | Always pair with |
|---|---|---|
| Claim | You will own the next decision on this report. | A glance at the narrative; do not claim what you will not handle. |
| Request changes | Missing facts, unclear narrative, wrong severity, or inappropriate visibility. | A comment explaining exactly what needs to change. |
| Verify | The report is ready for its intended audience and future search. | A comment if anything material was clarified or adjusted. |
| Reject | Duplicate, out of scope, unsupported, or not appropriate for an incident record. | A comment explaining the reason; link the related incident if duplicate. |
| Return to review | A previously closed report needs additional redaction, clarification, or operational judgment. | A comment explaining why the record is being reopened. |
Decision flow
Most reports follow one of three paths. Knowing the typical decision flow speeds the queue and reduces churn.
- Quick verify. Report is complete, severity is right, visibility is appropriate. Verify with optional comment.
- Request changes → verify. Report is mostly good but missing a fact or has wrong severity/visibility. Request changes with a specific comment, wait for resubmission, then verify.
- Reject. Report is a duplicate, out of scope, or not an operational record (test entry, personal complaint without security relevance). Reject with comment.
Edge cases:
- Hold for context. Sometimes a report needs an external check before verification (camera footage, partner confirmation). Leave the report in "under review" and comment on what you are waiting for. Reclaim or hand off as appropriate.
- Return to review. After verification, new facts may justify reopening — e.g., personal information should be redacted, or visibility was too broad. Return to review and adjust.
Reviewer notes
Use comments to preserve why a decision was made. A good note is short, factual, and useful to the next reviewer. Add a note when severity was changed, clarification was requested, visibility was narrowed, or a report was verified despite minor missing details.
Examples
Severity adjusted
"Downgraded medium → low — subject left immediately and no follow-up needed. Greeter handled appropriately."
Visibility narrowed
"Visibility narrowed from trust group to origin-only. Reason: narrative mentions a partner staff member; will share via partner message instead."
Verified with caveat
"Verified. Occurred-at time is approximate; greeter A confirmed within ±10 minutes of stated time."
Do not use comments as a replacement for fixing a poor report. If the narrative is unclear or the location is wrong, request changes instead.
Verification criteria
- The report has a clear title, summary, and narrative.
- The severity and operational status match the actual situation.
- The location is specific enough for follow-up.
- Visibility is no broader than necessary.
- Unnecessary personal identifiers have been avoided or removed.
- Any remaining assumptions are clearly labeled.
- Tags are present and useful for future search.
Common scenarios
The reporter described an interpretation, not an observation
Request changes with a specific ask: replace "he was acting suspicious" with what the person actually did. Provide an example if helpful.
Severity feels too high
Adjust severity yourself, comment with the reasoning, then verify. Down-grading after the fact is the reviewer's call. Do not request changes purely for severity.
The report duplicates an open incident
Reject with a comment linking the original incident ID. Add a sighting on the original record with any new observations from the duplicate.
You're conflicted — verify or reject?
If the underlying event is real and operationally relevant, verify with origin-only visibility and a note explaining the limits. Rejecting a real event because the writeup is rough loses the record entirely.
You claimed but can't finish today
Comment that you are unavailable and unclaim, or hand off to another reviewer by name. Do not leave the report in "under review" without context overnight.
Frequently asked questions
Can two reviewers claim the same report?
Claim is exclusive; reassignment is allowed. If two reviewers want to collaborate, one claims and the other comments.
Should I verify my own reports?
Avoid it when possible. A second reviewer's eyes catch most of the issues a self-review misses. For very small teams where it is unavoidable, comment explicitly that the reporter and reviewer are the same person.
What if I changed visibility but later realized it was wrong?
Return the record to review and adjust. Comment with the new reason. Past disclosures already made cannot be unmade — future visibility is what you control.
How do I handle a partner-submitted report I cannot verify?
Partners do not submit into your queue — they submit in their own workspace. If you received a partner-shared record and disagree with content, raise it via partner message; do not edit their record.
Is there an SLA for review?
The platform does not enforce one. Your organization should set an internal target (e.g., low/medium within 48 hours, high within 4 hours, critical within minutes). Document it where reviewers see it.