Ruleset 83

Core Rules

Ruleset and Gamestate

This is the Ruleset for BlogNomic; all Agents shall obey it. Section One consists of the "core rules" of BlogNomic, covering basic proposal mechanics; Section Two contains the rules of the current dynasty; and Section Three contains the glossary, which exists solely to clarify the remainder of the ruleset.

The Ruleset and Gamestate can only be altered in manners specified by the Ruleset.

Admins may correct obvious spelling and typographical mistakes in the Ruleset at any time, including replacing Spivak and gender-specific pronouns with the singular "they".

Agents

Anybody may apply to join BlogNomic (if they are not already playing) by registering at http://blognomic.com via the Register link in the sidebar, and then making a post announcing their arrival. An Admin shall add them to the roster in the sidebar and the GNDT, at which moment they become an Agent.

An Agent may leave the game at any time by posting an entry to the BlogNomic weblog requesting such an action. An Agent may only change their name as a result of a proposal approving the change.

Some Agents are Admins, responsible for updating the site and the Ruleset, and are signified as such in the sidebar. Agents who wish to become Admins may sign up with a username for the Ruleset Wiki, and submit a Proposal to make themselves Admins. Existing Admins may be removed from their posts by Proposal, CfJ, or voluntary resignation. New admins shall be given the GNDT configuration password when they become admins.

Some Agents are Idle, and shall be marked as such in the sidebar. For the purposes of the Ruleset, excluding Rules 1.1, 1.2, 1.8 and 1.10, Idle Agents are not counted as Agents. Admins may render an Agent Idle if that Agent has asked to become Idle or if that Agent has not posted an entry or comment in the last seven days. In the latter case, the Admin must announce the idling in a blog post. Admins may render themselves Idle at any time by announcing that they have done so in a blog post. Admins may de-Idle an Agent at their request, and Idle Admins may de-idle themselves at any time, unless the idle Agent in question asked to become (or rendered themselves) Idle within the previous 4 days, and within the current dynasty. The Agent’s personal gamestate retains the values it had immediately prior to their going Idle. If one or more values would be undefined, it is set to the value new Agents receive, if such a value exists.

Proposals

Any Agent may submit a Proposal to change the Ruleset or Gamestate, by posting an entry in the "Proposal" category that describes those changes, except that:

• An Agent cannot submit a non-Core Proposal if that Agent already has two or more non-Core Proposals pending.
• An Agent cannot submit a Proposal if that Agent already has three or more Proposals pending.
• An Agent cannot submit a Proposal if that Agent has already submitted three or more Proposals that day.

Proposals can either be Pending, Enacted, or Failed. When a Proposal is first put forward, it is considered Pending. A Proposal may not also be a Call for Judgment.

Voting

Any Agent may cast their Vote on a Votable Matter by making a comment to the official post that comprises that Votable Matter using a voting icon of FOR, AGAINST, DEFERENTIAL (only if the Votable Matter is a Proposal), or VETO (only if the Votable Matter is a Proposal and the Agent is the Director of Operations).

If the Agent who authored a Votable Matter has not cast a Vote on it, their Vote is counted as FOR. If an Agent uses more than one Voting Icon in comments on a Votable Matter, their Vote is the last voting icon they use. If an Agent leaves the game or goes Idle, their Vote is no longer valid. If an Agent Votes against their own Proposal, this renders the Proposal self-killed and that Vote may not be changed.

A Vote of DEFERENTIAL is a Vote of no opinion, or of faith in the decision of the Director of Operations. The Vote will count as the same as the Director of Operations’s Vote. If the Director of Operations casts a Vote of DEFERENTIAL on a Proposal, it serves the purpose of cancelling any previous Vote on that Proposal that was cast by the Director of Operations and counts as an explicit Vote of abstention. If there is no Director of Operations, or the Vote is made by the proposal’s author on their own proposal and the Director of Operations does not Vote on it, a Vote of DEFERENTIAL counts as an explicit Vote of abstention, and has no effect except possibly to void earlier voting icons by that voter on that proposal.

If no Director of Operations has Voted on a Proposal, a Vote of DEFERENTIAL on that proposal does not count as a Vote for the purposes of rule 1.5.

Resolution of Proposals

The oldest pending Proposal may be enacted by any Admin (and the Ruleset and/or Gamestate updated to include the specified effects of that Proposal) if either of the following is true:-

• It has a number of FOR Votes that exceed or equal Quorum, has been open for voting for at least 12 hours, and has not been vetoed or self-killed.
• It has been open for voting for at least 48 hours, it has continuously been a proposal for that time, it has more than 1 valid Vote, more than half of its Votes are FOR, and it has not been vetoed or self-killed.

The oldest pending Proposal may be failed by any Admin, if any of the following are true:-

• It has enough AGAINST Votes that it could not be Enacted without one of those Votes being changed.
• It has been open for voting for at least 48 hours and half or fewer of its Votes are FOR.
• It has been open for voting for at least 48 hours and has fewer than 2 valid Votes.
• The Agent who proposed it has Voted AGAINST it.
• The Director of Operations has Voted to VETO it

If the Director of Operationshas voted to VETO a proposal and that Vote’s comment includes the word “Procedural”, the vetoed proposal can be failed immediately by any admin, even if it is not the oldest pending proposal.

Whenever an Admin marks a proposal, CfJ, or DoV as enacted or failed, they must also mark their name, and report the final tally of Votes (or the fact that it was self-killed or vetoed).

Proposals the Director of Operations has Voted to VETO are considered vetoed, and such a Vote cannot be changed. Proposals the author has Voted against are considered self-killed unless the Director of Operations has Voted VETO on them, or they have fulfilled one of the other requirements to fail a proposal before the author’s self-kill Vote is placed. Immediately after enacting a proposal that causes a rule with no name to be added to the ruleset, unless the proposal specifically states that the rule should have no name, the enacting admin can change the rule’s title to give it a name, so long as doing so does not change the meaning of any part of the ruleset, nor change any properties of the rule (such as specific words in the title) that the ruleset specifically cares about.

Calls for Judgment

If two or more Agents actively disagree as to the interpretation of the Ruleset, or if an Agent feels that an aspect of the game needs urgent attention, then any Agent may raise a Call for Judgment (abbreviated CfJ) by posting an entry in the “Call for Judgment” category. The post shall go on to describe the issue, and measures that shall be taken to resolve it.

All Agents may cast Votes on that CfJ to indicate agreement or disagreement with the position taken in that CfJ. Unfailed CfJs continue until they reach a Quorum of FOR Votes, a Quorum of AGAINST Votes, or if there is no hiatus going on, until four days have passed, and if there is a hiatus going on until two days have passed. After this time, if more than half the cast Votes are FOR Votes, the CfJ may be enacted by any Admin by updating or correcting the Gamestate and Ruleset as specified. Otherwise, the CfJ fails. A Failed CfJ has no further effect.

Any CfJ that has no effect on the ruleset or gamestate may be automatically failed by any admin.

Gamestate Tracking

Proposals, Calls for Judgment, and other official posts, as well as specific gamestate information, shall be tracked by the BlogNomic blog at http://blognomic.com. Any Agent may post to the blog at any time, but may only make official posts to the blog when the Ruleset allows it. Posts following the format specified by a rule are considered official posts.

If no Agent has commented on it, an official post may be altered or removed by its author; otherwise this can only be done as allowed by the Ruleset. However, despite this, official posts can never be changed from one category to another, or changed to be a different sort of official post, if they have been posted for more than fifteen minutes. The Admin processing an official post is allowed to append to the post to reflect its new status. Anything appended to a post in this way must be placed in the Admin field of the post, and the post's Status must be changed to reflect its status.

A non-official post may not, through editing of the blog or otherwise, be changed into an official post, with the following exception: Whilst a non-official post has been posted for less than fifteen minutes and has no comments, the author may change the categories as they wish.

Voting and comments are accessible through the link at the bottom of every post.

Specific parts of the Gamestate data shall be tracked by the Generic Nomic Data Tracker at http://blognomic.com/gndt/generic.cgi?nomic=blog. Any Agent may update any Agents data via the GNDT, whenever the Ruleset permits it.

All updates to the GNDT are logged. Actions that change gamestate directly (defined in other rules) can normally be performed simply by applying their effects to the GNDT, which updates the gamestate accordingly, unless another rule specifies some other method of performing them; one GNDT update may contain one or more actions, or one action may be split over multiple GNDT updates, as long as it’s clear what is happening and the actions are otherwise legal. The GNDT merely represents the Gamestate, and is not the same thing. In the event that the Gamestate and the GNDT are different, any Agent may correct the GNDT to comply with the Gamestate.

If an Agent feels that the GNDT was altered such that it no longer matches the gamestate (such as by performing an action which was against the Rules (as they were at the time of the alteration), or by any other means), they may simply undo the effects of that alteration. Instead of repeatedly reverting and re-reverting a disputed GNDT update, Agents are encouraged to raise a Call for Judgment instead. Agents shall be assigned a password for the GNDT when they join the Nomic.

Dynasties

BlogNomic is divided into a number of Dynasties. Each Dynasty is headed by a single Agent, known as the Director of Operations.

The Director of Operations may Vote to VETO any Proposal.

Victory and Ascension

If an Agent (other than the Director of Operations) believes that they have achieved victory in the current Dynasty, they may make a post to the Blognomic weblog in the Declaration of Victory category, detailing this.

Upon doing so, the game immediately goes into Hiatus, if it hasn’t already. During this time, the only game actions that may be taken are those covered by Rules “Agents”, “Voting”, “Calls for Judgment”, “Gamestate Tracking” and “Victory and Ascension”.

Every Agent may cast Votes on that DoV to indicate agreement or disagreement with the proposition that the poster has achieved victory in the current Dynasty.

A DoV may be enacted if any of the following is true:

• It has been open for voting for 12 hours, has a number of FOR Votes that exceed or equal Quorum, and either the Director of Operations has Voted FOR it or it has no AGAINST Votes.
• It has been open for voting for at least 24 hours, has a number of FOR Votes that exceed or equal Quorum, and has a number of against Votes fewer than half of Quorum, rounded down.
• It has been open for voting for at least 48 hours, at least Quorum Agents have Voted on it, and more than half of its Votes are FOR.

A DoV may be failed if any of the following are true:

• It has been open for voting for 12 hours and has enough AGAINST Votes that it could not be Enacted without one of those Votes being changed.
• It has been open for voting for at least 48 hours and cannot be legally enacted.

When a DoV fails and there are no pending DoVs, Hiatus ends.

When a DoV is enacted, all other active DoVs are failed, and a new Dynasty begins with the Agent who made the DoV as its Director of Operations. (That Agent may pass this role to another Agent at this point, if they wish.) The Hiatus continues until the new Director of Operations posts an Ascension Address to the BlogNomic weblog - this should specify the Director of Operations’s chosen theme for the new Dynasty, and may optionally specify that the terms Agent and Director of Operations will be replaced with theme-specific terms throughout the entire ruleset, and/or a number of dynastic rules to keep. Upon posting such an Ascension Address, the ruleset is updated to reflect any changed terms, and any dynastic rules which were not listed to be kept are repealed.

A DoV may not be started in the period between an enacted DoV and that DoV’s Ascension Address. When a DoV is failed, if it has a number of AGAINST Votes that exceed Quorum, the Agent who posted it cannot make another DoV until after 120 hours (5 days) have passed since the time their DoV was failed.

A Declaration of Victory may not also be any other type of Official Post unless the rules concerning that type of Official Post explicitly state otherwise.

Fair Play

The following are BlogNomic’s rules of fair play. If any of the rules are found to have been broken, a proposal or CfJ may be made to remove the perpetrator from the game, and bar them from rejoining.

• A single person should not control more than one Agent within BlogNomic.
• An Agent should not “spam” the BlogNomic blog. What counts as spamming is subjective, but would typically include posting more than ten blog entries in a day, more than ten blog comments in a row, or posting a blog entry of more than 1000 words.
• An Agent should not deliberately exploit bugs or unexpected behaviours in the software running the game (ExpressionEngine, MediaWiki or the GNDT).
• An Agent should not edit their own blog comments once posted, nor those of any other Agent.
• An Agent should not edit the "Entry Date" field of a blog post.
• An Agent should not make a DoV primarily to delay the game by putting it into Hiatus.
• An Agent should not do any action meant to make the game unplayable (for example, changing multiple keywords to the same word in an ascension address).

Dynastic Rules

The Red Phone

The Director of Operations may be Telephoned by emailing blognomic.d.ops@gmail.com. The Director of Operations may also be referred to as “D-Ops”.

Codenames

Each Agent may have a Codename, a Description and an Allegiance. An Agent’s Allegiance, if they have one, can be either US, Soviet or Independent. An Agent’s Description is tracked in the GNDT; all other details are tracked privately by D-Ops.

An Agent’s description includes a Height (measured in feet and inches, between 5’0” and 6’4”), a Nationality (American, British, French, East German, Russian or West German) and a Cover Job (Academic, Banker, Courier, Diplomat, Journalist or Tourist).

Imposters

There are three non-Agent entities, the Imposters, who have a Codename, Description, Location and Allegiance as though they were Agents; however, their Descriptions are tracked privately by D-Ops. No Agent can be given an interim Description that is the same as an Imposter’s Description. As a weekly Action, D-Ops may - for each Imposter - change that Imposter’s Location to a random District.

Imposters may become Eliminated. If an Imposter has been Eliminated, its Location is always Unknown and it no longer counts as an Imposter for any rule other than this one.

Allegiances

If an Agent has a Codename but no Allegiance, the D-Ops shall set their Allegiance to Independent.

As a weekly action, an Agent (the “Defector”) may Telephone D-Ops with the Codename of an Agent they believe has recruited them. When D-Ops reads this Telephone message: if an Agent has the specified Codename and is in the same Location as the Defector, then the Defector’s Allegiance is altered to match that of the Agent with the specified Codename. If the Defector’s Allegiance changes as a result of this, the Defector shall be informed of this fact (although they will not be told their new Allegiance). If it does not, the Defector shall be told that the Defection failed to occur.

Any time an Agent’s Allegiance changes, the D-Ops may secretly change the Codename assigned to an Imposter (if any) with the Agent’s previous Allegiance.

Briefing

Any Agent who does not have a Codename may Telephone the Director of Operations to request an identity.

Upon receiving such a request, D-Ops may reply, giving an interim Codename (of D-Ops’ choice) and an interim Description (generated at random from all possible Descriptions, excluding those already held by other Agents).

The Agent who receives such a reply may update the GNDT once to change their Description to this interim Description; upon doing so, the Agent’s Codename is set to the interim Codename.

Surveillance

An Agent may, if they have not yet done so when they had their current Location, telephone D-Ops announcing their intention to perform surveillance. D-Ops should respond to this email. Responses by D-Ops shall be determined in the following manner:-

• If the Agent performing surveillance has a Location of “Unknown,” D-Ops will refuse and cite this reason.
• Otherwise, if there existed any Agents or Imposters with the same Location as the Agent performing the surveillance, at the time the Surveillance was announced, D-Ops will respond with a list of all of their Codenames and Nationalities.
• If neither of the above are true, D-Ops will respond that there were no suspicious characters in the District.

Berlin 1946

A map of Berlin can be found at Berlin map, divided into Areas, Sectors and Districts. This page may only be edited by D-Ops.

Each Agent has a Location, which is either a District on the map, or Unknown. Each Agent’s Location starts as Unknown. If an Agent’s Location has been Unknown for more than seven days, D-Ops may move the Agent to a random District, email the Agent to inform them of this and update the Agent’s Last Known Location to that District (prefixing it with an asterisk as if the Agent had updated it themselves).

Locations are notated as five-letter strings. The first letter of the string refers to which side of Berlin the Agent is in; the second and third letters refer to the sector occupied by the Agent; and the fourth and fifth letters refer to the district. A complete key to location information can be found at the same page as the map, linked to above. An Unknown Location is notated as “XXXXX”.

As a weekly action, an Agent who has a Codename may Walk to a new Location by telephoning the Director with their new Location, in an email with the subject line “CODENAME walks to LOCATION”, where “CODENAME” is the Agent’s Codename, and “LOCATION” is their intended Location. If valid, the Location change is considered to occur as soon as the email reaches D-Ops.

As a daily action, any Agent may take a Taxi to a new Location, and do one but not both of the following:

• Move to another Location within their current Area, and then truthfully update their own Last Known Location field in the GNDT to reflect this. They must then Telephone D-Ops in an email with the subject line “ACTION: CODENAME takes a taxi to LOCATION” (where “CODENAME” is the Agent’s Codename, and “LOCATION” is their new Location), to inform them of their new Location.
• Truthfully update their own Last Known Location field in the GNDT to their current Location, and then move to another Location within their current Sector. They must then Telephone D-Ops in an email with the subject line “ACTION: CODENAME takes a taxi to LOCATION” (where “CODENAME” is the Agent’s Codename, and “LOCATION” is their new Location), to inform them of their new Location.

Each Agent’s Last Known Location is tracked in the GNDT. This must consist of a valid Location (other than Unknown) and of a date at which it was believed to be true. Any Agent may update this at any time. If an Agent updates their own Last Known Location, this update must be prefixed by an asterisk. An Agent may update their own Last Known Location at any time, but such an update must be truthful.

Objectives

There exists a wiki document known as The Dossier, which contains a list of Objectives. At any time, D-Ops may select an Objective from a subrule to this rule and and add it to The Dossier as an Operation.

An objective must specify the time in which it must be completed, the number of Agents that may be assigned to it and the conditions that must be met to complete it, and may include one or more conditions for failure. When an Operation is added to the Dossier, D-Ops must assign it to a positive amount of Agents equal or lower to the limit specified in the Objective, and give it an Operation Name. When he does so, he shall privately inform the Agent(s) of their Operation, and shall mark upon the wiki document how many Agents are assigned to the Operation. When D-Ops creates one or more Operations, he should also create a Radio Transmission which includes the Operation’s Operation Name.

If an Operation is not completed in its alloted time, it is failed. When an Operation is completed or failed, it shall be marked as such in the Dossier, and all assignments to it are removed.

An Agent may only be assigned to a single Operation at a given time, and an Agent without a Codename cannot be assigned to an Operation. An Agent may telephone D-Ops at any time to request assignation to a particular Objective, with a subject line of “OPERATION REQUEST” and the name of an Objective in its body. As a daily action, D-Ops may select an Objective, and assign it as a single Operation to one or more Agents who have previously requested assignation to that Objective (selecting such Agents at random, and ignoring those who have been assigned the Objective since last requesting it, or who could not be assigned to the Operation).

List of Objectives

The Objectives that D-Ops may create are listed below:

Meet fellow operative

Time: 7 days

Maximum number of Agents: 1

An Agent with this Objective may telephone D-Ops with the subject line “MEET [AGENT]”, where [AGENT] is the name of another Agent. If, at the time of telephoning, both agents share a Location and Allegiance, this Objective is completed, and both Agents are informed of each other’s Codenames. If both Agents share a Location but not an Allegiance, this Objective is failed, and D-Ops shall privately inform [AGENT] of the codename of the Agent who had this Objective. Otherwise, this Objective is failed.

Find local office

Time: 7 days

Maximum number of Agents: 3

This Objective must be assigned to exactly three Agents, all three of which must have the same Allegiance. When this Objective is assigned, D-Ops must pick a Location, and privately send the Area of that location to one Agent, the first letter of the district code to the second Agent, and the second letter of the district code to the third. He shall not inform the assigned Agents of each other’s identities, and shall not tell either Agent with a district letter which position their letter holds. If all three of the assigned Agents simultaneously hold the correct location for more than 24 hours, and no more than 2 other Agents also hold that location for the same duration, the Objective succeeds, and D-Ops shall privately inform the assigned Agents of each other’s Codenames, as well as the Codename of one Imposter (listed seperately). If at least three Agents not assigned to this objective simultaneously hold the correct location for more than 24 hours, this Objective fails, and the Codename of a randomly chosen Agent who was assigned to this objective will be made public in a post. If at least two of the assigned Agents hold the correct location when this Objective expires, D-Ops shall privately inform them of each other’s Codenames.

Station Raid

Time: 7 days

Maximum number of Agents: 1

An Agent with this Objective may telephone D-Ops with the subject line “RAID [DISTRICT]”, where [DISTRICT] is either Steglitz (US Station), Heliersdorf (Soviet Station) or Spandau (Independent Station). If, at the time of telephoning, both the Agent's Location and Last Known Location match that District, then the Objective is completed - D-Ops shall select a random Agent whose Allegiance matches the Allegiance of the raided Station (if any exist), and send both their name and Codename to the raiding Agent. Otherwise, this Objective is failed.

Assassination

Time: 7 days

Maximum number of Agents: 1

An Agent with this Objective may telephone D-Ops with the subject line “ASSASSINATE [TARGET]”, where [TARGET] is any word. If, at the time of telephoning, an Imposter has the TARGET word as their Codename, and shares a Location with the Agent performing the Objective, then the Objective is completed - the Imposter is Eliminated, and the Agent shall be given the Codename of every Agent who shares an Allegiance with the Imposter. Otherwise, this Objective is failed. If this Objective is failed for any reason, the assassin is arrested - D-Ops shall post the Name, Codename and Location of the Agent performing the Objective to the weblog.

Interception

As a daily action, an Agent who has a Codename (the “Interceptor”) may Intercept another Agent by telephoning D-Ops with the subject line “INTERCEPT [AGENT] ON [OPERATION]” where “AGENT” is the name of an Agent, and “OPERATION” is the name of an Operation in the Dossier which has neither been completed nor failed.

If, at the time the email was sent, the named Agent (the “Target”) had been assigned to the named Operation, then the Operation is failed and the Interceptor is privately informed of the Target’s Codename. Otherwise, the Operation is unaffected, the Interceptor is privately informed of their failure, and the Target is privately informed of the Interceptor’s Codename (but not their name).

Radio Transmissions

Various rules create Radio Transmissions, which are either Queued or Archived. If any Radio Transmissions are Queued, D-Ops may make a post with the title “Radio Transmissions”, and a body composed of any number of Queued Transmissions in the order they were created, separated by ellipses. D-Ops may insert hyphens and remove spaces at his discretion. (Upon doing so, all Radio Transmissions become Archived.)

An Agent may make a Broadcast by telephoning D-Ops in an e-mail with the subject line “Radio Transmission”. The e-mail’s body must contain the message that the Agent wishes to broadcast, which must be a string of spaces, numbers and/or upper-case letters with a length of 30 or more. When D-Ops receives such an email, a Queued Radio Transmission is created with the email’s body as its content.

Communications

As a weekly action, an Agent may send a message to any Agent who has a Codename by telephoning D-Ops with the subject line “ACTION: Message to CODENAMEA in SECTORA”, where CODENAMEA and SECTORA are the codename and sector of the intended recipient. If this information is valid, D-Ops should forward the message to the recipient Agent. If the information pertaining to the recipient is incorrect, the message is not forwarded to the recipient Agent, and D-Ops shall respond to the sending Agent indicating as much, but the Interception conditions still apply.

As a weekly action, an Agent may send a message to any Agent who has a Codename by telephoning D-Ops with the subject line “ACTION: Message from CODENAMEA in SECTORA to CODENAMEB”, where CODENAMEA is the Codename of an Imposter, SECTORA is Sector in which that Imposter is located, and CODENAMEB is the Codename of the intended recipient. If this information is valid, D-Ops should forward the message to the recipient Agent. If the information pertaining to the Imposter is incorrect, the message is not forwarded to the recipient Agent, and D-Ops shall respond to the sending Agent indicating as much, but the Interception conditions still apply.

Interceptions

When a message is sent within one Sector, there is a 5% chance that it is intercepted, and a 95% chance that nothing happens. When a message is sent between two Sectors, there is a 10% chance that it is intercepted, a 5% chance that it is broadcast, and a 85% chance that nothing happens. When a message is sent between East- and West-Berlin, instead there is a 20% chance that it is intercepted, a 10% chance that it is broadcast and a 70% chance that nothing happens.

If a message is intercepted, D-Ops shall also forward it to a randomly chosen Agent in SECTORA or SECTORB apart from the sender or recipient. If a message is broadcast, it has been intercepted by a local radio station, and a Radio Transmission is created of the message (including all spacing and formatting, and surrounding by quotation marks). Whenever a message is posted or sent to an Agent, all information in the original subject line shall be omitted.

Final Report

As a weekly action, an Agent who has a Codename (the ‘Caller’) may Telephone D-Ops with a Final Report - a list of Codenames, each of them different, and each paired with the name of an Agent.

If all of the following conditions are met for a Final Report, then that Report is Confirmed:-

• The list contains at least four Codenames.
• Every Codename is paired with the name of the Agent who has that Codename.
• The Caller does not have the same Allegiance as any of the listed Agents.

If D-Ops has received a Confirmed Final Report from an Agent, then D-Ops shall confirm this in a public blog post, and that Agent has achieved victory. If D-Ops receives a Final Report which is not Confirmed, he must respond to the Agent who submitted it, telling them this.

If a submitted Final Report includes the Codename of an Impostor in its list of Codenames, the Agent who submitted it is Decommissioned, with D-Ops posting a blog entry to this effect. A Decommissioned Agent may not submit any further Final Reports.

Specialties

Every Agent has a Specialty and a Clue, which are tracked in the GNDT. An Agent’s Specialty starts as Generalist, and their Clue starts as blank.

The Specialties an Agent may have are as follows:

• Generalist. A Generalist who has a Codename may change their Specialty at any time, without updating their Clue.
• Lamplighter. A Lamplighter may send messages as per “Communications” as a daily action rather than a weekly action.
• Pavement Artist. As a weekly action, an Pavement Artist may Skulk to a new Location by telephoning the Director with their new Location, in an email with the subject line “CODENAME skulks to LOCATION”, where “CODENAME” is the Agent’s Codename, and “LOCATION” is their intended Location. If valid, the Location change is considered to occur as soon as the email reaches D-Ops. A Pavement Artist may not both Skulk and Walk within a six-hour period.
• Scalphunter. When attempting to Intercept another Agent on an Operation, a Scalphunter may use a Codename in place of that Agent’s name. If the Interception is successful, the Scalphunter is then informed of the Agent’s name rather than their Codename.
• Burrower. A Burrower may, as a daily action, perform Surveillance even if they have already done so in their current location.
• Sandbagger. A Sandbagger ignores the restriction of only being assignable to a single Operation at a given time. If three Agents are Sandbaggers, further Agents cannot become Sandbaggers.
• Inquisitor. When an Inquisitor performs Surveillance, the D-Ops shall indicate which, if any, Codenames they discover at that time belong to Imposters. The D-Ops shall then move any such Imposters to a new random Location as soon as it is legal to do so.
• Shoemaker. When changing Specialties to Shoemaker, an Agent may set their Specialty in the GNDT to any other Specialty, and may list the same new Specialty in their Story Post if necessary; however, they must privately telephone D-Ops at the time of the change to record that their true Specialty is Shoemaker, and they are not legally considered to have any other Specialty. When attempting to complete an Objective, a Shoemaker is treated as though they had whatever Allegiance is most advantageous for completion.
• Code Breaker. Whenever a message is sent, there is a 50% chance that its content is forwarded to all Code Breakers who share a Sector with the sender.
• Plant. If a Plant appears on a Surveillance list, then the recipient of the list is given a disguised Nationality for that Plant, depending on the Sector in which the Plant is located. If they are in the US sector, their Nationality is given as American; if in the French sector, as French; if in the British sector, as British; and if in the Soviet sector, as Russian.

As a daily action, any Agent who has a Codename may change their Specialty by updating their Specialty in the GNDT and adding one letter of their Codename to their Clue. An Agent may add the same letter to their Clue multiple times, but only as many times as that letter actually appears in their Codename. If an Agent has already revealed all the letters of their Codename in this way, they may continue to change Specialties as a daily action without updating their Clue.

Glossary

Keywords

A keyword defined by a rule supersedes the normal English usage of the word. A keyword defined in this glossary supersedes that defined by a rule. (eg. A rule specifying "bananas are blue" cannot be overruled by posting a dictionary definition or a photo of a banana, and a rule specifying "every day is Sunday" will be overruled by the glossary entry below.)

Can

"is able to"

Comment

A blog comment published to the BlogNomic weblog at blognomic.com

Core Proposal

A Proposal whose changes are limited to the creation, deletion, and/or amendment of core rules and/or the glossary, and/or renaming, banning, and/or the granting or removing of admin status from one or more Agents.

Daily Action

If a game action is a Daily Action, each Agent able to perform it may take that action once each day, but not more than once every six hours.

Day

References to a “day” as an entity rather than as a duration (e.g. “Sunday”, “The day after performing this action”, or “August 2nd”), unless otherwise stated, refer to a day beginning at and including 00:00:00 GMT, ending when the next day begins. It can never be 2 different days at the same instant.

Dice

References to "YDICEX" refer to Y X-sided dice, rolled within the GNDT. To roll dice, post DICEX in the comments field of the GNDT, replacing X with the number of sides on the die you wish to roll.

Dynastic Proposal

A Proposal whose only changes are the creation, deletion, and/or amendment of dynastic rules and/or gamestate defined by dynastic rules.

Effective Vote Comment (EVC)

An Agent's Effective Vote Comment with respect to a given Proposal means that Agent’s Comment to that Proposal (if any) that contains that Agent’s Vote on the Proposal that is given effect in accordance with Rule 1.4 when the Proposal is Resolved, not including explicit Votes of abstention..

Flavour Text

When posting a blog entry, an Agent may use the “Commentary or flavour text” field of the blog publishing form to add their own comments or description of their post. For the purposes of all other rules, such text is not considered to be part of the post.

Gamestate

Any information which the Ruleset regulates the alteration of.

IRC Channel

The Blognomic IRC channel is located at #nomic on the slashnet network (irc.slashnet.org).

May

"is permitted to"

Post

A blog post published to the BlogNomic weblog at blognomic.com

Quorum

Quorum of a subset of Agents is half the number of Agents in that subset, rounded down, plus one. If the word Quorum is used without qualifying which subset of Agents it is referring to, it is referring to a Quorum of all Agents.

Resolve/Resolution

If used in a context of Proposals, Call for Judgements or Declarations of Victory, the world “Resolve” means to perform the act, as an Admin, of enacting or failing a Proposal, a Call for Judgement or a Declaration of Victory. The world “Resolution” means then the act of doing so. If used in another context, the meaning of both “Resolve” and “Resolution” is the standard English meaning of these words.

Shall

"is required to"

Should

"is recommended that"

Story Post

A Story Post is an Official Post that is not a member of any specific category of Official Posts mentioned or defined in a Core Rule (excluding Official Post).

Subject

The "subject" of a blog entry is the part of the Title of an entry which is after the first colon. If the Title does not contain a colon, then the whole Title is the subject. Any entry whose subject is "" (i.e. an empty string) is not valid.

Votable Matter

The word “Votable Matter”, means a Proposal, a CFJ or a DoV.

Vote

The word “Vote”, used as a noun, means a Vote that is cast in accordance with Rule 1.4 “Voting”. The word “Vote”, used as a verb, means the act of casting such a Vote.

Voting Icons

For use in voting, a check box http://blognomic.com/images/vote/for.gif shall represent a Vote FOR, an X http://blognomic.com/images/vote/against.gif shall represent a Vote AGAINST, an IMP http://blognomic.com/images/vote/imperial.gif shall represent a Vote of DEFERENTIAL, and an Imperial Seal http://blognomic.com/images/vote/seal.gif shall represent the Imperial Veto.

Week

References to a week as an entity rather than as a duration (e.g. “At the beginning of each week”, or “already happened this week”), unless otherwise stated, refer to a period of time between the beginning of a Monday and the end of the following Sunday.

Weekly Action

If a game action is a Weekly Action, each Agent able to perform it may take that action once each week, but not more than once every twenty-four hours.

Wiki

The BlogNomic Wiki at http://blognomic.com/wiki/index.php?title=Main_Page

Clarifications

Numbers and Variables

• Unless otherwise specified, game variables defined to hold numeric values can hold only non-negative integers, and any action that would set those values below zero instead sets them to zero. Any situation which would require a roll of DiceX when X is zero or lower always yields a value of 0 unless stated otherwise.
• All numbers, unless stated otherwise by a rule, are in base ten.
• Unless otherwise specified, when “X” is a number, to spend X of a numeric value “V” means to subtract X from V (i.e. replace V with V-X); to gain X of a numeric value “V” means to add X to V; and to transfer X of a numeric value “V” from A to B means to subtract X from A's V and add the amount A's V was reduced by to B's V. Unless otherwise specified, a rule that allows Agents to transfer a numeric value only allows them to transfer that value from themselves to another Agent (of their choice unless otherwise stated).
• An Agent who has a choice in whether to take an action defined by a dynastic rule may not take that action if both of the following conditions are true: a) the action's effects are limited to changing values tracked in the GNDT and/or similar gamestate-tracking entities (such as a wiki page), and b) the action would change one of those values to an illegal value.
• If a rule implies that the result of a division should be an integer (for instance, by attempting to store that result in, or add it to, a gamestate variable that can only hold integers), the result of the division is instead the result rounded towards 0.
• If a number or other game variable is selected 'at random' or 'randomly' from a range of possible values, its value shall always be taken from a uniform probability distribution over the entire range of possible values, unless otherwise specified.

Rules and Proposals

• If a new rule is created by a proposal and its location is not noted in that proposal, that new rule is to be placed in the Dynastic Rules.
• Where a Proposal would amend the effects of Proposal Enactment, this does not apply to its own enactment unless explicitly stated (eg. a proposal proposing that enacted proposals earn their author a banana when enacted would not earn a banana for its own author, when enacted).
• Rules which trigger upon the Enactment or Failure of a Proposal are the responsibility of the Admin who Enacts or Fails it.

Time

• For the purpose of all rules, time in Blognomic is in GMT.
• All references to time must be either specific or defined within the ruleset to be considered achievable in the gamestate. Abstract concepts of time (e.g. "dinnertime", "twilight") cannot be achieved until they fulfil one of these criteria.
• Where the month, day and/or year of a calendar date are ambiguous (eg. "04/10/09"), it shall be assumed that the date is in a day/month/year format.

Spelling

• Superficial differences between the spelling of geographic versions of English, e.g, British English, American English and Australian English shall be construed as irrelevant for the purposes of play.

Names

• Within the ruleset, a word only refers to the name of an Agent if it is explicitly stated that it refers to an Agent's name.