Good moderation leaves a way back.
A small design principle behind Sentinel-VC: think about recovery before adding another restriction.
I keep coming back to one question while thinking about moderation tools: what happens after the action?
It is easy to focus on the interesting moment. A burst of events arrives. A threshold is crossed. The system decides to restrict something.
But the quieter part deserves just as much attention.
Remember what you changed
If a tool changes permissions, it needs enough context to recover carefully. That means respecting existing restrictions and the limits of its own authority. Giving someone more access than they had before is not recovery.
In Sentinel-VC, permission-aware recovery and temporary restrictions are part of that conversation. I see them as design responsibilities, not a finishing touch.
Leave room for uncertainty
A busy moment is not automatically an attack. A sudden wave of legitimate people can resemble a suspicious burst. A rule that looks neat in isolation can still make a bad decision in context.
That is why I like the idea of evidence that decays, bounded actions, and clear expiry. None of these makes a system infallible. They make it easier to reason about the consequences of being wrong.
A useful safeguard should have an understandable ending.
Make the next step obvious
For an administrator, the important questions are quite ordinary: what changed, why did it change, and what can I do now?
I want the software I build to answer those questions without making someone decode the implementation first. There is still work to do. But this is a direction worth keeping.

