Section 11
Voter status
This is the only surface a voter ever touches, and it is the one place where being more helpful makes the whole system dangerous.
The design objective, stated plainly. Help a voter take lawful action — chiefly, fix a correctable problem before the deadline — without creating a durable, third-party-verifiable artifact that reveals choices, lets a coercer monitor someone's voting behaviour, or meaningfully proves who completed a ballot.
Every restriction below follows from that one sentence.
The interface
Everything a voter is ever shown
Step a package through its life and watch the voter-facing projection. This is the engine's
voterStatus() function — the whole function, not a filtered view of a richer one.
Advance the package
What staff can see at this moment
What the voter sees
Official election portal · signed in
That is the entire payload: a status, one sentence of safe language, an optional official next step, and a timestamp. No token. No barcode. No event history. No staff names. No facility. Nothing downloadable.
Two places the interface is deliberately vague
SPENT reads exactly like ACCEPTED. A voter has no business knowing that envelope separation has happened, and a status that changed at separation time would leak the office's processing schedule to anyone watching over a shoulder.
Every transit state collapses into one sentence. Issued, outbound, delivered and returning all read as "has entered the mail process". A precise chronology is exactly what a coercer needs to demand compliance in real time — "it says delivered, show me now."
The printed recovery code
The envelope carries a short code like 7QK4-M2XB, readable down a
telephone line — no I, L, O or U, because
people transcribe those wrongly.
It is not a credential and cannot become one. It will not resolve a token for a write, and it will not retrieve a status, unless an independent voter authentication has already happened. That refusal lives in the engine, not in this interface.
It is generated independently of the token rather than derived from it, so it cannot reveal it — not as a matter of preimage resistance, but by construction.
Authentication rules
- Never authenticate on a printed envelope code, token, barcode or short recovery code alone
- Require voter-controlled identity proofing, with accessible alternatives
- Rate limit, and detect enumeration patterns
- Re-authenticate before showing cure documents
- Bind the session to the voter — no shareable status URLs
- Short expiry; no caching of sensitive pages
- Never send a full token in email, SMS, push or a URL
What it must never show
This list is longer than the interface itself, and that is the correct proportion.
A vote
Selections, contests, party, ballot images, tabulation results — and above all never a "you voted for X" confirmation. Not ever, under any authorisation.
A receipt
No downloadable proof of vote, no permanent artifact, no persistent cryptographic token that could be handed to a buyer, employer, campaign or family member.
A raw identifier
No lifecycle token, no full postal barcode. Those exist for the system, not the voter, and a voter who can read one can be made to show one.
A chronology
No detailed event timeline. Enough sequence detail is a live surveillance feed on somebody’s kitchen table.
The staff
No names or identities of intake, validation or separation officers. They are people, and this is a list of who touched which ballot.
The route
No exact custody path, facility locations or scanner IDs. That is an operational map of where ballots physically are.
A public lookup
No unauthenticated token lookup, ever. A public endpoint keyed on a printed code is a mass-enumeration tool with a login page drawn on it.
A third party
No household, campaign, employer, landlord, family or delegated access to an individual’s status. Delegated credentials are coercion with a permission model.
Notifications
Permitted
"There may be an update regarding your ballot. Sign in to the official election portal or contact the election office by [date]."
Not permitted
"Your ballot was accepted." — on a lock screen, in a preview, next to somebody else on the sofa.
A notification is read by whoever is holding the phone. Status detail goes behind authentication, not into the message — unless a voter has knowingly opted in and jurisdictional privacy review permits it.
Accessibility is not a secondary requirement here
No smartphone, app, webcam, internet access, email or digital wallet may be required for any part of voting or curing. Telephone, paper, in-person and accessibility-supported channels must exist and must work. Screen reader, keyboard, language access and low bandwidth are requirements, not enhancements.
Status is a convenience and a cure aid. It is never a condition of a ballot's validity — and a voter who never opens this page must be no worse off than one who checks it daily.
If a voter reports coercion
Provide an official support route. Do not require them to disclose their selections to get help. Where the law authorises it, offer a replacement or spoiled-ballot process that does not expose their prior choices. And never offer — or accept — live video, screen sharing, ballot display or possession verification as a way to prove anything, because every one of those is the mechanism a coercer would choose.