Furries PH Docs
Dashboard
Report system docs

Lifecycles

Record Maintenance Lifecycle

How to maintain, correct, reopen, archive, and verify report-system records over time.

AudiencePartner admins, FPH administrators, Support leads
Dashboard surfaces/reports, /reports/watchlists, /reports/bans, /reports/profiles
Records touchedIncident reports, Watchlist entries, Appeals, Person profiles, Audit entries

Follow The Record Over Time

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Record Maintenance Lifecycle narrows that work to how to maintain, correct, reopen, archive, and verify report-system records over time. 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 Partner admins, FPH administrators, and Support leads. 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/watchlists, /reports/bans, and /reports/profiles.
  • Records or contracts involved: Incident reports, Watchlist entries, Appeals, Person profiles, and Audit entries.
  • 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 Record Maintenance Lifecycle.
  2. Read what must be true before the next state: Use /reports, /reports/watchlists, /reports/bans, and /reports/profiles 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, Watchlist entries, Appeals, Person profiles, and Audit entries 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. List records due for review by status, age, reminder, owner, or retention policy. This anchors the work to the correct scope before any record changes.
  2. Step 2 - Read the existing facts before acting. Open each record and check whether facts, links, evidence notes, restrictions, and appeal information still match reality. Pause here and confirm the note is factual, fair, and reviewable.
  3. Step 3 - Make the smallest factual update. Correct inaccurate fields with a note; do not delete uncomfortable history to make a record look cleaner. 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. Archive, close, or keep active based on policy and current risk. The next action should still protect privacy, evidence, and due process.
  5. Step 5 - Verify the saved record and history. Confirm list views, profiles, and linked records still agree after maintenance. A later reviewer should be able to understand this step from the saved record.
  6. Step 6 - Hand off the next responsibility. Record unresolved questions for the next reviewer. This leaves a handoff trail another operator can understand.

Why maintenance exists

Records age. People change. Events end. Evidence links break. A fair report system needs periodic review so old records do not become confusing, unfair, or useless.

Maintenance actions

ActionUse whenWhat to record
CorrectA field is wrong or unclear.What changed and why.
ReopenNew evidence or appeal changes the case.Reason for reopening.
Archive or closeNo further action is planned.Closure reason.
ExpireTemporary watchlist/ban period ends.Expiry confirmation.
Link/unlink profileIdentity connection changes.Evidence for link or reason for removal.
Review network scopeShared record may no longer be needed.Decision and reviewer.

Yearly maintenance pass

At least once a year, partner admins should review:

  • Open new and triage reports.
  • Long-running investigating reports.
  • Active watchlist entries.
  • Temporary bans near or past expiry.
  • Network-scope entries from the partner.
  • Person profiles with weak or old links.
  • Appeal decisions that required follow-up.

Correction rules

When correcting:

  • Keep the original meaning visible through revision history.
  • Explain why the correction was made.
  • Do not remove evidence context unless it is unsafe to keep.
  • If identity was wrong, mark the correction clearly.
  • If action was wrong, review appeal and notification needs.

All docs