Deployment strategy §1
The order matters more than the ambition
Maricopa is already operating under its published 2026 Primary and General Elections Plan, and the current architecture includes established command, field-support, Vote Center, offline and courier processes. The blueprint’s judgement about what that means for deployment is unambiguous: a full rip-and-replace before the 2026 General Election would be poor engineering risk management.
Stage one
Shadow and training deployment
The platform runs against synthetic and training election data. A small number of managed iPads reproduce:
- opening
- closing
- incident intake
- help / emergency
- equipment-reference checks
- seal scanning
- supply checks
- simulated custody
- offline synchronization
Nothing becomes the controlling official record yet. The purpose of this stage is to find out whether the software survives the actual human environment — not whether it works in a demonstration.
Stage two
Limited Maricopa operational pilot
After county approval, select low-risk operational functions. The first strong candidates:
- incident intake
- support-ticket orchestration
- poll-worker procedural guidance
- accessibility inspections
- equipment inventory / reference
- seal tracking
- supply logistics
- chain-of-custody receipts that run in parallel with the controlling county process
Note the last one carefully. Custody receipts run in parallel with the controlling county process. They do not replace it, and during this stage they are not it.
Stage three
Full county operating layer
Only then does the rest arrive:
- command center
- dispatch integration
- digital custody
- evidence
- audit
- after-action
- policy / version management
- AI procedural retrieval
- records / compliance
- cyber operating picture
This is the first stage at which the platform is doing what the product description claims it does, and it is the third stage rather than the first for a reason.
Stage four
Arizona, then national
Arizona’s Secretary of State states that elections are conducted independently by its fifteen counties under state oversight, and describes the state’s system as decentralized. Arizona Secretary of State — Securing Elections.
The national system is a jurisdiction-pack platform, not a national election procedure. That distinction is what makes the platform national without pretending the United States administers elections through one uniform workflow.
For ballot custody, the existing county documentation remains authoritative until the county formally accepts the electronic procedure. This is not a transitional courtesy. The EAC’s own guidance emphasises defined written chain-of-custody procedures and consistent documentation — follow every step, document the process, review it afterward. EAC — Election Security Preparedness. A platform that quietly becomes the record of custody before anyone has approved it as the record of custody has created exactly the documentation gap it was bought to close.
The county’s official election systems remain authoritative throughout.
The proposition, stated honestly
The election operating layer that unifies these workflows — not a demand to throw away what already works.
The existing systems stay, as adapters
The sales proposition should not initially be “throw away FreshService and everything else.” Maricopa’s present operational environment already uses a command center, FreshService, geospatial dispatch and a separate mobile tracking process for ballot couriers. A platform that arrives demanding all of that be discarded is asking a county to take on integration risk, procurement risk and training risk simultaneously, in an election year.
FreshService
Can initially remain an adapter.
Existing GIS dispatch
Can remain an adapter.
County election systems
Remain authoritative.
What the platform adds on top is evidence and provenance, a standardised field interaction, and a verifiable record. “That drastically lowers implementation and procurement risk.”
Before stage three ships
Production acceptance requires all thirteen
security assessment
authorization testing
offline exercise
disaster exercise
restore test
accessibility testing
records-retention review
public-records review
chain-of-custody procedural approval
training
managed-device policy
key-management test
incident-response test
A module is not complete because a page renders. Completeness means UI, API, database model, migrations, permissions, authorization tests, domain events, LockChain integration, logging, offline behaviour, error states, source dependencies, accessibility, security tests, workflow tests, documentation, backup and recovery treatment, retention treatment and operational acceptance. No green checkmark should be given for a stub.
Do not create “Arizona = Maricopa × 15”
Fifteen counties conducting elections independently under state oversight is not one county replicated fifteen times, and an architecture that assumes it is will be wrong in fifteen different places at once. The shape is a baseline with inheritance, and each county inherits only what is actually common.
Arizona baseline
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
configuration
And every configuration value records which of the two it is, with the source authority and the effective dates attached:
INHERITED_FROM_ARIZONA COUNTY_OVERRIDE_APPROVED
An override that is not recorded as an override is a divergence nobody can audit later. An inheritance that is not recorded as an inheritance is a value that silently stops tracking the state baseline the day the baseline changes. Both failures look identical from inside the application and completely different in a review two years afterwards.
National
What each state gets
Thirteen components per jurisdiction pack. Not one national procedure with local exceptions bolted onto it — the inversion matters, because a platform whose default is a national workflow will treat every state as a deviation from something that does not legally exist.
Build order, not module order. Coding modules one through sixty-eight in sequence is the wrong development strategy: sixty-eight modules built before shared authorization, evidence and event architecture are mature simply produces sixty-eight places that later have to be rewritten. Foundation first — LockChain, evidence, identity, attribute-based access control, the jurisdiction engine, source currency, the event taxonomy, offline synchronization, observability and the test kit. Then field, then custody, then command, then intelligence and records. The copilot last, and only once the jurisdiction and source infrastructure is mature enough to keep procedural answers current.