Election Command

The executive finding

Not sixty election applications. One platform with sixty-eight modules.

The blueprint's central conclusion changes the architecture: BB2G should not be built as sixty independent election applications. It should be one election-operations platform with domain modules sitting on a small number of shared, hardened services — most importantly LockChain, identity and authorization, evidence, offline synchronization, jurisdiction rules, source currency, notifications, reporting and observability.

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

Counts are read from assets/registry.mjs at build time, not typed into this page. The completion matrix states plainly which of it is built and which is specified.

The boundary that governs everything else

The blueprint makes this a permanent design doctrine, and it is implemented as one rather than written on a slide. 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.

So the word used here is tamper-evident, never "immutable". A privileged attacker who possesses every database, signing key, checkpoint and backup could fabricate a replacement history. Separating signing keys from application databases, rotating and auditing them, protecting checkpoints and retaining independent verification material is what makes that expensive — not the hash chain by itself. The four layers each name what defeats them.

Four layers, not one hash

Run the checks in your own browser

Observation is not a conclusion

The evidence ladder is in the schema, the APIs and the UI — not in a style guide. The engine refuses to let a machine-generated record claim a rung above ANOMALY, and refuses a machine-authored narrative containing a conclusion word.

DATA→OBSERVATION→ALLEGATION→ANOMALY→EVIDENCE→FINDING→CONCLUSION

The software is permitted to say "Expected seal value differs from observed value. Review required." It is not permitted to say fraud, criminal conspiracy, election tampering, intentional suppression or malfeasance on its own account. Those are conclusions requiring evidence and, in some contexts, legal determinations. A named human reviewer may reach them; the machine may not author them. The ladder in full.

It has to work when the network does not

Offline operation is mandatory, not a degraded mode. The field application stores an encrypted local subset and turns every write into a queued event with an honest status. BB2G must not become the weak link that says "No internet. App unavailable."

The sync path and the status vocabulary · The role surfaces

Arizona law controls the procedure. NIST informs the safeguards.

The blueprint's most important correction to the earlier source hierarchy: an EAC recommendation does not automatically outrank controlling state law. The resolver here never ranks a federal issuer above a state one — it asks which instrument binds, in which jurisdiction, on which question, as of when. How authority resolves.

Beside the voting system, never inside it

This is an election operations, custody, evidence, safety, compliance, cybersecurity and auditability platform. It is not a voting or tabulation system, it holds no voter selections, and there is no "one-click connect to tabulator" feature anywhere in it. The shared services and the network boundary.

Rolled out the way you would actually roll it out

Shadow and training deployment first, against synthetic data, where nothing becomes the controlling official record. Then a limited operational pilot on low-risk functions running in parallel with the controlling county process. A full rip-and-replace before a general election would be poor engineering risk management. The progression and the acceptance list.