CodeshareModeration that leaves a record
An automated action nobody can explain afterwards is worse than no action. Why every decision is logged with its reason, and what that changes for a moderation team.
Automated moderation has a failure mode that is not false positives. It is unexplainable actions: a member was removed, nobody knows why, and the thing that did it kept no memory of its own reasoning.
The argument you cannot win
Someone appeals. Your moderators look and see that the bot timed them out. They cannot see which rule fired, what the message was, or what threshold it crossed. There is nothing to review, so the team either reverses an action they do not understand or defends one they cannot explain.
Both outcomes damage them. The first makes the automation pointless; the second makes the moderators look arbitrary to their own community.
What gets recorded
Sylon writes down the rule that matched, the content that matched it, the threshold in force at the time, and the action taken. Message, role, channel and moderation events go to whichever channels a server nominates, kept apart so the moderation record is not buried under join notifications.
That separation matters more than it sounds. A single firehose channel is technically complete and practically unreadable, and an unread log is the same as no log.
Thresholds belong to the server
A fifty-member server and a fifty-thousand-member server do not want the same spam sensitivity. What reads as a flood in one is an ordinary conversation in the other.
So sensitivity is set per server — and the value in force is recorded alongside the action. A log entry from three months ago can still be understood even after the setting has been changed twice since.
An automated decision is only as good as your ability to explain it afterwards.