Master Development Plan

From OSDVwiki

Contents 1 Introduction 1.1 Scope 1.2 Background on OSDV 1.3 Related Documents 2 Architecture Overview 3 OARS 3.1 System Overview 3.2 System Architecture Overview 3.3 Basic Issues 3.4 Projects 3.5 Prototype 4 OASES 4.1 System Overview 4.1.1 Key Concepts 4.1.2 Benefits 4.2 OASES System Architecture Overview 4.2.1 OASES System Architecture 4.2.2 OASES Component Architecture: SHARP 4.2.3 OASES Component Data-Flow 4.2.4 OASES Component Data Transport 4.3 Basic Issues 4.4 Prototype 4.5 Projects

[edit] Introduction

[edit] Scope

This master development plan provides a high-level to medium-level view of technology development activities at Open Source Digital Voting (OSDV), together with some background information included in this introduction section.

The plan consists of a description of a set of development projects that together will create much of OSDV’s technology deliverables. The project descriptions are based on preceding description of high-level system architecture and component-level architecture. The architecture descriptions intentionally brief, with further information provided by reference.

[edit] Background on OSDV

OSDV: What and Why

OSDV is building open-source technology for elections. This major component of OSDV activity supports OSDV’s mission: is to dramatically increase public trust in the computing technology that is used to conduct elections in the U.S., thereby increasing public confidence in election processes and results.

As to why we’re doing this, and why it will ultimately support that mission, there is more information in the OSDV Operations and Strategy Summary on the mission, rationale, goals, objectives, and methodology. The very short summary is that we’re making an open-source substitute for the proprietary e-voting and elections technology that has defects of many kinds, including many that undermine public trust in U.S. elections.

Primary Activities

OSDV’s fundamental technology deliverables are:

• a digital voter registration system and an election system (both defined below),
• draft standard public data interchange definitions, and
• system and software specifications and related tools for demonstrating and enabling feasible evaluation and certification (about which more is said in the Strategy Summary).

To create these deliverables, OSDV’s primary technology and developmental activities are:

• Software development,
  • performed using a public and open development process, with records freely available for public inspection, and
  • performed specifically to create software and systems with high assurance of public confidence factors such as integrity, security, reliability, etc.
  • Definition of hardware and software specifications
  • Publication of specifications and software source code, freely available for public inspection and use.
• Developing and demonstrating a public and open process for
  • repeatable, standards-based testing and evaluation of election systems,
  • including evaluation of assurance factors,
  • with all evaluation records freely available for public inspection.

This development plan focuses mainly on the description of software and systems development.

[edit] Related Documents

The OSDV Operations Strategy document provides full explanation of mission, goals, objectives, operational activities and steps, plans for implementation of them, and a sketch of the pro forma operating plan.i The Operations Summary provides a shorter form of similar materal.

The OASES System/Segment Specification document provides a more comprehensive specification of each of the components of OASES.

The VoteCal RFP (particularly sections 3 and 6) provide complete functional requirements for OARS.

[edit] Architecture Overview

This section provides an overview of the technical architecture for OSDV's development work. For more information, see OSDV Technical Architecture.

Top-Level Architecture

The top-level architecture features two distinct systems, standards-based data interchange between them, and standards-based data externalization for Web publication. The two systems are OARS and OASES, described below. The data standards are EML and EAML. EML(Election Markup Language) is an existing standard XML schema for standard representation of election-related data. EAML (Election Audit Markup Language) is new schema used for the externalization function of OARS and OASES. Externalization is a critical function of OARS and OASES, which enable a substantial degree of public transparency and accountability by:

• logging every transaction performed in each system, and
• externalizing the log data for Web publication,
• so that members of the public have access to searchable, importable, complete data documenting how a particular election was conducted.

As a result, the definition of EAML and the demonstration of its use will both be critical parts of the development plan.

The Top-Level Architecture of OSDV Technical Deliverables diagram

shows how these 4 top-level components interact. OASES and OARS interoperate by means of EML+, and both externalize information in EAML, which can be published to the Web for public access.

System Architecture

OARS and OASES are separate systems. The system architecture for each is summarized below, and described in more detail in the OSDV Technical Architecture.

[edit] OARS

[edit] System Overview

OARS (Open Auditable voter Registration System) is a digital voter registration system (DVRS) designed to meet U.S. Federal regulations and state-level requirements. Regulations are derived from the HAVA legislation that requires states to operate a state-wide definitive DVRS. State-level requirements can vary, but OARS’ requirements are driven from the very clear and specific California state requirements for the VoteCal system.

The general idea of a state DVRS is that a state agency (e.g. office of Secretary of State, or Board of Elections) manages the voter registration records for the entire state, storing the records in a VR database, and operating software and systems that provide access to the information in the VR DB. County or municipal elections agencies are clients of the DVRS service provided by the state. Some of the general roles and actions are as follows.

• The state agency manages the VR DB itself, and interconnections to other databases and sources of relevant information, such as DMV, Tax Board, deceased persons registry, Department of Corrections, etc.

• The county agencies access the VR data via a DB-backed Web-based application, using a private network.

• County staff use the Web application to perform transactions for update VR records for changes to county voters’ record (e.g. change of address or party affiliation), updates to existing records (to record participation in elections), and to create new records for newly registered voters.

• County staff also download the entire county’s VR records as an important information source for preparing for elections.

• State agency staff may be involved in some transactions as well, for example, a change of address from one county to another, a state-originated change in status (invalidation due to felony conviction), and resolution of problematic registration requests that involve information from other state agencies, e.g. DMV.

Some of the intended benefits of OARS, as an open system, are transparency, standards, and cost savings. Cost savings occur because the vast majority of DVRS requirements are state-independent; rather than each state doing its own large procurement (perhaps on the order of $30 million), a state can freely use OARS, and procure extension for state-specific requirements that have not already been created for other states. Standards benefits arise from multiple OARS implementations using a common, public draft standard for representing VR data and for representing records of transactions on the DVRS, changes to records, etc. Transparency and accountability benefits arise form the ability to publish, for access by the general public, transaction logs that record changes to the VR DB (e.g., who changed what VR records, how, and why) and other actions of interest. Use of a standard data format enables Web publication, data aggregation, and comparison between states’ management of their DVRSs.

[edit] System Architecture Overview

OARS architecture is that of a typical database-backed Web application for transaction processing. Client use a Web browser to access the Web application that implements a set of transactions on the VR DB itself, as well as support function such authentication, authorization, user management, logging, auditing, and reporting. The Web application is build on a typical open-source software stack for DB-backed web applications, e.g., Apache, Rails, MySQL. Embedded with this application framework are OARS application logic (for transactions on the VR DB, plus logic for support function, logging, etc.) and the OARS database itself, based on the OARS schema for VR records, transaction-related records, support function records, and log records.

One additional architectural point to note in the OARS Architecture diagram

is the use of a browser to use the DVRS’s Web application. Certainly this could be performed by any common Web browser software on existing county officials’ workstations. However, another element of OSDV’s technical architecture could be used, the Limited Open Browser Appliance (LOBE), described below.

[edit] Basic Issues

There are few other fundamental issues for OARS development. The VoteCal RFP enables the specification of a complete set of requirements, and OARS itself is a fairly straightforward DB-backed Web application. However, there are a couple elements worthy of note that distinguish OARS from a typical DB-backed Web application.

One distinguishing feature is the development of part of EAML (Election Audit Markup Language) to be sufficiently expressive to record the all various transactions and management operations of a DVRS, in sufficient detail to provide transparency benefits, but with sufficient flexibility to adapt to various information privacy models. A related feature is the use of XML to specify EAML, to enable straightforward XML-HTML publishing, and XML-based data import for data mining.

Another distinguishing feature is the option to use LOBE (Limited Open Browser Appliance). While the notion of an embedded browser appliance is not terribly innovative, it would be very useful for isolating a DVRS from existing county IT systems (or indeed any other system) if desired for reasons of security or reliability. There are multiple worked example of browser-based kiosk systems, and LOBE can be based in part on some of the same core technology, such as Firefox/XULRunner, an open-source toolkit for building and embedding browser functionality in applications and systems. However, unlike these worked examples, LOBE’s architecture shares some of the elements (such boot image and run-time integrity) of the operating system and platform as all of the components of OASES.

In addition to development activities, there are important outreach activities that are needed to ensure that OARS is developed effectively to meet real world requirements. Regarding effective development, outreach within the open-source browser community is required to ensure that LOBE can effectively leverage existing work. Regarding real world relevance, one important form of outreach is to state secretaries of state, boards of election, and thought-leader counties, for requirements and feedback into a consultative iterative development cycle. A related form of collaboration is with state secretaries of state, on the issues of DVRS deployment and operation. In creating OARS, we need ensure that it meets states’ requirements for the actual IT environment for deployment and management. However, it is important to note that OSDV is developing OARS in order to make it available to states for deployment. It is a state’s responsibility to deploy and use a DVRS, and indeed that is what a state should be paying for, rather than paying for custom development of a DVRS.

[edit] Projects

The following the current list of distinct projects of efforts to be performed in the development of OARS:

• The OARS prototype project described in below, including the demonstration result of a prototype OARS system available via OSDV’s Web presence.

• The LOBE prototype project, which boils down to using Firefox/XULrunner to build an “embedded browser” on the Linux distribution that’s the basis for SHARP. The embedding is essentially embedding in init so that the browser is the only application software running on the system. One demonstration-oriented result of the project is live CD image that is pre-configured to work with a the Internet demo version of the OARS prototype Other results are oriented to later-phase projects, such as a list of minimization, simplification, or packaging tasks needed to create a complete LOBE system.

• OARS Phase 1 project, focused on defining a reasonably complete VR DB schema and a corresponding set of transactions needed to meet the functional requirements derived from VoteCal. The main results are these specifications, the software that implements the transactions, an instance of the complete software stack packaged as a live CD distribution. Some efforts at EAML are part of the scope and the results.

• Virtual State project, which centers on a mock DVRS implemented with OARS, and public experimental use of it. The main results are feedback from state and county officials that will be needed to complete a satisfactory OARS system. This project can run concurrently with other efforts.

• Final LOBE project, which is the completion of the tasks planned in the prototype phase, making a simple LOBE system that supports all and only the browser/server functional requirements of OARS Phase 1.

• OARS Phase 2, which is to complete the implementation, documentation, and packaging OARS, with notable tasks including complete specification and implementation of EAML, and implementation of the external data interchange functions.

[edit] Prototype

The OARS prototype project is a rapid-prototyping effort to quickly get to a demonstrable proof-of-concept system, but is not an effort of throw-away development. The goal for the OARS P1 system is to specify and implement and small but significant subset of the transactions of a complete DVRS as envisioned by the VoteCal RFP.

The significance of the subset is that includes the transactions that are readily understandable to the general public, and/or comprise the “bread and butter” of county-level usage of a DVRS. The subset includes the transactions for creating a new voter registration record, modifying an existing record’s address or party affiliation, moving a record from one county to another, etc. The application logic for these transaction may not be complete, but should be part of the required logic. Likewise, the DB schema should be a realistic subset of what a full schema might be, and application framework and software stack should be the same as that envisioned for the complete OARS system.

Another primary goal is to develop the auditing and externalization facilities, including the definition of an initial subset of EAML.

The result of the OARS prototype project, i.e., the OARS P1 system, will be demonstrated and made available in the following ways: source code and build environment; live CD distribution, and on-line application accessible by an ordinary Web browser. The latter may support an initial phase of the Virtual State project, with capabilities to create mock county officials for voter registration functions. In that case, a companion service would be publication of the audit trail of OARS operation, via externalization in EAML, XML-HTML conversion, and Web publishing.

[edit] OASES

[edit] System Overview

OASES (Open Auditable Structured Election System) is a complete “election system” in the specific sense of the term used to describe a single-source suite of software and hardware/software devices, used by county election offices to automate the process of conducting elections, using functions for election management, ballot development, voting, tabulation, etc.

[edit] Key Concepts

Completeness is key concept for OASES, which is complete in the sense of providing all the functions and components required to be eligible for certification. (State certification, sometimes in conjunction with a prior Federal certification, are required for an election system to be used for a government election; only complete election systems may be certified, but not individual standalone components such as voting devices.) In addition, OASES may be the first ever election system specifically designed for feasibility of certification and especially re-certification. At present, any substantial change to current election systems could trigger another evaluation and certification process similar in scope, cost, and time to the first.

Re-certifiability is an aspect of OASES that is a potential breakthrough, because at present, none of the election systems in use in the U.S. meets the current standards, and there are no current election systems that have been shown to be certifiable under the current standards, much less re-certified at a fraction of the original cost and time. Further, re-certifiability is intended to enable a possible future in which a specific version of OASES could undergo the certification and evaluation process, with OSDV becoming the public custodian of the certified system, and managing the re-certification processes.

Transparency is another aspect of OASES that is a potential breakthrough, resulting from the extensive logging, externalization, and audit functions that provide the transparency benefits described below.

[edit] Benefits

Some of the intended benefits of OASES, as an open system, are transparency, standards, and cost savings. Standards benefits arise from OASES extending and using EML public standards for representing the various data objects used in automating an election (voter and pollbook records, ballots, ballot layouts, voted ballots, tabulation data, audit data, etc.). Standards benefits and transparency benefits are the result of OASES using a common, public draft standard (EAML) for representing records of all activities performed with the election system. Transparency is enabled by using the standard datasets as the based for publishing to the general public for web searching, data mining, independent analysis and audit, etc.

The transparency benefits are also a potential breakthrough, because the present closed systems use proprietary audit data formats, and lack the ability to externalize a full set of audit data. As a result, transparency is blocked by the lack of full data, significant efforts to obtain and publish even some information. In practice, election officials rarely have the motivation to perform this “extra effort.” The goal for transparency goal for OASES is to make logging, audit, and publication an integral capability of an election system, with publication requiring so little effort that the effort itself is not a valid excuse for withholding information that is readily accessible to the public.

Cost savings may not be a breakthrough, but will occur via a significant change in the current business model for election systems, by de-coupling hardware, software, and services. Election officials may procure hardware separately, including trailing-edge commodity systems. Software procurement can be limited to services for implementing election system components with hardware and open source software; and these services can also be unbundled from other services for technical support of election system components, or consulting services for assistance in the use of election systems.

[edit] OASES System Architecture Overview

OASES’ architecture is non-traditional, both as compared with exiting voting systems, and with typical PC-based system. The architecture is a key factor for achieving goals for a system that is simple, minimal, feasible to assess, modular, feasible to re-assess, trustworthy, and high assurance. For a full explanation of the distinctive aspects of OASES architecture, see the OASES System Architecture description.

[edit] OASES System Architecture

The OASES Architecture diagram shows the two types of components of OASES: EMS components and devices. Unlike the large, inter-dependent and complex EMS (Election Management System) components of conventional election systems, OARS' EMS functions are broken out into a small separate components, so as to minimize the complexity of the code involved in such critical but simple functions as tabulation. In addition to the EMS components, OASES consists of the minimum number of device components:

• a polling-place counting optical scanner (PCOS) device that can scan hand-marked or electronically marked ballots;
• an electronic ballot marking device that provides enhanced access functions for voters who need them for independent voting; and
• a central office ballot scanner that incorporates a number of post-election back-office functions for ballot scanning.

[edit] OASES Component Architecture: SHARP

Each of the 9 components of OASES has the same component architecture, consisting of a common platform, and a set of component-specific software modules. The platform software is an embedded operating system, and embedded application execution environment. We use the term embedded because each of the 9 components operates as a separate fixed-function computing device, that performs only:

• the component-specific functions of the embedded application software;
• the functions of the application execution environment, and
• the OS and related functions needed to support the execution environment.

The latter functions are implemented by a minimized OS, called SHARP (Sustainable High Assurance Re-uasble Platform). SHARP is “minimized” because it provides all and only what is required to support the platform for the embedded application. Each embedded application uses the same application platform, which uses the same minimized OS. Further, the application platform is minimized to the limited needs of suite of the embedded applications.

SHARP has a number of assurance, integrity, security goals that are central to its purpose as the system base for fixed function devices, which are similar to computing "appliances", but with additional property that it can’t be reprogrammed. This type of fixed-function device is sometimes referred to as a "toaster" because it has a fixed type of input and a fixed set of logic to "cook" the input into an instance of a fixed set of outputs. The assurance and other properties of SHARP are documented in detail in OTA.

The fundamental architectural ingredients of SHARP are: a minimized build of an open-source distribution of the Linux OS; a minimized build of an open-source distribution of the python programming language interpreter, which serves as the embedded execution environment.

An architecture diagram shows the nine OASES components each as an instance of SHARP that varies from the others only in the embedded application software running on SHARP.

For more information on SHARP's architecture, see the SHARP Architecture.

[edit] OASES Component Data-Flow

The OASES Component Data-Flow diagram shows how the EMS components interact with one another and with the device components.

• The OASES Precinct and District Manager (PDM) manages the dataset that defines the geographical and street-addres definitions of each precinct and district in an election jurisdiction (county or municipality).
• The PDM provides precinct/address datasets to the OASES Voter Eligibility Manager (VEM). The VEM also consumes a dataset of voter registration records, derived from a DVRS, either OARS, or any other EML-compliant DVRS. The VEM combines these datasets to produce pollbook datasets. (See Glossary#Pollbook.)
• The PDM provides precinct/district datasets to the OASES Contest and Ballot Manager (CBM). The CBM manages the dataset that describes the contests and ballot measures that the county's districts have submitted for a given election. Based on this dataset and the data from the PDM, the CBM creates a ballot-style dataset for each precinct.
• The OASES Ballot Studio uses these datasets as the basis for its main function: to assist election officials in designing the actual ballots, based on the ballot-style definitions. The Ballot Studio produce are distinct representations of the resulting ballots: paper ballots, and ballot-definition datasets that become part of the programming of voting devices.
• The OASES System Builder component consumes those ballot definition/design datasets, and uses the data to produce the election-specific programming for each of the 3 OASES voting device components.
• The scanner device components produce tally datasets, i.e., totals of the votes recorded from the ballots scanned by the device.
• Though not shown in the diagram, each component also produces complete audit datasets contain log entries for every action undertaken by each component. The log records, when consolidated into a single EAML dataset, can be the basis for publication of a complete account of how the election was conducted.

All these dataflows are summarized in the diagram. The dataflows within a polling place are in the shaded box; all other operations occur in a county central elections office. The path of paper ballots is indicated with dotted lines, while the solid lines are the digital information flows described above.

[edit] OASES Component Data Transport

SHARP is designed to run on hardware that meets simple specifications that enable the re-use of existing commodity PC hardware, printers, and scanners. An exception to this goal may be the EBM (electronic ballot marking) device, which may require custom industrial design for handicapped access, but use the same basic commodity computing hardware.

All OASES components run as stateless fixed-function systems, booting from a read-only boot media, reading input and writing output to write-once removable media. The data flow and transport are illustrated in the OASES Component Data-Transfer diagram. In contrast to the OASES Component Data-Flow diagram, which shows the dataflows between the components, the OASES Component Data-Transfer diagram shows the same dataflows as being conveyed by removable media, either media with datasets, or media with boot images for the three voting device components.

The three voting device components of OASES differ from the others in that they require election-specific input data, which is provided as part of the boot image (so that only removable media is required to operate the system). The OASES System Builder component creates these boot media with the election-specific data. (In other systems, the term election “programming” is used, but this would be a misnomer for OASES because election-specific processing is entirely data driven.)

[edit] Basic Issues

Most of the basic issues for OASES development fall into one of two categories: platform, and data externalization. The primary methods to deal with most issues are parallelism and specification.

Data externalization issues arise from the toaster architecture in which each OASES component is a standalone system that interacts with others only via input and output datasets. Hence, at the level of the embedded applications software for each component, much of the work is in specification of standard schemas for these datasets – essentially the EML+ effort. Implementation of these schemas is parallelized, as each can be done separately, as distinct bodies of parser/generator software. Iterative development is another technique, with initial simpler schema definitions to drive rapid prototyping of embedded application software. Since the same body of parser/generator software can be shared by the multiple separate applications that use the data, implementation of newer versions of a schema can be upgraded in parallel.

Platform issues arise from the architecture in which SHARP is the common platform for each of the OASES components, and comprises the majority of the software, the complexity, and the technical risk for development. The large majority of the work for developing SHARP is minimization efforts to “slim down” standard open source distributions of Linux and Python. There is plenty of parallelism in the minimization activities, but some feedback loops as well. For example, each of the following can be seen independent minimization efforts: OS distribution, OS kernel, python distribution, python runtime, python interpreter. At the same time, embedded application software can be developed independently of the platform, using the pthin language subset specification as the “contract” between the present application developer and the future complete platform.

Perhaps the biggest platform issue, however, is testing. Minimization is essentially a process of removing functionality and testing to see if the system still works properly and still meets the needs of the embedded application software. Further, minimization of pre-existing code may expose latent bugs or undocumented dependencies. This is likely the greatest development risk of a major goal (minimization, assurance, trust).

[edit] Prototype

The initial OASES prototype project is a rapid-prototyping effort to quickly get to a demonstrable proof-of-concept system that is an early version of SHARP. The goal for the OASES P1 system is to develop, distribute, and demonstrate an initial version of SHARP is that (a) significantly minimized, and with clear direction for further minimization, and (b) sufficient to support a credible body of application software of a component of an election system. The application software is pvote, the work of Ka-Ping Yee (see http://pvote.org), which includes the definition of pthin and the implementation in pthin of a small body of software that implements the functions of an electronic ballot marking/printing device.

Pvote serves the critical function as “litmus test” for minimization. If a platform interface or service is needed to support the execution of pvote, then it is necessary; otherwise it is eligible for removal (and breakage testing!). In addition, pvote is a particularly useful litmus test, since an EMB device is one of two OASES components (the other being the PCOS device) with the greatest complexity WRT platform requirements due to extensive user interface driven by GUI library code of greater complexity than most of the actual embedded device software.

Rather than being an effort of throw-away development, the initial version of SHARP is an enabling step for a number of other steps towards a truly minimized platform for the body of embedded application software packages that comprise a complete election system. As a superset of a future, more minimized SHARP, the initial version serves as a proof of the important concepts of strong separation between platform and application, and separate comprehensibility and reviewability of each. These are critical for practical use because of the requirement that before becoming legal for use in government elections, an election system must first be independently reviewed and certified.

The result of the OASES prototype project, i.e., the initial version of SHARP, plus pvote, will be demonstrated and made available both as a live CD distribution and as source code and build environment; live CD distribution, and on-line application accessible by an ordinary Web browser. The latter may support an initial phase of the Virtual State project, with capabilities to create mock county officials for voter registration functions. In that case, a companion service would be publication of the audit trail of OARS operation, via externalization in EAML, XML-HTML conversion, and Web publishing.

[edit] Projects

The following the current list of distinct projects of efforts to be performed in the development of OASES:

• The prototype effort described above.

• The SHARP 4-way minimization project, which consists of independent efforts in the following areas:
  • Kernel minimization: removing kernel functionality that is not needed to support the OS requirements of the user-space code (particularly the python interpreter) of the prototype system.
  • Python run-time environment minimization: removing components of the python run-time (python code used as a body of common library functionality) that is not needed for either of two reasons: not used by pvote or other python packages that pvote depends on; not used by any program written in pthin.
  • Pthin implementation: modifying the standard python distribution to be an interpreter for pthin rather than full python, together with any minimization of the interpreter implementation that may be enabled as a result.
  • Software package minimization: system-build work to reduce the number of user-space software packages needed to build the prototype system

Though these can be pursued completely independently, we can also be agile enough to take advantage of situations in which progress in one area enables further work in another.

• EMS 1 Project - Election management software prototyping efforts: independent development of embedded application software for early versions of the OASES components that perform election management functions. The emphasis on these efforts is to flesh out the data interchange formats for the input and output data of the components, and build the framework for rapid evolution of the software as the dataset definitions evolve.

• EML+ Project – largely a specification exercise, drawing on existing EML and VIP data definitions, and extending to the needs of OASES. Some data conversion tools may need to be developed, to convert some existing datasets into EML+ datasets for use as test data in further EMS software development. Also include definition and implementation of initial subsets of EAML.

• SCAN 1 project – initial pthin implementation of basic ballot scanning capability, using an expedient experimental ballot format, full EML implementation, and integration with two other OASES components: tabulator to consume output datasets; EBM to produce ballots to be scanned.

• SHARP Integration, Integrity, and Test Project – integrate the results of previous SHARP efforts, add implementation of integrity features, and develop a robust test framework to detect software breakage resulting from minimization efforts. Integration efforts critically include integrating and/or developing system build tools so that SHARP can be built from standard open-source software distributions. Integrity efforts mainly consist of; adding to the kernel build some existing packages for memory protection; adding to the kernel build new functionality for run-time execution control; adding to the python interpreter new functionality for run-time execution control. The test framework is important to support both the stability of the integrated systems, and also the result of further work in this project to perform additional minimization enabled by the integration of previous minimization efforts.

• Ballot Studio 1 Project – develop the majority of the ballot studio functionality including output of full datasets for device components. Initially includes support for SCAN-1 ballot format, but also includes support for the existing vendor(s)’ ballot formats, and existing standards and guidelines on ballot design and layout.

• SCAN 2 project – three main goals: support existing vendor(s)’ ballot formats; extend the capability of EMS components to produce full input datasets for both the scanner and EBM devices; extend devices’ implementations to use the full input datasets.

• Ballot Studio 2 Project – completion of Ballot Studio by addition of additional functionality not needed for the initial effort, e.g., candidate ordering, addressing extended access and multi-language issues, support for incorporation of late ballot definition changes, …

• EMS 2 project – completion of the pre-election-phase EMS components, particularly user interface functionality, full EML+ support, extending EAML definition, providing full EAML support.

• System Builder – complete implementation of the System Builder Component, using the full input datasets from the other components, a complete SHARP implementation, and the device software implementations. Also includes facilities for rapid update to support new versions of SHARP and OASES applications.

• Central Scanner – complete implementation of central scanner, principally adding user-oriented features and UI for interpretation, disposition, reporting, as well as logging of the these activities and EAML support.

• Tabulator – finished implementation of a tabulator component, adding support for central scanner datasets, enhanced report data generation, and related EAML support.

Not included above are demonstration and distribution efforts are various “rendezvous points” of the various projects. Also not included, but strongly implied, are outreach efforts for the later projects, as part of product management efforts to determine an acceptable set of user-facing functionality around the core functions for the OASES application software.