What Is an Incident Report?

Start With The Idea

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, What Is an Incident Report? narrows that work to a plain-language explanation of report records, report subjects, evidence, actions, and why the dashboard keeps them structured. Because this is a foundations page, read it as part of the Report System learning path rather than as an isolated checklist.

A report is a written memory of something important. The goal is to protect people, keep facts clear, and leave enough context for future reviewers. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What This Page Explains

This is the concept layer. Read it before trying to operate the workflow so the later steps make sense in ordinary language first. The intended readers are New staff and Trust and Safety staff. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /reports and /reports/new.
• Records or contracts involved: Incident reports and Report revisions.
• Main care point: Watch for incomplete facts, unfair wording, privacy exposure, or a decision that another reviewer cannot understand later.
• Proof worth keeping: report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner.

How The Idea Builds Toward Action

1. Say the idea in ordinary words: Begin by naming the Report System situation, the owner, and the exact item involved in What Is an Incident Report?
2. Connect the idea to one real screen or source: Use /reports and /reports/new to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Name what could change for people or records: Keep Incident reports and Report revisions in view so the work stays tied to the records or contracts it can affect.
4. Choose the next practical guide from the related links: Before handing off, save proof such as report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner so another reviewer can understand the facts without relying on memory.

You Are Ready To Continue When

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on people, privacy, fairness, evidence, and the trustworthiness of the record.
3. Proof is findable: The handoff points to evidence that another reviewer can understand the facts without relying on memory.

End-to-end operator runbook

Use this numbered runbook when you need to operate this area without getting stuck. Read the purpose of each step, do the action in order, and use the final sentence as the checkpoint before continuing.

1. Step 1 - Choose the right path. Read this page before operating the related dashboard workflow so the terms and risks are clear. This anchors the work to the correct scope before any record changes.
2. Step 2 - Confirm scope and records. Identify which people, records, and community outcomes the workflow can affect. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Do the operating action. Open /reports, /reports/new only when you know what decision or check you are performing. This keeps the report useful to the next reviewer instead of only to the person writing it.
4. Step 4 - Verify the result. Before changing Incident reports, Report revisions, ask whether the action is fair, accurate, necessary, and explainable later. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Hand off remaining work. Use the related pages to move from concept to the exact operating surface, lifecycle, or reference checklist. This leaves a handoff trail another operator can understand.

Simple meaning

An incident report is a structured safety record. It records something that may have happened, who was involved, what evidence exists, what staff did, and what should happen next.

Think of it like a careful notebook entry that future staff can trust. It is not a punishment by itself. It is a record that helps staff decide whether action is needed.

Main people in a report

Term	Plain meaning
Reporter	The person or staff member who gave the information.
Subject	The person being reported.
Victim	The person harmed or targeted, if there is one.
Witness	A person who saw, heard, or received evidence about what happened.
Officer or investigator	Staff member handling the report.
Reviewer	Someone checking the record later, such as an admin or appeal reviewer.

What a report can include

• A short summary.
• Date, time, place, and event context.
• Names, handles, emails, or other identifiers.
• What happened, in plain words.
• Evidence such as screenshots, chat logs, links, photos, or witness notes.
• Severity and status.
• Staff notes and investigation notes.
• Action taken, such as watchlist, local ban, or network ban.
• Appeal process notes.
• Revision history showing what changed.

What a report is not

A report is not:

• A place for insults.
• A rumor collection.
• A punishment announcement.
• A private venting space.
• A place to hide uncertainty.

Why structure matters

Structured fields help staff search, compare, and review reports. They also make mistakes easier to find. A clear record helps a partner answer hard questions later: why did we ban this person, why did we not ban them, what evidence did we have, and who made the decision?

First links to learn next

After this page:

1. Action 1. Read Accountability to understand the weight of report records. Pause long enough to confirm the record says only what is known.
2. Action 2. Read Local vs Network Records before sharing anything beyond your partner. Check the saved value before adding more context.
3. Action 3. Read File a Report before using /reports/new. Use the report history as the source of truth before continuing.