This is the working brief for the election application. It opens with eligibility and vetting, because that is where the privacy boundary is set and every other design decision follows from it.
It then assigns every component to an isolation tier, names the single authoritative repository for each, and states what is unfinished. Nothing here is presented as certified, audited, or piloted.
The boundary that makes everything else defensible. Two systems share exactly one bit and no join key.
The identity side proves the person as hard as the law allows. Registration, eligibility, signature verification and the cure path all live there. The ballot side never learns who anyone is.
Six steps. The token begins at step five, and by then the system can no longer connect it to the person.
Identifiers inside the identity domain are namespace-scoped keyed tokens under a derived pepper — not plain hashes. The reasoning is written into the tokenization specification: a plain hash of a name and a date of birth is a rainbow table, and shipping one is worse than holding the identifiers, because it looks responsible.
{ election_id, jurisdiction, ballot_style, eligible }
No name. No registration reference. No precinct. No timestamp. A fifth field is refused at construction rather than filtered out later — the refusal is a test, not a convention.
There is no single assembled eligibility and credentialing service. The pieces above are real, tested, and in three different repositories. Assembling them into one service is genuine unbuilt work and should be scoped as such. It is the clearest near-term engineering task in the programme.
Four other vetting systems exist in the estate — harbor-intake, verifypro, verifyfirst-teams and clearance-console. They vet vendors, responders and partners, not voters. harbor-intake is the best engineered of them — identity-decoupled intake, AES-256-GCM identity sealing, revocation that re-seals — and is the right basis for poll-worker and vendor vetting later. It should not be pulled into the voter path now.
Isolation strength is assigned by what a workload can touch — not by a blanket rule.
An earlier draft of this architecture asserted a strict “VM everywhere, never containers” doctrine on the grounds that containers share a kernel. That framing is out of date and was withdrawn in version 3 of the specification. It would not survive review by a competent infrastructure engineer, and it costs credibility that the rest of the work does not need to spend.
The accurate position is the three-tier model below. It is stricter than the old rule where strictness matters, and cheaper everywhere else.
Ordered by what should be stood up first. Each names one authoritative repository, its isolation tier, the evidence that supports it, and the gap that remains.
Stated openly, because a reviewer who finds one of these unlisted will discount everything else. None of them require a new invention.
When a credential is superseded, that fact is currently recorded as a mutated flag rather than as a chained event. It must become an appended event included in the hash preimage, with state derived from the log and the mutable attribute deleted. Half a day plus tests, and it is the first item.
Per-event separation timestamps and fine-grained ordering can narrow a small precinct. The fix is a batch seal with a minimum batch size, a two-officer shuffle attestation, published times rounded to the batch, and a stated minimum reporting unit. Two to three days.
One path proves a ballot is well formed. Two do not. Until they do, those paths should not be described as end-to-end verifiable.
Key setup currently assumes a trusted dealer rather than distributed generation, and produces no ceremony record. This is the item most likely to be raised by an external cryptographer, and the one that most needs a written procedure rather than more code.
The shipped verifier accepts an attestation that should be rejected as stale, and a rule chain check does not start at step zero. The corrected function already exists and needs promoting. Hours of work.
The published record is only meaningful if publication is compelled and at least one party outside the organisation witnesses the root. Neither is wired in yet.
The write-once-read-many position and the tamper-evident-not-immutable position are stated inconsistently across documents and must be reconciled in one place. Separately, the module count is written as 60 in one document, 68 in another and 70 in the platform of record; only the 70-module build is reachable. Pick the number.
Deployments are serving from the wrong account. Every deployment named after a repository in the organisation account is in fact git-linked to a personal-account twin — the operations platform, the custody service, the vault surfaces, the verifiable-voting surface, the document repository. This is the direct answer to “where does authoritative source live”: today it is not where the deployment name implies. One account must be chosen and the links re-pointed.
Two live sites have no recoverable source. All twenty-five election hosts were checked directly on 27 August 2026. Twenty-three are correctly excluded from indexing — by response header, by robots.txt, or by page metadata, and most by all three. Two are not: elections.bornbetween2generals.com and electionlaw.bornbetween2generals.com.
The indexing gap is the smaller half of the problem. Neither project is linked to a repository, and no repository matching either name exists in either account. Both are serverless deployments serving production traffic from a one-time upload whose source is not in version control. The exclusion cannot be added without the source, and the source cannot be extracted from a running deployment.
Left publicly reachable deliberately, at the owner's instruction, pending the redeploy. Neither host is password-protected.
One rule is requested out of this: no host may carry a custom domain unless its project is git-linked to a named repository. Twenty-three hosts follow that pattern and are correctly protected; the two that do not are the two that failed.
Election Day is Tuesday, 3 November 2026 — sixty-eight days from today.
The overseas and military ballot wall is Saturday, 19 September 2026 — twenty-three days from today.
The second date is the one that shapes the schedule. Anything intended to touch a real 2026 ballot has twenty-three days, not sixty-eight. That constraint is the reason the mail-ballot custody component leads this inventory and the verifiable-voting work does not: custody can be stood up and audited inside the window, and the cryptographic tally argument cannot.
The verifiable-voting track is the 2028 argument. It should begin the week after the midterms with a published external cryptographer review — not before.
The three tiers above, mapped to named Azure services, with the numbers the platform team needs to act on. The full engineering specification carries the derivation; this is the part that must be agreed in the meeting.
Confidential OS disk encryption binds the disk keys to the machine's own TPM, bypassing the hypervisor and host operating system, and it enables Secure Boot. It cannot be changed after the machine is deployed. Getting it wrong means rebuilding the custody machine from scratch. The decision is: on, with a customer-managed key. Similarly, a signing key created as exportable is exportable for life — every key must be created non-exportable.
Azure enforces virtual-processor quota at two levels for each subscription in each region: a total regional quota, and a separate quota per virtual-machine family. A subscription can hold ample regional quota and still fail to deploy because the family quota is zero, and a grant applies only to the region named in the request. So the ask is stated as two numbers, not one.
Azure Database for PostgreSQL Flexible Server, General Purpose Standard_D4ds_v5 in production — four vCores, 16 GiB, zone-redundant high availability with the standby in a separate zone, 512 GiB of storage rated to 6,400 IOPS, and point-in-time restore set to the 35-day maximum. Private access mode only, with no public endpoint at any point in the server's life — a database that was briefly public was public. Test runs General Purpose rather than Burstable, because Burstable throttling makes load results meaningless.
The discipline that matters more than the tier: append-only is enforced by permission, not by convention. The application role is granted INSERT and SELECT; UPDATE and DELETE are never granted at all, so a bug cannot rewrite history even if it tries. Identity data and ballot data never share a server, a credential or a backup.
A dedicated Managed HSM pool carries a flat hourly fee independent of use — roughly $2,300 to $2,400 per month before transaction charges, by independent estimate, to be confirmed in the portal for the chosen region. It is the largest recurring cost in the environment and it accrues whether or not a single signature is produced.
The mitigation is straightforward and should be agreed in the meeting: Key Vault Premium — hardware-backed, billed per actively used key — for development and test, with a dedicated pool provisioned only from the first real pilot. The application code path is identical, so nothing goes untested except the pool boundary itself.
Devcontainer with a committed toolchain and synthetic data only → signed commit on a short-lived branch → pull request with required checks, including engine-hash verification and the adversarial suites → build the container image once, sign it, attach a bill of materials → vulnerability scan gate → infrastructure declared as code, nothing created by hand in the portal → development, then test, then production, promoted by image digest rather than by tag so the artifact that ships is the artifact that was tested → attestation gate, where a custody deployment proceeds only if the measurements match → automated post-deployment verification with automatic rollback → scheduled runtime work for anchors, retention clocks and key rotation → and the eleventh stage, the one most teams skip.
Every production release emits one document: the commit hash, the image digest, the bill-of-materials hash, the test counts as reported by the run, the attestation measurements, the approver's name, and the timestamp. It is filed in the controlled document repository. This is what turns a deployment into evidence — and it is the artifact an auditor, a court or a county procurement officer will actually ask to see. Deployment authenticates by federated OpenID Connect, so no long-lived Azure secret is ever stored in GitHub.
The fifty-item platform checklist held alongside this brief states the rest — subscription and access, compute and quota, data, keys, network, pipeline, operations, and the five answers that must come in writing — with an owner and a date against each line.
The first three decide the rest.
Available in this session, ready to open next to this brief.
Carry engines byte-for-byte, hash them at ingest, recompute the hash in the reader's own browser, and never resolve a drift by updating the recorded hash. Where a port must exist, prove it against the original. Where a port need not exist, do not create one.
And the claim to distrust in any document, including this one: any statement of the form “N of N complete.” The model to copy is the completion matrix that reports zero complete rows rather than a flattering average.