Alliance Operations

An effective MissionChief alliance increases resilience without encouraging members to empty their own networks, hide permanent capability gaps or depend on undocumented rules. This guide treats alliance administration, mutual support and shared operating standards as explicit community policy.

Evidence boundary

Administrative structures, contribution models, dispatch etiquette, mutual-support layers and moderation processes are recommendations. Game-enforced permissions, limits, costs and formulas are stated only when separately reproduced in current evidence. Missing mechanics remain unknown rather than inferred.

Current evidence baseline: 28 July 2026.

Operating principles

1. Local core capacity first — members should retain enough routine Fire, Police and Ambulance response to operate safely.
2. Alliance support as contingency — help absorbs unusual peaks; it should not conceal a permanent local deficit.
3. Explicit requests — responders should know what is required, where, how urgently and when resources can be released.
4. Protected donor reserve — assistance should not empty the donating member’s own network.
5. Specialists coordinated deliberately — command, HART, public order, railway, airfield, marine and other rare resources can become shared single points of failure.
6. Policies documented — contribution, conduct, event and escalation expectations should not exist only in private memory.
7. Permissions separated — financial, moderation, recruitment and operational authority should be granted intentionally.
8. Evidence before enforcement — rules about game mechanics should be verifiable; community preferences should be labelled as policy.

Three operating modes

Member

• maintain local core response;
• request support clearly;
• dispatch only what can be spared;
• follow mission and event etiquette;
• report unavailable-resource or conduct problems through the agreed channel.

Dispatcher / Coordinator

• assess the requested capability rather than total vehicle volume;
• protect donor reserve;
• coordinate rare specialists and release them promptly;
• avoid conflicting instructions;
• maintain an operational picture during major incidents.

Administrator

• publish policies and role boundaries;
• maintain recruitment, moderation and contribution processes;
• review shared infrastructure and specialist gaps;
• preserve auditability for important decisions;
• separate operational urgency from disciplinary action.

Evaluating an alliance

Before joining, assess the operating model rather than only member count.

Area	Questions to ask
Activity	Are members active in the same hours and regions as you?
Support culture	Are requests answered reliably without pressuring members to over-dispatch?
Rules	Are conduct, contributions, events and inactivity policies visible?
Leadership	Are roles and escalation routes clear?
Infrastructure	Is shared development planned against actual member geography?
Specialists	Are rare capabilities distributed or concentrated in one member?
Communication	Is there a usable in-game, forum or optional external communication method?
New members	Is onboarding available, or are expectations assumed?
Disputes	Is there a proportionate and reviewable moderation process?
Fit	Does the alliance support your play style without demanding unsafe fleet behaviour?

Warning signs

• contribution or dispatch expectations are unclear until after joining;
• leaders rely on unexplained permissions or undocumented formulas;
• every major incident depends on one person’s specialists;
• members are routinely expected to send their last local units;
• public criticism replaces private correction and evidence review;
• inactive or disruptive behaviour is handled inconsistently;
• external tools are mandatory without privacy or access boundaries.

Member onboarding

A consistent onboarding process reduces avoidable disputes.

Recommended onboarding packet

• alliance purpose and operating style;
• conduct and communication rules;
• dispatch and major-incident etiquette;
• contribution policy and any exceptions;
• event participation expectations;
• role and permission boundaries;
• inactivity and absence process;
• moderation and appeal route;
• optional Discord or external-tool privacy notice;
• links to the account progression and service guides.

First-week checklist

• member has read the rules;
• preferred name and timezone are known where voluntarily shared;
• local service strengths and major gaps are understood;
• contribution expectations are confirmed;
• support-request format is understood;
• optional communication access works;
• no unnecessary administrative permissions were granted.

Roles and separation of duties

Role names vary by alliance. The functional responsibilities below are recommendations.

Function	Responsibility	Safeguard
Member support	Onboarding, questions and routine guidance	Does not require financial or moderation power
Dispatcher	Coordinates support and major incidents	Cannot use urgency to bypass conduct rules
Training / guide lead	Maintains operational references and mentoring	Labels recommendations and evidence boundaries
Recruitment	Reviews applicants and communicates expectations	Uses consistent criteria and records decisions
Finance / infrastructure	Administers agreed funds and shared projects	Publishes policy and significant decisions
Moderator	Handles conduct reports and proportionate action	Separates evidence gathering from personal conflict
Senior administrator	Maintains permissions, continuity and appeals	Uses least privilege and more than one trusted owner where possible

Least-privilege rule

Grant only the permissions required for the function. Review them when roles change, members become inactive or tools are replaced.

Contribution and shared-fund policy

Contribution systems are alliance policy unless a specific game mechanic is independently verified.

Policy choices

Model	Strength	Risk
Voluntary	Flexible and accessible to developing members	Shared projects may progress slowly
Recommended target	Gives direction without automatic punishment	Can become an unofficial mandatory rule if poorly communicated
Tiered expectation	Can reflect account maturity or role	Requires transparent, reviewable criteria
Project-specific drive	Links contributions to a defined outcome	Can create repeated pressure without a project backlog
No central target	Minimises administration	Makes infrastructure planning less predictable

Minimum policy record

Document:

• whether contributions are voluntary or expected;
• what the funds support;
• who can approve expenditure;
• how large projects are prioritised;
• whether exceptions or hardship pauses exist;
• how progress is reported;
• how policy changes are approved.

Do not publish an unsupported claim that a particular percentage, amount or enforcement rule is required by the game.

Shared infrastructure planning

Shared hospitals, custody, schools and other alliance facilities should be placed against member geography and operational demand where the game configuration supports them.

Planning gates

1. Demand — which repeated member problem will the project solve?
2. Geography — which members and mission clusters can use it practically?
3. Specialisation — are departments, classrooms or other options required and verified?
4. Funding — is the policy understood before construction starts?
5. Ownership — who maintains the facility and evidence record?
6. Resilience — does the project reduce a bottleneck or create one new central dependency?
7. Review — what measured result will justify the next shared project?

Project backlog

Maintain a visible queue:

Priority	Project	Evidence of need	Region	Owner	Status	Review condition

Avoid building only where leadership is concentrated if member mission geography indicates another region.

Dispatch etiquette

Standard support request

Use a compact request such as:

Mission / location:
Missing capability:
Quantity or personnel state:
Urgency:
Resources already travelling:
Expected release condition:

This prevents a generic “send everything” response when one specialist or personnel role is the real blocker.

Member dispatch rules

Recommended practice:

• send only the requested capability unless broader support is invited;
• retain local frontline and hard-specialist reserve;
• avoid duplicating units already confirmed as travelling;
• announce rare command, air, towing or access resources;
• release or recall resources promptly when no longer required;
• preserve guaranteed, alternative, conditional and probabilistic semantics;
• do not pressure members to dispatch their last local response.

Donor reserve

Before sending alliance support, check:

• current local missions;
• staffed rather than purchased availability;
• trained-personnel ownership;
• patient, custody or towing work still in progress;
• travel and return time;
• whether another alliance request is using the same specialist;
• the member’s documented local response floor.

Mutual-support layers

Layer 1 — local member capacity

The member handles routine demand and the common response to their generated missions.

Layer 2 — nearby alliance reinforcement

Members with practical travel time reinforce quantity, command or specialist gaps while preserving donor reserve.

Layer 3 — alliance specialist reserve

Rare resources are distributed or registered so several members do not assume the same vehicle is available.

Examples:

• major-incident command;
• HART and mass-casualty support;
• public order and custody;
• airfield/ARFF;
• railway access and EIU;
• maritime vessels and towing systems;
• Mountain/SAR command and aerial search;
• Bomb Disposal land/marine capability;
• HGV Recovery.

Layer 4 — exceptional mobilisation

A large event or major incident receives coordinated support under a named dispatcher or operating channel.

Alliance assistance should become more structured as the incident scale increases—not less.

Capability registry

Maintain a voluntary operational registry without exposing private account information unnecessarily.

Capability	Region / member	Normal availability	Replacement depth	Contact method	Notes

Registry rules

• list capability, not complete account inventory;
• update when resources or personnel change;
• mark conditional or unreliable coverage honestly;
• do not promise a resource that requires the same cohort as another listed capability;
• identify towing, carrier, launch or personnel dependencies;
• treat the registry as planning evidence, not a guaranteed service-level agreement.

Major-incident coordination

Activation

Use a dedicated incident thread, channel or agreed in-game process when:

• several members are responding;
• multiple rare specialists are required;
• patients, prisoners or recovery assets create prolonged work;
• several command groups must be allocated;
• a second regional incident could expose the alliance.

Recommended command structure

Role	Function
Incident coordinator	Maintains the overall requirement and confirms completion state
Service leads	Track Fire, Ambulance/HART, Police, SAR/maritime or other service groups
Resource recorder	Tracks rare resources, quantities and donor ownership
Donor liaison	Protects member reserve and communicates release/repositioning
Patient/custody/recovery lead	Tracks work that continues after scene requirements are met

One person may perform several functions on a small incident. The responsibilities should still be clear.

Incident board

Track:

• verified mission requirements;
• guaranteed resources received;
• independent alternative groups;
• required and available personnel states;
• patients, transports and critical care;
• prisoners and custody capacity;
• recovery assets;
• rare resources and donor reserve;
• release and recovery state.

Completion rule

Do not close coordination merely because the mission turns green. Confirm that members’ rare resources, patient/custody work and regional reserve are returning to useful positions.

Alliance missions and events

Event planning cycle

1. publish scope, time and participation expectations;
2. identify host regions and mission families;
3. record rare-resource and patient/custody risks;
4. name coordinators and communication channels;
5. define donor reserve expectations;
6. run the event;
7. release resources deliberately;
8. review delays, conduct and infrastructure gaps.

Participation policy

State whether participation is:

• optional;
• encouraged;
• expected for particular roles;
• limited by capacity or region.

Avoid treating a community event as justification to leave personal networks unsafe.

Large-alliance regional model

Divide a large alliance into operational regions while retaining central standards.

Each region should know:

• routine support coverage;
• neighbouring reinforcement;
• rare specialists;
• shared infrastructure;
• coordinators;
• escalation route;
• recovery condition.

Central leadership should monitor regional single points of failure rather than attempting to dispatch every mission directly.

Recruitment

Published criteria

Recommended criteria may include:

• activity and communication fit;
• willingness to follow dispatch etiquette;
• conduct history where legitimately available;
• region or timezone coverage;
• service interests;
• acceptance of contribution and inactivity policies.

Do not imply access to private information the alliance does not have.

Application review

Use consistent questions and a recorded decision reason. Avoid arbitrary requirements that are unrelated to alliance operation.

Trial or review periods

Where used, document:

• duration or review condition;
• expected conduct;
• available support;
• decision owner;
• outcome and appeal route.

Inactivity and leave

Distinguish:

• declared temporary absence;
• reduced activity;
• prolonged unexplained inactivity;
• departure;
• conduct-related removal.

Recommended process:

1. publish the inactivity policy;
2. allow members to declare leave privately where possible;
3. send a proportionate check-in;
4. review roles and permissions before removal;
5. document the outcome;
6. avoid presenting inactivity action as disciplinary misconduct when it is not.

Moderation and disputes

Evidence-first process

1. receive the report privately where possible;
2. preserve relevant messages, mission context and timestamps;
3. separate factual findings from interpretation;
4. allow the affected member to respond;
5. apply the published rule proportionately;
6. record the action and review condition;
7. provide an appeal or senior review route for significant decisions.

Graduated outcomes

Depending on severity and policy:

• guidance;
• informal warning;
• formal warning;
• temporary role or permission restriction;
• event or communication restriction;
• removal;
• immediate protective action for serious safety or abuse concerns.

Do not use operational dispatch control to punish a member during an unrelated dispute.

Optional Discord and external tools

External communication can improve coordination but requires clear boundaries.

Recommended controls

• explain what data is posted;
• use least-privilege bot permissions;
• separate public announcements from private moderation;
• restrict sensitive logs;
• document who administers integrations;
• provide an alternative route for members who cannot or do not wish to use the external platform where practical;
• review inactive accounts and tokens;
• do not claim an external tool is an official MissionChief requirement.

Useful channels or surfaces

• announcements;
• support requests;
• major incidents;
• events;
• training and guide updates;
• infrastructure projects;
• recruitment;
• private staff/moderation;
• service status or integration monitoring.

Reporting and review

Operational review

Periodically review:

• unanswered support requests;
• repeated rare-resource shortages;
• donor members being overused;
• regions with weak coverage;
• patient, custody and recovery bottlenecks;
• shared infrastructure utilisation;
• event outcomes;
• conduct and onboarding trends.

Decision log

Record significant:

• policy changes;
• permission changes;
• shared projects;
• major moderation outcomes;
• event after-action findings;
• specialist-distribution decisions.

The log should be proportionate and respect member privacy.

Common alliance failures

Failure	Operational symptom	Correction
“Send everything” culture	Donor networks become unsafe and requests are duplicated	Request exact capabilities and protect reserve
One-member specialist dependency	Major incidents fail when that member is absent	Distribute or register strategic reserve
Unwritten contribution rules	Members feel pressured or treated inconsistently	Publish the policy and exceptions
Excessive permissions	Routine roles can make high-impact changes	Apply least privilege and reviews
Public moderation by argument	Disputes escalate and evidence is lost	Use a private, recorded process
Central leadership dispatching every call	Regional response becomes slow and fragile	Delegate within documented regions
Mission completion treated as recovery	Rare resources remain unavailable for other members	Track release and return-to-readiness
External tools without boundaries	Privacy, access and continuity become unclear	Publish data and permission controls
Alliance support hiding local gaps	Routine requests consume shared capacity continuously	Build local core capability

Member readiness checklist

• local routine reserve is protected before sending support;
• requested quantity and capability are understood;
• trained personnel, towing and carrier dependencies are available;
• rare resources are announced and not duplicated;
• mission conditions and probabilities are preserved;
• resources are released promptly;
• conduct and communication rules are followed.

Dispatcher readiness checklist

• one coordinator owns the operational picture;
• every guaranteed and alternative group is tracked;
• donor reserve is protected;
• patients, prisoners and recovery assets are included;
• rare resources and member ownership are recorded;
• conflicting instructions are avoided;
• the incident remains open until regional recovery is underway.

Administrator readiness checklist

• rules and contribution policies are published;
• roles and permissions use least privilege;
• onboarding and inactivity processes are consistent;
• shared projects have evidence, ownership and review conditions;
• moderation uses evidence, proportionality and appeal;
• external tools have privacy and permission boundaries;
• specialist and regional gaps are reviewed;
• administrative policy is not misrepresented as game mechanics.

Stage 39 completion

The Alliance Operations programme now covers:

• membership evaluation and onboarding;
• roles, permissions and separation of duties;
• contributions and shared projects;
• dispatch etiquette and donor reserve;
• capability registries and mutual-support layers;
• major incidents, events and regional coordination;
• recruitment, inactivity and moderation;
• optional external integrations and reporting.

The next programme is Stage 40 — Account Readiness Planning Suite.