The platform · Election Command

The executive finding

The hard infrastructure lives once

The blueprint's central argument is an instruction about what not to build:

“The central architectural mistake to avoid is creating sixty copies of authentication, evidence handling, audit logging, jurisdiction logic and synchronization. The sixty modules should be comparatively thin domain applications. The hard infrastructure should live once.”

So this is not sixty election applications. It is one election-operations platform with 68 domain modules sitting on top of a small number of shared, hardened services. The modules are thin on purpose. Every one of them names which services it consumes, and the counts below are read from the registry rather than claimed — a service consumed by everything and a service consumed by twelve modules are different kinds of risk, and the platform should be able to say which is which.

Counted at build time from assets/registry.mjs: 10 services, 68 modules.

The ten shared services

The Production responsibility column is the blueprint's own text for each service, reproduced verbatim. The third column is measured: how many of the 68 modules declare that they consume it.

The ten shared platform services, their production responsibility and how many modules consume each
Shared service	Production responsibility	Consumed by
LockChain Ledger Core	Event canonicalization, hash chain, signed receipts/checkpoints, correction links, independent verification	68
Evidence Core	Immutable originals, derivatives, provenance, classification, legal holds, custody and evidence manifests	46
Identity & Authorization Core	MFA, managed devices, RBAC + ABAC, jurisdiction scope, least privilege, privileged-access review	65
Offline Sync Core	Encrypted local event queue, idempotent replay, conflict handling, server acknowledgements	28
Jurisdiction Rules Engine	State/county/election applicability, effective dates, controlling authority and procedure selection	51
Election Knowledge Currency Engine	Source retrieval, section hashes, changes, supersession, stale-source warnings and human review	12
AI Election Copilot	Citation-grounded procedural retrieval with mandatory abstention when current authority is unavailable	1
Notifications & Escalation Core	Alerting, acknowledgements, escalation timers, delivery history	42
Reporting & Document Core	PDF/CSV/JSON outputs, custody receipts, evidence packages, audit reports and manifests	61
Observability & Security Core	Application health, security events, sync failures, source freshness, backup health and operational telemetry	24

On one word in that table. The Evidence Core line is the blueprint's verbatim text and it is left exactly as written. It is describing how evidence originals are stored. It is not the word this project uses about LockChain: the blueprint is explicit that even four integrity layers should be described publicly as tamper-evident, and the engine's own describeLimits() refuses the stronger word outright. The four layers page shows why.

Why it is a platform and not a page

The same Evidence Core is intended to serve elections, investigations, public records and child-safety work. That is what makes it infrastructure rather than sixty copies of the same idea.

The security foundation

Established public standards, not a proprietary security vocabulary

The blueprint is direct about this: the security foundation should be built using established primary standards rather than a house dialect invented for the occasion. A proprietary vocabulary cannot be audited by anyone outside the company, and an election office cannot procure against it. Four anchors, and one accessibility standard.

NIST Cybersecurity Framework — Election Infrastructure Profile

The risk-based cybersecurity framework for voting equipment and the information systems supporting elections — not only the machines. It is the risk-management anchor for the whole cybersecurity group.

And the part that is easy to skip: NIST itself describes the Election Infrastructure Profile as a voluntary, risk-based approach. That is why nothing in this platform treats a federal framework as a mandate, and why the authority resolver will not let one outrank controlling state law on procedure.

https://www.nist.gov/publications/cybersecurity-framework-election-infrastructure-profile

NIST SP 800-218 — Secure Software Development Framework

The framework for incorporating security into software development. It governs how the platform itself is built, which is a separate question from how an election is run.

https://csrc.nist.gov/pubs/sp/800/218/final

NIST SP 800-63-4 — identity proofing, authentication and federation

The current identity guidance behind the Identity & Authorization Core: MFA, managed devices, RBAC and ABAC, jurisdiction scope, least privilege and privileged-access review.

The blueprint names this publication in the same sentence as SP 800-218 and gives one URL for the pair. Rather than guess at a second link, this page names the publication and leaves the reader to it. See standards & sources.

NIST SP 800-207 — Zero Trust Architecture

Support for moving away from implicit trust based merely on network location or affiliation. A tablet inside a county building is not trusted because it is inside a county building.

https://csrc.nist.gov/pubs/sp/800/207/final

WCAG 2.2 — the iPad and mobile interface

WCAG 2.2 applies to web content across mobile and kiosk-like devices, and W3C provides additional guidance for applying its principles to native, mobile-web and hybrid applications. The field surface is a kiosk-like device in a public building on election day; accessibility is not a later pass.

https://www.w3.org/TR/WCAG22/

CISA / EAC Election Risk Profile Tool

A risk profile tool built for state and local election officials. The blueprint cites it alongside the NIST profile as informing the cybersecurity layer.

https://www.cisa.gov/resources-tools/resources/election-risk-profile-tool

These are cited, not implemented. Naming a standard is not conformance to it. Nothing on this site has been assessed against SP 800-218, SP 800-63-4, SP 800-207 or WCAG 2.2 by anyone. The completion matrix is where that is said row by row.

The build order

Foundation first, and the reason why

Trying to code modules 1 through 60 in numeric order is the wrong development strategy. The blueprint gives the sequence and the reason in one sentence:

“Sixty modules built before shared authorization, evidence and event architecture are mature simply produces sixty places that later have to be rewritten.”

1. Foundation release

LockChain, evidence, identity, ABAC, jurisdiction engine, source currency, event taxonomy, offline synchronization, observability and the test kit come first. Sixty modules built before shared authorization, evidence and event architecture are mature simply produces sixty places that later have to be rewritten. These are the modules that are the shared spine rather than consumers of it: the jurisdiction configuration engine, the evidence vault and its provenance, the immutable audit log, the identity and access layer, and the managed-device fleet the field surfaces will depend on.

Modules: 032930314767
Count: 6 of 68

2. Field release

Tablet shell, opening and closing, checklists, incidents, emergency, equipment and seals, accessibility and supplies. This is the release that meets the actual human environment, so it is where offline behaviour, the HELP control and evidence capture have to be proven under real conditions. Poll-worker management, training and observer management ship alongside because the field release is what they staff and certify.

Modules: 070809101112131422232425262736373840414261
Count: 21 of 68

3. Custody release

Ballot inventory, transfer, custody, reconciliation, evidence, audit, retention and legal hold. Ballot transfer plus chain of custody plus LockChain is the strongest candidate for an initial county pilot, and it runs in parallel with the controlling county process until the county formally accepts the electronic procedure. Media capture, document authentication, the audit workspace, the legal package generator and courier operations ship here because they are what makes a custody claim verifiable by someone outside the application.

Modules: 151617181920213233343565
Count: 12 of 68

4. Command release

County and state operating picture, dispatch, logistics, after-action and cybersecurity. Once the field and custody layers are emitting real events there is something for command to see, and the cyber operating picture, physical security, warehouse logistics, facility acquisition, communications and scenario exercises complete the operating layer that sits over them.

Modules: 010205063943444546484962636466
Count: 15 of 68

5. Intelligence / records release

Anomaly review, timelines, entity mapping, disposition, public records, legal library and compliance. Review only makes sense once there is a trustworthy event record to review, and the legal source library and policy management built here are the infrastructure the Copilot release then depends on. Vendor assurance ships with this group as a compliance surface.

Modules: 505152535455565758596068
Count: 12 of 68

6. Copilot release

Only after the jurisdiction and source infrastructure is mature enough to keep procedural answers current. Both modules here are answer surfaces whose correctness is entirely a function of source currency: the readiness score rolls up evidence that must be fresh and must never be read as proof of election validity, and the certified-system reference centre must show source-last-checked, current status and the source record rather than any hard-coded certification fact. Neither can be trusted before the currency engine and the human-verification loop are mature.

Modules: 0428
Count: 2 of 68

6 releases covering 68 of 68 modules, with none unplaced. Read from RELEASES in assets/registry.mjs; hover a number for the module name, or read the whole map on the 68.

The hardest boundary in the platform

Beside the voting system, never inside it

Equipment & Technology is the module group that decides whether this product is procurable at all. Arizona's current 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. The state also requires equipment inventory, physical safeguards, tamper-evident seals and chain-of-custody controls.

BB2G Election Command

Operations, custody, evidence, safety, compliance, cybersecurity and auditability. Inventory identifiers. Approved metadata. Manual and scan workflows. Authorized offline files. A specifically approved isolation or import architecture.

The voting system

Tabulation and the electronic voting-system components. Not connected to the internet, wireless communications or an external network, with an exception for e-pollbooks. No remote-access capability. The county's official election systems remain authoritative.

There is no “one-click connect to tabulator” feature, and there never will be. It is not a missing feature or a later phase. A control channel from an operations platform into a voting system is the thing this architecture exists to not have.

Equipment enters BB2G through inventory identifiers, approved metadata, manual and scan workflows, authorized offline files, or a specifically approved isolation and import architecture — and nothing else. Module 22 carries it as a standing constraint: registry, service history and certification references, with no unauthorized control channel.

The same discipline applies inside the cybersecurity group. A vulnerability scanner can itself create operational risk, so Module 46 carries a hard control: a voting-system target detected means the automated scan is blocked unless an explicit authorization and an approved test plan exist. “Cybersecurity” should never become the justification for casually probing an election system.

Arizona guidance: https://azsos.gov/elections/about-elections/elections-procedures/voting-equipment. Every source on this page is reproduced with its blueprint reference number on standards & sources, and source currency is checked per section rather than per page — see authority & currency.