Standards & sources
The blueprint's numbered sources, reproduced in full. Nothing added, no conclusion extended beyond what the source is cited for, and the tracking parameters stripped out of the links.
The reference list
This is the blueprint's own numbered source list, entries [1] through [23], reproduced as a reference list. 19 distinct documents carrying 23 reference numbers — two documents are cited more than once and are shown once, with all their numbers.
Three rules were applied, and they are worth stating.
Nothing was added. No source appears here that the blueprint does not cite. It would be easy to strengthen a reference list by adding the obvious further reading, and it would make the list stop being a record of what this architecture was actually built from.
No conclusion was extended. Each entry says what the blueprint relies on the source for. Where the blueprint states a legal position — that the Arizona EPM has the force of law, that the NIST profile is voluntary — that is the blueprint's statement about what the source says, and it is not restated here as anything more. Nothing on this page is legal advice.
The tracking parameters were stripped. Sixteen of these URLs arrived carrying
a utm_source query parameter from the research session. A reference list should hand the
reader the document, so the parameter was removed and nothing else about the URLs was changed.
3 sources
The blueprint grounds its architectural argument partly in what the BB2G portfolio already does in public. These are cited as evidence that a shared-asset philosophy already exists, not as authority on election administration.
[1] [23]
Cited for the shared-asset philosophy — applications linking to the same common stylesheet and JavaScript rather than copying them into every project — and for the portfolio measurements the blueprint quotes as of August 4, 2026. Cited again at [23] for the point that the roster is derived from live project and account status rather than manually curated, which is why the portfolio is now much larger than the sixty-module election list.
[2]
Cited for the existence of shared platform components including @bbg/ledger — evidence that a reusable-platform concept already exists inside the portfolio — and again for the conceptual direction of the existing public ledger work.
https://university.bornbetween2generals.com/bbg-university.html
[3]
Cited for the distinction the blueprint turns into permanent design doctrine: record integrity is not factual truth. Cryptography can demonstrate that recorded bytes have not been altered in defined ways; it cannot prove that an allegation contained inside those bytes is true.
5 sources
The EAC sources carry the chain-of-custody and election-security material the operations layer is built around, and the certification references the equipment group must read live rather than hard-code.
[4]
Cited for the EAC's position that election offices should maintain written chain-of-custody procedures, follow every step, document the process and review it afterward — and again in the rollout section for the emphasis on defined written procedures and consistent documentation.
https://www.eac.gov/election-officials/election-security-preparedness
[5]
Cited for the EAC's recognition of Los Angeles County's operational electronic chain-of-custody solution — implemented to digitize custody tracking, enable real-time monitoring and automate records for election equipment and materials — and for its description of the manual-process problems digitization addresses: illegible entries, missing documentation, transport handoff delays and risks of lost custody records. Cited again for programs using de-escalation and situational-awareness training for election personnel.
https://www.eac.gov/election-officials/eac-clearinghouse-award-winners-2024
[18]
Cited as the live certification source behind Module 28. The blueprint's instruction is that certification facts and counts are read from this source with a last-checked timestamp and a retained previous state — never hard-coded.
https://www.eac.gov/voting-equipment/certified-voting-systems
[19]
Cited for the point that migration to VVSG 2.0 does not itself decertify previously certified VVSG 1.0 or 1.1 systems, and that state law may impose its own requirements.
https://www.eac.gov/voting-equipment/voluntary-voting-system-guidelines
[20]
Cited for the EAC treating physical security, chain of custody, system security, incident response and continuity as interconnected election-security concerns — which is why the Incident & Safety group is not separated from the custody and cybersecurity groups.
https://www.eac.gov/election-officials/clearinghouse-resources-election-security
3 sources
The security foundation is anchored on these rather than on a proprietary BB2G security vocabulary. All of them are frameworks and guidance; the blueprint is explicit that a federal framework does not automatically outrank controlling state law on procedure.
[7]
Cited twice, and the second time is the important one. First, as the risk-based cybersecurity framework for voting equipment and the information systems supporting elections — not only voting machines. Second, for NIST's own description of the profile as a voluntary, risk-based approach, which is the basis for the blueprint's correction to the source hierarchy.
https://www.nist.gov/publications/cybersecurity-framework-election-infrastructure-profile
[8]
Cited for incorporating security into software development — how the platform itself is built. The blueprint names current NIST SP 800-63-4 (identity proofing, authentication and federation) in the same sentence under this same reference number, but its source list gives only the SP 800-218 URL. The publication is named here without a link rather than linked to a URL the blueprint never supplied.
[9]
Cited for moving away from implicit trust based merely on network location or affiliation.
1 source
One source, cited alongside the NIST profile as informing the cybersecurity layer.
[21]
Cited as a risk profile tool designed for state and local election officials, provided by CISA and the EAC.
https://www.cisa.gov/resources-tools/resources/election-risk-profile-tool
1 source
The accessibility anchor for the field surface.
[10]
Cited for WCAG 2.2 applying to web content across mobile and kiosk-like devices, and for W3C providing additional guidance on applying WCAG 2.2 principles to native, mobile-web and hybrid applications.
5 sources
The state sources. The blueprint's correction to the earlier source hierarchy turns on these: Arizona law and the EPM control the procedure, while NIST, EAC and CISA inform cybersecurity and administrative safeguards unless incorporated into controlling requirements.
[6]
Cited twice, and it is the source of the hardest boundary in the platform: current Arizona election guidance states that electronic voting-system components may not be connected to the internet, wireless communications or an external network, with an exception for e-pollbooks, and says the systems may not contain remote-access capability. Also cited for the state's requirements on equipment inventory, physical safeguards, tamper-evident seals and chain-of-custody controls.
https://azsos.gov/elections/about-elections/elections-procedures/voting-equipment
[11]
Cited for the Secretary of State identifying the 2025 Elections Procedures Manual, approved December 22, 2025, as the current manual, and stating that the EPM has the force of law.
https://azsos.gov/elections/about-elections/elections-procedures/epm
[12]
Cited for a specific observation made during the research: a resources page serving current resources also returned legacy text referring to 2020 registration deadlines. That is the reason the currency engine works at section level with source versioning and human verification, rather than scraping official websites nightly and trusting whatever came back.
[16]
Cited for current early-voting guidance expressly requiring county officials to develop and implement secure ballot-retrieval and chain-of-custody procedures, and for its description of physical controls for drop boxes.
https://azsos.gov/elections/about-elections/elections-procedures/early-voting-procedures
[22]
Cited for the state's statement that elections are conducted independently by its fifteen counties under state oversight, and for its description of the state's system as decentralized — which is why the architecture is an Arizona baseline with fifteen county configurations rather than "Arizona = Maricopa × 15".
https://azsos.gov/elections/about-elections/securing-elections
1 source
One document, cited under four reference numbers. It is the operational reality check for the command centre, the field surface, the courier workflow and the offline requirement.
[13] [14] [15] [17]
Cited at [13] for the published 2026 plan describing a staffed command-centre hotline, FreshService service-ticket records, field dispatch, offline SiteBook and printer procedures and real-time tracking. At [14] for real-time wait-time reporting, polling-place simulations, training thousands of election workers and the operational support structures around Vote Centers. At [15] for the plan's estimate of roughly 237 Vote Centers for the primary and 250–260 for the general election, which is why the interface must behave as a fleet-management surface. At [17] for bipartisan ballot couriers, a mobile application tracking courier location into the command center, the early-ballot transport statement documenting chain-of-custody requirements, the geospatial dispatch process, and the documented procedures for operating in an offline mode when connectivity is lost.
Not per page. Per section. The blueprint's reason is a thing that actually happened during the research: an Arizona SOS resources page that served current resources also returned legacy text referring to 2020 registration deadlines. The page fetched perfectly. Part of it was years out of date.
So a source that responds is RETRIEVED, never VERIFIED. Only a named human promotes a
section to verified, an old verification goes stale on its own, and a certification count is a
measurement carrying a timestamp rather than a constant in the code. The engine that implements this
is assets/authority.mjs, and the rules above are gated — including the 2020-deadline
trap itself.
Authority & currency Completion matrix
The blueprint's own closing note on its limits is reproduced on the completion matrix: the private source tree was not available for inspection during the research, so no responsible assessment could state that the modules are already implemented, identify a canonical branch for each, or certify existing code as deployment-ready. This site does not state it either.