New Report Surface

Use This Dashboard Area Safely

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, New Report Surface narrows that work to field-by-field guide for creating incident reports through /reports/new. Because this is a surfaces 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 The Screen Controls

This page explains a specific surface. Treat every button, field, filter, and table as a way to view or change real records, not just as a visual layout. The intended readers are Trust and Safety staff and Partner admins. 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/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.

Read The Screen From Top To Bottom

1. Confirm you are on the right event, report, route, or file: Begin by naming the Report System situation, the owner, and the exact item involved in New Report Surface.
2. Read the current state before changing it: Use /reports/new to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Use the smallest action that matches the task: Keep Incident reports and Report revisions in view so the work stays tied to the records or contracts it can affect.
4. Check the list, detail view, history, or public page afterward: 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.

Before You Leave The Screen

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 - Identify the report and scope. Open /reports/new and confirm you are in the correct partner or network scope. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the existing facts before acting. Complete subject, incident, reporter, evidence, severity, action, and appeal sections in order. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Make the smallest factual update. Use markdown-ext only to make the report clearer; do not hide important facts inside formatting. This keeps the report useful to the next reviewer instead of only to the person writing it.
4. Step 4 - Check fairness, privacy, and risk. Review required fields and validation messages before saving. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Verify the saved record and history. Save the report, then open the created detail page and confirm the saved values match your intent. A later reviewer should be able to understand this step from the saved record.
6. Step 6 - Hand off the next responsibility. If saving fails, keep the draft visible, capture the error, and ask a support lead before retyping sensitive material elsewhere. This leaves a handoff trail another operator can understand.

Purpose

/reports/new is the intake page. Use it when a partner needs to create a new incident report from information received from staff, attendees, witnesses, or direct observation.

The page is built as a wizard-style workflow. It collects subject identity, victim information, incident details, evidence, staff handling, and any enforcement action.

Who should use it

Role	Expected use
Trust and Safety	File safety reports and update own report context.
Partner admin	File reports and review serious reports.
ConOps or Marketing	Should not create report records unless explicitly granted report permissions.
FPH admin	May create or review network-relevant reports when operating in the correct scope.

Major sections

Section	What it records	Why it matters
Subject	Names, handles, emails, alternate identifiers.	Helps avoid mistaken identity.
Victim	Person affected, if known and safe to record.	Helps staff protect the harmed person.
Violation	What happened, severity, violation types, incident narrative.	Forms the core factual record.
Officer	Staff member receiving or handling the case.	Makes ownership clear.
Investigation	Investigator, contact, date, and notes.	Shows how the case was checked.
Evidence	Witnesses, screenshots, links, logs, documents.	Supports or weakens the decision.
Action	Warning, watchlist, event ban, network ban, appeal process.	Records consequences and fairness steps.
Cross-partner	Recommendation and notes for wider sharing.	Controls whether other partners need context.

Markdown-ext fields

Long text fields support the dashboard markdown-ext style used for report notes. Use it for:

• Clear lists of evidence.
• Short timelines.
• Links to source material.
• Tables only when they make the record easier to understand.

Avoid decorative formatting. Markdown should make the report clearer, not louder.

Save behavior

After save, the system creates an incident report and revision history. If an enforcement action is included, it may also create or update watchlist or ban records. Confirm the saved report appears on Detail and Manage.

Common mistakes

• Choosing high severity because staff are upset, not because risk is high.
• Writing “proof attached” without describing what the proof shows.
• Adding network-scope notes before partner review.
• Forgetting to record who received the report.
• Using a ban action when a watchlist entry is more appropriate.

Verification checklist

• The report has a clear subject or says what is unknown.
• The incident narrative is factual and chronological.
• Evidence notes say what exists and where.
• Status and severity match the current stage.
• Any action has action notes and appeal process notes.
• The saved report opens through /reports/detail?id=:incidentId.