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. 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).
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...
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. 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 said, it's still likely we would sometimes
fail to specify the changes we want, or that the changes we define
would fail to match reality.
2b. You've only fixed a subset of ambiguities. For instance, if a
rule's revision number is higher in the ruleset than reality, this
would arguably introduce some amendments to the rule to knock its real
revision number up to the value stated in the ruleset? If the revision
number is lower, does the ratification fail entirely because the rules
can't be changed to the desired state? If two rules are conflated
together, which is amended and which is repealed? The problem stems
from the inexactness of your phrasing. "Make changes X, Y, and Z so as
to accomplish A" admittedly makes sure that you don't end up with
changes not on that list, but how often is that actually the source of
our ratification problems? The ambiguities usually come from other
directions.
2c. Even in the situations where your example does adequately specify
a change, I'm not sure the change would be different from the one we
arrived at otherwise. If a rule has different text in the ruleset then
in reality, what change would one apply other than amending the rule
to match the desired state?
You way feel that I'm being ridiculously hard on your example. Truth
be told, I'd actually agree with you. I have picked on every single
point I can think of. The thing I'm pointing to though, is that I'm
not sure specifying the changes to be applied is actually helpful in
the general case. I think it moves us further from the intuitive goal
of the system, thus introducing more opportunities for problems. To
explain why, let me look at this problem from another angle.
What is ratification meant to do?
Ratification is, as we describe it to new players, a way of dealing
with the inevitable errors that accumulate over time. If an error
isn't caught for long enough, we pretend that the version we thought
was true was true.
In my mind, the goal of our ratification rules should be to encode our
intuitions about how ratification is supposed to work. This has
several advantages. On the one hand, it will make the ratification
rules easy to read, because their implementation will match their
intuitive description. On the other hand, it will reduce bugs, because
the rule text will encode the behavior we want in plain terms,
allowing the judiciary to use common sense to apply that behavior to
reality.
Your model unquestionably improves on the mess we currently have.
However, it fails to describe the intuitive behavior of ratification.
Intuitively, ratification is a retroactive action; it is us pretending
that the past is something that it wasn't. My implementation is
intended to codify this.
The biggest weakness of my model is that it doesn't codify how the
gamestate is changed. Generally, we don't care, but there are cases
where the rules depend on how things became the way they are now. I'm
not sure how to address this weakness. Maybe I need some extra text
clarifying how those changes are considered to have been applied, or
maybe it doesn't matter very much usually and we can just special case
the cases where it does. But, despite this difficulty, I still believe
that making the ratification match up with the way we intuitively
perceive it is a good thing.
As an aside, I think my system includes yours, the same way you point
out that your system includes mine. All we'd have to do in my system
to get the results your system does is to ratify a statement like
"Change X was applied at time Y." The difference is that mine doesn't
make that model the default. I believe that most of the time it's not
what we want, and forcing people to specify how the changes are
applied will cause more problems than it solves (see the above). On
the other hand, if there are specific instances we decide that
behavior is best in, we can still encode that in my system.
> > 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 states, or otherwise
> > the time of its publication.
> >
> > 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.
>
> I don't think this deals with dates properly. Consider this timeline:
>
> - At time T1 I publish this document: { Falsifian has 10 Coins }, and
> announce intent to ratify it without objection.
>
> - At time T2 I ratify it without objection.
>
> So, play proceeds as if { Falsifian has 10 Coins } is now true? Doesn't
> that mean my Coin balance is reset to 10, regardless of what happened
> between T1 and T2?
>
> That's not what we want, especially if { Falsifian has 10 Coins } is
> part of the Treasuror's self-ratifying weekly report, causing my Coin
> balance to reset to 10 seven days after publication.
>
> Did I miss something?
You did!
I moved the place where this is handled to the statement layer. The
statement you would ratify at T2 would be "The document X became true
and correct in all respects at its effective date." Ratifying a
document is shorthand for that statement (it's in my version of Rule
1551).
The advantage here is that I've removed all hypotheticals from the
ratification rule. Instead, the hypothetical is implied. What we're
doing is pretending that a statement is true. If it's a statement
about the past, we pretend the past was the way the statement
described. No nested virtual realities needed.
Incidentally, I'm still not entirely sure whether or not defining the
shorthand is helpful or not. It risks getting people too used to
relying on it rather than saying what they want. I'm open to
suggestions for making things clearer.
-Aris
