Method: The candidate registry & election receipts

Before anyone can score a platform, compare a ward, or tell a voter what's actually out there, someone has to answer a duller question first: who is running, and where can a resident go read what they've said for themselves? This is the method behind that registry — the base layer everything else on this site stands on. It exists so that no downstream page ever has to guess at a candidate's web presence; it has to check a dated, sourced row instead.

What it produces

A structured registry covering every registered candidate in every race we track, with each row carrying a State-of-the-Election receipt: not just a claim that a candidate has a website or a platform document, but the date that claim was last actually verified and where it was verified. Downstream, this registry is the only thing our platform-scoring process is allowed to score — it never scores a candidate's web presence from memory or assumption, only from what this registry says, on the row's own face, has been confirmed and when.

How it works, step by step

The registry is built and refreshed in two connected passes.

Race and candidate refresh. For each municipality, someone goes back to that municipality's own clerk or elections office page — never a third-party mirror or aggregator — and re-confirms who is on the ballot and how many candidates are registered in each race. Any field that can't be re-confirmed on a given pass is carried forward rather than blanked out, so the registry never silently loses information it once had. Every change is written as a complete proposed update, never edited in place, and a single accountable person merges those updates into the live registry — never two people writing to the same record at the same time.

Candidate web-presence search. Finding a candidate's actual website, social accounts, and platform documents runs as a staged search. First, a broad automated sweep checks clerk listings, searches the web, and crawls likely campaign pages, producing proposed matches — never writing directly into the live registry. Second, those proposed matches are sorted into confidence tiers: verified, probable, an unconfirmed lead, genuinely unsure, or not found. Third, every "unsure" call, every case where two different candidates' proposed links collide, and a meaningful random sample of everything else is personally re-checked by a person before any of it is trusted. Only after that human check does anything move into the live registry, through one single, disclosed, rule-bound process — never a free-for-all where any tool or pass can write to the record directly. A final pass checks confirmed sites for basic safety and hygiene issues, and a separate pass specifically hunts for a subtle failure mode: a website that matches a candidate's name but actually belongs to a same-named person or place somewhere else entirely.

How it's checked

The registry is built so that no single pass, tool, or person can quietly corrupt it, and so an outsider has concrete things to check us against.

• Every uncertain call gets a second, independent look. Anything the automated sweep marks "unsure," and any case where two candidates' proposed web links collide, is personally re-verified by a person before it's trusted — not sampled, all of it.
• A meaningful share of everything else is independently audited too. A real, disclosed percentage of both the accepted and the rejected proposals is spot-checked against the live source. If that audit turns up more than a small, stated error rate, the whole batch is held back rather than applied — we would rather publish less, later, than publish wrong.
• One route in, and it's logged. Nothing enters the live registry except through that single verification-and-apply step, and every change it makes is recorded, so any row's history can be reconstructed.
• A dedicated sweep for name/place confusion. After any large batch of updates, a separate check specifically looks for websites that were matched on a name but actually belong to a different person or a different place, across the whole registry, not just the new rows.
• Nothing is silently deleted. If something is later found to be wrong — a misattributed website, a bad match — it's withdrawn into its own dated, retracted record rather than erased, so the correction itself is checkable.
• The date is the receipt. Every row states plainly when it was last confirmed. We never describe the registry's size or coverage as a fixed, standing fact in prose — only as a dated snapshot, because a registry like this is out of date the moment it's finished and the honest thing is to say so on every row.

If you want to challenge a specific entry, the challenge that actually works is: what date was this confirmed, and against what source? That's the question the registry is built to answer for every row, and the question we'd expect anyone auditing us to ask.

What it honestly costs

The scarce resource here is not software, it's sustained human attention. Automated sweeps and first-pass sorting can run on lighter-weight tools with no real judgment involved — that part is mechanical. But the parts that actually make the registry trustworthy — re-checking uncertain calls, auditing samples, deciding what counts as "verified," merging updates without collision — require a person applying real judgment, and that doesn't scale down. In one real working session on this registry, a single verification pass covered roughly two thousand ambiguous candidates through staged automated sorting followed by a few hundred rows of hands-on human review — that's one real run, not a guaranteed rate, and it's the kind of evenings-and-weekends effort a motivated small team can sustain, not something that happens by itself.

Known limits

We'd rather name our own gaps than have someone else find them first.

• There is no single, start-to-finish checklist for this process yet — the steps exist, but they currently live across several separate working documents rather than one instruction a new volunteer could follow end to end without guidance.
• The audit-sample rule — check a meaningful share, hold back the batch if error rates run high — is currently enforced by people disclosing their own results honestly, not by a mechanical gate that would refuse to let ungated data through automatically. That's a real gap, and closing it is a live priority.
• When two updates to the same record are merged together, there isn't yet a hard technical guarantee that a merge can never lose previously verified information — this has happened, been caught, and been hand-fixed more than once. A standing safeguard against it is designed but not yet built.

What stays internal, and why

The schema, the staged search sequence, and the verification bar are exactly the parts we publish here, because those are what let someone else replicate and check this work. What stays internal: the raw, in-progress proposal streams before they've been verified, and unreviewed working notes that can carry speculation or research-in-progress language not fit to stand as a public claim about a real person. And one rule we hold absolutely: this registry catalogs who is running and what they've published — it never characterizes or criticizes a candidate. That judgment, where it happens at all, happens in a separate process, in aggregate only, and never here.

If your municipality is holding an election and you want to build this yourself, the method above is the whole thing — start with Run this in your municipality for what comes first, second, and third, and see How we verify for how we hold every claim on this site to a receipt regardless of who or what drafted it.

— The Unknown Soldier · uniteTOlove · Toronto