Ballot secrecy
The design prohibits linking a cast ballot to its voter. Eligibility operations and ballot records have separate data boundaries.
SPARKGLIM / ELECTRONIC VOTING APPLICATION
A separate system for supervised, locally hosted elections. SEVA brings administration, check-in, ballot marking and evidence review into a controlled operational design.
Explore the architecture ↗THE ELECTION ENVIRONMENT
Conceptual workflow. Voter identity and cast ballots remain separate.
ONE LIFECYCLE / SEPARATE RESPONSIBILITIES
Define contests, eligibility, authorities and approved devices before the election is sealed.
↗02Supervise eligibility checks and ballot marking on separate operational surfaces.
↗03Close voting before trustees authorize threshold decryption.
↗04Review result evidence, paper records and the audit trail before publication.
↗PURPOSE-BUILT APPLICATIONS
Election configuration and the voter’s ballot experience have different responsibilities. SEVA’s architecture separates them and restricts the actions available at each stage.
Administration application →Voting kiosk application →
THE ASSURANCE MODEL
The design prohibits linking a cast ballot to its voter. Eligibility operations and ballot records have separate data boundaries.
Decryption requires a threshold of trustees. Candidate totals stay unavailable until voting closes and authorized decryption occurs.
Paper evidence, append-only records and hash chains support reconciliation. Architecture alone does not establish election readiness.
CURRENT PRODUCT STATUS
SEVA is pre-release and is not yet suitable for any live election. A discussion starts with your governance, locations, equipment, accessibility needs and evidence requirements.
Request a readiness discussion ↗Deployment requirements →EXPLORE SEVA