Staff Handbook
Part I. Foundations
1. Purpose and status
1.1. Purpose
This handbook defines the structure, authority, duties, standards, and internal procedures of the Underspire staff team.
It applies to all staff members, regardless of rank or branch.
The Staff Handbook works together with the Underspire Code of Conduct. Staff members remain subject to the same player conduct rules as every other member of the community. Staff members also have additional duties because they may have access to private information, game systems, administrative tools, development systems, NPCs, and decision-making authority.
1.2. Public status
This handbook is public.
Players should be able to understand how the staff team is organized, what authority different staff members hold, how major decisions are reviewed, and what standards govern the use of staff power.
Some staff material must remain private. Private material may include passwords, security procedures, exploit details, infrastructure information, unreleased content, active plot information, moderation records, private reports, and information that must remain hidden for IC reasons.
Private staff material must not create a secret player conduct rule, a secret punishment, or a form of staff authority that conflicts with this handbook or the Code of Conduct.
1.3. Relationship to the Code of Conduct
The Code of Conduct defines the standards that govern participation in Underspire.
This handbook defines how staff exercise authority under those standards.
The Code of Conduct should tell a player what conduct is required or prohibited. This handbook should tell staff how to administer the game, how to use staff tools, how to review reports, how to make decisions, and how to remain accountable for those decisions.
When a staff procedure conflicts with the published Code of Conduct, the published Code of Conduct controls player conduct.
When a private staff procedure conflicts with this handbook, this handbook controls staff conduct unless an urgent security or legal issue requires temporary action. Any long-term change must then be added to the handbook or another published policy.
1.4. Terms used in this handbook
- The word must states a requirement.
- The words must not state a prohibition.
- The word may states an action that staff are permitted to take.
- The word should states the normal practice when there is no specific reason to use another approach.
- A formal action is an official staff action that affects a player’s conduct record, permissions, access, or participation.
- A staff direction is an official instruction that requires compliance. A personal opinion, suggestion, or informal comment from a staff member is not automatically a staff direction.
- A major staff action includes a substantial suspension, permanent ban, removal from staff, major permission restriction, or another action with a substantial effect on access to Underspire.
- A temporary measure is an interim action used before a final finding or while a problem is being reviewed.
2. Staff philosophy
2.1. What staff are for
Underspire is a roleplaying game before it is a PvP game.
The game contains PvP, PvE, politics, crime, social conflict, permanent consequences, economic systems, and mechanics that players can master. These parts of the game matter. They exist to create roleplay rather than replace it. The staff team maintains the conditions in which that roleplay can happen.
Staff create and maintain the world, operate the systems that support it, control the parts of the setting that require a GM, and make the world respond to player action. Players then turn that material into a living story, thus players are co-authors.
A player character is not a prop in a staff story. A faction is not a tool that staff use to force players toward a planned ending. A plot is not successful because the players found the solution that the GM expected. The game is an emergent system. Staff can introduce people, plots, resources, secrets, dangers, opportunities, and events. Staff cannot plan every result.
When players create an unexpected alliance, destroy an expected plot route, build a new institution, start a feud, change a neighborhood, embarrass an important NPC, create a movement, or turn a minor event into a major political problem, staff must treat that as play rather than interference.
Our task is to preserve the frame of the setting and let consequences develop inside it.
The world can resist a character; staff must not resist a player. Deshret can be unfair in-character; administration must be fair out-of-character.
2.2. Players as co-authors
Staff do not own the narrative. The world contains staff-created factions, NPCs, systems, history, and setting limits. Players still create much of the actual history through play.
Staff should treat player-created relationships, institutions, rumors, businesses, rivalries, movements, and social changes as part of the world when play gives them significance. Staff-created content is not automatically more important than player-created content.
A GM may establish the motives of an NPC or faction. The GM must still allow player action to affect what happens next. Staff should not protect a preferred narrative because it was planned in advance.
2.3. Player agency and emergent play
Player agency means that player choices can affect the course of play. Player agency does not guarantee success.
A character can fail. A faction can retaliate. An NPC can refuse a request. A plan can collapse. A player character can lose status, money, freedom, health, relationships, or life. These consequences do not remove agency when they follow from the setting, game rules, and events of play.
Agency is damaged when an outcome was fixed in advance and staff refuse to allow valid player action to matter - staff should prepare situations rather than fixed endings.
A plot may include goals, resources, conflicts, secrets, and likely reactions. It should not depend on players following one hidden sequence of required decisions. When players find another valid solution, staff should allow it. When players make the situation worse, staff should allow that result as well.
2.4. Consequences, failure, and narrative meaning
Staff do not exist to protect player characters from failure. Failure, loss, humiliation, betrayal, imprisonment, injury, and death can create strong roleplay.
Staff must make sure that these consequences come from the game, player choices, established setting forces, or valid adjudication. They must not come from staff hostility, favoritism, OOC punishment, or a desire to protect a predetermined story.
2.5. Community stewardship
Staff are responsible for more than code, rooms, and rules. Staff also help maintain the culture of the community.
A veteran player does not have greater OOC worth than a new player. A powerful character does not give the player greater OOC authority. Mechanical knowledge, donor status, staff friendships, or years of participation must not become an informal social rank that staff reinforce.
Text communication is imperfect. Players will sometimes understand rooms, lore, customs, systems, and events differently. Staff must expect this.
When a player’s interpretation is incorrect about a fact that matters, staff should clarify the fact. Staff must not ridicule the player for failing to reproduce the interpretation that staff expected. This is especially important with new players.
3. Administrative principles
3.1. Transparency
Underspire uses transparency by default. Staff must not use secret conduct rules, shadow-bans, hidden punishments, or undeclared restrictions. Staff must not quietly reduce a player’s plot opportunities, IC treatment, access, or success as punishment for an OOC issue.
If staff have a conduct concern, staff must address the player directly. If staff take a formal action, staff must identify it as a formal action. If staff create or change a player conduct policy, the policy must be published.
Major game or balance changes should also be explained when the explanation can be public. Staff do not need to reveal hidden numbers, undiscovered mechanics, or IC secrets. They should still explain the problem that the change is intended to address when that information can be shared.
Transparency does not require staff to publish private reports, private messages, protected identities, or security information. Staff must separate information that requires protection from information that can be disclosed.
3.2. Direct administration
Staff must communicate directly.
Staff must not use rumors, indirect warnings, unfavorable plots, coded disadvantages, social pressure, NPC behavior, or unexplained restrictions to correct a player’s OOC conduct. When a player conduct issue can be addressed directly, staff should explain the concern, identify the applicable rule when one applies, and state what must change.
Not every problem requires formal moderation. Some problems come from misunderstanding, poor communication, different expectations, or OOC bleed. Staff may help resolve these problems without creating a formal conduct case.
Direct communication does not require endless debate. Staff may make a final ruling. Once a ruling is final, staff must clearly state what the ruling requires and what review or appeal options remain.
3.3. Fairness and consistency
Staff decisions must be based on conduct, context, available information, and the published rules. A staff decision must not be based on popularity, personal dislike, friendship, donor status, character importance, faction importance, staff convenience, or a person’s reputation in another community.
Similar cases should receive similar treatment when the important facts are similar. Important differences may justify different results. These differences can include severity, effect, intent, repetition, prior conduct in Underspire, retaliation, concealment, cooperation, and risk to other people. When a result differs substantially from a similar case, the internal record should explain why.
3.4. Minimum intervention
Staff should use the least intrusive action that can solve the problem.
This principle does not encourage weak action when serious action is needed. A minor misunderstanding may need clarification. A repeated problem may need a formal warning. A serious safety issue may require immediate restriction or removal. Staff should not use a stronger tool only because it is available, but should apply it relevant to the context of the situation.
3.5. Separation of IC and OOC authority
IC authority and OOC authority must remain separate. A GM may control an NPC, faction, or setting response. That authority must not become a hidden way to punish a player.
A staff member may issue a moderation direction. That direction must not be disguised as an IC event. Staff must not use plots, NPCs, faction responses, code, mechanics, or world access to solve personal OOC disagreements.
Staff must not use OOC moderation to change a valid IC outcome unless the IC outcome itself was created through misconduct or staff error.
Part II. Staff Organization
4. Staff structure
4.1. Rank and branch
Every staff member has a rank and one or more branches. Rank defines the general level of authority and responsibility. Branch defines the type of work that the staff member performs.
The three staff branches are the Chorus, the Forge, and the Logos.
A staff member may belong to more than one branch when their duties require it. Cross-branch authority must be assigned.
A Magister of the Forge does not automatically receive senior GM authority, a Magister of the Chorus does not automatically receive production infrastructure access, and so on.
4.2. Chain of authority
Underspire uses four staff ranks.
| Rank | Function | General authority |
|---|---|---|
| Neophyte | Support or trial staff | Limited authority under supervision |
| Adept | Full staff member | Normal independent authority within an assigned branch |
| Magister | Senior staff | Supervision, senior review, and approval of major actions |
| Archon | Head Staff | Overall administration, staff appointments, policy, and final executive authority |
Rank represents trust, responsibility, and the level of authority that the staff member is expected to use correctly. A matter should normally be handled at the lowest rank that has the required authority.
Neophytes should escalate matters that exceed their training. Adepts should escalate serious, unusual, or high-impact matters. Magisters should handle senior review, supervision, and major decisions. Archons should handle matters that require Head Staff authority, policy decisions, or final executive resolution.
A staff member may bypass the normal chain when the next person in the chain has a conflict of interest or is the subject of the concern.
4.3. Cross-branch work
The branches are different areas of responsibility - not competing departments.
A Chorus request does not automatically override a Forge or Logos concern.
A Forge or Logos concern does not automatically override a player-facing or narrative requirement.
When work affects more than one branch, the relevant branches must coordinate before a high-impact change goes live. If staff cannot resolve a cross-branch disagreement, the matter must move to a Magister with the required authority or to an Archon.
5. Staff branches
5.1. The Chorus
The Chorus is the game master branch of Underspire. The Chorus manages player support, plots, NPCs, events, IC adjudication, ongoing world activity, and most player-facing game administration - it is the active voice of the world.
A Chorus GM may play NPCs, create events, respond to player plans, adjudicate situations that require staff input, and introduce new pressures or opportunities into the setting. A Chorus GM must not treat this authority as ownership of the story.
A GM may decide what an NPC knows, wants, or does. A GM may decide how a faction responds to an event. A GM may create a crisis or determine how the wider setting reacts when a response is required. Players must still be able to affect what happens next.
A GM must not protect a planned conclusion from player action. If the players find another valid solution, staff must allow that solution to exist. If players create a consequence that staff did not expect, staff should determine how the world responds rather than how the original plan can be restored.
Continuity and setting integrity remain important. Staff do not have to accept an outcome that contradicts established facts, breaks the game rules, or exceeds what the setting can support. The Chorus also handles most player conduct and moderation work. Formal moderation authority depends on rank and assignment.
5.2. The Forge
The Forge is the builder branch of Underspire. The Forge creates and maintains rooms, areas, objects, environmental content, and the on-grid implementation of Deshret.
Forge staff build for play rather than only for display. A room exists so that something can happen there. An area exists so that players can inhabit it, explore it, work in it, fight over it, hide in it, or give it meaning. Forge staff must consider the effect of live changes on active play.
A builder must check for active plots, player property, stored objects, faction activity, exits, systems, and other live dependencies before making a major change. The Forge and Chorus must coordinate when a world change affects active roleplay.
A Forge member does not receive moderation authority only because they are staff. A builder who observes a player conduct issue must refer it to staff with the correct moderation authority.
5.3. The Logos
The Logos is the development branch of Underspire. The Logos develops and maintains code, systems, mechanics, databases, integrations, infrastructure, deployment processes, and other technical parts of the game.
Technical authority carries a high level of trust because Logos staff can have access to information and systems that players cannot see.
A developer must use that access only for staff work.
A developer must not inspect private player information because of curiosity.
A developer must not use hidden mechanics, logs, database information, unreleased features, or technical knowledge to benefit their player character.
A developer must not change a live mechanic to influence an IC dispute.
The Logos must work with the Chorus when a mechanic affects roleplay, game balance, or IC adjudication. The Logos must work with the Forge when code affects rooms, areas, objects, or environmental systems.
The Logos is responsible for technical integrity, and it does not have sole authority over game design. A system can work exactly as coded and still create poor gameplay. Technical implementation belongs to the Logos. The design decision belongs to the appropriate staff group.
6. Staff ranks
6.1. Neophyte
A Neophyte is a support or trial staff member. The Neophyte rank is a training rank. A Neophyte receives enough access to learn the role but does not receive unrestricted staff authority.
Every Neophyte must have a supervisor. The supervisor should normally be an Adept, Magister, or Archon from the same branch. A Neophyte must ask for help when a matter exceeds their training, authority, or confidence. Escalation is correct staff conduct.
A Chorus Neophyte may answer routine support questions, observe approved staff procedures, assist with events, control assigned NPCs, and handle simple IC issues.
A supervisor may grant additional authority for a specific task.
A Chorus Neophyte must not make the final decision in a serious moderation case, issue a permanent ban, or create major policy.
A Forge Neophyte may create and edit content in assigned development areas. Major live changes require review before deployment.
A Logos Neophyte should work in development or test systems when possible. High-impact production changes require senior technical review.
A Neophyte may take a temporary action when immediate action is needed to stop harm, stop a scene, or protect the game service. The Neophyte must report the action to a supervisor. A staff member with the correct authority must review it.
6.2. Adept
An Adept is a full staff member. An Adept may perform normal work within their branch without direct supervision.
A Chorus Adept may run normal plots, NPCs, events, support requests, and IC adjudication. When moderation is part of the Adept’s assigned role, the Adept may handle routine conduct matters, give formal warnings, and issue targeted directions or restrictions within their authority.
An Adept may take an immediate temporary protective action during a serious incident. A major final enforcement action requires senior review.
A Forge Adept may maintain normal live content within their assignment. Major structural changes, new major areas, or changes that can affect many players require senior approval.
A Logos Adept may perform normal technical work independently. High-impact changes to infrastructure, security, player data, core mechanics, or destructive production operations require senior review.
An Adept may supervise a Neophyte when assigned to do so.
6.3. Magister
A Magister is a senior staff member. A Magister supervises staff, reviews important decisions, and handles work that requires senior authority.
A Chorus Magister may lead major plots, complex IC adjudication, formal moderation reviews, and major enforcement decisions.
A Forge Magister may approve major area work, major structural changes, and other high-impact changes to the live world.
A Logos Magister may approve high-impact deployments, migrations, permission changes, and other operations that can create substantial service or data risk.
A Magister may review, correct, or reverse an action taken by a Neophyte or Adept when the action is incorrect, exceeds authority, or creates a problem that requires correction.
Senior authority should not replace normal delegation. A Magister should not take over routine work only because they hold a higher rank.
6.4. Archon
An Archon is Head Staff. More than one Archon may serve at the same time. Archons are responsible for the operation of the staff team as a whole. They appoint staff, assign ranks and branches, grant or remove staff permissions, approve staff structure, and hold final executive authority when a matter cannot be resolved at a lower level.
An Archon remains subject to the Code of Conduct and this handbook.
An Archon must not prevent a complaint about an Archon from being recorded or reviewed.
An Archon must not act as the only reviewer of their own conduct.
When uninvolved senior staff are available, a complaint about an Archon must be reviewed by them.
An Archon may take emergency action when immediate action is required. The action must still be recorded and may be reviewed later.
An Archon who wants to change policy must change the policy through the same policy process that applies to the rest of the staff team.
7. Permissions and access
7.1. Minimum access
Staff permissions follow the principle of minimum access. A staff member must receive the commands, systems, records, and tools needed for their duties.
Technical access does not equal authority. A command may exist on a staff account while use of that command remains outside the staff member’s assigned role.
Staff must not use a command, database, log, private channel, player record, building tool, NPC control function, or technical system without a staff purpose.
7.2. Branch permissions
The game should use separate permission groups for rank and branch. This allows staff access to match actual duties.
A Forge Adept, for example, can receive normal editing permissions without receiving infrastructure access or senior moderation commands.
A Chorus Adept can receive normal GM tools without receiving unrestricted development access.
A Logos Adept can receive normal development tools without receiving unrestricted NPC or moderation authority.
Cross-branch permissions must be assigned when they are needed.
7.3. Rank permissions
The exact command list may change as the codebase develops. The intended access model is:
| Rank | Normal access |
|---|---|
| Neophyte | Support and observation tools required for training. Limited assigned NPC, build, or development access. No unrestricted high-impact commands. |
| Adept | Normal operational tools within the assigned branch. Independent use of routine staff commands. |
| Magister | Senior branch tools, review functions, higher-impact commands, and supervisory access. |
| Archon | Administrative access required for Head Staff duties, including staff permission management. |
Branch-specific permissions should remain granular.
- A Forge Adept may be allowed to edit approved live descriptions without receiving unrestricted room creation or deletion.
- Advanced mapping, large structural changes, and destructive world operations may be limited to Forge Magisters and Archons.
- A Logos Neophyte may receive repository and test access without production access.
- A Logos Adept may receive normal production tools while destructive operations, infrastructure permission changes, and high-risk migrations remain limited to Magisters or Archons.
- A Chorus Neophyte may receive support and assigned NPC controls without unrestricted observation or moderation tools.
- A Chorus Adept may receive normal GM tools while commands that expose broad hidden information or allow high-impact intervention remain limited to Magisters or Archons.
7.4. Invisible staff bodies and observation
Staff tools that allow unrestricted invisibility, broad observation, or access to areas without normal player awareness require additional control. Full invisible staff bodies and unrestricted observer access should normally be limited to Magisters and Archons.
An Archon may grant temporary access to another staff member when a specific technical, training, investigation, or operational need requires it. Staff must not use invisible observation for curiosity, entertainment, or personal interest. Observation must have a staff purpose.
7.5. Account security
The following requirements apply to staff accounts:
- Staff must not share staff accounts or permissions.
- A staff member must not allow another person to use their staff account.
- A staff member must not use another staff member’s account.
- Passwords, authentication credentials, recovery codes, and similar security information must not be shared outside approved technical procedures.
- When a staff member leaves staff or changes role, their permissions must change with the role.
7.6. Logging and audit records
High-impact administrative actions should be logged.
Staff must not delete, alter, or conceal logs in order to hide their own action, another staff member’s action, or a staff mistake.
Technical staff may rotate or remove logs for legitimate operational reasons.
Such maintenance must not be used to destroy records that are relevant to an active review.
Part III. Staff Conduct
8. General staff duties
8.1. Use of authority
Staff authority exists to operate the game, support players, protect the community, maintain the world, and resolve matters that require staff action. A staff member must use authority only for those purposes.
Staff must not use staff authority to win a personal argument, protect a friend, punish a critic, gain an IC advantage, or influence a private dispute. A staff member must not use more authority than the task requires.
8.2. Professional conduct
Staff must communicate in a clear and calm manner. A staff member may disagree with a player, reject a request, enforce a rule, or end an argument.
Staff must not use humiliation, ridicule, provocation, or public embarrassment as administrative tools. A staff member must not threaten formal action during a personal argument. Staff should separate correction from punishment.
If a simple clarification can solve the problem, staff do not need to make the matter disciplinary.
8.3. Communication with players
Staff should explain official decisions in language that the affected player can understand. When staff identify a rule violation, staff should identify the rule that applies. When staff require a player to change conduct, staff should state what must change.
Staff do not need to debate a final ruling without limit. A player should still be able to understand what the final ruling requires and what appeal or review process is available.
8.4. Official directions and rulings
A staff member’s personal opinion is not automatically an official ruling. When staff require compliance, the staff member must state that they are giving an official staff direction. An official ruling should state what the player must do or stop doing.
A player may ask for clarification. Staff must not intentionally blur the difference between informal advice and mandatory direction.
8.5. Criticism and disagreement
Players may disagree with staff, criticize staff policy and official decisions.
Staff must not treat criticism as misconduct only because it is uncomfortable, negative, or directed at staff. Conduct that independently violates the Code of Conduct may still be moderated. This includes harassment, threats, retaliation, disclosure of protected information, or deliberate disruption.