Method: The harvest — collecting what residents actually say
Before you can represent what a community wants, you have to actually ask it — and ask in a way people trust enough to answer honestly. The harvest is how we collect short, real input from residents: one-line visions, complaints, nominations, and longer expert opinions, in person and online, without turning anyone’s private words into a liability for them or for us.
What it produces
A growing body of first-person public input, held in one place built specifically to hold it — never mixed with any list of verified real names or contact identities we hold elsewhere. What’s counted publicly is aggregate: how many contributions, how many group conversations, published honestly rather than inflated. Individual submissions are never the public-facing artifact; the patterns and the aggregate counts are.
How it works, step by step
- Someone has to be responsible for the data before collection starts. Nothing is collected until a real, named person is accountable for how submissions are handled — that’s decided before the first form goes live, not after.
- Public input lives in its own dedicated place. The harvest is kept entirely separate from any list of verified supporters or contacts. Mixing an anonymous complaint with a verified identity, even by accident of storage, is exactly the kind of harm this separation exists to prevent.
- Two ways in. A short web form takes one-line input directly online. A paper-sheet path lets someone collect input at an in-person event on paper, then enter it digitally afterward — a photo of the sheet is used only to transcribe it, then deleted.
- A quick form for a quick thought. The default ask is short on purpose: a vision, a complaint, or a nomination in a line or two, so the bar to contribute is low.
- A deeper door for those who want to say more. Anyone with a longer expert opinion, a research link, or a fuller statement about the future can go further in — that contribution is clearly labeled as such at the moment it’s made, not relabeled later.
- Group conversations count as themselves. An in-person conversation with a real headcount is logged as a room, distinct from a single online submission, so we don’t conflate one voice with a room full of them.
- Counts are published honestly, or not at all. The public count of conversations and submissions is held at an honest zero until the threshold for what counts as a genuine group conversation is actually set — we do not round up or estimate to make an early number look more impressive than it is.
- A regular, encrypted handoff to the one accountable person. On a set schedule, the accumulated data is bundled, encrypted so only the accountable custodian can open it, and handed off. Nothing about this handoff runs automatically without someone choosing to run it.
- Anyone can ask to be deleted. A contributor can request their own submission be removed at any time, and that path has been tested against the real system, not just assumed to work.
How it's checked
Here, the privacy architecture is the method — not a bolt-on, the actual audit surface a challenger should look at. Consent is recorded in an append-only way: once logged, a consent record cannot be quietly edited or deleted later, only added to through the proper withdrawal path — and this is enforced at the database level, not just by staff discipline or a policy that could be skipped under pressure.
In any classroom or youth setting, a minor’s submission is anonymous by default — the system is built to refuse to store a child’s email address at all, under any mode, enforced the same hard way as the consent rule. Only a parent’s or teacher’s contact might exist, and only where a receipt path makes sense.
Personal data never enters our public repository or our general working files. The place that holds submitted content is a single, dedicated store built for exactly this purpose — nowhere else in our systems keeps a copy of what someone actually wrote. And deletion is honored: a self-serve request removes a submission, and that path has been tested against the real system twice, once against a simulated version and once against the real thing, because a simulation only ever proves what its author remembered to imagine.
What it honestly costs
Building the intake system itself — the form, the paper-to-digital path, the group-room mode, the deeper door for longer input, the counting logic, the export and delete tools — ran as one connected build effort, not scattered across many separate passes. Beyond the build, what it costs on an ongoing basis is attention: a real decision about who the accountable data custodian is, deliberate handling of any sensitive configuration (never handled casually), and a standing decision about when a count of conversations is genuine enough to publish. None of that is free, and none of it is optional if you want people to actually trust you with their words.
Known limits
Said plainly, because this is the section where honesty matters most: most of this system has been tested against a realistic, fully simulated version of itself — including the encrypted handoff to the accountable custodian — but not yet against a live custodian’s real encryption key, because that requires a real custodian relationship at the other end first. The receipt-sending path — a confirmation message back to someone who leaves an email — is currently a placeholder that doesn’t yet send anything; the promise it makes (a one-click way to stop future contact) is proven, but the sending mechanism itself is not wired up yet. And the rule for what counts as a genuine online group conversation, as opposed to a single submission, hasn’t been defined yet — it’s deliberately left at zero rather than guessed at. None of these gaps are hidden; they’re named here so anyone relying on this method knows exactly where the proven ground ends.
What stays internal, and why
The accountable custodian’s specific handling procedures once data leaves our system, and the technical configuration of exactly how the intake tool is built and hosted, stay internal — a reader doesn’t need those details to trust the promise, and publishing them would only make the system easier to abuse, not easier to audit. What matters publicly is the architecture described above, and that promise holds regardless of which tools sit behind it. The one rule that never bends: personal data does not belong in a public repository, and it never will.
Want to build this for your own community? Start here: Run this in your municipality. Curious how we decide anything is true before we publish it at all? Read How we verify.
— The Unknown Soldier · uniteTOlove · Toronto