This is a counter-proto to Alexis's "Ratification by Legal Fiction", in the sense that I think it also fixes the problem of ratification failing due to minimal gamestate changes being ambiguous. It is a more radical change and makes the use of ratification less concise, but in my opinion the reward is that it greatly increases simplicity and certainty in what the effect of ratification actually is.
I proposed something like this in July when I was arguing for "ratification via closed timelike curves". At the time, Aris argued that this makes complicated (see https://mailman.agoranomic.org/cgi-bin/mailman/private/agora-discussion/2019-July/055130.html --- search for "Also, how is this a rules simplification?"). To be fair, I had claimed in my that thread that what I was proposing was a rules simplification, and in this case, I'm not exactly making that argument. I'm arguing that it makes the rules simpler to understand, even if it makes the text longer and forces us to describe different cases explicitly. I am curious to hear people's opinions. I personally would be much more comfortable if ratification worked like this, but I'm not sure others will feel the same way. The bit added to Rule 2034 about setting the list of voters is rough; probably it would be better to change the quorum rules to make it clear that "number of voters" can be a fictional number associated with a decision, and then in R2034 just say the number of voters is set to whatever was indicated. Title: Retroactive Events AI: 3 Chamber: Efficiency Text: [Comment: The purpose of this proposal is to replace the "minimally modified" language of Rule 1551 with something easier to determine. It accomplishes this by replacing ratification of documents with ratification of explicitly-specified events, which may be cumbersome to use, but should be easier to interpret. It also eliminates the use of ratifying "portions" of documents, which I think is was bit vaguely specified.] Amend Rule 1551 (Ratification) to read in full: A "retroactive event" is a change to the gamestate, or other hypothetical event (the "event"), together with a time in the past (the "event time"). If not otherwise specified, the event time defaults to the time at which the retroactive event was originally published. When a retroactive event is ratified, rules to the contrary notwithstanding, the gamestate is modified to what it would be if the event had occurred at the event time. Such a modification cannot add inconsistencies between the gamestate and the rules, and it cannot include rule changes unless the message or rule describing the event explicitly and unambiguously recites either the changes or the resulting properties of the rule(s). If the description of a retroactive event is too ambiguous or convoluted for its effect at the event time be reasonably determined, or the description internally inconsistent, that event cannot be ratified. Ratification is secured with power threshold 3. Amend rule 2201 (Self-Ratification) by replacing the text from "When a public document" through "contents of the message" inclusive with: When a public document is continuously undoubted for one week after publication and the rules associate any "self-ratifying" retroactive events with that document, those retroactcive events are ratified. If the document specifies a time before its own publication as the time at which was accurate, that is used as the event time; otherwise, it is the time at which the document was published. Amend Rule 2162 (Switches) by replacing item 3 in the only list with: 3. Optionally, exactly one office whose holder tracks instances of that switch. That officer's (weekly, if not specified otherwise) report includes the value of each instance of that switch whose value is not its default value. A public document purporting to be that officer's report is associated with the following self-ratifying event: flip all instances of the switch to the values listed in the report, or to their default value if they are not listed in the report. Amend Rule 1607 (Distribution) by replacing the last sentence with: A public document purporting to be a Promotor's report is associated with the following self-ratifying retroactive event: modify the proposal pool to contain exactly the proposals listed in the report, with exactly the text and attributes listed in the report. Amend Rule 107 (Initiating Agoran Decisions) by replacing the last paragraph with: A public notice purporting to initiate an Agoran decision is associated with the following self-ratifying retroactive event: if the notice did not cause the decision to be initiated, but nonetheless identified the matter to be decided, then initiate it anyway. Amend Rule 2034 (Vote Protection and Cutoff for Challenges) to read in full: A public message purporting to resolve an Agoran decision is associated with the following self-ratifying event, with an event time that is immediately after the message was published. The event is for the following to happen in order: 1. If such a decision did not exist, create it. 2. For the purpose of determining quorum of future decisions, if the number of voters on the decision does not match the notice, set the number of voters to be as indicated. (If the list of voters is important and the number has changed as a result of this provision, the list of voters is "Fake person 0", "Fake person 1", etc.) 2. If the notice did not cause the decision to be Resolved as indicated, resolve it so. 4. If the indicated outcome was to adopt a proposal: 4a. If the proposal does not exist, create it. 4b. If the proposal was not adopted, adopt it. 4c. If the proposal did not take effect, it takes effect. Amend Rule 2202 (Ratification Without Objection) by replacing its first two paragraphs with: Any player CAN, without objection, ratify a specified retroactive event, optionally specifying the event time. Amend Rule 2166 by replacing "This portion of that entity's report is self-ratifying." with: A public document purporting to be such a report is associated with the following self-ratifying retroactive event: destroy any instances that were not listed, and create instances that are listed but did not exist. (In the case of fungible assets, this means creating or destroying instances so that the number of instances owned by each entity is as listed, and entities not listed as owning assets have a balance of zero.) - Falsifian
