Report Writing Best Practices

Apply This Operating Standard

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Report Writing Best Practices narrows that work to how to write report text that is factual, neutral, readable, and useful for later review. Because this is a best practices 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 Good Operation Looks Like

This page is a judgment aid. Use it before and during sensitive work, especially when a action that looks valid on screen could still confuse attendees, staff, reviewers, or support leads. The intended readers are Report writers and Reviewers. 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 and /reports/manage?id=:incidentId.
• Records or contracts involved: Incident reports 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.

Use The Standard Before You Act

1. Identify the policy or risk behind the task: Begin by naming the Report System situation, the owner, and the exact item involved in Report Writing Best Practices.
2. Compare the planned action with the standard: Use /reports/new 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. Adjust the action before saving if the standard is not met: Keep Incident reports and Revisions in view so the work stays tied to the records or contracts it can affect.
4. Record any exception and who approved it: 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.

Signs The Standard Was Met

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. Open the related workflow page and confirm you are working on the correct record or event. This anchors the work to the correct scope before any record changes.
2. Step 2 - Confirm scope and records. Use this best-practice page as a checklist before making changes in /reports/new, /reports/manage?id=:incidentId. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Do the operating action. Check policy, permissions, affected people, money, privacy, and communication impact before saving. This keeps the report useful to the next reviewer instead of only to the person writing it.
4. Step 4 - Verify the result. Make the smallest accurate change, then verify Incident reports, Revisions show the intended result. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Hand off remaining work. Write down unresolved questions and escalate anything that could affect safety, fairness, money, or trust. This leaves a handoff trail another operator can understand.

Write like a careful witness

Good report writing is calm, plain, and specific. It does not try to sound dramatic. It helps someone who was not there understand what happened and why staff acted.

Facts, claims, and opinions

Separate these three things:

Type	Example	How to write it
Fact	A message was sent at 9:14 PM.	”Screenshot shows a message timestamped 9:14 PM.”
Claim	A reporter says the subject followed them.	”Reporter stated that the subject followed them after being asked to stop.”
Opinion	Staff think the behavior is predatory.	”Staff concern: behavior may show a pattern of ignoring boundaries.”

Use simple words

Prefer:

• “The subject sent three messages after being told to stop.”
• “The reporter provided two screenshots.”
• “Staff could not verify the second account.”

Avoid:

• “Subject is obviously dangerous.”
• “Everyone knows what they are like.”
• “This was creepy.”

Write uncertainty clearly

Use phrases like:

• “Unconfirmed.”
• “Reporter believes…”
• “Staff have not verified…”
• “The screenshot appears to show…”
• “This may be the same account, but identity is not confirmed.”

Do not over-share

Do not include private details unless they help understand the safety decision. If private details are necessary, explain why they are relevant.

Good final check

Before saving, ask:

1. Question 1. Is this understandable without me explaining it in person? Write the answer before choosing the next action.
2. Question 2. Did I separate facts from claims? Write the answer before choosing the next action.
3. Question 3. Did I avoid insults and loaded words? Write the answer before choosing the next action.
4. Question 4. Did I describe evidence clearly? Write the answer before choosing the next action.
5. Question 5. Would an appeal reviewer understand the decision? Write the answer before choosing the next action.