What Is a Report

Overview

A report is a durable incident record. It explains what happened, who was involved, what evidence exists, what action staff took, how appeal review works, and whether the case should stay local or move to network review.

A report is not a casual note. It can create watchlist or ban context, feed network-ban review, and become evidence for future operators.

Record model

flowchart LR
  report["Incident report"] --> revision["Report revisions"]
  report --> watchlist["Local watchlist entry"]
  report --> ban["Local ban entry"]
  report --> cross["Cross-ban recommendation"]
  cross --> network["Network ban decision"]
  network --> appeal["Network ban appeal"]
  report --> profile["Person profile links"]

Inputs that define a report

Input family	Surface	What it proves
Severity and status	New Report, Manage Report	Urgency and lifecycle state.
Incident details	New/Manage	What happened, when, where, and in what organizational context.
Reported person and victim fields	New/Manage	Who the record concerns and who was affected.
Violation and evidence fields	New/Manage	Why the report exists and what supports it.
Witness fields	New/Manage	Who can corroborate or clarify facts.
Action, ban scope, and appeal process	New/Manage, Bans	What restriction exists and how review can happen.
Cross-community recommendation	New/Manage, Cross-ban Requests	Whether FPH admin should consider network action.
Revision history	Report Detail	How the report changed after submission.

Workflow context

flowchart TD
  facts["Incident facts and evidence"] --> intake["File New Report"]
  intake --> review["Read Report Detail"]
  review --> maintain["Manage Report if facts change"]
  maintain --> local["Watchlist or local ban state"]
  maintain --> network["Optional network review"]
  local --> history["Revision and action history"]
  network --> history

Completion standard

A report is usable when another reviewer can identify the report number, subject, status, severity, evidence, action notes, appeal path, and current owner without asking the original filer to remember details.

End-to-end operator runbook

1. Name the incident: Use a factual summary and route to New Report.
2. Capture evidence: Add source links, screenshots, witness context, and uncertainty.
3. Record action: Explain what staff did and why.
4. Preserve appeal path: Write how the subject can ask for review.
5. Verify detail page: Confirm the rendered report shows the same facts future staff need.

Common mistakes

Do not rely on chat memory or private staff notes as the report. If the reasoning affects safety or access, it belongs in the report or an auditable linked record.