The Formal STV Model of Computation

Everything is ready to formally present the small-step semantics discussed in Sec- tion 2.2.1. We only detail the sanity checks for three transitions, namely elect, transfer-elected and transfer-removed. This provides the reader with a clear pic- ture of the formalisation without exhausting them. In light of the discussion, it is

§3.3 The Formal Semantics 51

Figure 3.16: Sanity Check of Elect Transition

easy to construct the rest of the sanity checks from their mathematical formulation in section 2.2.1 for other transitions.

To keep the encoding tidy and avoid tedious proofs, we break the sanity check of each transition into two separate declarations. One of them encapsulates the appli- cability criteria of the transition and the other stipulates the progress constraints. As we explained in the previous chapter, the constraints which we define as the sanity check for a transition are the minimal conditions required from that transition to sat- isfy which appear in numerous STV algorithms. Minimality enables us to formally realised a larger class of STV algorithms in our system. It also pins down the core meaning behind each transition so that there is a universal semantics for them across various STV schemes. Therefore, the reader knows why we have these conditions in- stead of other ones as the semantics of the transitions. Nonetheless, we shall refer to some real STV algorithms to make the formalisation of the semantics more concrete at this stage. Later in the subsequent chapter, we dive into a deep discussion about how STV schemes such the Victoria STV and the ACT STV used for real elections fit into our system.

Figure 3.16 explains what it means for a given transition R to legitimately be an elect transition. SanityCheck_Elect_Appasserts thatRis legallyapplicableas an elect transition if and when the pre-state premiseon which it operates is an intermediate state for which the list of uncounted ballots are empty, there is (at least) one candidate c who has exceeded the quota, that candidate is among the continuing ones so that no one eliminated or already elected is chosen mistakenly as a winner, and the length of the list of elected candidates is less than empty seats cardinal so that by electingc we do not go above the initial vacancies of the election.

At this point, one may wonder how is it possible that some algorithm elects more candidates than there are vacancies? Is not restricting the elect transition by including conditions such aslength proj1_sig (e) + 1≤ stfictional? Not indeed and one shall never underestimate the catastrophe that under-specification can introduce. To give

an example, take an STV algorithm that uses the Droop quota. If a user decides to modify the formulation of the Droop quota and replace it with the following formula to obtain their favourite STV scheme, then there can be scenarios where one vacancy is left however there are more than one electable candidates to fill it.

number of valid ballots number of initial vacancies + 1

Note that the only difference between the above formula and Droop’s is that the latter increments the above fraction by 1. The difference may appear small at first glance. Nonetheless, the consequences of this seemingly minor modification can be significant. Note that our framework is designed to accommodate as many possible STV algorithms as there can be. Therefore, in our framework one is able to formalise such an STV scheme. Indeed our framework allows defining any quota that a user desires2. Because of such considerations, we build restrictions in the machine’s se- mantics to have control over insensible use of our means and ensure, for instance, that no formalised algorithm elects more than there are empty seats.

We elaborate further on some of the constraints in the SanityCheck_Elect_App. As you see in the figure, the applicability check asserts that there exists some can- didate c who satisfies such and such conditions one of which is having received at least as much as the quota of the election. Therefore, in our system electneverapplies unless the ones elected have reached or exceeded the quota. Moreover, the existential quantifier is not limiting us to capture the elect transition of STV algorithms such as Tasmania STV where all of the electable candidates are elected in one step.

SanityCheck_Elect_App does not inform us what happens when one applies the elect transition. It merely dictates existence of some post-state conc3. Sanity- Check_Elect_Redon the other hand declares the immediate consequences of apply- ing elect. It asserts that if and when a transitionRapplies as an elect transition, there must exist some pieces of data such that they form components of the premiseand

conclusionin such a way that both states are intermediate, some changemayhappen

to the empty list of uncounted ballots by this transition so that consequently there are ballots to deal with later, the tally remains the same which means every candi- date’s amount of attracted vote is not affected in this step. The pile, backlog, list of elected and list of continuing candidates are updated. SanityCheck_Elect_Redin- tendedly does not specify how exactly they are updated so that it allows instantiation of various ways of updating this information across the STV family.

Note that by "updated" we do not mean that the witness instantiated for the pieces of information in the post-state necessarily differ from the ones instantiated in the pre-state. It only means that their instantiation may differ depending on the STV algorithm with which one instantiates the machine and depending on how they decide doing it as we shall detail in the next chapter.

Furthermore,SanityCheck_Elect_Reddemands that the length of the elected can- didates e in the premise must be shorter than its counterpart ne in the conclusion.

2_{Recall that the quota is defined in the parameters modules as a generic variable of rational numbers’}

type. It can be substituted in the instantiation module with an arbitrary rational value.

§3.3 The Formal Semantics 53

Figure 3.17: Sanity Check of Transfer-elected Transition

Note that the constraint simply specifies a condition about the length rather than the content of these lists. The reason is variance across the STV family in how they treat electable candidates. As mentioned, some of them may elect only one electable per- son while some others elect all of them in the same application of the elect transition. But one core aspect of the elect transition in STV is the universal fact that the length of these entities varies according toSanityCheck_Elect_Red.

The sanity check for the transfer-elected transition determines what it means for a given transition R to be legally applicable as a correct instance of transferring votes of some elected candidates (figure 3.17). SanityCheck_TransferElected_App

specifies that in order to apply Ras a transfer-elect transition, thepremiseshould be an intermediate state where there are neither uncounted ballots left to deal with nor there are any votes from eliminated candidates awaiting transfer. Moreover, there must be someone already elected whose votes can be transferred (fst(bl) 6= [])) and some vacancies still remain to fill. Then there exists a post-state concto which the machine moves by applyingR.

SanityCheck_TransferElected_Red lays down the reducibility criteria of applying R. The pre-statepremise must be an intermediate state where the list of uncounted ballots and the list of already eliminated candidates whose votes awaits transfer are empty. By moving to the post-stateconclusionwhich is also an intermediate state, the list of the uncounted ballots, pile, and the list of candidates whose surplus should still be transferred (bl1) are updated in such a way that the length of bl1 reduces. Again, the exact mechanism of updating the information is not a concern at this point but only meeting the conditions ofSanityCheck_TransferElected_Redis. Other pieces of data such as tally remain the same.

Figure 3.18: Semantics of the Transfer-removed Transition

reader must already know how to read the definitions, we do not comment any further on the sanity check declarations.

We define the generic STV machine (figure 3.19) as a record of generic transition labels and evidence that each of the labels satisfies the conditions of the relevant applicability and reducibility sanity checks. We choose to formalise the transitions as generic labels so that our formalisation can extend to a broader class of STV al- gorithms. But the generic transitions in and by themselves do not specify anything pertinent to STV. We therefore include the evidence of the correctness of the labels with respect to the small-step semantics in the record as well to obtain what repre- sents the generic STV algorithm discussed in the previous chapter.

Including evidence for the correctness of the transition labels in turn results in proof automation. Whenever one wants to instantiate theSTV, which is the generic machine, the generic transitions need to be instantiated with specific transitions of some concrete STV counting mechanism and then proof obligations are required to be discharged so that the instantiation is verified as a true instance of the STV. Once the instantiation is successfully carried out, the instance automatically inherits properties established for the machine.

Finally, instantiation into the machine enables designing the system modularly in the manner discussed earlier in this chapter. We can perform instantiation in separate modules so that (a) each module only deals with specification and verification of a specific STV algorithm, (b) each extracted program only includes codes related to one single STV rather than several ones in one extracted module and (c) if instantiation of one module fails due to lack of enough proofs from users side, other successful instantiations can be extracted into executable programs without any problem.