Difference between revisions of "Command Policy"

From Bravo Fleet
m
 
(29 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{icons|bfo}}Last Update: 16 December 2022
{{icons|bfo}}Last Update: 1 June 2024


=1 - Registry Definition=
==1 - Registry Definition==
#The registry lists all starships, starbases, and other entities available to Bravo Fleet for use as Commands or Games.
#The registry lists all starships, starbases, and other entities available to Bravo Fleet for use as Commands or Games.
#The registry’s purpose is to maintain consistency across Bravo Fleet and its ongoing canon. As such, entries will not be added to, removed, or altered from the registry without permission of the Intelligence Office.
#The registry’s purpose is to maintain consistency across Bravo Fleet and its ongoing canon. As such, entries will not be added to, removed, or altered from the registry without permission of the Intelligence Office.
#The registry represents the In Character starships and starbases available to the Fourth Fleet in {{Year}}, and the starships and starbases available for Games and Commands.
#The registry represents the in-universe starships and starbases available to the Fourth Fleet in {{Year}}, and the starships and starbases available to members in their personal writing or the RPGs they play and run. They are represented on BFMS by Games and Commands, which are attached to the dossiers of the members who own them, and house the character biographies of the crew and the Missions and Stories depicting their adventures.
##Exceptions such as non-Starfleet ships or ships of a different era have been created for Fictions or Games, and may not be used as Primary Commands. These will be more often added, deleted, or altered.
##Exceptions such as non-Starfleet ships or ships of a different era have been created for Games, and may not be used as Primary Commands. These will be more often added, deleted, or altered.
##The use of registry entries in Games is governed by Section 4 of the Operations Policy.
## The use of registry entries in Games is governed by Section 4 of the Operations Policy.
#Ships in the registry should only be used in lore by the members or Task Forces (in the case of TFHQ ships or Flagships only) to which they are assigned.
#Ships in the registry should only be used in lore by the members or Task Forces (in the case of TF Assets) to which they are assigned.
#Events involving registry ships prior to 2399 may be referenced in circumstances such as character service records and backstory. If a story requires another ship, it should use a name not listed in the registry and would fall within the bounds of member canon. This restriction begins at 2399 as this is when the current fleet canon went live; members should not be dictating fleet or member canon for this period outside of their own characters and Command.
#Stories may depict other ships, including Starfleet ships, not in the registry. These must never be written as the 'main' vessel in a story, and their place in stories must be restricted to minor or supporting roles. The existence and use of these 'NPC' ships constitutes member canon.
#Members should not apply for Commands on BFMS until they are ready to acquire or change their Primary Command, or for a fiction/RPG proposal to be discussed with the Intelligence Officer/Operations Officer. Draft Commands or proposals self-identifying as WIPs will have their registry link removed or be deleted.
## These ships must always have a name not found in the registry.
=2 - Primary Commands=
##NPC ships may not be written as assigned to a joint mission alongside a member's ship, and especially not under their command.
#Primary Commands are attached to a member's dossiers as their character's starship or auxiliary craft. They are the vessels assigned In Character to a member’s Task Force in the Fourth Fleet in {{Year}}.
##These ships should play roles like delivering supplies or personnel or being in need of rescue as a story's instigating event. They and their crews should not be recurring, significant dramatic actors in a manner that undermines the Fleet Assets System. Members who want to write multiple ships and crews must wait until attaining the fleet rank of Captain.
#Members can write on their Primary Command on their own or with others. Writing with others on a Primary Command does not require a proposal or activity commitment being sent to the Intelligence Office. Members ''may not'' use their Primary Command as an RPG; ie, they may not openly recruit for crew or create a separate website, and collaboration should be limited to invitation-only. RPGs which any member of the Fleet may apply to join must be accepted by the Bravo Fleet Operations Officer, and thus Primary Commands are unsuitable for this purpose.
#Events involving registry ships ''prior to'' 2399 may be referenced in circumstances such as character service records and backstory. This restriction changes at 2399 as this is when the current fleet canon went live; members should not be dictating fleet or member canon after this outside of their own characters and Command.
#Members may only have one Primary Command. Requesting a new eligible Primary Command will result in the current registry ship being removed from the member's dossier and returned to the pool of available ships. This includes any member 'upgrading' from a Raven-class to a starship command at Lieutenant Commander.
# Fleet canon about a ship is defined by the Intelligence Office or any member who holds that Command. Subsequent members who command a registry ship must adhere to that fleet canon and not retcon or change it without permission from the Intelligence Officer.
#Primary Commands will be removed from a member's dossier upon transfer to the Reserves.
##Fleet canon established by prior commanders is limited to the names of captains and crewmembers and the dates of their assignments, and major points of the ship's activities, such as participation in a fleet-wide storyline or where and when the ship was commissioned. Members are not beholden to retain more minor details of a ship's mission history, design, or configuration. Any pre-2399 history of a command established by a member is member canon and thus may be rewritten or disregarded by any new commander.
#When a member reaches the rank of Midshipman they may request a ship on the registry for use as their Primary Command. Ship classes available are unlocked upon reaching certain ranks.
##The history of registry ships is maintained on their wiki article. Members are free to depict this history as they wish, either retaining original text or rewriting. There is no obligation to mention events or history prior to their command. The only requirement is to retain a list of previous commanders, ''with links to their BFMS Commands'', as seen [https://wiki.bravofleet.com/index.php/USS_Rhyndacus#Notable_Crew here].
{| class="wikitable" style="margin:auto"
==2 - Primary Commands ==
|+Ship classes by rank
# The assigning and management of ships and Commands is governed by the [[Logistics Office Policy]].
|-
#Primary Commands are attached to a member's dossiers as their character's starship or auxiliary craft. They are the vessels assigned In Character to a member’s Task Force in the Fourth Fleet in {{Year}}.
!Midshipman!!Lieutenant Commander!!Commander!!
##Regardless of what Secondary Commands a member may own, their Primary Command must always be a Starfleet ship assigned to the Fourth Fleet in {{Year}}.
|-
# Members can write on their Primary Commands on their own or, with some restrictions, with others.
|[[Raven Class|Raven]]||[[California Class|California]]|| colspan="2" |[[Akira Class|Akira]]
##Members may only have one other member permanently writing on their Command. This member may play one or several characters, including crewmembers and senior staff assigned to the ship. This additional member may not play the ship's Commanding Officer; the CO must be a character assigned to the member who holds the Command.
|-
##Members may invite others to temporarily write on their Command as guests. There is no restriction in how many guests may be on write on a Command at one time, but this collaboration cannot last longer than one mission and is expected to be limited to one or a handful of Stories. These guests may write characters from other BF Commands or RPGs in a 'cross-over,' or they may write new characters created for this collaboration. They may return later for more guest appearances, but this collaboration should stay in the spirit of a 'guest star' on a Star Trek episode.
| ||[[Challenger Class|Challenger]]|| colspan="2" |[[Defiant Class|Defiant]]
## Writing with others on a Primary Command does not require a proposal or activity commitment to be sent to the Intelligence Office. Members ''may not'' use their Primary Command as an RPG; ie, they may not openly recruit for crew or create a separate website, and collaboration should be limited to invitation-only. RPGs which any member of the Fleet may apply to join must be accepted by the Bravo Fleet Operations Officer, and thus Primary Commands are unsuitable for this purpose.
|-
##These restrictions apply to Secondary Commands as well as Primary Commands.
| ||[[Cheyenne Class|Cheyenne]]|| colspan="2" |[[Excelsior II Class|Excelsior II]]
|-
| ||[[Diligent Class|Diligent]]|| colspan="2" |[[Gagarin Class|Gagarin]]
|-
| ||[[Grissom Class|Grissom]]|| colspan="2" |[[Inquiry Class|Inquiry]]
|-
| ||[[Intrepid Class|Intrepid]]|| colspan="2" |[[Luna Class|Luna]]
|-
|
|[[New Orleans Class|New Orleans]]
| colspan="2" |[[Manticore Class|Manticore]]
|-
| ||[[Norway Class|Norway]]|| colspan="2" |[[Nebula Class|Nebula]]
|-
| ||[[Nova Class|Nova]]|| colspan="2" |[[Pathfinder Class|Pathfinder]]
|-
| ||[[Olympic Class|Olympic]]|| colspan="2" |[[Prometheus Class|Prometheus]]
|-
|
|[[Parliament Class|Parliament]]
| colspan="2" |[[Rhode Island Class|Rhode Island]]
|-
| ||[[Reliant Class|Reliant]]|| colspan="2" |[[Sutherland Class|Sutherland]]
|-
| ||[[Saber Class|Saber]]|| colspan="2" |
|-
| ||[[Springfield Class|Springfield]]
|-
| ||[[Steamrunner Class|Steamrunner]]
|}
=3 - Squadrons=


#The Squadron system allows members holding the dossier rank of Captain and above greater flexibility in their Command choices. Where Commanders and below may pick a single Primary Command from a list, Captains are entitled to a certain level of ‘Squadron Strength’ in their Command selection. This gives them options like choosing between a single, larger ship or multiple smaller ones.
==3 - Task Unit and Fleet Assets==
#If a member holds multiple Commands under the Squadrons system, these ships are all subject to the same usage requirements as outlined under Primary Commands above. They may not be used as RPGs, and IC are starships assigned to the member’s Task Force.
##Members with multiple ships should designate one as their Primary Command on BFMS.
##Members have some freedom on how to IC depict these multiple ships. They may be entirely unaffiliated, all falling directly under their Task Force’s IC chain of command, with the member using them to tell totally different stories.
##Members may use all/some of them to form an IC-only unit within their Task Force, referred to as a squadron. This typically takes its title from the squadron’s ‘lead ship’ or starbase (for example, a squadron led by the USS Endeavour would be called ‘Endeavour Squadron’). This ensures all squadrons have a unique IC name. Members may not call these IC units ‘task groups’, to avoid confusion with the OOC unit.
##Members may create an officer in command of this squadron, who may or may not also be the commanding officer of one of these starships/starbase, and who falls IC under the chain of command of the member’s Task Force. All Canon Policy rank restrictions remain.
#The Squadron Strength to which a member is entitled is dependent on their dossier rank.
{| class="wikitable"
|+'''Squadron Strength by Dossier Rank'''
!Captain
!Fleet Captain
!Commodore
!Rear Admiral
!Vice Admiral
!Admiral
!Fleet Admiral
|-
|3
|4
|6
|7
|8
|9
|10
|}


== 3.1 - Starship Strength ==
#The assigning and management of Task Unit Assets is governed by the [[Logistics Office Policy]].
 
#Members may use these assets in their stories, with some limitations. These assets should never be significantly altered by the events of a member's writing without the permission of the Intelligence Officer.
# Ship classes are allocated a certain level of Strength depending on their size, power, modernity, and so forth.
##Task Force Headquarters and Secondary Stations may be freely depicted, without permission, by any member of any Task Force as locations their ships can visit on their journeys. TFHQs or stations may never be depicted as being significantly imperiled over the course of a story.
# Members may select any number of ships as their Commands under the Squadrons system, so long as the total Strength does not exceed their rank entitlement.
##Task Force Flagships and Guest Ships may only be used by members of the TF to which they are assigned.
 
###Task Force Flagships may be depicted in a member's stories with permission from the TFCO.
{| class="wikitable" style="margin:auto"
###Task Force Guest Ships may be freely depicted, without permission, by members of the Task Force to fulfill 'cameo' roles in stories. This constitutes minor usage, such as the mention of a ship's off-screen activities (for example, providing the initial report of an incident that leads to a member's ship conducting the deeper follow-up investigation), or a rendezvous with the member's ship to deliver supplies or a crewmember.
|+Ship classes by rank
###Guest Ships may be used in larger roles in the stories of TF members with permission from the TFCO. More significant story roles include, for example, the ship in need of rescuing as the main objective of a mission, or a joint operation between two starships.
|-
#Development of Task Unit Assets is the responsibility of TF Staff, with the oversight of the Intelligence Office. This constitutes building their wiki articles, determining the asset's mission profile, and creating its CO and other crewmembers. Each Task Unit Asset should have sufficient information about it available that multiple members may depict it in their stories with relative consistency.
!1!!2!! colspan="2" |3
#The usage of Task Unit Assets by members remains member canon. Members are encouraged to add their use of an asset to its wiki page to build a shared narrative among others in the TF, but this should be to facilitate a spirit of shared ownership, not provide constraints.
!4
|-
|Small Civilian Ship|| colspan="2" |[[Akira Class|Akira]]||[[Century Class|Century]]
|[[Odyssey Class|Odyssey]]
|-
|[[California Class|California]]|| colspan="2" |[[Defiant Class|Defiant]]||[[Galaxy Class|Galaxy]]
|
|-
|[[Challenger Class|Challenger]]|| colspan="2" |[[Excelsior II Class|Excelsior II]]||[[Obena Class|Obena]]
|
|-
|[[Cheyenne Class|Cheyenne]]|| colspan="2" |[[Gagarin Class|Gagarin]]||[[Ross Class|Ross]]
|
|-
|[[Diligent Class|Diligent]]|| colspan="2" |[[Inquiry Class|Inquiry]]||[[Sovereign Class|Sovereign]]
|
|-
|[[Grissom Class|Grissom]]|| colspan="2" |[[Luna Class|Luna]]||[[Typhon Class|Typhon]]
|
|-
|[[Intrepid Class|Intrepid]]|| colspan="2" |[[Manticore Class|Manticore]]||[[Vesta Class|Vesta]]
|
|-
|[[New Orleans Class|New Orleans]]|| colspan="2" |[[Nebula Class|Nebula]]||
|
|-
|[[Norway Class|Norway]]|| colspan="2" |[[Pathfinder Class|Pathfinder]]||
|
|-
|[[Nova Class|Nova]]|| colspan="2" |[[Prometheus Class|Prometheus]]||
|
|-
|[[Olympic Class|Olympic]]|| colspan="2" |[[Rhode Island Class|Rhode Island]]||
|
|-
|[[Parliament Class|Parliament]]||[[Sutherland Class|Sutherland]]
|-
|[[Reliant Class|Reliant]]||
|-
|[[Saber Class|Saber]]||
|-
|[[Springfield Class|Springfield]]
|
|-
|[[Steamrunner Class|Steamrunner]]
|
|}
#For example, upon reaching the rank of Captain a member has a Squadron Strength entitlement of 3. If they already have a Commander-level ship, they are only using 2 of their Squadron Level. They may ‘upgrade’ as they did upon reaching the rank of Commander, returning their current ship to the registry and choosing a single new Command with a Strength of 3. If they keep their ship with its Strength of 2, they may choose to add to their dossier another ship with a Strength of 1.
##Members are under no obligation to use their total Squadron Strength. These Commands are a reflection of the hard work of members, however, and may be chosen for storytelling opportunities or simple prestige.
#‘Small Civilian Ship’ is a catch-all term for non-Starfleet civilian vessels members may wish to use for different kinds of storytelling. It refers to ships of, for example, the [[Kaplan F17 class]] or the [[Groumall class]], usually freighters, that are not affiliated IC with Starfleet and may be used for trading, prospecting, exploration, or other adventures. Acquiring a ship like this is subject to a successful Fiction Proposal, and so they are not listed as available on the registry but created as required by the Intelligence Office.
#The Intelligence Office may make adjustments to ship class Strengths to account for balance as the system and canon evolve. No member will have an asset removed because of a rebalance, but they would only be grandfathered in until they wanted to change their squadron, at which point the new strength values would be used.
 
== 3.2 - Starbase Strength ==
 
# Starbases as Commands work the same as starships under the Squadron system, but are subject to different requirements. They represent starbases assigned In Character to the member’s Task Force in the Fourth Fleet in 2400.
# Members do not have to choose between a starbase or starship under the Squadron system. They are only restricted by their rank’s total Squadron Strength.
# Registry Starbases are created by the Intelligence Office, and will have their own wiki article explaining the location and setting material relevant to that starbase that has been ratified by the Intelligence Office. This is Fleet Canon that cannot be altered without permission of the Intelligence Office, even by the member to whom the starbase registry is attached. As such, members should heavily consider their choice, as a Starbase Command is under more restrictions and requirements from the Intelligence Office.
## If you are interested in a Starbase Command, please speak with the Intelligence Office to develop your concept so the registry can be created.
# Members may choose to depict any of their other ships as attached to or operating out of the starbase.
 
{| class="wikitable" style="margin:auto"
|+Starbase classes by Strength
|-
!2!!3!!4
|-
|[[Jupiter Class|Jupiter]]||[[Anchorage Class|Anchorage]]||[[Canopus Class|Canopus]]
|-
|[[K Class|K-Type]]||[[Copernicus Class|Copernicus]]||[[Unity Class|Unity]]
|-
|[[Regula Class|Regula]]||[[Narendra Class|Narendra]]||
|-
|[[Vision Class|Vision]]||[[Presidium Class|Presidium]]||
|-
| ||[[Watchtower Class|Watchtower]]||
|}
 
== 3.3 - Attached Ships ==
 
# Certain commands, like starbases, have an attached ship, which has its own registry entry but has an effective Strength of 0. Whether or not an attached ship is selected does not affect a member’s Squadron Strength.
# Most attached ships are assigned to starbases. Upon requesting a starbase, the member should identify to the Intelligence Office an appropriate choice of ship from the registry. That ship will then be removed from the public pool. It will not be given a BFMS Command, but should be written about as part of the starbase’s Command.
# The ''Odyssey''-class always has an ''Aquarius''-class ship attached. Unlike with starbases, the ''Aquarius''-class’s name is predetermined and cannot be changed. Details about an ''Odyssey’s'' ''Aquarius''-class will be listed on the ship’s wiki page.
 
{| class="wikitable"
|+Starbase Attached Ship Options
![[Aquarius Class|Aquarius]]
!
!
!
!
|-
|[[Raven Class|Raven]]
|
|
|
|
|-
|[[Sydney Class|Sydney]]
|
|
|
|
|}
 
== 3.4 - Requesting Squadron Ships ==
 
# Members must use BFMS to request any Commands under the Squadron system, as was done with previous Command requests.
# BFMS requests for new Commands under the Squadron system must use the ‘Lore Office Proposal’ window to clearly communicate their allocation of their Squadron Level. This must include what ships, if any, are being returned to the registry.
## If a new Captain requests a Command with a Strength of 3 with no further detail, the Intelligence Office will assume they are returning their current ship to the registry, just as with previous upgrades, and process accordingly.
## If a Member wishes to retain their current Command and add another, they may request the new ship under BFMS and say so in the Proposal window. A simple message, such as ‘I am keeping the USS Lollipop (Strength 2), and adding this one (Strength 1) for a total Squadron Strength of 3’ will suffice.
## If a Member wishes to return any of their ships to the registry, they must say so. Any requests for additional Commands that does not include a registry return and would bring a member over their Squadron Strength will be deleted. A simple message, such as ‘I am returning the USS Lollipop (Strength 2) and adding this one (Strength 3) for a total Squadron Strength of 3’ will suffice.
# If the Intelligence Office receives competing requests for the same starship, requests for a primary command from Lieutenant Commanders or Commanders will be prioritised, or upgrades to a single Strength 3 starship for new Captains. After that, ships will be allocated on a first-come, first-served basis.

Latest revision as of 15:43, 1 June 2024

This article is official Bravo Fleet Official Policy.








Last Update: 1 June 2024

1 - Registry Definition

  1. The registry lists all starships, starbases, and other entities available to Bravo Fleet for use as Commands or Games.
  2. The registry’s purpose is to maintain consistency across Bravo Fleet and its ongoing canon. As such, entries will not be added to, removed, or altered from the registry without permission of the Intelligence Office.
  3. The registry represents the in-universe starships and starbases available to the Fourth Fleet in 2401, and the starships and starbases available to members in their personal writing or the RPGs they play and run. They are represented on BFMS by Games and Commands, which are attached to the dossiers of the members who own them, and house the character biographies of the crew and the Missions and Stories depicting their adventures.
    1. Exceptions such as non-Starfleet ships or ships of a different era have been created for Games, and may not be used as Primary Commands. These will be more often added, deleted, or altered.
    2. The use of registry entries in Games is governed by Section 4 of the Operations Policy.
  4. Ships in the registry should only be used in lore by the members or Task Forces (in the case of TF Assets) to which they are assigned.
  5. Stories may depict other ships, including Starfleet ships, not in the registry. These must never be written as the 'main' vessel in a story, and their place in stories must be restricted to minor or supporting roles. The existence and use of these 'NPC' ships constitutes member canon.
    1. These ships must always have a name not found in the registry.
    2. NPC ships may not be written as assigned to a joint mission alongside a member's ship, and especially not under their command.
    3. These ships should play roles like delivering supplies or personnel or being in need of rescue as a story's instigating event. They and their crews should not be recurring, significant dramatic actors in a manner that undermines the Fleet Assets System. Members who want to write multiple ships and crews must wait until attaining the fleet rank of Captain.
  6. Events involving registry ships prior to 2399 may be referenced in circumstances such as character service records and backstory. This restriction changes at 2399 as this is when the current fleet canon went live; members should not be dictating fleet or member canon after this outside of their own characters and Command.
  7. Fleet canon about a ship is defined by the Intelligence Office or any member who holds that Command. Subsequent members who command a registry ship must adhere to that fleet canon and not retcon or change it without permission from the Intelligence Officer.
    1. Fleet canon established by prior commanders is limited to the names of captains and crewmembers and the dates of their assignments, and major points of the ship's activities, such as participation in a fleet-wide storyline or where and when the ship was commissioned. Members are not beholden to retain more minor details of a ship's mission history, design, or configuration. Any pre-2399 history of a command established by a member is member canon and thus may be rewritten or disregarded by any new commander.
    2. The history of registry ships is maintained on their wiki article. Members are free to depict this history as they wish, either retaining original text or rewriting. There is no obligation to mention events or history prior to their command. The only requirement is to retain a list of previous commanders, with links to their BFMS Commands, as seen here.

2 - Primary Commands

  1. The assigning and management of ships and Commands is governed by the Logistics Office Policy.
  2. Primary Commands are attached to a member's dossiers as their character's starship or auxiliary craft. They are the vessels assigned In Character to a member’s Task Force in the Fourth Fleet in 2401.
    1. Regardless of what Secondary Commands a member may own, their Primary Command must always be a Starfleet ship assigned to the Fourth Fleet in 2401.
  3. Members can write on their Primary Commands on their own or, with some restrictions, with others.
    1. Members may only have one other member permanently writing on their Command. This member may play one or several characters, including crewmembers and senior staff assigned to the ship. This additional member may not play the ship's Commanding Officer; the CO must be a character assigned to the member who holds the Command.
    2. Members may invite others to temporarily write on their Command as guests. There is no restriction in how many guests may be on write on a Command at one time, but this collaboration cannot last longer than one mission and is expected to be limited to one or a handful of Stories. These guests may write characters from other BF Commands or RPGs in a 'cross-over,' or they may write new characters created for this collaboration. They may return later for more guest appearances, but this collaboration should stay in the spirit of a 'guest star' on a Star Trek episode.
    3. Writing with others on a Primary Command does not require a proposal or activity commitment to be sent to the Intelligence Office. Members may not use their Primary Command as an RPG; ie, they may not openly recruit for crew or create a separate website, and collaboration should be limited to invitation-only. RPGs which any member of the Fleet may apply to join must be accepted by the Bravo Fleet Operations Officer, and thus Primary Commands are unsuitable for this purpose.
    4. These restrictions apply to Secondary Commands as well as Primary Commands.

3 - Task Unit and Fleet Assets

  1. The assigning and management of Task Unit Assets is governed by the Logistics Office Policy.
  2. Members may use these assets in their stories, with some limitations. These assets should never be significantly altered by the events of a member's writing without the permission of the Intelligence Officer.
    1. Task Force Headquarters and Secondary Stations may be freely depicted, without permission, by any member of any Task Force as locations their ships can visit on their journeys. TFHQs or stations may never be depicted as being significantly imperiled over the course of a story.
    2. Task Force Flagships and Guest Ships may only be used by members of the TF to which they are assigned.
      1. Task Force Flagships may be depicted in a member's stories with permission from the TFCO.
      2. Task Force Guest Ships may be freely depicted, without permission, by members of the Task Force to fulfill 'cameo' roles in stories. This constitutes minor usage, such as the mention of a ship's off-screen activities (for example, providing the initial report of an incident that leads to a member's ship conducting the deeper follow-up investigation), or a rendezvous with the member's ship to deliver supplies or a crewmember.
      3. Guest Ships may be used in larger roles in the stories of TF members with permission from the TFCO. More significant story roles include, for example, the ship in need of rescuing as the main objective of a mission, or a joint operation between two starships.
  3. Development of Task Unit Assets is the responsibility of TF Staff, with the oversight of the Intelligence Office. This constitutes building their wiki articles, determining the asset's mission profile, and creating its CO and other crewmembers. Each Task Unit Asset should have sufficient information about it available that multiple members may depict it in their stories with relative consistency.
  4. The usage of Task Unit Assets by members remains member canon. Members are encouraged to add their use of an asset to its wiki page to build a shared narrative among others in the TF, but this should be to facilitate a spirit of shared ownership, not provide constraints.