DIS: Re: [Arbitor] CFJ 3903 Assigned to G.
On 4/3/2021 9:37 PM, Kerim Aydin wrote: > On 4/3/2021 5:32 PM, Kerim Aydin wrote: >> The below CFJ is 3903. I assign it to G. >> >> status: https://faculty.washington.edu/kerim/nomic/cases/#3903 >> >> === CFJ 3903 === >> >> R. Lee's votes on the referendums on proposals 8549 and 8552-8555 >> were clearly specified. >> >> == > > Proto: > > In the past, we've accepted many complicated conditionals. In principle, > I don't see why "does this specified proposal add text to ruleset" is more > complicated or error-prone than, say "I vote for the candidate who > transfers me the most coins" in terms of difficulty to the vote collector. > > For the latter, for example, the vote collector would need to track any > coin transfer, look at recent reports to know if the transfers succeeded, > and maybe even (if the transfers had previous transfer dependencies) track > more. And errors would be made. Yet I suspect we would accept such a > conditional without thinking about it too much and the poor officer would > be on the hook. > > So I don't think we can throw out proposal parsing for conditionals just > because they're proposals or rule changes, or else if we do, we'd throw > out many conditionals that we've accepted in the past. > > As an example, looking at one of the proposals in question (8549), the > proposal is of the form "insert after [text] the following [other text]". > I looked up the rule, checked the power, and knew that the proposal in > question would increase the words in any of the rulesets. 3-5 minutes, > and fewer references to check than the coin thing. And probably less > prone to error than the coin thing. > > So in principle, proposals aren't special. Some are harder to interpret > than others in the name of interpreting conditionals, That's evaluated > case-by-case - it doesn't force evaluation of "arbitrary" text - some > proposals, just like some conditionals, could be "too hard", but it's > case-by-case). > > Now, some of the ones in this batch may be too difficult - but the caller > notes that they're not. Having looked over them for 5 minutes, I conclude > similarly - these are not difficult tasks. TRUE. > > I'll note that what's easy in the individual is often difficult in the > aggregate, but that's a matter of social restraint. Doing too many > blanket conditionals is similar to submitting lots of proposals and not > pending them, or calling and retracting lots of cfjs, or whatever. I > don't think a blanket cfj-ban based on the reasonableness of each one (and > these in particular are reasonable) is an appropriate way of handling > that, if it becomes an actual issue. I think I'd edit this to add a standard, to get the assessor out of all but the easiest jobs. Something like "the conditional must be clear and obvious within a minute or two of checking on facts". So a proposal that repeals a rule (requiring a word count), or has more than even one add or subtract so character count had to be tracked, would be too much. It's a pity every one of the proposals in this batch was so clear on whether they added text!
Re: DIS: [Proto] Ratification Rewrite
On Thu, Apr 01, 2021 at 06:14:51PM -0700, Aris Merchant via agora-discussion
wrote:
> This reply is likely longer and more rambly than it needs to be. For
> that, I apologize in advance.
>
> > I'm tempted to bring out my "self-ratifying events" proto again. Were
> > there any particular objections you had?
> >
> > It wasn't complete, but it is possible to implement in stages.
> >
> > Its benefit is to get rid of the "minimally modified" language. It
> > keeps the (arguably confusing) "what it would be if, ..." part, but I'm
> > not sure it makes sense to get rid of that --- see my criticism below
> > of your proto.
> >
> > ***
> > Summary of self-ratifying events: instead of ratifying "{ At time T,
> > Falsifian has 10 Coins }", you ratify an event: "{ At time T, the Coin
> > balance of Falsifian was set to 10 }".
> >
> > If we found we still needed old-style ratification for some reason, we
> > could invoke it explicitly: ratify that "{ At time T, the gamestate is
> > minimally modified so that ... }".
> >
> > To ratify a ruleset, we could explicitly say something like: "at time
> > T, the all rules are simultaneously amended, repealed or (re-)enacted
> > to match what's listed in this document". This might make it easier to
> > reason about whether, for example, the revision numbers changed. The
> > event we ratified in this example doesn't say anything about revision
> > numbers, so we are free to conclude that the revision numbers were
> > affected in the natural way by any changes to rule text. That's a
> > benefit to saying precisely what happens, rather than vaguely saying
> > "this becomes true".
> > ***
>
> I disagreed with your design. The problem wasn't a fundamental
> breakage, but I'm not convinced it works well for modifications beyond
> simple state modifications.
Overall comments:
* I'm not really sure my design would be an improvement. You do raise
some good points! I think I have reasonable counter-arguments to
them, included below, but I'm by no means convinced we should hop
right over to my system.
* I want to make sure I understand the reason behind your proto. Is it
that you think people find the current language of R1551 confusing?
I think R1551 is cool (although I do like complaining about the
"minimally modified" concept). Maybe it is confusing, but I wonder if
rephrasing it would partly solve that? E.g. Murphy's proto would
improve it a bit.
> Take for instance Rule 2034, "Vote
> Protection and Cutoff for Challenges". It describes at length a series
> of properties about the Agoran decision that we want to ratify. If I
> recall correctly, your solution was to ratify into existence a
> decision that did have the correct properties. I don't really think
> that's what we want. It leaves around another decision that could
> potentially be resolved at some point that does something we don't
> want. If we create a matcher that instead modifies a similar decision
> to have the stated properties, we either have to specify how the match
> is determined (adding to rules bloat) or leave it vague (losing the
> benefit of the specificity your architecture was supposed to give us).
Having just found my draft text, it doesn't look like a big problem to
me. I guess there's a notion of "matching" implicit in my proto, just
in the sense that it's written assuming it's clear "which" decision is
being referred to. But is that "matching" any different in nature from
determining which decision(s) the Assessor is resolving when e
publishes one of eir resolution messages?
The bit about quorum could probably be made more precise.
> More generally, I think moving the specification of what's supposed to
> happen to the rule providing for the application of ratification was a
> mistake. There are a few reasons for this:
>
> 1. It removes the ability to make anything self-ratifying easily.
> Instead, one has to specify an algorithm for each new type of
> ratification. This makes it more work to add new ratification rules to
> the ruleset. One might argue that this is justified by the additional
> specificity your model introduces. However...
I don't think it's complicated, except maybe for ratifying decisions
into existence.
> 2. The added specificity isn't actually all that helpful.
> 2a. It introduces another point of potential breakage. Let's take your
> example: "at time T, all rules are simultaneously amended, repealed or
> (re-)enacted to match what's listed in this document". You forgot to
> list retitling and changing power.
I did, but at least the effect is easy to determine now that you've
noticed it: clearly, the power and titles of the rules were not
changed.
Compare that to a situation where it's unclear what the minimal
modification is, or whether "multiple substantially distinct possible
modifications would be equally appropriate".
> Now, I'm aware that this is an off
> the cuff example, and that we'd be more careful when designing the
> actual text. That being
DIS: Re: [Arbitor] CFJ 3903 Assigned to G.
On 4/3/2021 5:32 PM, Kerim Aydin wrote: > The below CFJ is 3903. I assign it to G. > > status: https://faculty.washington.edu/kerim/nomic/cases/#3903 > > === CFJ 3903 === > > R. Lee's votes on the referendums on proposals 8549 and 8552-8555 > were clearly specified. > > == Proto: In the past, we've accepted many complicated conditionals. In principle, I don't see why "does this specified proposal add text to ruleset" is more complicated or error-prone than, say "I vote for the candidate who transfers me the most coins" in terms of difficulty to the vote collector. For the latter, for example, the vote collector would need to track any coin transfer, look at recent reports to know if the transfers succeeded, and maybe even (if the transfers had previous transfer dependencies) track more. And errors would be made. Yet I suspect we would accept such a conditional without thinking about it too much and the poor officer would be on the hook. So I don't think we can throw out proposal parsing for conditionals just because they're proposals or rule changes, or else if we do, we'd throw out many conditionals that we've accepted in the past. As an example, looking at one of the proposals in question (8549), the proposal is of the form "insert after [text] the following [other text]". I looked up the rule, checked the power, and knew that the proposal in question would increase the words in any of the rulesets. 3-5 minutes, and fewer references to check than the coin thing. And probably less prone to error than the coin thing. So in principle, proposals aren't special. Some are harder to interpret than others in the name of interpreting conditionals, That's evaluated case-by-case - it doesn't force evaluation of "arbitrary" text - some proposals, just like some conditionals, could be "too hard", but it's case-by-case). Now, some of the ones in this batch may be too difficult - but the caller notes that they're not. Having looked over them for 5 minutes, I conclude similarly - these are not difficult tasks. TRUE. I'll note that what's easy in the individual is often difficult in the aggregate, but that's a matter of social restraint. Doing too many blanket conditionals is similar to submitting lots of proposals and not pending them, or calling and retracting lots of cfjs, or whatever. I don't think a blanket cfj-ban based on the reasonableness of each one (and these in particular are reasonable) is an appropriate way of handling that, if it becomes an actual issue.
DIS: Fwd: [proto] Retroactive Events: a refactor of ratification
Here's my old retroactive events proto, for reference. (I brought it up in the thread "Ratification Rewrite".) I couldn't find it in the archive for some reason. -- Forwarded message - From: James Cook Date: Sat, 1 Feb 2020 at 16:17 Subject: [proto] Retroactive Events: a refactor of ratification To: Agora Nomic discussions (DF) 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
Re: DIS: [Proto] Archimedes' Principle
On 4/3/21 10:20 PM, Aris Merchant via agora-discussion wrote: Title: Archimedes' Principle Adoption index: 2.0 Author: Aris Co-author(s): Trigon, nix Speaking officially as Treasuror, I would like to point out that this is remarkably similar to a proposal I myself drafted a while ago except that it's more focused on this specific change. I truly do believe that a system like the one described in this proposal is better than what we have now. Charities will actually be funded the right amount each month, and the entire system just becomes more predictable in general. Additionally, despite the fact that the monthly message will ideally be automated and sent as soon as possible after the beginning of the month, the correct value will even be available beforehand. TL;DR: This proposal gets Treasuror endorsement. -- Trigon ¸¸.•*¨*• Play AGORA QUEST I’m always happy to become a party to contracts. I LOVE SPAGHETTI transfer Jason one coin nch was here I hereby don't... trust... the dragon... don't... trust... the dragon... Do not Construe Jason's message with subject TRIGON as extending this
DIS: Re: BUS: Re: OFF: Re: [Arbitor] Voting on the Indictment of Cuddlebeam
> On Apr 3, 2021, at 6:31 PM, Gaelan Steele via agora-business > wrote: > > > >> On Apr 3, 2021, at 6:29 PM, Gaelan Steele via agora-business >> wrote: >> >> I find G. guilty of violating Rule 2168/9 by Being Too Polite. I levy a fine >> of 1 blot. This fine is forgivable; the specified words are ["cuddle", >> "beam", "Cuddlebeam", "humiliate", "humble", "humbug", "humidity"]. > > Oops: If the quoted text didn't cause G. to gain a blot, I do the following: > > I find G. guilty of violating Rule 2168/9 by Being Too Polite. I impose the > Cold Hand of Justice, levying a fine of 1 blot. This fine is forgivable; the > specified words are ["cuddle", "beam", "Cuddlebeam", "humiliate", "humble", > "humbug", "humidity"]. > > Gaelan Bah! Turns out, this is actually the crime of Tardiness; 2143/33 makes any failure to perform a duty by a deadline Tardiness. I think my Cold Hand still worked. Gaelan
Re: DIS: [Proto] Archimedes' Principle
> On Apr 3, 2021, at 3:20 PM, Aris Merchant via agora-discussion > wrote: > > Title: Archimedes' Principle > Adoption index: 2.0 > Author: Aris > Co-author(s): Trigon, nix > > > [Changes: > -The Treasuror sets a target for the Total Buoyancy every week; > the most recent target takes effect at the beginning of the month > -The Unit of Floatation is now rounded, so people can actually remember > it > -The Treasuror no longer has a monthly report, and is instead > just encouraged to make sure the Total Buoyancy and Unit of Floatation > are published > ] Read through it; seems sensible to me. Gaelan
DIS: Re: BUS: Trying Out Judging Again [attn. Arbitor]
On 4/3/2021 5:05 PM, Aris Merchant via agora-business wrote: > I'm interested in judging a case sometime. If possible, I request one > that isn't incredibly complex. You're on the "occasional" list and I tapped you last month - not sure how to fit a request like this in the rotation exactly but I'll keep in in mind for at least the next few. -G.
DIS: Re: BUS: [CFJ] R. Lee's vote
On 4/3/2021 4:52 PM, nix via agora-business wrote: > On Sunday, March 28, 2021 11:08:30 PM CDT Jason Cobb via agora-business wrote: >> I CFJ, barring R. Lee: "R. Lee's votes on the referendums on proposals >> 8549 and 8552-8555 were clearly specified." > > I indicate I'm an interested judge, and I favor this case. Apologies - I started processing the cases before this last set of emails and didn't refresh my mail until just now. -G.
Re: DIS: [Proto] Ratification Rewrite
On Thu, Apr 1, 2021 at 6:14 PM Aris Merchant wrote: > > This reply is likely longer and more rambly than it needs to be. For > that, I apologize in advance. > > > I'm tempted to bring out my "self-ratifying events" proto again. Were > > there any particular objections you had? > > > > It wasn't complete, but it is possible to implement in stages. > [...] > > I disagreed with your design. The problem wasn't a fundamental > breakage, but I'm not convinced it works well for modifications beyond > simple state modifications. Take for instance Rule 2034, "Vote > Protection and Cutoff for Challenges". It describes at length a series > of properties about the Agoran decision that we want to ratify. If I > recall correctly, your solution was to ratify into existence a > decision that did have the correct properties. I don't really think > that's what we want. It leaves around another decision that could > potentially be resolved at some point that does something we don't > want. If we create a matcher that instead modifies a similar decision > to have the stated properties, we either have to specify how the match > is determined (adding to rules bloat) or leave it vague (losing the > benefit of the specificity your architecture was supposed to give us). I'll just add that I'm open to being convinced that something like yours is better. Right now it feels like mine is better, but I'm not as sure of that as I'd like to be. -Aris
Re: DIS: [Proto] Ratification Rewrite
On Sun, Mar 28, 2021 at 1:05 PM Aris Merchant via agora-discussion wrote: > > Wasn't really planning to publish this so soon, as I'm not really done > editing it. On the other hand, Murphy has published eirs, so I'm going > for it. > > -Aris > --- > Title: Ratification Rewrite > Adoption index: 3.0 > Author: Aris > Co-authors: Jason, G. An updated version that removes the confusing special case for ratifying public documents. I also incorporated part of Murphy's proposal (specifically, eir definition of the time of a document's ratification). -Aris --- Title: Ratification Rewrite Adoption index: 3.0 Author: Aris Co-authors: Jason, G., Murphy [Let's face it, the ratification rules are a mess. They're nearly unreadable, full of complicated technical language that is painfully hard to understand. While they deal with an inherently complex problem, that doesn't mean they need to be impossible to read themselves. A while back people suggested some rewrites that came at the problem from different angles, but all of them had their own problems. This proposal maintains the same basic conceptual approach as the current rules, but rewrites the text to make it more readable and adjusts the complex to simplify them. I hope this will lead to cleaner results than we have at present.] Enact a new power 3.0 rule entitled "Documents", with the following text: A document is a body of text. A public document is a document that is part (possibly all) of a public message. A public document's effective date is the time it was published, unless the document explicitly specifies a different past time as the time it was true, in which case its effective date is that past time. Amend Rule 1551, "Ratification", by changing it to read as follows: When a statement is ratified, play proceeds as if the statement has become true, and the state of the game is updated accordingly. A statement CANNOT be ratified if: 1. it is internally inconsistent; 2. it describes a state of affairs that is impossible for reasons outside its scope; 3. its ratification would make the state of the game indeterminate or inconsistent with the rules. The ratification of a statement does not change the rules, unless the statement (or a public document that it references) explicitly and unambiguously recites either the changes to them or their final properties. Text purportedly about previous instances of ratification is excluded from ratification. Ratification is secured at power 3. Amend Rule 2202, "Ratification Without Objection", by changing it to read in full: A player CAN, without objection, ratify a specified statement. Ratification without objection CANNOT cause rule changes, rules to the contrary notwithstanding. A player SHALL NOT ratify or announce intent to ratify a statement without objection if e knows it is incorrect or indeterminate, unless the general nature of the statement's error and reason for ratifying it is plainly described in the announcement of intent. Doing so is the Class 8 Crime of Endorsing Forgery. Amend Rule 2201, "Self-Ratification", by changing it to read in full: When a public document is defined as self-ratifying by the rules remains continuously undoubted for one week, it is ratified that the statement became true and correct in all respects at its effective date. Any person CAN by announcement submit a claim of error, identifying a document (perhaps implicitly) and explaining the nature of a perceived error in it. For so long as a claim exists against the document, it is doubted. When this happens, the publisher of the original document SHALL (if e was required to publish that document) or SHOULD (otherwise) do one of the following in a timely fashion, in an announcement that clearly cites the claim of error: 1. Deny the claim (causing it to cease to exist). 2. Initiate an inquiry case regarding the truth of the claim (if the subject is actually a matter of law), or cite a relevant existing inquiry case. 3. Publish a revision. If no claim of error is stated, the revision implicitly responds to all claims of error against the document being revised. Amend Rule 107, "Initiating Agoran Decisions", by replacing: A public notice purporting to initiate an Agoran decision is a self-ratifying attestation of the notice's validity. with: A public notice purporting to initiate an Agoran decision contains an implied self-ratifying statement that the notice is valid. Amend Rule 2034, "Vote Protection and Cutoff for Challenges", by replacing: A public message purporting to resolve an Agoran decision is a self-ratifying attestation that with: A public message purporting to resolve an Agoran decision contains an implied self-ratifying statement that
DIS: [Proto] Archimedes' Principle
Title: Archimedes' Principle Adoption index: 2.0 Author: Aris Co-author(s): Trigon, nix [Changes: -The Treasuror sets a target for the Total Buoyancy every week; the most recent target takes effect at the beginning of the month -The Unit of Floatation is now rounded, so people can actually remember it -The Treasuror no longer has a monthly report, and is instead just encouraged to make sure the Total Buoyancy and Unit of Floatation are published ] Amend Rule 2634, "Buoyancy Control", by changing it to read in full: The Total Buoyancy and Buoyancy Target are singleton integer switches, tracked by the Treasuror in eir weekly report. The Treasuror CAN, by announcement, set the Buoyancy Target to a specified value approximately equal to the sum of all coin balances at a specified point within the last week, and SHALL do so each time e publishes eir weekly report. The Treasuror may exercise reasonable judgement in calculating the Buoyancy Target. The Buoyancy Target will be deemed set so long as the value chosen by the Treasuror is not obviously and grossly incorrect. However, the Treasuror SHALL NOT deliberately introduce error into the Buoyancy Target. At the beginning of each month, the Total Buoyancy is flipped to the Buoyancy Target. Amend Rule 2635, "Floating Rate Fleet", by changing it to read in full: The Unit of Flotation is equal to 1/2500 times the Total Buoyancy, rounded to the nearest integer, and is tracked in the Treasuror's weekly report. A boatload of something is a quantity of that thing equal in count to the Unit of Floatation. The Treasuror is ENCOURAGED to arrange for the new Total Buoyancy and Unit of Floation to be published as close as possible to the beginning of the month. [No clue why this should be secured — granting assets isn't secured. The reason I'm amending this is to make the payday happen after the boatload value update; I'm open to other phrasings.] Amend Rule 2559, "Paydays", by replacing: The occurrence of Paydays is secured. At the beginning of each month, a Payday occurs. with: At the beginning of each month, after all other events that take place at the beginning of the month, a Payday occurs.
DIS: Re: BUS: [Proposal] The Election Cycle
On 4/3/2021 6:42 AM, nix via agora-business wrote: > Also note this removes method A from the original. It doesn't get much > use, so I don't see much reason to keep it. Plus, impeachment serves > a similar role. 1. Keeping it for Prime Ministers is enough use to keep it. 2. This means that, if an ADoP wants to keep an office interim for some reason, there's no way to start an election for it short of ADoP impeachment. I'd actually liberalize it somewhat, and allow starting elections by announcement by anyone if the office is vacant or (perhaps PM specific) been held for 90+ days. But at the very least, keep some level of ability there. -G.
DIS: Re: BUS: Re: OFF: [Notary] The Notes (pledges & promises)
On 4/3/2021 3:32 AM, Aris Merchant via agora-business wrote: On Wed, Mar 24, 2021 at 7:49 AM ATMunn via agora-official wrote: This is a continuation of the Notary's weekly report. Information about contracts can be found in a separate message. HISTORY OF PLEDGES & PROMISES = 21 Mar 2021: Jason made the pledge "General objection" -- time of last report -- 11 Mar 2021: The pledge "You can make it happen, R. Lee!" expired -- 2 reports ago -- 09 Mar 2021: Aris cashed the promise e created 09 Mar 2021: Aris created a promise 06 Mar 2021: The pledge "Referee Electoral Pledge" expired 01 Mar 2021: The pledge "CFJ annotations please" expired 28 Feb 2021: G. cashed the promise "Neverending PRESENT"[2] 28 Feb 2021: G. created the promise "Neverending PRESENT" -- 3 reports ago -- 20 Feb 2021: Falsifian destroyed the promise "Hopefully Last Assignment Fallback" w/o objection 20 Feb 2021: Falsifian destroyed the promise "Another Assginment Fallback" w/o objection 20 Feb 2021: Falsifian destroyed the promise "Assignment Fallback" w/o objection 17 Feb 2021: G. cashed an instance of the promise "Two by two" 14 Feb 2021: Falsifian created the promise "Hopefully Last Assignment Fallback" 14 Feb 2021: Jason cashed the promise created by Falsifian 14 Feb 2021: Falsifian created a promise 14 Feb 2021: Murphy granted nix the promise "Ratification compensation" 11 Feb 2021: Aris cashed the promise "Guess That Agoran" 08 Feb 2021: Trigon cashed the promise created by Jason 08 Feb 2021: Jason created a promise 08 Feb 2021: nix's pledge expired 06 Feb 2021: Jason cashed the promise nix granted em 06 Feb 2021: nix granted Jason a promise 06 Feb 2021: Jason cashed the promise created by Gaelan 04 Feb 2021: ATMunn[1] created the promise "Guess That Agoran" 03 Feb 2021: Falsifian cashed the promise nix granted em 03 Feb 2021: nix granted Falsifian an promise 03 Feb 2021: G. made the pledge "Rational dictatorship" 03 Feb 2021: Gaelan made the pledge "Keeping secrecy" 03 Feb 2021: Gaelan created a promise 02 Feb 2021: nix cashed the promise created by Aris 02 Feb 2021: Aris created a promise 02 Feb 2021: nix made a pledge [1] Sent from the email address "bunny.voo...@gmail.com"; this player was later revealed to be ATMunn. [2] The promise purports to create another promise upon cashing and then immediately cash that new promise; the effectiveness of this is PARADOXICAL under CFJ 3901. CoE: This is a misreading of CFJ 3901. CFJ 3901 stated that the statement "The cashing of one or more promises created by G. has been EFFECTIVE at changing the final vote tally and/or number of voters on the referendum to adopt Proposal 8543, for the purposes of R208, R879, and/or R2623." was PARADOXICAL. The PARADOX was in the effect of the promise, not the cashing; the promise was unambiguously cashed. Unless I'm mistaken, the promise no longer exists, so the portion of your report saying it does is in error. -Aris I wasn't really sure how to interpret that - thanks for the heads up. I don't have time to fix it right now but I will as soon as I can. -- ATMunn friendly neighborhood notary :)
