Documentation Standards
Chapter 20 — How to write ban reasons, incident reports, and where documentation should live.
Clear documentation is what turns individual staff judgement into a reliable team record. This chapter consolidates the documentation habits introduced throughout this handbook into one standard.
Writing a Good Ban Reason / Report
- State what happened, factually, without editorializing ("used a modified client" not "was being a huge cheater").
- Include when and where it happened.
- Link the evidence directly (screenshot, recording, LibertyBans
/historyoutput). - Note who else was involved in the decision (a second Moderator/Admin, if applicable).
Incident Reports
For larger situations — raids, major disputes, serious rule violations — write a short incident report for Admins covering: what happened, the timeline, who was involved, what actions were taken, and any recommendations for preventing it in the future.
Where Documentation Lives
All logs, evidence, and reports should go into the shared staff systems (logging channels, evidence drive) — never only in your own private notes or DMs, where the rest of the team can't access them if needed.
GOLDEN RULE
Write every report as if someone with zero context will read it in six months and need to fully understand what happened and why, without asking you first.
Quick Review — Q&A
Q: What tone should a ban reason use?
A: Factual and neutral, describing what happened without editorializing or exaggerating.
Q: What should a larger incident report include?
A: What happened, the timeline, who was involved, actions taken, and recommendations to prevent recurrence.
Q: Where should documentation and evidence be stored?
A: Shared staff systems accessible to the team, not just private personal notes or DMs.