Agora Wiki

Agora Nomic's wiki. Learn more at

Note that due to elements of code in this essay it is reproduced in PRE format.

A Completely Formal Nomic

Submitted in partial fulfilment of the
requirements for the degree of Bachelor
of Nomic.  This Thesis is associated with
the recent Proposal "A B.N. for favor".

Player Favor, Agora Nomic


Historically, many of the scams and CFJs in Agora Nomic
have hinged on matters of word-meaning.  Everyday language
is notoriously ambiguous and dependant on assumptions
about speaker and listener intent that are not logically
well-founded; they require the application of what is
often called "common sense" (a loose and imperfectly-shared
collecion of default assumptions, word-usage rules, and so on).

The Rules and Customs of Agora Nomic have historically
had an ambivalent attitude towards common sense.  Judges
have sometimes been allowed or required to exercise it
when the Rules are not clear.  Some Players have cited the
imperfect consensus on matters of common sense in borderline
cases, and tried to reduce or eliminate the Rules' dependence
on it.

CFJs and scams based on word usage are welcomed and relished
by some Players, and despised by others.  Some have accused
the community of making scams impossible by encouraging
Judges to block them by quibbles on word meaning; others
have claimed that without such quibbles, most scams would
be impossible in the first place.

It would be illuminating to consider what a Nomic game
might be like that was wholely lacking in disputes and
disagreements about word usage and meaning, or about
common sense or other broad subjective notions.  Such
a game would be interesting by virtue of the contrasting
light it would throw on Agora and similar Nomics, as well
as potentially leading to interesting games in its own right.


The idea is to design a completely formal Game, one in which
there are no rules that have subjective components, or are
otherwise open to disputes about common sense or the
meanings of words.  The game should also be as Nomic-like
as possible, given that restriction, in that the rules of
the game should be represented within, and changeable by
moves of, the game.

This will *not* be "real" Nomic unless we are wildly more
successful than I think we will be.  Because we have to
choose a comparatively simple formal framework (in order
to keep it comprehensible), it's unlikely that we'll
be able to get as "meta" as non-formal Nomic can get.
It will also, of course, not have the fun of Judgement
and dispute about word meanings and intent and sense
and reference and all that that most Nomics offer.  This
is intended to be a *different* game, albeit somewhat
inspired by the usual Nomic.  But there's no claim that it's
better than any other Nomic, or truer to any particular ideal,
or anything like that.

There will, of course, have to be an interface between
the formal system in which the rules sit and the players,
who are out in the physical world.  This interface will be
referred to as the Mechanics of the game, and these will
be subject to all sorts of disputes and things.  But they
are *not* part of the game itself; any issues that come up
about the Mechanics ("I didn't make that move; someone must
have forged the e-mail!") will be extra-game issues, and
will not be expressed or resolved in the gamestate.

Similarly, the language in which the game is expressed will
be subject to change (and in particular to expansion) as
the game goes on, but this again is an extra-game process.
As new verbs or conditions or whatever are added to the
language, we will just have discovered new parts of the
formal space that the game is exploring.  The status of
the language of the game is not contained in the game
itself.  This is another limitation that nonformal Nomic
does not, at least in theory, suffer from.  I suspect,
however, that a strong case could be made for the claim
that any nonformal Nomic played by humans will in fact
be subject to the same sort of limitation, in that humans,
being finite entities instantiated in a limited universe,
cannot ultimately escape all bounds of language themselves.

Relationship to Agora Nomic

Formal Nomic can serve Agora Nomic as a thought-pump, if
nothing else.  If some actual or contemplated feature of
Agora Nomic would be especially hard or easy to add to
a hypothetical game of Formal Nomic, or would require
diddling with the Mechanics, that says something about
the nature of the feature.  If two apparently-similar
ways of embodying within Agora the same basic idea turn
out to have very different implications for a hypothetical
game of Formal Nomic, that says something about the
differences between them.

Formal Nomic might also be a useful, or instructive,
or amusing subgame (probably a Contest) within Agora
Nomic.  One Player would implement (either automatically,
or by hand) the Mechanics, and choose an Initial Set;
the other Players in the jurisdiction of the subgame
would submit input to the Mechanics, changing the state
of the subgame.  Winning the subgame could mean being
awarded the subgame's Treasury, or whatever.

Details / Examples

The rest of this paper consists of a worked-out example
of one completely formal Nomic, including a description
of the mechanics, and an Inital Set (that is, an initial
object-pool).  It is of course only one example; the
basic objective could be accomplished in many other
ways.  For instance, if all the Players were willing
to be computer programmers, the ruleset and gamestate
could be expressed directly as computer program texts
and variable values, at a considerable increase in power,
and a considerable cost in difficulty of play.

For this example, the incoming interface is relatively
simple: when a piece of mail comes in for the "server",
it's parsed into one or more objects in the system.
Each object has a Type of "move", a Sender and Timestamp
filled in from the envelope, a randomly-generated BatchNumber
that's the same for all the objects created by the same piece
of mail, and other fields filled in from the body of the
message.  For instance, a request to register might look like:

   From: Matt Zimola <[email protected]>
   Date: 14 Aug 1995, 12:36:13 UTC
   Subject: to the Mech server


and the corresponding object that gets created might be:

   objectId: 127
   batchId: 114
   moveTimeStamp: 1995/08/14 12:36:13
   moveSender: [email protected]
   type: move
   subtype: register
   nickname: MattZ

"REGISTER MattZ" is syntactic sugar, to make a common operation
easier.  In its full generality, the incoming Mechanics would
allow the sender of the mail to specify any attributes and values
e wants to (except type, objectId, batchId, and so on).

On the other end, there will be a small set of verbs that
cause extra-game side-effects; primarily mail-sending to let the
physical-world players know what's going on.  But these side-effects
are not defined in or modifiable by the game rules; they are
the Mechanics, not the Rules.  From the point of view of the
game-state itself, the sendFoo() verbs will be no-ops.

A rule is just another object, with Type "rule", an "if"
attribute which is some boolean function of the gamestate,
and a "then" attribute which is some sequence of verbs.
It also has a ruleOrder, to determine which rules get to
look at the game-state first, and probably various other
housekeeping numbers.  (More generally, we can have a
special engineSettings object which would tell the engine
which type of objects are really rules; that would normally
be set to "rule", but could be diddled with for various
special effects.)

The sequence of events in the game is as follows.  Note that
this is again a thing that isn't part of, or changable by,
the Rules, and this is another un-Nomic-like limitation.
It may be possible to make some or all of this stuff adjustable
within the game also, with some effort.  (Note that that effort
would have to be done outside the game, in the Mechanics, to
enable laters efforts within the game.)

  - Something happens: either a new object arrives from the
    physical world via the incoming interface, or a rule
    suddenly fires due to a schedule pop.

  - For each object of Type "rule" in the gamestate, in order
    of ruleOrder, the value of the "if" attribute is
    evaluated.  If the result if "false", we proceed to the
    next "rule" object.  If the result is "true", the verbs in the
    "then" attribute fire, creating or deleting or modifying or
    scheduling objects; then we restart this "for" loop, back at
    the rule with the highest (lowest-numbered) PrecendenceNumber.
    (If a rule fires, but the "then" clause does *not* change
    the game-state, we don't restart.)

  - Once the highest-ruleOrder rule has had its "if" part
    evaluate to "false", we go to sleep again until the next
    thing happens.

There are all sorts of "programming" issues involved in making these
things actually work.  When a rule fires and changes the game-state,
for instance, it will almost always have to make sure that the change
it makes is such that it won't fire again for the same reasons, since
its change will cause a restart, and if no rule with a lower ruleOrder
fires, it will see the game-state again just the way it left it.  So
for instance a rule that gives a player a point because of some
condition should make sure to also make the condition false, otherwise
it may give the player an infinite number of points, one at a time!
(Another aspect of the Mechanics will presumably be an extra-Game
meta-rule like "if the game-state goes into a verifiable loop,
the last player to submit a move wins".)

One way to manage this is to have a rule simply delete the object
that caused it to fire; this is sensible in some cases, although it
will often be better to simply mark it in some way (set the
processedByRule47 attribute to T, for instance), rather than deleting
it, so that other rules with higher ruleOrders will get a chance
to act on it as well.

Below is a sample Initial State.  It includes registration (but not
deregistration or On Hold), proposals (which may contain multiple
Rule Changes), voting (but not multiple votes, or changing votes),
quorum, simple majority (AIs and MIs are quite doable, but are not
in this Initial State), points for voting and having your proposals
pass, and a simple Win on points (which ends the game).  Kudos,
degrees, Win Tokens, Extra Votes, the Potato, and some other familiar
Agora concepts would fit into this set in reasonably simple ways.

Some other concepts are much harder; for instance, the idea
of sub-rulesets that only apply to some Players, as in Group
Ordinances and Contest Regulations.  Platonic sub-rules are
especially hard to formalize.  For instance, if a Group
Ordinance says that in some circumstances a Group Member
shall transfer fifteen Marks to a non-Member, that's
acceptable.  If it says the opposite, that some non-Member
shall transfer fifteen Marks to some Member, that isn't.
In both cases, both a Member and non-Member appear in the
subrule; formalizing the difference between the two is a
subject for further study.

I haven't actually *implemented* any of this as a computer program,
and I'm not sure that I have any interest in doing so.  But I hope
it will spur some interesting discussion nonetheless...

A note on scams: an amusing proof that scams are entirely
possible in this formal Nomic.  In the first draft of this Initial
State, Rule 16 didn't set the "cleanup" attribute of incoming votes
to F.  So if you submitted a vote, and set "cleanup" to T in the
move object, you'd get your point for voting, but the vote would
be destroyed by the Sweeper, so you could do it again.  And again.
And again.  Getting a point each time, and winning at will.  Easy
to fix, but illustrative!  (In the very first version of Rule 16,
it didn't even have the check to ensure that the proposal ID was
valid, making it easy to win by voting for a hundred non-existent


Basic attributes of objects:
  objectId - a number, used as a handle for talking
     about an object, assigned sequentially by the system
     when the object is created.  Match clauses always
     find the matching object with the lowest objectId.
  type - tells what it is; the incoming interface produces only
     objects of type "move".  The rule engine gets its settings
     from the first objects of type "engineControls", and
     runs only objects whose type is the same as the runType
     attribute of engineControls. All other types have meaning only to
     rules.  A basic type in the initial set is "player".

Move attributes set by the incoming interface (these attributes
are always assigned; any and all other attributes besides Type
can be set by the incoming mail explicitly):
  moveSender - [email protected] that sent the mail
  moveTimeStamp - yyyymmddhhmmss (a time-format string), from
     the date: line of the mail
  moveBatch - a contentless id assigned to all the "move"
     objects that come in in the same piece of mail (for
     batching up multiple Rule Changes into a single proposal,
Except for these three, and type (which is always "move"), the
sender of the mail can control all the attributes of the move object.
Syntactic sugar of various kinds will presumably be provided for
common cases.

Rule attributes used by the engine:
  ruleOrder - rules are run in order of ruleOrder, lowest to highest.
  if - condition tested when a rule is run.
  then - verbs executed when an if is true; if this causes any
     change to the existing objects (creation, deletion,
     amendment), the ruleset is restarted.

Some verbs:
  delete(match) - deletes the matching object (with the lowest
     objectId, as usual)
  create(match) - creates a matching object
  set(match1)(match2) - Changes the object matching match1 so
     that it matches match2.
  send([email protected][....])(expression) - queues up the value
     of the expression for sending to [email protected] (or list thereof).
  sendObject([email protected][...])(match)(string) - queues up a
     print form of the matching object, with the string for a
     header, for sending.
  sendNow() - actually sends all queued stuff off.

Some functions for use in expressions:
  timeGE(timevalue) - Tests if the current time is >= the given
     time.  Used for timers.  A possible engine optimization:
     duing each pass, keep track of the lowest-value timeGE
     that fails; set an actual timer to re-check all rules
     at that time, if nothing else has happened in the meantime.

  - Some sort of "for" clause in rules may be needed for performance
    and clarity reasons.  Otherwise, the only way to do something
    like sending the entire ruleset to a player in response to a
    query move would be to do passes through the
    first part of the ruleset, using some kludged-up bookkeeping
    attribute or object to keep track of which rules we haven't
    sent yet.  Maybe that's OK?
  - Perhaps allow a rule to say that the engine *shouldn't* restart
    the ruleset after processing it?  That, instead, it should just
    test the rule itself again, and then proceed onwards?
  - A more radical change to this model would be to have all
    object-changes take place in a second, "shadow", copy of
    the object-pool, and switch over to that object-pool only
    when no rule in the current pool wants to make any changes.
    Could be an engineControls switch?
  - Probably be good to have a setall(match1)(match2), that would
    efficiently set all objects matching match1 to match match2.

An Intial State

Loose conventions about ruleOrder:

  We will use ruleOrder 10000-19999 for rules that don't delete
  the object that sets them off (although they may set some
  attributes so that it doesn't set them off again).

  We will use ruleOrder 30000-39999 for rules that do delete, or
  otherwise make very significant changes (like changes of type)
  to the object that sets them off.

  We will use ruleOrder 99000-99999 for rules that should basically
  only run for cleanup-type reasons at the very end of an event.

Initial engine settings and (empty) player-list:

  objectId: 1
  type: engineSettings
  runType: rule

  objectId: 2
  type: playerList
  listContents: ""

Rules about registration:

 objectId: 3
 ruleOrder: 30010
 type: rule
 if: exists(type=="move" & subtype=="register" & moveSender==%s &
            nickname!="" & nickname==%n & moveTimeStamp==%tm & objectId==%mo) &
     !exists(type=="player" & nickname==%n) &
     exists(type=="playerList" & listContent==%pl)
 then: create(type=="player" & defaultEmail==%s & nickname==%n &
              registeredAt==%tm & score==0 & objectId==%po) &
       set(objectId==%mo)(processed==T & cleanup==T) &
       create(type=="newPlayer" & reference==%po & cleanup==T) &
       send(%pl,"New player" %n "registered at" %tm) &
       send(%s,"Welcome to Engine City," %n"!")
 comment: "if someone's registering, and e gave a nickname that
           isn't already in use, create a proxy object for em with
           their information, note that the move was processed for
           later cleanup, and create a newPlayer object for other
           rules to process.  Also tell everyone."

 objectId: 4
 ruleOrder: 30020
 type: rule
 if: exists(type=="move" & subtype=="register" & processed!=T &
            moveSender==%s & nickname!="" & nickname==%n & objectId==%mo) &
     exists(type=="player" & nickname==%n)
 then: sendObject(%s)(objectId==%mo)("A player" %n "is already registered") &
 comment: "handle error case where someone tries to register with a
           name that's already in use."

 objectId: 5
 ruleOrder: 30030
 type: rule
 if: exists(type=="move" & subtype=="register" & moveSender==%s &
            nickname=="" & objectId==%mo) &
 then: sendObject(%s)(objectId==%mo)("You have to give a nickname when you
       register") & delete(objectId==%mo)
 comment: "handle error case where someone tries to register without
           a name."

 objectId: 6
 ruleOrder: 30040
 type: rule
 if: exists(type=="move" & from=="" & moveSender==%s & objectId==%o) &
     exists(type=="player" & defaultEmail==%s & nickname==%n)
 then: set(objectId==%o)(from==%n)
 comment: "if no from is given on a move, guess from the email address"

 objectId: 7
 ruleOrder: 30050
 type: rule
 if: exists(type=="move" & from==%f & moveSender==%s & objectId==%mo) &
     !exists(type=="player" & nickname==%f)
 then: sendObject(%s)(objectId==%mo)("You are no known player.") &

 objectId: 8
 ruleOrder: 30060
 type: rule
 if: exists(type=="newPlayer" & listed!=T & defaultEmail==%e &
            objectId==%po) &
     exists(type=="playerList" & listContent==%l & objectId==%lo)
 then: set(objectId==%po)(listed==T) &
       set(objectId==%lo)(listContent==%l %e)
 comment: "Maintain a list of all player email addresses, for
           mass sendings"

A simple Win rule:

  objectId: 9
  ruleOrder: 10010
  type: rule
  if: exists(type=="player" & score>100 & nickname==%n & objectId==%o) &
      !exists(type=="win" & who==%o) &
      exists(type=="playerList" & listContent==%pl)
  then: create(type=="win" & who==%o) &
        send(%pl,%n "wins the game!")
  comment: "if a player has over 100 points, e wins"

  objectId: 10
  ruleOrder: 10020
  type: rule
  if: exists(type=="win")
  then: halt()
  comment: "the game ends when one or more players win"

Rules about Proposing:

  objectId: 11
  ruleOrder: 30120
  type: rule
  if: exists(type=="move" & subtype=="ruleChange" &
            ruleChangeType=="repeal" & target==%t &
            batchid==%b & objectId==%mo) &
      exists(objectId==%to & type=="rule")
  then: set(objectId==%mo)(type="changeBeingVotedOn")
  comment: "snarf in an incoming repeal rule change; we'll
     let ones that attempt to repeal a non-existing rule just
     fall through to the general error handler at first."

  objectId: 12
  ruleOrder: 30130
  type: rule
  if: exists(type=="move" & subtype=="ruleChange" &
            ruleChangeType=="amend" & target==%t &
            batchid==%b & objectId==%mo) &
      exists(objectId==%to & type=="rule")
  then: set(objectId==%mo)(type="changeBeingVotedOn")
  comment: "snarf in an incoming amendment rule change"

  objectId: 13
  ruleOrder: 30140
  type: rule
  if: exists(type=="move" & subtype=="ruleChange" &
            ruleChangeType=="create" & target==%t &
            batchid==%b & objectId==%mo)
  then: set(objectId==%mo)(type="changeBeingVotedOn")
  comment: "snarf in an incoming create rule change"

  objectId: 14
  ruleOrder: 30150
  type: rule
  if: exists(type=="changeBeingVotedOn" & sent!=T & batchId==%b &
            objectId==%o) &
      exists(type=="playerList" & listContent==%pl)
  then: sendObject(%pl,%o,"Proposed rule-change (proposal" %b"):") &
  comment: "Tell all players about new proposals"

  objectId: 15
  ruleOrder: 30160
  type: rule
  if: exists(type="changeBeingVotedOn" & batchid==%b) &
      !exists(type=="voteInProgress" & propId==%b)
  then: create(type=="voteInProgress" & propId==%b) &
  comment: "Creates the voting object representing a pending Proposal"

Rules about Voting:

  objectId: 16
  ruleOrder: 30220
  type: rule
  if: exists(type=="move" & subtype=="vote" & propID==%p &
        from==%f & objectId==%o) &
      exists(type=="player" & nickname==%f) &
      exists(type="voteInProgress" & propId==%b) &
      !exists(type=="vote" & propID==%p & from==%f)
  then: set(objectId==%o)(type=="vote" & credited==F & cleanup==F)
  comment: "One Player, one unchangable vote per proposal"

  objectId: 17
  ruleOrder: 30230
  type: rule
  if: exists(type=="vote" & from==%f & credited==F & objectId==%vo) &
      exists(type=="player" & nickname==%f & score==%s & objectId==%po)
  then: set(objectId==%po)(score==1+%s) &
  comment: "One Point when you vote"

The End of the Voting Period:

  objectId: 18
  ruleOrder: 30320
  type: rule
  if: exists(type=="voteInProgress" & timeGE(expiryTime) &
  then: set(%o)(type="voteCompleted")

  objectId: 19
  ruleOrder: 30330
  type: rule
  if: exists(type=="voteCompleted" & propId==%p) &
      exists(type=="vote" & propId==%p & from==%f & vote==%vc &
            noted!=T & objectId==%vo) &
      exists(type=="playerList" & listContent==%pl)
  then: set(objectId==%vo)(noted==T) &
        send(%pl,"Player" %f "receives one point for voting" %vc "on" %p)
  comment: "Announce content of votes"

Tallying Votes:

  objectId: 20
  ruleOrder: 30420
  type: rule
  if: exists(type=="voteCompleted" & objectId==%o & propId==%p &
            objectId==%o) &
      count(type=="vote" & propId==%p)<(count(type=="player")/4) &
      exists(type=="playerList" & listContent==%pl)
  then: set(objectId==%o)(type="proposalFailed" & cleanup==T) &
        send(%pl,"Proposal" %p "fails quorum.")

  objectId: 21
  ruleOrder: 30430
  type: rule
  if: exists(type=="voteCompleted" & objectId==%o & propId==%p &
            objectId==%o) &
      count(type=="vote" & propId==%p & vote=="FOR")>
      count(type=="vote" & propId==%p & vote=="AGAINST") &
      exists(type=="playerList" & listContent==%pl)
  then: set(objectId==%o)(type="proposalPassed" & credited==F) &
        send(%pl,"Proposal" %p "passes.")

  objectId: 22
  ruleOrder: 30440
  type: rule
  if: exists(type=="voteCompleted" & objectId==%o & propId==%p &
            objectId==%o) &
      count(type=="vote" & propId==%p & vote=="FOR")<=
      count(type=="vote" & propId==%p & vote=="AGAINST") &
      exists(type=="playerList" & listContent==%pl)
  then: set(objectId==%o)(type="proposalFailed" & cleanup==T) &
        send(%pl,"Proposal" %p "fails.")

  objectId: 23
  ruleOrder: 30450
  type: rule
  if: exists(type="proposalPassed" & from==%f & credited==F &
            objectId==%pro) &
      exists(type=="player" & nickname==%f & score==%s & objectId==%plo) &
      exists(type=="playerList" & listContent==%pl)
  then: set(objectId==%pro)(credited==T) &
        set(objectId==%plo)(score==5+%s) &
        send(%pl,%f "receives 5 points for the proposal ("5+%s")")
  comment: "Five points when your proposal passes."

Implementing passed rulechanges:

  objectId: 24
  ruleOrder: 30520
  type: rule
  if: exists(type="proposalPasssed" & propId==%b) &
      exists(type="changeBeingVotedOn" & batchId==%b & objectId==%o)
  then: set(objectId==%o)(type=="changePassed")

  objectId: 25
  ruleOrder: 30530
  type: rule
  if: exists(type=="changePassed" & ruleChangeType=="repeal" &
            target==%t & objectId==%o)
  then: delete(objectId==%t) &
        set(%o)(type=="changeDone" & cleanup==T)

  objectId: 26
  ruleOrder: 30540
  type: rule
  if: exists(type=="changePassed" & ruleChangeType=="amend" &
            target==%t & newif==%ni & newthen==%nt & neworder==%no &
  then: set(objectId==%o)(if==%ni & then==%nt & ruleOrder==&no) &
        set(%o)(type=="changeDone" & cleanup==T)

  objectId: 27
  ruleOrder: 30550
  type: rule
  if: exists(type=="changePassed" & ruleChangeType=="create" &
            newif==%ni & newthen==%nt & neworder==%no &
  then: create(type=="rule" & if==%ni & then==%nt & ruleOrder==&no) &
        set(%o)(type=="changeDone" & cleanup==T)

Cleanup Rules:

 objectId: 28
 ruleOrder: 99910
 type: rule
 if: exists(type=="proposalFailed" & propId==%p) &
     exists(type=="changeBeingVotedOn" & batchId==%p & objectId==%o)
 then: delete(objectId==%o)

 objectId: 29
 ruleOrder: 99920
 type: rule
 if: exists(type=="proposalFailed" & propId==%p) &
     exists(type=="vote" & batchId==%p & objectId==%o)
 then: delete(objecId==%o)

 objectId: 30
 ruleOrder: 99930
 type: rule
 if: exists(type=="proposalPassed" & propId==%p) &
     exists(type=="vote" & batchId==%p & objectId==%o)
 then: delete(objectId==%o)

 objectId: 31
 ruleOrder: 99940
 type: rule
 if: exists(type=="move" & processed!=T & objectId==%o &
 then: sendObject(%ms)(objectId==%o)("This move didn't do anything") &
 comment: "If an unprocessed move is hanging around, delete it,
           and send a warning to the sender."

 objectId: 32
 ruleOrder: 99980
 type: rule
 if: exists(cleanup==T & objectId==%o)
 then: delete(objectId==%o)
 comment: "the Final Sweeper"

 objectId: 33
 ruleOrder: 99990
 type: rule
 if: T
 then: sendNow()
 comment: "Send out accumulated mailings" </[email protected]>