BB2G-Master-Specification-v3

The Born Between 2 Generals Elections System — Master Specification

Version: 3.1 · Status: Normative draft for review · Date: 9 September 2026 Editorial correction, 2026-09-10: §2 row 1 cited §10 for the bb2g-elections monorepo; the v3.1 renumbering moved One build to §12, so the citation now reads §12. No normative text changed.

Change in 3.1: Added §10 (vote centers / county-wide polling places) and §11 (post-quantum cryptography), the latter incorporating the quantum-safe and halo work that sat outside the 23 elections repositories and therefore outside v3.0. Sections 10 and 11 of v3.0 became 12 and 13; no requirement identifier changed, which is what stable identifiers are for. Author of record: Kristen Hall, Born Between 2 Generals, LLC Supersedes: Safe Elections v2, Safe Elections Update Spec, StrongRoom Spec v2, Three Sites Spec, Election Integrity on StrongRoom SPEC (all four copies), Full Voting System Architecture, Org Election MVP Architecture, Isolation Architecture, Safe Vote SPEC, Verifier Spec, and the five Election Command architecture documents.

0 · How to read this document

This is the first BB2G elections specification that is normative. Earlier documents mixed doctrine, sales copy, build plans and aspiration in the same paragraph, and where two of them disagreed nothing said which one won. Twelve such disagreements existed at the time of writing; every one is resolved here by decision, not by compromise.

Requirement language. MUST, MUST NOT, SHOULD, SHOULD NOT and MAY carry their RFC 2119 meanings. Every requirement carries a stable identifier (SEV-1, KEY-4, …). Identifiers are permanent; if a requirement is withdrawn, its number retires with it.

Precedence. Where any other BB2G document conflicts with this one, this one governs. Where this one is silent, no requirement exists — silence is not permission to improvise on the ballot path.

Claim discipline. Three states are tracked separately for every component, and prose MUST NOT blur them:

Nothing in this system is "audited" until a named cryptographer has published a report against a named commit. As of this version, that has not happened, and no BB2G surface may say otherwise.

1 · The governing principle, restated

> Verify hard, then sever. > Prove who someone is as rigorously as the law allows at enrollment. Then issue an anonymous credential that proves eligibility without carrying identity. From the moment a ballot is cast, no record anywhere links that ballot to the person who cast it.

This is carried forward verbatim from safe-elections-isolation/kit/docs/full-voting-system-architecture.md and it remains the single sentence the whole architecture exists to enforce.

SEV-1. No table, index, log, backup, cache, or derived artifact anywhere in the system MUST be capable of reconnecting a voter to their ballot. Severance MUST be enforced by cryptography, not by access control, not by policy, and not by operator restraint.

SEV-2. StrongRooms tokenizes custody and eligibility. It MUST NOT tokenize the voter-to-ballot link. No feature, module, connector, report, or analytics surface may be added that crosses this line. A proposed feature that requires crossing it MUST be rejected rather than mitigated.

SEV-3. Every service MUST be classifiable into exactly one of two domains — identity-side or ballot-side — and MUST NOT hold data from both. The seam between them is the blind signature described in §5.

SEV-4. A build gate MUST fail if any identity-side type is importable from ballot-side code, or vice versa. tools/poison/poison-severance.mjs in the current corpus is the correct shape for this gate and MUST be promoted to a required CI check.

1.1 The seven doctrines

Carried forward unchanged from Safe Elections v2 §7. These constrain every requirement below.

• An eligible voter with no credential is our failure, not theirs.
• A broken credential can never be what stops someone voting. Every failure path ends in a ballot.
• Replying is expected, never required.
• No arrival deadline on voters. The deadline is on us.
• Dual control anywhere a credential is minted or resolved.
• Software MUST NOT decide the ambiguous case. It refers.
• Affirmative per-person verification, yes. Automated purge lists, no.

DOC-1. These seven are requirements, not values statements. A component that violates one MUST NOT ship, and the violation MUST NOT be closed by adding a warning to the interface.

2 · What v3 decides that v2 left open

The twelve contradictions found across the prior corpus, and the decision for each. Full evidence is in the audit report accompanying this specification.

3 · System profiles

The single largest failure of the prior corpus was describing one system that was simultaneously a binding public election, an organizational pilot, and a teaching demo. v3 defines three profiles. A component MUST declare its profile, and a profile MUST NOT borrow a security claim from another.

PRO-1. BB2G MUST NOT offer binding internet voting for a public governmental election under Profile A. This is a permanent architectural position, not a roadmap item.

PRO-2. The reason MUST be stated plainly wherever the question arises: two problems remain unsolved by anyone, including us — voter-device compromise and remote coercion out of camera shot. Re-voting and independent verification apps reduce them; they do not cure them. The prior corpus already admitted this in full-voting-system-architecture.md and in verified-vote/docs/VERIFIER-SPEC.md, which states that voter intent cannot be established without a voter-verified paper record. v3 promotes that admission from a footnote to a constraint.

PRO-3. Profile C surfaces MUST be labelled as demonstrations in the interface itself, MUST use synthetic data only, and MUST NOT accept a real government identifier. A demo that looks binding is a liability, not a sales asset.

PRO-4. What BB2G does offer for Profile A is the part that is actually defensible and actually wanted: verified enrollment, tokenized custody, tamper-evident publication, and an audit any citizen can run. The product is confidence that can be checked, not a database of who everyone is.

4 · The four tiers, and what "containers at every level" means

The prior corpus specified a four-tier isolation model but enforced none of it at runtime; the systemd unit referenced a Python entry point that does not exist, the firewall configuration used undefined variables, and the attestation gate passed an all-zero report while printing that it was replayable. v3 specifies the tiers as enforced boundaries with named mechanisms.

CON-1. Every Tier 2 and Tier 3 artifact MUST ship as a signed OCI image with a generated SBOM and provenance attestation. Images MUST be signed (Sigstore/cosign or equivalent) and the deploy pipeline MUST refuse an unsigned or unattested image.

CON-2. Container images MUST be built reproducibly, MUST pin every dependency by digest, and MUST NOT install a package at container start.

CON-3. Containers MUST run rootless, read-only, with no ambient capabilities, a default-deny egress policy, and no shared writable volume between tiers.

CON-4. A container MUST NOT be presented as equivalent to Tier 1 isolation. A container shares a kernel with its host; a confidential VM does not. Where the prior goal said "containers at every level," v3 reads that as an enforced, attested, reproducible runtime at every level — which for Tier 1 is a CVM and for Tier 0 is air gap. Putting the registrar in a container instead of a CVM would be a downgrade, and the specification says so rather than satisfying the letter of the goal.

CON-5. Remote attestation MUST bind a fresh nonce into report_data. An attestation with all-zero report data MUST fail closed. The correct implementation already exists in the corpus at safe-elections-isolation/kit/engine/attest.mjs and MUST replace the Python gate that currently passes.

CON-6. EXPECTED_MEASUREMENT MUST be produced by the reproducible build and MUST be published before the election phase in which it is used. A tier that cannot produce its measurement MUST NOT accept traffic.

CON-7. One compose.yaml MUST bring up the full Tier 2/3 stack locally for development, and it MUST NOT be capable of standing in for Tier 0 or Tier 1 in any environment named production.

5 · The Black Box — vault, keys, tokens, rotation

This section specifies the component described as "a container that creates the tokens inside a vault, and then the token rotates the whole time the key is moving, and logs the whole way with hash and tokenization." It is the heart of v3 and the place where the goal has to be split into the parts that are safe and the part that is not.

5.1 What the Black Box is

BB-1. The Black Box is a Tier 1 service, running inside a confidential VM with a hardware HSM, whose only functions are: mint blind signatures over eligibility credentials, mint and rotate custody and session tokens, and emit a signed entry to the transparency log for every operation.

BB-2. Private key material MUST be generated inside the HSM and MUST NOT be exportable. No code path may serialize a private key to disk, to a log, or to a response body.

BB-3. The Black Box MUST NOT receive, store, derive, or log any voter identifier. Its input from the identity side is an eligibility attestation containing one bit and no name (§6.5).

BB-4. Under Profile A and B, a Black Box without an attested HSM MUST refuse to mint. The current engine already refuses in production without an HSM; v3 keeps that refusal and adds the HSM.

5.2 Three token classes — the necessary distinction

The single most important correction in v3. "The token rotates the whole time" is right for two of these classes and actively harmful for the third.

TOK-1. Session and transport tokens MUST be short-lived (≤ 15 minutes), MUST rotate on every privilege change, MUST be bound to the attested tier that issued them, and MUST be replay-protected by a nonce and an expiry.

TOK-2. Custody tokens MUST rotate at every hand-off, and each rotation MUST write a log entry linking the prior token digest to the new one, so the chain is walkable end to end without revealing content. This is the "logs the whole way with hash and tokenization" requirement, satisfied.

TOK-3. A ballot credential MUST NOT be re-issued, re-blinded, refreshed, or rotated while a ballot is in flight. Reason, stated plainly: every rotation of an anonymous credential is an opportunity to correlate the old value with the new one. Continuous rotation of the ballot credential would create precisely the linkage that §1 exists to destroy. Rotation makes a session safer and makes an anonymous credential weaker, and the two must not be governed by one rule.

TOK-4. Where longer-lived anonymity is required, the mechanism MUST be credential epochs (§5.5), not rotation of a live credential.

5.3 Issuance accounting without a list

ISS-1. The Black Box MUST publish, to the transparency log, one entry per issuance containing the blinded request digest, the key epoch, a timestamp rounded to the phase, and the dual-control approvers. It MUST NOT publish or retain the unblinded credential.

ISS-2. The registrar MUST maintain a count of credentials issued per precinct and per phase, and MUST NOT maintain a list of issued credential values. Reconciliation is: issued count == count of blinded issuance entries in the log. This satisfies the exact-reconciliation requirement of the integration spec and the "count, never a list" requirement of the isolation spec simultaneously, which is why contradiction #5 was a false conflict.

ISS-3. One credential per eligible voter per election MUST be enforced on the identity side, before blinding, under dual control.

5.4 The nullifier protocol

NUL-1. A ballot submission MUST carry a nullifier — a deterministic, one-way function of the credential secret and the election identifier — which the ballot box records to detect reuse. The nullifier MUST NOT be derivable back to the credential or to a voter.

NUL-2. Under the remote profile (B), a repeat nullifier MUST supersede the prior ballot silently. The bulletin board MUST publish that a supersession occurred and MUST NOT publish which prior entry was superseded in a way that lets an observer tell whether any particular voter re-voted. Coercion resistance depends on the coercer being unable to learn that.

NUL-3. Under the in-person profile (A), a repeat nullifier MUST be rejected as a double-cast, and the voter MUST be routed to the provisional path. Rejection MUST NOT be the end of the interaction.

NUL-4. A single election MUST NOT mix NUL-2 and NUL-3 semantics. The profile is declared in the election definition and is immutable once the roll closes.

5.5 Key epochs — how rotation and audit stop fighting

Continuous rotation and permanent verifiability are in genuine tension: a signature verifiable in 2036 needs its 2026 key to still be discoverable. The prior corpus rotated keys by adding a version and retaining every version forever, which accumulates secrets rather than reducing exposure.

KEY-1. Every signing key MUST carry an epoch identifier, and every signature MUST name the epoch that produced it.

KEY-2. The Black Box MUST publish a Key Transition Log (KTL): an append-only, witness-cosigned log recording, for each epoch, the public key, the activation time, the retirement time, and the digest of the predecessor entry. The KTL MUST be published to the same three independent witnesses as the transparency log.

KEY-3. Signing keys MUST rotate at every election phase boundary (roll close, polls open, polls close, certification) and at least every 24 hours during an active phase.

KEY-4. A retired private key MUST be destroyed inside the HSM, and the destruction MUST be logged. A retired public key MUST be retained in the KTL permanently. This is the resolution: old signatures stay verifiable forever from the KTL, while old private keys stop existing. Retention of secrets is not the price of auditability.

KEY-5. Guardian tally key shares MUST use k-of-N threshold splitting with k ≥ 3, guardians drawn from adversarial parties, shares held on separate Tier 0 hardware. Share replacement MUST require a re-share ceremony with a published transcript.

KEY-6. Compromise of any epoch key MUST trigger: immediate retirement in the KTL, publication of the compromise window, and re-verification of every log entry signed within it. There MUST be a written, rehearsed procedure for this, and it MUST NOT be improvised during an election.

KEY-7. Break-glass approvals MUST include a nonce, an expiry, and a request identifier inside the signed payload, and the requesting party MUST be inside the signature. The current implementation signs none of these and its approvals replay indefinitely; that is a fix, not an enhancement.

KEY-8. No signing key MUST be stored in, adjacent to, or reachable from the filesystem holding the log it signs. This requirement exists because it was violated.

6 · Identity, verification, MFA

6.1 The two tiers of enrollment

ENR-1. Voters with a long, clean, unambiguous record MUST be auto-enrolled with no action required. This is the default and it covers the large majority.

ENR-2. Where a genuine identity question exists, the voter MUST be offered three paths, all equivalent in outcome: automatic (already resolved), in-person at the Office of Election Integrity, or a remote online notarization session.

ENR-3. The rule sorting tier 1 from tier 2 MUST be published, MUST be fixed before the roll closes, and MUST be logged per decision so that geographic or demographic skew can be measured and challenged by anyone.

ENR-4. "Flagged" MUST mean please verify. It MUST NEVER mean excluded, and no code path may treat it as exclusion.

6.2 Remote verification

IDV-1. Remote identity proofing MUST be conducted through a compliant remote online notarization provider with a credentialed notary, live audio-visual, government-ID proofing, and a tamper-evident session record. A generic video call is not sufficient and MUST NOT be described as verification.

IDV-2. Identity proofing MUST meet an IAL2-equivalent bar (NIST SP 800-63), including presentation-attack detection. Deepfake and injection resistance MUST be a named acceptance criterion of the chosen provider, and the residual risk MUST be published rather than minimized.

IDV-3. Session evidence — recording, calling number, verified email, mailed letter shown on camera, session GPS, government-ID check — MUST be captured as separate reconciling factors. No single factor may be sufficient alone.

IDV-4. Location capture MUST be session-scoped. Continuous or post-session location tracking MUST NOT be built, and the schema MUST make it impossible to store a second location for the same person.

IDV-5. Retention, disclosability, and public-records treatment of recordings and location MUST be decided in writing, with counsel, before the first session is recorded. Safe Elections v2 raised this and left it open; v3 makes it a gate: no recording capability ships until the retention decision is signed.

IDV-6. The mobile driver's licence path MUST use ISO/IEC 18013-5 selective disclosure, answering a fresh challenge per presentation. Static printed QR codes MUST NOT be used as a credential — they are copyable, and the concern that raised this was correct.

IDV-7. Where a session does not resolve, a human MUST refer to in-person. Software MUST NOT adjudicate the ambiguous case, and there MUST NOT be an automated referral-to-prosecution trigger. A software flag is not probable cause; a complete tamper-evident record referred by a person is what survives a court.

IDV-8. The provisional ballot path MUST remain open through every branch of §6, including suspected impersonation. The ballot is never the leverage.

6.3 MFA — where it belongs and where it must not go

The prior corpus contains no MFA implementation of any kind; one security document states outright that there is no login. v3 specifies it, and specifies its boundary.

MFA-1. Every staff and custodian role — registrar operator, verifier, notary-facing clerk, guardian, witness operator, administrator, deploy operator — MUST authenticate with phishing-resistant multi-factor authentication: WebAuthn hardware authenticators or passkeys. TOTP MAY be a fallback for break-glass only, with a nonce-bound approval per KEY-7.

MFA-2. Any operation that mints, resolves, or revokes a credential MUST require two distinct authenticated humans (dual control), each with independent MFA, and MUST log both.

MFA-3. Guardian key ceremony participation MUST require hardware-token authentication plus physical presence at Tier 0.

MFA-4. MFA MUST NOT be applied to the anonymous ballot credential. A second factor bound to a ballot-side action is an identity attached to a ballot, which §1 forbids. Voter-side authentication happens once, on the identity side, at enrollment; the ballot side authenticates a credential, never a person. This is the correct answer to "MFA and 2FA everywhere," and the exception is load-bearing rather than an oversight.

MFA-5. Voter-facing account recovery MUST route through the same enrollment verification paths in §6.2. There MUST NOT be a self-service reset that lowers the identity bar, because that reset becomes the cheapest attack on the system.

6.4 Identity documents first

DOC-2. The system SHOULD address document integrity in this order — Social Security record, birth certificate, passport, driver's licence — on the finding that elections inherit their fraud from the documents underneath them.

DOC-3. Duplicate-request alerting MUST route to verification, never to automatic denial. The same identity requesting a replacement document in two places is a signal to check, not a determination.

DOC-4. The document vault (personal and family) MUST use client-side encryption with keys held apart from storage, and MUST follow the same severance rules as every other module.

6.5 The attestation seam

ATT-1. The eligibility registrar MUST emit an attestation containing: election identifier, eligibility bit, precinct or ballot style, and the registrar's epoch signature. It MUST NOT contain a name, address, document number, session identifier, or any value derived from them.

ATT-2. The attestation MUST be single-use, nonce-bound, and expiring.

ATT-3. The attestation gate MUST fail closed on any missing, replayed, or unbound field.

7 · Integrity, transparency, and the audit log

The audit accompanying this specification demonstrated that the current hash-chained log can be rewritten end to end — every hash recomputed, every entry re-signed, the head file replaced — and its own verifier still reports success, with a recorded vote changed. The signing key sits in the directory it signs. Nothing publishes a head anywhere else. So the corpus today does not achieve tamper-evidence; it achieves tamper-evidence only against an adversary who cannot reach the disk, which is not the adversary that matters.

LOG-1. The transparency log MUST be an RFC 6962-style Merkle tree with signed tree heads, inclusion proofs, and consistency proofs. MBLTS-MERKLE-V1 MUST be retained only as a read-only verifier for roots already published, and both roots MUST be published during the transition. A root MUST NOT be silently recomputed under a different tree shape.

LOG-2. Every signed tree head MUST be witness-published to at least three independent witnesses, operated by separate organizations, in separate jurisdictions, with a documented independence test. Witness cosignatures MUST be published.

LOG-3. Verification MUST fail if a head cannot be corroborated by at least two witnesses. A locally verifiable chain MUST NOT be reported as verified. The verifier's status vocabulary MUST distinguish locally consistent from witness-corroborated.

LOG-4. Signing keys MUST be stored outside the log's trust domain, per KEY-8.

LOG-5. Witness publication MUST occur at each of the four phase boundaries — roll close, polls open, polls close, certification — because those are the moments at which a state could not have been reconstructed afterwards. A head published at poll close, before anyone knows the result, is what makes "records were adjusted after the outcome was known" both unprovable and undoable.

LOG-6. Only the head leaves. No voter, no mark, no ballot, no location, no identifier.

LOG-7. The word tamper-proof MUST NOT appear on any BB2G surface. The system is tamper-evident: it makes alteration detectable by an independent party, and it MUST document who that party is and what they must retain.

LOG-8. Ballot serial numbers, tokens, nullifiers, and any other security-relevant value MUST be generated from a cryptographically secure random source. Math.random MUST NOT appear in any security path. It currently mints ballot serials in one platform module, and that is a defect of the highest order in an election system.

LOG-9. Inclusion proofs MUST return a Merkle path. Returning the entry itself is not a proof and MUST NOT be described as one.

7.1 The two audits, kept separate

AUD-1. The risk-limiting audit checks the tally against the paper record, performed by trained people using a published statistical method (BRAVO, Kaplan-Markov).

AUD-2. The citizen panel checks the system: that published arithmetic matches published records, that findings were issued when they should have been, that a claim traces to its document. Randomly selected, jury-duty style, no expertise required.

AUD-3. These MUST be named separately in code, in copy, and in every sentence of every pitch. If they blur, someone will eventually claim that untrained citizens are checking the count — which is not happening, would be a bad idea, and is a free attack on a system whose whole value is being unattackable.

AUD-4. Under Profile A, certification MUST NOT occur without a completed RLA against a voter-verified paper record.

8 · The election lifecycle, normatively

Phase 0 — Enrollment. Identity verified once, per §6. Registrar stores the eligibility bit plus only what law requires. No dossier travels toward a ballot.

Phase 1 — Issuance (the severing). Voter generates a secret on their own device, blinds it, the Black Box blind-signs it having seen only noise, the voter unblinds. One credential per eligible voter, dual control, blinded issuance entry logged. Blind signatures MUST follow RFC 9474 rather than a hand-rolled scheme.

Phase 2 — Casting. Credential, signature, nullifier, and an encrypted ballot are submitted with no identity attached. The ballot box verifies the signature, checks the nullifier per the declared profile, and publishes a receipt.

Phase 3 — Tally. Encrypted ballots are summed while still encrypted. A quorum of k-of-N guardians each contribute a partial decryption with a zero-knowledge proof. Only the total is ever decrypted. Everything is posted to the bulletin board so any observer can verify cast-as-intended and counted-as-cast.

BUILD-1. Phase 3 MUST be built on ElectionGuard rather than hand-rolled threshold cryptography. Phase 1's token layer is the piece BB2G owns and differentiates on; everything else is integrated from audited systems.

8.1 Who can know what

SEP-1. No row above may hold the capability of two rows. The registrar, the token service, and the ballot box MUST run as separate processes, on separate hosts, in separate tiers, with separate datastores. The current development server collapses all three into one process over one SQLite file with an in-memory credential-to-token map — which dissolves the anonymity wall the entire design rests on. That tool MUST be deleted rather than hardened, because a convenience that can be mistaken for the architecture is worse than no tool.

SEP-2. No BB2G service MUST serve election traffic over cleartext HTTP in any environment holding real data.

8.2 The trial election

TRIAL-1. Every jurisdiction MUST be able to run the full cycle against historical data before committing to anything, publishing nothing. This capability already exists in the corpus as a readiness tool and MUST be surfaced as a named public feature, "Run a trial election."

TRIAL-2. The trial MUST report the silent cohort as its headline, never a turnout or coverage figure. Non-response is an upper bound, not a forecast.

TRIAL-3. If the projected resolution-desk ceiling comes out absurd, that is the finding. No jurisdiction can staff its way out of a bad reach rate, and the report MUST NOT soften this.

8.3 Concurrent resolution

RES-1. Verification MUST run in parallel with voting, never on the critical path. Nobody does paperwork while a queue waits.

RES-2. The resolution desk pool MUST run statewide so idle desks absorb another county's surge, MUST stay staffed until polls close, and MUST route any unresolved case to a live human while the voter is still present.

RES-3. The affected person MUST be able to trigger resolution themselves, without a poll worker deciding they qualify to ask.

RES-4. An override inside the building MUST route outward. A flag only the flagged party can see is not oversight.

8.4 Offline operation

OFF-1. Poll books MUST operate from a signed, immutable roll snapshot and MUST reconcile on reconnection.

OFF-2. Offline double check-in MUST be detected at reconcile; the online ballot box remains authoritative for the cast decision, and conflicts MUST resolve to the provisional path with a published reconciliation entry.

OFF-3. Every reconciliation discrepancy MUST be published. A discrepancy that is only visible internally is not reconciliation.

9 · If electronic casting is used (Profile B only)

EV-1. Cast-as-intended verification MUST use a genuine Benaloh challenge: the voter may spoil an encrypted ballot and have it opened and proven, repeatedly, before committing. Displaying the plaintext the client already holds is not verification and MUST NOT be described as such. The current implementation shows the JavaScript variable it just encrypted, which proves nothing about what was transmitted.

EV-2. An independent verification application, built by a different team from the voting client, MUST be available. Software independence is the goal; a single vendor verifying itself is not verification.

EV-3. Re-voting MUST be available for the entire casting window (NUL-2). It is the primary defence against vote-buying and off-camera coercion, and it MUST be explained to voters in plain language.

EV-4. All voter-facing surfaces MUST ship a strict Content-Security-Policy, HSTS, Subresource Integrity on every script, and no third-party script of any kind. Marketing sites in the current corpus have stronger headers than the voting client, which is exactly backwards.

EV-5. Client integrity limits MUST be published on the voter-facing site, in plain language, including the fact that a compromised device can misrepresent a ballot and that this is not solved.

EV-6. A paper fallback MUST exist and MUST be reachable by any voter who asks, without justification.

10 · Vote centers (county-wide polling places)

A precinct assigns a voter to exactly one building. A vote center lets any eligible voter in the jurisdiction cast a ballot at any participating location. This is not a novel idea and not a risky one: it is an established alternative to neighborhood precincts, authorized in Texas by statute under the Countywide Polling Place Program, and studied — Stein and Vonnahme found vote centers raise turnout, with the gain concentrated among infrequent voters, and Larimer County, Colorado recorded roughly 3,000 additional voters after adoption.

It also happens to be the deployment model this architecture is best suited to, because the thing that makes vote centers hard is exactly the thing BB2G already builds: a trustworthy, synchronized record of who has already voted.

VC-1. A vote center MUST be a supervised polling place under the authority of the election official, staffed by sworn election workers during posted hours, with the ballot of record on paper (PRO-1 is unaffected — a vote center is an in-person location, not internet voting).

VC-2. Vote centers MUST NOT be unsupervised kiosks. A voting machine standing unattended in a retail lobby has no chain of custody, no accessibility support, no provisional-ballot path, and no one to detect tampering between voters. Where the site is not staffed, the correct device is a ballot drop box, not a voting machine.

VC-3. Site eligibility. A location MAY host a vote center only if it satisfies all of: full ADA accessibility of the path of travel and the voting station; a lockable room or securable area under sole election-official control during the voting period; documented power and network redundancy; a written use agreement; no electioneering and no commercial solicitation within the statutory buffer; and no site whose ordinary business requires the voter to make a purchase, present a receipt, or interact with a private employee to reach the voting station.

VC-4. Consequently: city hall, courthouses, public libraries, community centers, schools, recreation centers, county service buildings and fire stations qualify and are the standard set. A post office MAY host one only under a written USPS agreement, as federal property is not the county's to allocate. Grocery stores, shipping stores and other private retail SHOULD NOT host vote centers — the specification does not forbid a jurisdiction from trying it, but the buffer, custody, accessibility and employee-proximity conditions of VC-3 are rarely satisfiable in a leased retail footprint, and the failure mode is a contested location rather than a contested ballot.

VC-5. Real-time check-in is mandatory, and it is the hard requirement. Because a voter may appear anywhere, every vote center MUST share one authoritative, continuously reconciled record of who has checked in. Electronic poll books are what make vote centers possible, and the known failure is synchronization lag — a documented window in which a fast, deliberate voter can cast at two locations.

VC-6. The check-in service MUST therefore satisfy all of:

VC-7. Provisional path. A voter whose eligibility cannot be confirmed at the site MUST be offered a provisional ballot and a tracking receipt, and MUST NOT be turned away. A voter flagged by the check-in service as possibly already voted MUST be offered a provisional ballot, not a refusal — the flag means please verify, exactly as everywhere else in this system.

VC-8. Custody. Every ballot container, poll book device and memory device moved to or from a vote center MUST be sealed with a recorded seal number, transferred under dual control (CON-3), and logged with a custody token that rotates at each hand-off (TOK-3). A vote center multiplies the number of custody hand-offs by the number of sites; this is the principal operational cost of the model and MUST be resourced before adoption, not after.

VC-9. Placement MUST be documented. The jurisdiction MUST publish, before the election, the criteria used to select sites and the resulting map, with an explicit analysis of travel time and transit access by neighbourhood. Vote centers reduce the number of locations; consolidation that lengthens the trip for voters without cars is the model's real equity risk, and it MUST be measured rather than assumed away.

VC-10. Adoption MUST be incremental: a low-stakes organizational election first (Profile B or C), then a single-race public election, with a published post-election report covering wait times, check-in latency observed, reconciliation events raised, and provisional-ballot rate at each site.

11 · Post-quantum cryptography

This section exists because the post-quantum work was real, was well done, and was not in this specification — it lives in kristenslab/quantum-safe, quantum, quantum-suite, quantum-lab and halo, none of which were among the 23 elections repositories. Nothing in the elections corpus references a PQC primitive; searched exhaustively, the only occurrences of "quantum" across all 1,700 elections files are four reserved subdomain names in command-center/data/fleet.json.

That gap matters more here than in a messaging app. An election produces artifacts intended to remain verifiable for decades: signed audit-log heads, custody records, published Merkle roots, ownership proofs. Every one of them is currently signed with Ed25519, which is exactly the primitive quantum-safe/lib/assess.ts correctly classifies as quantum-vulnerable. An adversary who records the public record today and acquires a cryptographically relevant quantum computer later does not need to break the election — they need only to forge a signature over a rewritten history and become indistinguishable from the archive. Harvest-now-forge-later is the elections-specific form of the threat, and it is worse than harvest-now-decrypt-later because ballot secrecy is protected by blinding rather than by long-lived encryption.

What is already built (verified, not claimed). halo/lib/pqc.ts implements hybrid key establishment using QSF_ml_kem768_p256 from @noble/post-quantum — the IETF PQ/T generic hybrid KEM combiner over ML-KEM-768 (FIPS 203) and ECDH P-256, with HKDF domain separation. That is the correct construction, taken from a library rather than hand-rolled, and it is the single most reusable piece of cryptography in the portfolio. quantum-safe/app/api/qrng/route.ts mixes ANU photonic entropy into the OS CSPRNG by XOR, so the output is never weaker than crypto-grade even when the remote source fails. HYBRID-PQC-PLAN.md is honest about what is not built: ML-DSA authenticity, forward secrecy, and crypto review.

PQ-1. Hybrid, never replacement. Every migration MUST run the classical and post-quantum primitive together and derive from both, so the artifact holds if either primitive survives. A bare PQC signature MUST NOT replace a classical one on the ballot path.

PQ-2. Signatures are the priority, not encryption. In this system the long-lived exposure is signing: audit-log entries and heads (LOG-3), key transition records (KEY-5), custody receipts, witness cosignatures, and published roots. These MUST migrate to a hybrid Ed25519 + ML-DSA-65 (FIPS 204) signature before any artifact is described as durable, and the verifier MUST require both signatures to validate.

PQ-3. The blind-signature credential is explicitly out of scope for now, and this MUST be stated rather than glossed. RFC 9474 blind RSA has no standardized post-quantum equivalent with equivalent blindness guarantees at this time. Substituting an unreviewed lattice blind signature on the credential path would trade a distant threat for an immediate one. The credential is also short-lived — one election — which is the case where harvest-now-forge-later does not apply. Revisit when a standardized scheme exists; do not improvise.

PQ-4. Symmetric primitives stay, sized up. AES-256-GCM and SHA-384 or higher MUST be used wherever a choice exists; Grover halves effective strength and does not break them. Nullifiers, HMAC tokens, the hash chain and the Merkle tree are already quantum-resistant in structure and MUST NOT be redesigned in the name of PQC.

PQ-5. One shared module. The hybrid primitives MUST live in a single packages/pqc inside bb2g-elections (ONE-1), derived from halo/lib/pqc.ts, wrapped by the JS↔Python parity gate (ONE-5), and MUST NOT be re-implemented per application. The plan's own recommendation — package the Halo module as a shared helper, review it once, then review each integration — is adopted here as normative.

PQ-6. Entropy. Ballot serials, nullifier salts and key material MUST come from the platform CSPRNG or the HSM. Quantum entropy MAY be mixed in by XOR under the qrng pattern, and MUST NOT ever be the sole source: a remote entropy service is an availability dependency and a third-party trust point on the ballot path. This also closes the Math.random finding by giving the serial path one sanctioned source.

PQ-7. Claim discipline, extended. The four posture states of ADD-TO-ALL.md — vulnerable, planned, hybrid, ready — are adopted for every elections component, and no component may display hybrid or ready until the GATE-1 cryptographer has signed off on the shared packages/pqc module and on that component's integration. As of this version every elections component is vulnerable; that is the honest label and it MUST be shown.

PQ-8. Crypto-agility as a first-class requirement. Every signature, key and log entry MUST carry an explicit algorithm identifier alongside the key epoch (KEY-5), and every verifier MUST be able to validate historical algorithm sets it no longer issues. The Key Transition Log is the mechanism: it already records epochs, and it MUST record the algorithm suite per epoch so that a 2026 Ed25519 head and a 2030 hybrid head are both verifiable in 2040 by the same tool.

PQ-9. Migration order for elections, mirroring the plan's staging: packages/pqc extracted and reviewed → audit-log heads and witness cosignatures → key transition records → custody receipts → poll-book and check-in ledger records → election result declarations. Voter-facing tracking codes migrate last, because they are short-lived and changing their shape breaks published receipts.

12 · One build

ONE-1. All elections code MUST live in a single repository, bb2g-elections, with npm workspaces plus one Python workspace, one CI pipeline, one container build for Tiers 2–3, and one confidential-VM deploy kit for Tier 1. Twenty-three repositories, each with exactly one commit and no CI anywhere, is the condition v3 exists to end.

bb2g-elections/
├── packages/          blindfold-py (reference) · blindfold-js (parity-gated)
│                      log · strongroom-engine · custody · election-registry
│                      election-engine · identity · keyvault · pqc · house-ui
├── apps/              registrar[T1] · bulletin[T2] · verifier[T2]
│                      pollbook[T3] · checkin[T1] · tally[T0] · election-command[T2]
├── sites/             _generator + 15 static surfaces
├── docs/              spec/ (single copy) · architecture/ · ADR/ · NAMING.md
├── deploy/            attest/ build/ systemd/ net/ tiers.md
├── tools/             gates/ poison/ media/
├── Dockerfile  compose.yaml  Makefile
└── .github/workflows/ ci.yml · parity.yml · deploy.yml

ONE-2. There MUST be exactly one implementation of the Merkle/log layer. Six exist today, in two mutually incompatible tree shapes, which means two live BB2G sites cannot verify each other's roots. custody-layer/src/lib/merkle.mjs handles both shapes correctly and MUST be the base.

ONE-3. There MUST be exactly one MBLTS custody engine (three exist), one election-command module registry (two exist, 68 versus 70 modules), and one copy of the governing specification document (four exist, three of which still carry the withdrawn "anchoring" vocabulary).

ONE-4. Cross-package dependencies MUST be declared in package manifests. Sibling-checkout coupling through $HOME MUST NOT be used — it currently makes the corpus unbuildable as delivered and requires two repositories that were never named.

ONE-5. CI MUST run on every push and MUST include: build, unit tests, the severance poison gate, the Merkle-shape poison gate, and the JS↔Python parity gate. The parity gate is the only thing standing between two crypto implementations and silent divergence, and it currently runs on one laptop or not at all.

ONE-6. strongroom-engine is marked retired but is the only repository that ever implemented external anchoring. That implementation MUST be recovered into packages/log before the repository is archived; retiring it deleted the one piece of code that made LOG-2 possible.

ONE-7. Two architecture decision records MUST be written before any migration code: ADR-001 Merkle shape, and ADR-002 key rotation versus long-term audit verifiability (resolved here by §5.5, to be recorded).

ONE-8. Migration MUST proceed so that no live domain breaks: extract shared packages and stand up CI first, converge the log format second, merge duplicated implementations third, and move DNS last.

13 · Before anything binding

GATE-1. A named cryptographer MUST review the protocol against a named commit, and the report MUST be published.

GATE-2. Election-law counsel MUST review the enrollment tiers, due-process guarantees, RON legality, and records retention per jurisdiction.

GATE-3. The retention and disclosability decision of IDV-5 MUST be signed before any session is recorded.

GATE-4. No public statutory deployment MUST occur before an organizational pilot has run with a paper fallback and a published audit report.

GATE-5. Code, proofs, and audits MUST be published. Verifiability is the product; an unpublished verifiable system is a claim, not a verification.

Appendix A · Requirement index

Appendix B · Adjacent BB2G systems this specification draws on

The 23 elections repositories are not the whole portfolio, and three systems outside them hold work that this specification adopts rather than reinvents. This appendix exists so that a future v4 does not repeat the v3.0 mistake of specifying in isolation something that was already built next door.

ONE-9. packages/pqc MUST be derived from halo/lib/pqc.ts, and the custody and break-glass implementations in packages/keyvault SHOULD be derived from sentinel-id rather than written fresh, since that code has a test suite and the elections break-glass path has a replay defect (KEY-7). Any adoption MUST be recorded in an ADR naming the source commit.

Appendix C · Source provenance

Every requirement in this document derives from, corrects, or resolves a conflict between the following files in the kristenslab repositories, read at the commits present on 27 August 2026:

lockchain/kit25/elections/safe-elections-v2-spec.md · lockchain/kit25/elections/safe-elections-update-spec.md · lockchain/kit25/strongroom/strongroom-spec-v2.md · lockchain/kit25/three-sites-spec.md · strongroom/docs/SPEC.md · election-integrity/site/downloads/Election-Integrity-on-StrongRoom-SPEC.md · safe-elections/site/downloads/Election-Integrity-on-StrongRoom-SPEC.md (the corrected copy, adopted as canonical) · strongroom-elections/{site,dist}/downloads/Election-Integrity-on-StrongRoom-SPEC.md · safe-elections-isolation/kit/docs/full-voting-system-architecture.md · safe-elections-isolation/kit/docs/org-election-mvp-architecture.md · safe-elections-isolation/kit/deploy/ISOLATION-ARCHITECTURE.md · safe-vote/SPEC.md · verified-vote/docs/VERIFIER-SPEC.md · bb2g-election-command/docs/architecture/*.md · bb2g-election-command/docs/security/SECURITY_ARCHITECTURE.md · checks-and-balances/PRIVACY_AND_AUDIT.md · strongroom-workflow-demo-2026/.project/spec.yaml

Post-quantum requirements in §11 derive from quantum-safe/HYBRID-PQC-PLAN.md, quantum-safe/ADD-TO-ALL.md, quantum-safe/lib/assess.ts, quantum-safe/app/api/qrng/route.ts, and halo/lib/pqc.ts with halo/pqc.test.mts — five files in two repositories outside the elections corpus, read 9 September 2026.

External standards referenced: RFC 2119, RFC 6962, RFC 9474, NIST SP 800-63A, ISO/IEC 18013-5, W3C WebAuthn Level 2, ElectionGuard, Sigstore.

Specification, not legal or security advice. The severance step, the remote-proofing attack surface, and the transparency-log trust domain are the three places to spend the most review. Engage a cryptographer and election-law counsel before any binding use.

Born Between 2 Generals, LLC · 2026