Method: Ward profiles and math cards

Toronto elects its council by ward — 25 of them. For every ward, we build one honest, non-ranking page: what happened last time, who has filed to run this time, what the Census says about the people who live there, and whatever else genuinely checkable is on file. Where we don’t have something, the page says so instead of quietly leaving it out.

What it produces

Three linked pieces per ward, built from the same underlying data so they never disagree with each other. A one-page card for a fast read. A candidate pack — the same handout, in the same format, for every candidate in that ward, so no one gets a longer or shorter writeup than anyone else. And a fuller profile that adds the Census layer, whatever civic detail is genuinely on file for that ward, and a note on what else shares the ballot.

How it works, step by step

Before any page is drafted, every data source is checked live against its own publisher — not assumed current because it looked current last time. Ward boundaries, the 2021 Census breakdown, the City Clerk’s candidate list, and the 2022 result are each confirmed against their official source, not a cached copy.

Cards and candidate packs are generated the same mechanical way for every ward and every candidate: same fields, alphabetical by surname, no ranking and no characterizing language. A blank field reads “none on file” — never guessed, never filled in to look complete.

Profiles layer the Census summary on top, using the City’s own published ward-level breakdown, matched to the ward by its official name and number. Where a civic finding from our broader research ledger names a specific ward by name, and that finding has cleared our verification bar, it gets folded into that ward’s profile. Findings that haven’t cleared verification never appear.

Facility-level detail — libraries, community centres, parks by ward — is a known gap we chose not to paper over: until that data is sourced and checked to the same standard as everything else here, that section reads “no ward-level data,” plainly, rather than being quietly dropped from the page.

Every ward is checked against a full field-by-field coverage list before anything is published — not “does the plan say we cover this,” but “does the actual output for this ward have it.” Nothing goes live until that check runs clean.

How it's checked

This is the audit surface, and it’s meant to be challenged. The candidate and Census data behind every ward are checked live against the publisher at build time, not read off a page that might say “retired” or be stale without saying so. One ward (Ward 4) was hand-verified in full against the raw Census workbook — population, median age, income, housing tenure split, and top-five languages spoken — as a check on the whole method, and it matched exactly. If a source changes its own structure underneath us, the build is designed to fail loudly rather than quietly publish a wrong number. Every profile carries its own receipt: what was sourced, when, and a note that candidate counts are provisional until nominations close. The 2022 turnout figure is citywide only, and every page says so plainly rather than implying a ward-specific number we don’t have.

What it honestly costs

Building and regenerating all 25 wards’ cards, packs, and profiles is mechanical once the source data is checked and locked in — a same-day pass. The real cost sits upstream of that: verifying every data source is actually live and current, and then auditing the finished output field by field against that source, both took a full working session each. Keeping everything current going forward needs low ongoing attention, but someone has to actually re-run the build when the underlying candidate list changes — that step doesn’t happen by itself.

Known limits

Stated plainly, not softened. Facility-to-ward data (libraries, community centres, parks) is a named skip, not a hidden one — we found the datasets but haven’t brought them in to the standard the rest of this method holds itself to. Our broader research ledger’s ward-level coverage is thin: only a small handful of verified findings currently name a specific ward, so most wards’ civic-texture section is sparse — a real content gap in our underlying research, not a bug in how profiles are assembled. We’ve also seen published pages drift out of sync with the data behind them when the candidate list updates and no one re-runs the build — that coupling is manual today, and we say so rather than implying it’s automatic. The neighbourhood-to-ward and school trustee-to-ward mappings are confirmed not built yet for almost all wards.

What stays internal, and why

This method never handles anyone’s personal contact information. Every candidate field comes from the City Clerk’s own public registrant feed — name, office sought, published links — plus public Census aggregates. Nothing is looked up, guessed, or pattern-generated for any individual. The one place judgment is applied is civic-issue findings drawn from our broader research: a finding only gets promoted into a public ward page once it has cleared our full verification standard, never before. Every published page is written to inform a voter, never to rank, endorse, or characterize a candidate.

Want to build this for your own municipality, or check our work first? Run this in your municipality walks through what it takes, and How we verify is the general standard every claim on this site is held to.

— The Unknown Soldier · uniteTOlove · Toronto