AI support
With AI support enabled, GatorSys answers support tickets automatically. It draws on a knowledge base you control, answers what it's confident about, and escalates the rest — and it learns from feedback so it gets better at your server over time.
How an answer looks
Every AI reply is rendered inside a bordered container with the answer, a short disclaimer note, and two buttons — Resolved and Unresolved.
Resolved
Tells the AI the answer landed. It reinforces that answer so it's reused with more confidence.
Unresolved
Records a knowledge gap and routes the ticket to a human right away.
The knowledge base
The AI only makes server-specific claims from knowledge you've given it. From Dashboard → Tickets → AI knowledge base you can add, edit, and delete items. Add the things people ask about constantly — your rules, links, and processes — and the AI stops guessing.
Knowledge gaps
When the AI can't answer from saved knowledge, it records a knowledge gap instead of inventing an answer. From Dashboard → Tickets → AI knowledge gaps you can answer a gap (which adds it to the knowledge base) or dismiss it.
This is the training loop: members ask, gaps surface, you answer once, and the AI knows it forever.
The AI won't fabricate a rule, channel, role, or process it wasn't told about. If it doesn't know, it logs a gap and escalates instead of guessing.
Actions: what the AI can do, not just answer
GatorAI can carry out a small set of actions when somebody asks for one in conversation — "who's on shift right now", "look up that player", "log a warning on them for RDM". You do not use a special command for this; you say it, and if it maps to an action, the action runs.
Permission is checked against you, not against the AI
The AI has no authority of its own. Every action resolves the member who asked and checks what
that member could do by hand, against the same Permissions config the slash commands read. A
moderator without management permission who asks the AI to file a ban gets refused for exactly the
reason /punish would have refused them.
The model chooses which action and what arguments. It does not choose whether you may take it — that decision is made in code, against your roles, after the model has answered. A model cannot be prompted out of a check it never evaluates.
The actions
| Action | Needs | Module |
|---|---|---|
| Live ER:LC server status | Staff | PRC |
| Who is on shift | Staff | Shifts |
| Who is on duty for a department | Staff | Department |
| Look up a Roblox player and their record here | Staff | — |
| File a punishment record | Staff (management for bans and BOLOs) | Punishments |
| Summarise open tickets | Staff | Tickets |
| A member's full record | Management | — |
| A department's roster | Management | Department |
An action belonging to a module you have switched off is unavailable. Turning a module off also turns off the AI's ability to act on it — nobody should have to disable a feature twice.
What it will not do
The list is deliberately small and skewed toward the reversible. Filing a punishment records the case; it does not kick or ban anybody by itself, and acting on the case stays a deliberate command. Nothing that removes a member from the server is exposed at all — the failure mode of a misunderstood sentence should never be somebody getting kicked.
Everything is written down
Every attempt, allowed or refused, is recorded with who asked, what was asked for, the arguments, and the outcome. An action taken through a chat message is as auditable as one taken through a command, and a punishment filed this way is marked as such so a reviewer can tell the two apart.