Not yet properly documented. Some rough points:
The pollwiki is the most important structural component in the network. It serves as a deployment container for several classes of function:
Note that function (1) is for the most part unique to the pollwiki and irreplaceable. The pollwiki is the only facility for this. Functions (2) and (3), on the other hand, are not unique. The pollwiki only provides a default UI onto its database and a default drafting medium. Other UIs may be layered atop the wiki or attached via the network, and other drafting media may be added via supports for free-range drafting. These structural freedoms are intended to absorb any forking tensions that might otherwise split the voterbase.
Note also that function (2) is poorly performed by the pollwiki. The wiki's integrated UI is of poor quality for any purpose aside from collaborative drafting (3). It may suffice as a default or temporary stop-gap for (2), but hopefully it will not be long before the users have better alternatives to choose from.
For a more information, including a running example of a pollwiki, see http://reluk.ca/w/Stuff:Pollwiki.
A deployment area is an administrative scope within which a set of voting facilities are independently installed, maintained and operated. The deployment area may correspond to a city, state or organization, or it may be defined in some other way by its administrator. There are no restrictions on the definition of deployment areas.
Every deployment area is associated with a single pollwiki. The administrator may choose to deploy a dedicated pollwiki, one that serves that area alone. In this case, the polls of the area are identified by separate pages in the wiki. The area itself (dotted lines in figure below) need not be formalized in the dedicated pollwiki, nor in any other facility of the core network. It is purely an administrative concept without technical representation.
Alternatively, the administator may create an area page within a multi-area pollwiki. In this case, the area is formalized as a top-level page of the wiki while its polls are formalized as subpages. The area name thus forms a part of each poll name and is therefore subject to the poll naming restrictions. Examples of area and poll pages within a multi-area pollwiki are Tor and Tor/p/grfin.
In stage 1 of the rollout, the administrator defines a new area within a multi-area pollwiki. The area's voters are automatically served by the pollwiki's associated cluster of servers. Ordinarilly all areas of the pollwiki (*) are served by a single instance of each server type (1), such as a particular project or vendor's model of vote server (model A is shown above). The area administrator has no privledged access either to the servers or to the pollwiki itself.
In stage 2, the administrator deploys an independent cluster of the most essential servers. Each server is configured to serve only the administrator's area in the multi-area pollwiki. The vote servers of the new cluster are configured for unidirectional mirroring of the votes originally cast within the old cluster (mirroring left to right, not shown).
In stage 3, the administrator deploys a dedicated pollwiki for the area. The area is then more-or-less independent of the previous voting facilities. It may continue to mirror the old votes for some time (not shown). The original area page and subpages need not be removed from the multi-area pollwiki. They may continue to be maintained by other administrators, and may spawn further independent areas in future.