Section 12 · Section 15
Reconciliation
Every token issued must reconcile to exactly one current state, every day. Anything that does not balance has an owner and a documented resolution — not an explanation offered afterwards.
A day of operations
Run a batch of packages and balance the book
This issues real tokens and walks each through a randomly drawn but lawful path, then runs the
engine's reconcile() against the resulting ledger.
The daily categories
Fourteen buckets, counted every day of active operations. The point is not the numbers themselves — it is that a package which is in none of them, or in two, is visible immediately rather than in December.
| Category | What it counts |
|---|---|
issued | Tokens created and assigned to an authorized package |
printed | Physically produced in a controlled print batch |
spoiled / destroyed | Withdrawn before mailing, with a documented reason |
mailed | Entered the mailstream |
undeliverable | Returned by the postal service without reaching the voter |
received | In the election office’s physical possession |
cure required | A correctable defect identified under governing law |
cured | A cure response recorded as adequate for continued review |
accepted | Passed lawful validation |
rejected | Not accepted, with a recorded lawful reason |
voided | Withdrawn under an authorized documented procedure |
reissued | Replaced by a separately issued successor token |
spent | Accepted, separated under dual control, and consumed |
open exceptions | Anything the count cannot explain — each with an owner |
The print batch reconciles too
Before a single envelope reaches a voter there is a second book to balance, and it is the one that catches problems earliest: created = mailed + spoiled + retained. Tokens created, printed, spoiled, destroyed, mailed and retained must all account for one another.
Retained is the interesting bucket — issued but never entered the mailstream. It is the pile that has to be physically counted in a cage at the end of the day, and a retained count that does not match the shelf is the earliest signal available that a print run went wrong. The button above computes it from the events already in the log, without inventing event types the specifications do not define.
What reconciliation is actually for
It is tempting to read this as bookkeeping. It is not. A reconciliation that does not balance is the earliest signal available for every serious failure mode in the system: a scanner writing events for packages that do not exist, a batch of envelopes sitting in the wrong tray, a bulk void that hit sixty more tokens than intended, or an insider removing records.
The chain and the anchors tell you the log has not been altered. Reconciliation tells you the log matches the paper. Those are different questions, and only one of them can be answered by cryptography.
Counts reconcile; contents never do. Accepted and spent totals are reconciled against anonymous ballot and batch totals — the number of ballots in a tabulation batch, not which ones. That comparison is possible precisely because it operates on counts, and it is the only join permitted across the boundary. Why that boundary holds →
What a pilot would measure
Seven measures, from the design document. Note what is absent: none of them is a count of voters, and none requires knowing anything about a ballot.
| Measure | Why this one |
|---|---|
| Percentage of issued packages reconciled | The headline number. Anything below 100% is a list of specific envelopes with specific owners. |
| Percentage of postal and election-office events ingested | Separates a postal integration problem from an intake problem — they have different fixes and different owners. |
| Duplicate/replay detection rate and resolution time | Detection alone is not the goal. An exception nobody closed is an exception nobody handled. |
| Median time from receipt to status notification | The number a voter actually experiences. A cure they learn about too late is a cure that did not exist. |
| Cure-notification timeliness and completion rate | The one measure where the system either enfranchises somebody or does not. |
| Audit-log signature and hash verification success rate | Must be 100%. Any other figure means the tamper-evidence is not working, whatever the cause. |
| Confirmed absence of voter-to-vote linkage in tabulation data | The pass/fail one. Established by adversarial review, not by inspecting a schema. |
A pilot has to measure success without creating voter-surveillance risk — which is itself one of the open decisions a jurisdiction must answer before coding. A metric that requires per-voter tracking to compute has already given away the thing the system exists to protect. Every measure above is an aggregate over packages, not over people.
Public reporting
Aggregate and privacy-reviewed. A jurisdiction publishing "3,481 received, 42 in cure, 19 rejected for signature defect" is transparency. The same table broken down until a cell contains one person is disclosure wearing transparency's clothes, and the review exists to catch exactly that.