Anticheat Config Change Log Template

Log every change with its reason and rollback step

Keep one change log entry for every anticheat setting you change, whether the change came from a staff request, an alert review, or a plugin update. Each entry records the reason, the evidence, the approver, the exact setting, and how to undo it. A log that says only tuned reach cannot answer an appeal or help the next admin.

Required fields for each entry

Every field below is required. If a field does not apply, write not applicable and the reason. Leaving it blank looks like a missing step.

Copy the template

Paste this block into a shared document or a text file in your config repository. Replace each placeholder and remove any field you do not use. Keep Reason, Approver, and Rollback, because an appeal or an incident review needs all three.

ID:          <yyyy-mm-dd>-<nn>
Setting:     <file>: <key path>
Change:      <old value> -> <new value>
Reason:      <one sentence describing the alert pattern or problem>
Evidence:    <sample file or channel link>, labels: real <n>, unclear <n>, false <n>
Approver:    <name>
Applied by:  <name>, <timestamp>, reload method: <method>
Rollback:    restore <old value> in <file>, then reload with the same method
Review date: <yyyy-mm-dd>
Outcome:     <kept | reverted | extended>, <reason>

Apply the working rules

The template only works if the habits around it are consistent. These rules keep entries comparable across staff members and over time.

• Write the entry before the change, then fill in the applied fields after it goes live.
• Use one entry per setting. A single entry for three settings hides which one helped or hurt.
• Never edit an old entry to match a newer decision. Add a new entry that supersedes it and link to the old ID.
• Attach the approver's name or ticket. A change without an approver is a finding to raise, not a log entry.
• Keep the log in the same repository as the config, so each entry can point to a commit.

Review open entries on schedule

Check open entries on each review date. An entry with no outcome after its review date is a process failure, not a neutral state. Give one person the job of chasing open entries each week, and close each entry with an outcome before the same check changes again.

Worked example: one entry from start to finish

A staff member proposes raising the tolerance on a movement check after a wave of boat-related false alerts. The entry is created before the change, with the ID, setting, old value, reason, evidence path, and approver filled in. After the approved change goes live, the applied-by line gets the time and reload method. The review date is set three days out. On that date, the outcome line records kept, along with the labeled counts from the new window. That single entry is what an appeal needs for the period.

Common mistakes with change logs

A log fails quietly. Entries look complete until someone needs one during an appeal, so check for these habits during each review.

• Filling in the outcome at change time. An outcome written before the window closes is an expectation, not a result.
• Using vague reasons such as tuning. A reason should name the alert pattern that prompted the change.
• Writing the rollback as see previous version. A rollback must name the file, the key, and the old value.

What the log does not do

The log records decisions and the evidence stated for them. It does not make a decision correct, and it does not replace the alert data. If an entry cites a sample you no longer have, write that gap into the evidence field instead of leaving it blank.