Архитектура правил блокировки: как не превратить модерацию в свалку исключений

Архитектура правил блокировки: как не превратить модерацию в свалку исключений

Правило блокировки должно делать одну вещь: быстро отделять нарушение от шума. Если в схеме есть двусмысленность, оператор начинает гадать, а система — ошибаться. Результат предсказуем: лишние баны, лишние апелляции и очень занятые люди, которые могли бы не заниматься ерундой.

Держите базовую структуру:
— триггер: какое действие считается нарушением;
— контекст: что допускается как исключение;
— порог: когда срабатывает блокировка, а когда предупреждение;
— срок: временная мера или перманентный отказ в доступе;
— проверка: кто и как подтверждает решение.

Не смешивайте в одном правиле поведение, последствия и апелляцию. Это три разных слоя. Поведение описывает факт. Последствие фиксирует реакцию системы. Апелляция определяет, есть ли смысл пересматривать инцидент. Когда всё свалено в одну строку, у вас не политика, а текст для взаимного недопонимания.

Хорошее правило читается без толкования. Плохое оставляет поле для эмоций, а эмоции в блокировках обычно кончаются ручным разбором и одинаково бессмысленными вопросами: «за что?» и «почему меня?» Если ответ требует длинной переписки, правило написано плохо.

Сначала стройте логику, потом формулировки. Система зафиксировала нарушение. Дискуссия закрыта.