So Vote logo

SO VOTE

consensus that scales

An open-source decision-making platform built on a simple belief:

giving people a direct, meaningful voice in decisions that affect them reduces conflict, improves coordination, and leads to better outcomes.

Not just voting on outcomes — but shaping how decisions themselves are made.

Learn More
The Challenge

One person, one vote
8 billion lives.

Binary polls and one-off votes don’t scale to real human complexity.

Large groups need ways to express nuance, surface disagreement, adapt over time, and still move forward together.

The Strategy

Solve small-group consensus first

Learn, adapt, and repeat.

Focus on building a general system for collective decision-making that works in small groups such as:

Book Clubs
Open Source Projects
Informal Events

Then scale to larger, more complex communities.

A Definition of Consensus

Consensus not unanimity

Here, consensus is a state where:

1.
Enough people have participated
2.
Sufficient agreement has emerged
3.
Less than half the population objects

Consensus is maintained, not locked in.

Decisions can evolve as the group evolves.

From a High Level

Core Requirements

The qualities we need in the system to meet the challenge

Nuanced
Go beyond yes/no. Support ranked choices, parameters, text, numbers, and structure.
Easy
Meet users where they are. Participation should feel natural, intuitive, and even enjoyable.
Comprehensive
Every aspect of every decision - including the rules themselves - must be open to discussion and vote.
Modular
The scope is unknown. The system must be unopinionated, extensible, and composable.
Scalable
Design for growing groups and increasingly complex domains.
From Core Requirements to...

A Solution

So Vote models decisions as living objects that groups can propose, shape, challenge, and refine over time.

Instead of voting once on a fixed question, participants interact with shared subjects that evolve through structured input.

A closer look at

How It Works

1. A subject is proposed by a user
2. The group contributes votes, comments, and objections
3. Conflicts and disagreements are made explicit
4. Consensus emerges through participation and convergence
5. The subject becomes active - and remains open to revision
6. Later, the subject loses consensus and becomes inactive
Introducing

The Cast

Building blocks that combine to produce a flexible and scalable voting platform.

The SubjectThe Subject icon

The core unit of decision-making.

A subject represents something to be decided - a proposal, rule, value, or outcome.

Its behavior is defined by its subject type. (see here for an initial list of subject types)

A subject:
1.
Starts inactive
2.
Becomes active once its criteria are met
3.
Remains active as long as the group continues to support it
4.
May change result over time without restarting the process

Subjects can feed into one another - for example, one subject defining the engagement threshold for another.

The UserThe User icon

An individual participant whose identity is verified by the host or wider community.

The GroupThe Group icon

A purpose-oriented container for users and the subjects they collectively decide.

Subjects can be shared between groups allowing specialist groups to provide artifacts for other groups to make use of.

For Example:

A group known for specialising in inclusive behavioural standards could agree on a code-of-conduct (CoC) which is then adopted by another group.

Updates to the CoC automatically propagate to the adopting group.

That group can choose, at any time, to change the source of their CoC or they may decide to adopt a custom standard internally.

Groups can also be hosted and managed by different organisations while still being connected; a pattern known as "federation".

This maintains some of the ease-of-use qualities of a centralised system while offering organisations full autonomy (and responsibility)

The VoteThe Vote icon

A user’s input on a subject.

The form of a vote depends on the subject type.

For example:
text for text subjects
rankings for ordered lists
numbers for numeric subjects
etc.

Votes are positive expressions of intent or preference. Objections are covered below by Rejections.

RejectionRejection icon

A universal safeguard.

Any subject - regardless of type - can be rejected by a simple majority.

A rejected subject is marked illegitimate and becomes inactive.

This prevents the system from being captured by:
Unreachable thresholds
Unfair rules
Structurally undemocratic decisions

Authors of a rejected subject can simply create a new subject in a form that has wider appeal

No rule is above the group (except this one).

AssociationAssociation icon

A relationship between subjects.

Associations allow subjects to influence or reference one another.

What an association means depends on the subject types involved.

Influence Example:

A Percent subject feeding into the engagement threshold parameter of another subject

Reference Examples:

A Comment subject associated with a target subject
A Conflict subject associated with two or more subjects deemed incompatible
An initial set of building blocks

Subject Types

These are the building blocks that all decisions are made out of.

They can be used individually or composed by other subject types to represent more complex outcomes.

Each subject type will have distinct criteria, result behaviour and vote input format, though, many will share characteristics (e.g. all subject types will have an engagement threshold parameter)

Subject parameters can either be set to specific values when the subject is created or derive their values from the result of other Subjects.

Text

Text image

A free text subject.

Users can make their own suggestion or up-vote someone else's.

Number

Number image

A subject for reaching consensus around a number.

Binary

Binary image

The simplest type of subject; producing a yes/no result.

Conflict

Conflict image

Represents a conflict between two or more subjects.

Once a conflict has been accepted by the community, they may or may not choose to take action such as de-activating or changing the value of subjects.

Shape

Shape image

Represents the shape and parameters of an entity. For example a group name would be a text subject with between 1 and 200 characters.

List

List image

An ordered list of entities. Users can set their order preference of existing items as well as adding new items themselves

Comment

Comment image

A comment associated with another subject.

From building blocks

Constructs

While the platform is unopinionated, it's useful to examine the types of structures communities could build to inform the underlying design.

A set of subject categories:

Values

A set of high level values agreed by the community.

E.g. "We believe every life has equal value."

These values guide more concrete group decisions and activities and provide a wide problem-space from which communities can find solutions that meet the needs of all.

Information

A collection of authoritative, objective information accepted by the community.

E.g. Academic research, photographic evidence, news reports, etc...

Theories

Ideas proposed by the community off the back of accepted information

Policies

Ongoing agreements within the community.

E.g. The chair person, code of conduct, market strategy, etc...

Activities

Short lived and well defined activities executed within the context of one or more policies.

E.g. as part of our marketing strategy, deploy a Facebook ads campaign to increase awareness.

The Roadmap

Where are we now and where are we going?

PoC

2025

A Proof of Concept to clarify the domain. Repo available here

Landing Page and Manifesto

Feb 2026

Set out the mission and obtain initial input from interested parties. Locate and onboard team-members.

Minimal prototype

Mid 2026

Working version that can be used to demo to potential users

Dogfooding

Late 2026

Use the platform to organise the development of the platform. See term explanation.

Deployment with test partners

Early 2027

Onboard test partners to start gaining real-world feedback

Cryptographic safety

Late 2027

Introduce tamper proofing measures

Cloud provider detachment

Early 2028

Generalise so the platform can be deployed in a variety of environments: Multi-cloud, on-prem, home.

We need you

Get Involved!

Register for updates:

Apply to join the development group: