Report Lifecycle

Follow The Record Over Time

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Report Lifecycle narrows that work to how an incident report moves from intake through triage, investigation, resolution, and closure. Because this is a lifecycles 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 Changes Across The Lifecycle

This page follows a record from one state to another. Read it as a timeline so handoffs, reversals, and closeout work stay understandable. 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, /reports/detail?id=:incidentId, and /reports/manage?id=:incidentId.
• Records or contracts involved: Incident reports, Status changes, and 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.

Track Each State Change

1. Find the current state: Begin by naming the Report System situation, the owner, and the exact item involved in Report Lifecycle.
2. Read what must be true before the next state: Use /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. Watch for side effects when the state changes: Keep Incident reports, Status changes, and Revisions in view so the work stays tied to the records or contracts it can affect.
4. Keep the history clear for the next reviewer: 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.

The Lifecycle Is Clear 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 - Identify the report and scope. Start at intake: create or locate the report and confirm the report ID. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the existing facts before acting. Move through triage: assign owner, severity, immediate risk, and required follow-up. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Make the smallest factual update. Investigate by adding evidence, witness notes, subject links, and decision notes as they become known. 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. Choose an outcome: no action, monitor, watchlist, local action, network review, or ban process. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Verify the saved record and history. Close only when required actions, appeal notes, and record links are complete. A later reviewer should be able to understand this step from the saved record.
6. Step 6 - Hand off the next responsibility. Reopen if new evidence changes risk, accuracy, scope, or fairness. This leaves a handoff trail another operator can understand.

Lifecycle overview

Every report should move through a understandable path. Not every report needs every step, but every status should have a reason.

Status	Entry condition	Responsible role	Verify completion
New	Report was just filed.	Report writer or intake staff.	Basic fields and source are present.
Triage	Staff are deciding urgency and owner.	Trust and Safety or partner admin.	Urgency, scope, and next step are clear.
Investigating	Staff are checking evidence or contacting people.	Investigator or assigned staff.	Evidence and notes are updated.
Resolved	Decision and action are complete.	Partner admin or authorized staff.	Action notes and appeal process are recorded.
Closed	No further action is planned or record is archived.	Authorized reviewer.	Closure reason is clear.

Allowed transitions

Common transitions:

• new -> triage
• triage -> investigating
• investigating -> resolved
• resolved -> closed
• closed -> triage when reopened with a clear reason

Avoid jumping from new to closed unless the report is clearly duplicate, invalid, withdrawn, or outside scope.

What changes in the dashboard

• Lists update status badges.
• Detail pages show the latest status and revision history.
• Manage pages allow authorized users to edit status and action fields.
• Related watchlist, ban, appeal, and profile surfaces may change depending on action.

Reopen rules

Reopen a report when:

• New evidence appears.
• A linked profile shows a pattern.
• An appeal reveals a record error.
• The action was applied incorrectly.
• The wrong person was identified.