FAIRNESS & ACCOUNTABILITY
Appeals & Expiration System
VIRCON provides a structured appeals workflow for users to contest moderation decisions, plus an automatic expiration system to ensure temporary punishments don't become permanent. Together, these systems maintain fairness and prevent over-punishment.
Appeal Commands
Commands for submitting and managing user appeals.
- ,appeal submit <punishment_id> <reason>
- ,appeal view <appeal_id>
- ,appeal list [status]
- ,appeal review <appeal_id> <approve|deny> <notes>
Expiration Commands
Commands for managing automatic punishment expiration.
- ,expire set <punishment_id> <duration>
- ,expire check <punishment_id>
- ,expire list [upcoming|expired]
- ,expire mark <punishment_id> <expired>
Appeal Statuses
Possible states in the appeal review process.
Expiration Types
Default expiration periods for different punishment types.
| Punishment Type | Default Expiry | Auto-Remove |
|---|---|---|
| Warning | 30 days | No |
| Temporary Ban | Set duration | Yes |
| Kick | No expiry | No |
| Strike | 90 days | No |
Appeal Workflow
Step-by-step process for submitting and reviewing appeals.
- 1. User submits appeal via ,appeal submit with punishment ID and reason.
- 2. Appeal enters 'pending' status and notifies staff in appeal review channel.
- 3. Staff member reviews the appeal with ,appeal review.
- 4. Reviewer can approve (lifting punishment) or deny (keeping it in place).
- 5. User receives automated DM with decision and reviewer notes.
- 6. Appeal is logged to audit trail with full decision context.
Expiration Workflow
Automated process for expiring temporary punishments.
- 1. Staff sets expiration with ,expire set when issuing punishment.
- 2. System tracks expiry timestamp in punishment_expirations table.
- 3. Daily cron job checks for expired punishments at 00:00 UTC.
- 4. Expired warnings and strikes are marked as inactive (not deleted).
- 5. Expired temporary bans trigger automatic unban via VRChat API.
- 6. Expiration event logged to mod-log channel with automated context.
Appeal Database Schema
Database fields for tracking appeal submissions and reviews.
| Field | Description |
|---|---|
| appeal_id | Auto-incremented unique identifier. |
| punishment_id | Reference to original moderation action. |
| submitter_discord_id | User who submitted the appeal. |
| submitter_vrc_id | VRChat account of the appellant. |
| reason | User-provided justification for appeal. |
| status | pending, under_review, approved, denied. |
| reviewer_discord_id | Staff member who reviewed the appeal. |
| decision | approve or deny. |
| reviewer_notes | Staff explanation for decision. |
| submitted_at | Timestamp of appeal submission. |
| reviewed_at | Timestamp of staff decision. |
Expiration Database Schema
Database fields for tracking punishment expiration timers.
| Field | Description |
|---|---|
| expiration_id | Unique expiration record ID. |
| punishment_id | Link to moderation log entry. |
| punishment_type | ban, warn, strike, kick. |
| expires_at | ISO timestamp for automatic expiration. |
| expired | Boolean: has expiration occurred. |
| auto_removed | Boolean: was action auto-lifted. |
| removed_at | Timestamp when removal occurred. |
System Integration
How appeals and expiration systems integrate with other features.
- Appeals integrate with incident reports - linked via punishment_id.
- Expired punishments still appear in search and modhistory (marked as expired).
- Appeal approvals can auto-close linked incidents if configured.
- Expiration events are logged to audit trail for accountability.
- Staff can manually override expiration timers before they trigger.
Best Practices
Guidelines for effective appeal and expiration management.
- Set realistic expiration timers - 30 days for warnings, 90 for strikes.
- Require staff notes when denying appeals for transparency.
- Review pending appeals within 48 hours to maintain user trust.
- Use expiration list to audit upcoming auto-removals weekly.
- Link expiration to severity - minor infractions expire faster.