Read this first. BB2G Election Command is a specification-complete, foundation-built artifact. It is not a deployed county system, it is not running an election, and no part of it holds a real record. There are no databases, no migrations, no APIs, no authorization tests, no deployed services and no offline device synchronization in this build.
What is built is the spine: the LockChain engine, the crypto substrate, the authority and currency engine, the module registry, the gates that poison-test them, and a verifier the reader can run in their own browser. That is a real foundation and it is worth exactly what it is worth. This page is where the distance between the foundation and a production system is written down instead of glossed.
Why this page has almost no green in it
The blueprint sets the rule and gives the example:
“No green checkmark should be given for a stub.”
“Claude cannot mark Module 17 — COMPLETE because
/ballot-chain-of-custody renders.”
A rendering route is not a module. So every cell below was scored against a rule that is printed on this page beside the column it applies to, and no cell is marked ✓ unless a real file or a passing test can be pointed at for exactly what that cell claims. Across 68 modules and 11 dimensions — 748 cells — there are 40 marked ✓, and they are all in one column. 0 modules have a full row of ✓. The correct number of modules that read COMPLETE is zero, and that is what this reads.
The matrix
68 modules × 11 dimensions. Scroll the table sideways; the module column stays put.
✓ built & gated — 40 ◐ specified with an acceptance gate — 402 — not started — 210 n/a not applicable — 96
| Module | UI | API | DB | AuthZ | Audit | Offline | Security | Accessibility | Currency | Tests | Docs |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 01 · Master Election Command Center | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 02 · Election Calendar & Milestones | — | — | — | — | ◐ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 03 · Jurisdiction Configuration Engine | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 04 · Election Readiness Score | — | — | — | — | ◐ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 05 · Election-Day Operations Console | — | — | — | ◐ | ◐ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 06 · After-Action Command Center | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 07 · Polling-Place Opening | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 08 · Polling-Place Closing | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 09 · Poll Worker Management | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 10 · Poll Worker Training | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 11 · Polling-Place Checklist | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 12 · Supply & Inventory Management | — | — | — | ◐ | ✓ | ◐ | — | ◐ | n/a | ◐ | ◐ |
| 13 · Wait-Time / Capacity Monitoring | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 14 · Accessibility Compliance | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 15 · Ballot Inventory | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 16 · Ballot Transfer | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 17 · Ballot Chain of Custody | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 18 · Mail-Ballot Workflow | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 19 · Provisional-Ballot Workflow | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 20 · Ballot Reconciliation | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 21 · Ballot Storage & Retention | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 22 · Voting Equipment Registry | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 23 · Equipment Testing | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 24 · Logic & Accuracy Documentation | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 25 · Equipment Seal Tracking | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 26 · Device Configuration Registry | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 27 · Maintenance / Failure Tracking | — | — | — | ◐ | ✓ | ◐ | — | ◐ | n/a | ◐ | ◐ |
| 28 · Certified-System Reference Center | — | — | — | — | ◐ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 29 · Evidence Vault | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 30 · Immutable Audit Log | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 31 · Evidence Provenance | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 32 · Photo / Video Evidence Capture | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 33 · Document Authentication | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 34 · Audit Workspace | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 35 · Evidence Export / Legal Package Generator | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 36 · Incident Intake | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 37 · Incident Triage | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 38 · Incident Escalation | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 39 · Physical Security | — | — | — | ◐ | ◐ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 40 · Emergency Response | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 41 · Threat / Safety Reporting | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 42 · Election Worker Safety | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 43 · Election Cyber Command | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 44 · Asset Inventory | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 45 · Network / System Risk Registry | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 46 · Vulnerability Management | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 47 · Access-Control Monitoring | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 48 · Cyber Incident Response | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 49 · Backup / Recovery / Continuity | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 50 · Election Anomaly Review | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 51 · Cross-Jurisdiction Pattern Engine | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 52 · Timeline Correlation | — | — | — | ◐ | ◐ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 53 · Relationship / Entity Mapping | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 54 · Human Review & Disposition | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 55 · Public Records Repository | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 56 · FOIA / Public Records Request Manager | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 57 · Statute & Regulation Library | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 58 · Retention Rules Engine | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 59 · Policy / Procedure Management | — | — | — | ◐ | ✓ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 60 · Compliance Evidence Generator | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | ◐ | ◐ | ◐ |
| 61 · Observer Management | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 62 · Warehouse Logistics | — | — | — | ◐ | ◐ | ◐ | — | ◐ | n/a | ◐ | ◐ |
| 63 · Election Communications | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 64 · Facility Acquisition | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
| 65 · Courier Operations | — | — | — | ◐ | ✓ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 66 · Election Scenario Exercises | — | — | — | ◐ | ◐ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 67 · MDM Fleet Management | — | — | — | ◐ | ◐ | ◐ | ◐ | ◐ | n/a | ◐ | ◐ |
| 68 · Vendor Assurance | — | — | — | ◐ | ◐ | n/a | ◐ | ◐ | n/a | ◐ | ◐ |
Every row carries the same status: FOUNDATION ONLY — not started as a
module. No row is BLOCKED, because nothing has got far enough to be blocked. Generated at build
time from assets/registry.mjs and assets/lockchain.mjs; the
40 ✓ marks are the 39 modules whose aggregate type the engine implements,
plus the ledger module itself.
The rule this page exists to obey
No green checkmark should be given for a stub.
What each column means, and how it was scored
The first paragraph in each card is the blueprint's definition of the dimension. The second is the rule this build applied, so a reader can check the scoring rather than trust it.
UI
Every workflow in the module is reachable and operable in the role surfaces that own it, with real error states — not a rendering route.
How this column is scored here. — for every module. No module UI exists in this repository. Workflows, role surfaces and an acceptance gate are written down for all of them, which is a specification, not a screen.
API
Documented endpoints for every workflow, with validation, idempotency and versioned request/response contracts.
How this column is scored here. — for every module. There is no endpoint, no request/response contract and no validation anywhere in this build.
DB
Database model and migrations for the module’s primary objects, including correction links rather than in-place edits of history.
How this column is scored here. — for every module. Primary objects are named in the registry. There is no schema, no migration and no persistence of any kind.
AuthZ
RBAC + ABAC permissions with jurisdiction scope, least privilege, and authorization tests that prove denial as well as access.
How this column is scored here. ◐ where the module declares the Identity & Authorization Core; — where it does not. Nothing is ever ✓: there is not one authorization test in this repository, and an authorization claim without a denial test is worth nothing.
Audit
Domain events emitted to LockChain with canonical hashing, signed receipts and independent verification material.
How this column is scored here. ✓ where the aggregate type this module’s events would attach to is implemented in assets/lockchain.mjs and exercised by a passing gate — canonical hashing, hash chain, signed checkpoint, independent verification. It is a statement about the ENGINE. The module that would emit those events is not built. ◐ everywhere else, because every module declares LockChain.
Offline
Defined offline behaviour: encrypted local queue, idempotent replay, honest sync state, and a locally-saved state that can never be mistaken for a server acknowledgement. May be N/A where the module is not a field surface.
How this column is scored here. ◐ where the module declares the Offline Sync Core; n/a where it is not a field surface. The sync-state ladder itself is implemented and gated in the engine, which is why no cell here is blank — but no module queues, replays or acknowledges anything.
Security
Security tests, secret and key handling, logging of security events, and no unauthorized control channel to any voting system.
How this column is scored here. ◐ where the module carries a named constraint with an acceptance gate; — where it does not. No security test exists for any module.
Accessibility
WCAG 2.2 conformance for the web and kiosk-like surfaces, including the mobile and hybrid application guidance.
How this column is scored here. ◐ for every module. WCAG 2.2 is specified as a platform-wide requirement. Nothing has been measured against it, by anyone, on any surface.
Currency
Source dependencies registered with section-level dates, supersession and stale-source warnings, with human review. May be N/A where the module depends on no external authority.
How this column is scored here. ◐ where the module declares the Election Knowledge Currency Engine; n/a where it depends on no external authority. The currency engine and its abstention rule are built and gated; no module is wired to them.
Tests
Workflow tests, authorization tests and security tests that fail loudly; a stub earns no green checkmark.
How this column is scored here. ◐ for every module. Each has a written acceptance gate. None has a workflow, authorization or security test.
Docs
Operational documentation including backup/recovery treatment, retention treatment and operational acceptance.
How this column is scored here. ◐ for every module. Purpose, workflows, primary objects, domain events and the acceptance gate are written and published from the registry. The blueprint’s Docs dimension also requires backup/recovery treatment, retention treatment and operational acceptance — and that exists for no module, which is why this column has no ✓ either.
What is actually built in this repository
Measured at build time. These are the files a ✓ can point at.
| File | What it is | Size |
|---|---|---|
assets/crypto.mjs | The crypto substrate — SHA-256/512, CanonicalJSON, Ed25519 (RFC 8032, pure BigInt), Merkle, ULID. Lifted verbatim from the ballot-trail engine rather than reimplemented. | 387 lines |
assets/lockchain.mjs | The LockChain spine — canonical event fields, the hash chain, signed checkpoints, the four integrity layers, correction links, the sync-state ladder and the evidence ladder. | 710 lines |
assets/authority.mjs | The authority and currency engine — jurisdiction resolution, supersession, effective dates, section-level currency states and the Copilot abstention rule. | 284 lines |
assets/registry.mjs | The module registry — 68 modules, 10 groups, the ten shared services, the release order and these eleven completion dimensions. | 1901 lines |
The engine gates, run during this build
These numbers were not typed. Generating this page executes each engine gate in
test/ and reads the count out of the gate's own output, so a gate that starts failing
changes this page rather than being quietly left behind by it.
| Gate | Result at build time |
|---|---|
test/engine.mjs |
18/18 passed |
test/gate-authority.mjs |
14/14 passed |
test/gate-contrast.mjs |
22/22 passed |
test/gate-film.mjs |
ran, but printed no "N/M passed" line |
test/gate-provenance.mjs |
7/7 passed |
test/gate-vectors.mjs |
7/7 passed |
Not all gates reported a clean pass at build time — see the table above
The gates are poison-tested: each integrity layer has a check that breaks it on
purpose and asserts the engine catches it, because a gate nobody has seen fail is not a gate. Run them
yourself with node test/engine.mjs, or run the four integrity layers in your own browser
on verify it yourself. test/gates.mjs is a build gate: it reads the rendered site in dist/, so it runs after this page has been written and is listed here rather than run from inside it.
The governance record
The blueprint requires four documents before any module is called complete:
CURRENT_SYSTEM_INVENTORY.md, VERSION_RECONCILIATION.md,
MODULE_REGISTRY.md and MODULE_COMPLETION_MATRIX.md.
Present in docs/ at build time: CURRENT_SYSTEM_INVENTORY.md, MODULE_COMPLETION_MATRIX.md, MODULE_REGISTRY.md, VERSION_RECONCILIATION.md.
The module registry is held as executable data in assets/registry.mjs and published on
the 68; this page is the completion matrix.
The distance to COMPLETE
What would have to be true to move a row to COMPLETE
Not what would have to be built — what would have to be true, and demonstrable to somebody who does not work here. The blueprint gives two lists. Both apply.
Per module, as applicable
A module is complete only when it has all of these. Nineteen items, and a stub satisfies none of them:
UIAPIdatabase modelmigrationspermissionsauthorization testsdomain eventsLockChain integrationloggingoffline behaviorerror statessource dependenciesaccessibilitysecurity testsworkflow testsdocumentationbackup/recovery treatmentretention treatmentoperational acceptance
Production acceptance, for the county operating layer
Above the module level, the blueprint requires that production acceptance include:
security assessmentauthorization testingoffline exercisedisaster exerciserestore testaccessibility testingrecords-retention reviewpublic-records reviewchain-of-custody procedural approvaltrainingmanaged-device policykey-management testincident-response test
None of these thirteen has happened. There has been no security assessment, no authorization testing, no offline exercise, no disaster exercise, no restore test, no accessibility testing, no records-retention review, no public-records review, no chain-of-custody procedural approval, no training, no managed-device policy, no key-management test and no incident-response test. Not one of them is partially done.
Most of them cannot be done by the people who wrote the software. Authorization testing, accessibility testing and a security assessment are the kind of thing that only counts when somebody else runs it. Chain-of-custody procedural approval is not an engineering task at all — it belongs to the election authority, and until that authority formally accepts an electronic procedure the existing county documentation stays authoritative and any electronic receipt runs in parallel with it.
And one that is not on either list
A deployment. Every service in this platform is a design in a file. Moving a row to COMPLETE means a running system with a database behind it, a key held somewhere an application cannot read, backups that have been restored from at least once, and a device fleet under a managed-device policy. The rollout page describes the sequence: shadow and training deployment on synthetic data first, where nothing becomes the controlling official record, because the first thing worth learning is whether the software survives the actual human environment.
Every quotation on this page is from the blueprint. The scoring rules are this build's, and they are printed above so they can be argued with. If a rule looks generous, it is meant to be read as generous — the honest reading of this matrix is that a foundation exists and a product does not.