Many Voices, One Plan
Fifteen people in a room want fifteen different things. The usual fix is a consultant’s report nobody implements. Here’s what we do instead — and why the billing rule matters as much as the method.
Every community that starts talking seriously about owning its own AI infrastructure hits the same wall, and it isn’t technical.
The library wants patron privacy and public terminals. The school district wants something that survives a superintendent change. The city IT director wants one more system he doesn’t have to babysit. The farm bureau wants to know what it does for irrigation scheduling. The county commissioner wants to know what it costs and who gets blamed. Somebody in the back is against the whole idea because the last data center that came through town promised jobs and delivered a fenced lot.
Every one of those positions is correct from where the person is standing. That’s the problem. It isn’t that people disagree — it’s that nobody has a way to turn six correct partial views into one plan that all six will still support in eighteen months.
What “change management” usually means
Usually it means this: an outside firm arrives, runs interviews, produces a handsome deck, presents it, and leaves. The deck describes a future state. Nobody in the room built it, so nobody in the room owns it. Six months later the deck is in a drawer and the consultant is invoicing someone else.
That model is extractive in the most literal sense. The expertise arrives from outside, the money leaves to outside, and what stays behind is a PDF. The community is a customer, not an author.
We think the opposite is possible: that the shared vision has to be built by the stakeholders themselves, in public, with their disagreements preserved in the record rather than smoothed over. Our job is to hold the process and supply the tooling — not to hand anyone the answer.
The six phases
The method isn’t ours originally. It came out of project-based learning work already running with real teams, and it has six phases:
| Phase | What happens | You can’t leave until |
|---|---|---|
| Spark | Name the actual community problem, sharply | There’s a written problem statement and at least three confirmed people |
| Speculate | Diverge. Generate options without judging any of them | At least three distinct options are on the table |
| Plan | Converge. Pick an approach and scope it | There’s a workplan with a named owner and a target date |
| Assess | Score every option against a rubric the group agreed to | Every option carries scores from at least two different people |
| Rank | Order what gets built first | There’s a ranked list, not a wish list |
| Kickoff | Commit — team, roles, charter | Roles are assigned and a charter exists |
Read the right-hand column again, because that’s the whole design. Those aren’t suggestions. They’re exit criteria, and in our tooling they’re checked against the database — not against anyone’s assertion that the work got done.
Where the blending actually happens
If you want to know where fifteen views become one plan, it’s phases two and four, and they work by opposite mechanisms.
Speculate forces divergence before judgment. Most community meetings collapse the moment the first plausible idea appears — everyone piles onto it because agreement feels like progress. Requiring three real options before anyone may advance is a structural defense against the loudest person in the room setting the agenda by speaking first.
Assess forces every option to survive more than one perspective. The rule that each option needs scores from at least two different members against a rubric the group wrote is doing quiet, heavy work. The librarian scores the privacy criterion. The IT director scores maintainability. The commissioner scores cost exposure. Nobody has to pretend to expertise they don’t have, and no single view can carry an option through on its own.
What comes out the other side isn’t consensus in the mushy sense — everyone nodding at a vague statement. It’s a ranked list where the disagreements are recorded as scores against named criteria. When someone asks in month nine why the mesh went with option B, the answer is in the record, with the rationale each person wrote at the time.
And when a team moves backwards — which happens, and should — that writes a history entry too. Regression is data, not failure.
What the software adds
Facilitation alone gets you a good meeting. The tooling is what makes the outcome durable.
- The rules are enforced, not displayed. A phase board you can click through without doing the work is a progress bar, not a process. Our exit criteria are validated server-side. A blocked advance tells you exactly which criterion is unmet, which is the feedback that makes software useful rather than agreeable.
- Agents draft. People publish. AI assistance in the workspace can propose a problem statement, summarize an assessment round, or draft a charter — and everything it writes lands as a draft. There is no publish capability in the agent’s hands, by design. That’s the honest pedagogy for community work, and it’s the thing that makes this defensible in front of a school board.
- The record is yours and it’s portable. Your project content lives on your federation’s own site and exports through a standard API. If you decide to leave, you leave with everything. We’d rather compete on being worth staying with.
The billing rule is the argument
Here’s the part that separates this from a nicer-sounding version of the same extraction.
We do not charge you for compute you own.
Work that runs on your community’s own hardware is metered at zero — permanently, on every tier including the free one. We only bill for things that actually cost us money: relay traffic, inference on our stack, and calls we route to a frontier model on our account.
That isn’t generosity and it isn’t a promotion. It’s a structural position a hyperscaler cannot copy, because their margin is the inference. A business whose revenue rises every time you compute is a business that needs you never to own anything. A business that charges zero for your own compute has to earn its money somewhere that doesn’t depend on your dependence.
This is what we mean when we say we’re trying to build a regenerative economy rather than an extractive one, and it’s why we’d rather say it as a billing line than as a value statement. Values are cheap. Pricing is a commitment you can hold us to.
The rest follows the same logic: hardware we’d rather lease to you than sell you a subscription instead of, so title transfers at the end of the term and the asset ends up in the community. Support that includes teaching your own admins to run it. A free tier with no time limit and no credit card, because a community operating happily at zero marginal cost is the entire argument.
What we can’t claim yet
We’d rather you hear the limits from us.
- The workspace software is in development, not general availability. The methodology is real and running with actual teams today; the plugins that encode it are being built and piloted. If someone tells you it’s shipping, that’s a sales person getting ahead of engineering.
- We don’t have completion statistics to wave at you. We believe project-based work holds people better than a course does, because the commitment is supplied by peers rather than by badges. That’s a claim about mechanism, and we can defend it. A percentage would be a claim about outcomes we haven’t measured yet, and we’re not going to invent one.
- Peer obligation excludes as well as retains. The thing that makes this work — people showing up for each other, in person — means someone who can’t make the meeting is out in a way they wouldn’t be with a self-paced course. That’s a genuine equity cost. It has to be designed around deliberately with hybrid participation and asynchronous assessment, and any community doing this should name it early rather than discover it.
- Teams stall. Assess and Rank are where enthusiasm goes to die — which is exactly why they carry the strictest exit criteria. Anyone who’s run a community project knows this. Pretending otherwise would cost us the trust of the people best positioned to do the work.
Where to start
The first phase happens in a room, not in software. Spark is a conversation among people who already live in the same place and have a problem worth solving — and that’s Townhall.Community, which exists to help you convene one.
After that, the work has somewhere to live, the rules get enforced, and the disagreements get written down instead of averaged away.
If your community is somewhere in this — arguing about a data center, or trying to get six organizations to agree on anything — I’d rather hear what’s happening in your town than talk. Grab a slot.
