Report System Documentation

Choose Your Starting Point

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Report System Documentation narrows that work to a staged guide for operating the Furries PH partner dashboard report system safely, clearly, and responsibly. Because this is a start 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 Section Helps You Decide

This is the map page. Start here when you know the general area but not the exact guide. The page should help you choose the next safe reading path before opening a dashboard screen, file, or service route. The intended readers are Partner admins, Trust and Safety staff, and FPH administrators. 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, /reports/new, /reports/detail?id=:incidentId, and /reports/manage?id=:incidentId.
• Records or contracts involved: Incident reports, Watchlist entries, Bans, Appeals, and Person profiles.
• 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.

A Natural Way Through The Section

1. Name the situation in front of you: Begin by naming the Report System situation, the owner, and the exact item involved in Report System Documentation.
2. Match it to the closest guide group: Use /reports, /reports/new, /reports/detail?id=:incidentId, and /reports/manage?id=:incidentId to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Open one guide at a time: Keep Incident reports, Watchlist entries, Bans, Appeals, and Person profiles in view so the work stays tied to the records or contracts it can affect.
4. Return here when the work changes shape: 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.

Leave This Page With A Direction

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. Start at this guide home and choose the stage that matches your job: foundations, basics, surfaces, best practices, lifecycles, or reference. This anchors the work to the correct scope before any record changes.
2. Step 2 - Confirm scope and records. Open the linked dashboard surface only after you understand the purpose and risk of that workflow. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Do the operating action. Follow the page-specific operator runbook before changing records. This keeps the report useful to the next reviewer instead of only to the person writing it.
4. Step 4 - Verify the result. Use related links when a step touches another workflow, such as payments, check-in, appeals, or record maintenance. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Hand off remaining work. After finishing work, verify the dashboard state and record any follow-up for the next operator. This leaves a handoff trail another operator can understand.

What this guide is for

This guide teaches partners how to use the dashboard report system without guessing. It explains what each page does, what each record means, who is responsible for each step, and how one report can affect a person, an event, and the wider community.

The language is intentionally plain. A Year 7 student should be able to understand the main idea, while a senior operator can still trace the dashboard surface, record type, permissions, and verification steps.

Learning stages

Stage	Read when	Pages
Foundations	You need the basic ideas first.	What Is a Report?, Accountability, Local vs Network Records
Safe basics	You need to do normal staff work.	File a Report, Review and Update
Dashboard surfaces	You need to understand each page.	Overview and Lists, New Report, Detail and Manage, Watchlists and Bans, Appeals and Cross-Bans, Person Profiles, Reminders and States
Best practices	You need safer judgement.	Report Writing, Evidence Handling
Lifecycles	You need to know how records move over time.	Report Lifecycle, Appeal Lifecycle, Record Maintenance
Reference	You need exact roles, records, or certification checks.	Role Access Matrix, Data Records, Certification Checklist, Glossary

Dashboard report surfaces audited

These dashboard routes are in scope:

• /reports: reports overview.
• /reports/all: all reports visible to the current role.
• /reports/my-reports and /reports/mine: reports filed by or assigned to the current user, including the legacy route.
• /reports/new: new report wizard.
• /reports/detail?id=:incidentId: report reader and revision context.
• /reports/manage?id=:incidentId: report editor and action workflow.
• /reports/bans: local and relevant ban records.
• /reports/watchlists: local watchlist and shared network watchlist.
• /reports/cross-bans: cross-community ban requests.
• /reports/network-ban-appeal?entryId=:watchlistEntryId: appeal submission flow for a network ban entry.
• /reports/ban-appeals: FPH/admin appeal review surface.
• /reports/profiles: person profile records and report linking.

Core rule

Every report should answer four questions:

1. Question 1. What happened? Write the answer before choosing the next action.
2. Question 2. How do we know? Write the answer before choosing the next action.
3. Question 3. What action did we take, if any? Write the answer before choosing the next action.
4. Question 4. How can a future reviewer understand and check our decision? Write the answer before choosing the next action.