Mechanisms

A mechanism is the pure aggregation function that converts submitted choice inputs plus configured parameters into a binding outcome. Mechanisms are deterministic — same inputs, same parameters, same seed always produce the same outcome.

Mechanisms settle decisions, not every kind of room work. In the coordination profile, an action’s responsibility mode and completion policy are separate from the room’s voting mechanism. Exact artifact review requires its specified reviewers’ approval; choosing a majority mechanism for the room does not turn that review into majority voting.

Why determinism matters

Determinism makes semantic replay possible. When a receipt exposes its ballots, anyone can re-run the named mechanism with the signed parameters and compare the result with the signed outcome. This is separate from checking the JWS signature and receipt chain. Aggregate-only receipts from choice_visibility: "never" rooms do not contain enough information for ballot-level replay.

Built-in mechanisms

Mechanism	Ballot shape	Use case
`simple_majority`	single option	Binary or narrow decisions where a strict majority should be required
`supermajority`	single option	High-stakes ratification and safety gates
`plurality`	single option	Baseline multi-option selection; top option wins
`approval`	option array	Find the broadest viable intersection, especially scheduling
`ranked_choice`	ranked option array	IRV compatibility and familiar public ranked-choice semantics
`ranked_pairwise`	ranked option array	Pairwise preference aggregation for serious mechanism comparisons
`score_vote`	option-to-score map	Confidence/intensity-aware selection
`quadratic_vote`	option-to-credit map	Costly conviction under a fixed credit budget

budget_allocation, bilateral_negotiation, and conviction_vote are reserved identifiers for post-v0.1 mechanisms — not part of the v0.1 set of eight. Liquid delegation and custom third-party mechanisms remain deferred.

simple_majority parameters

The default v0.1 mechanism takes:


{
  "kind": "simple_majority",
  "options": ["yes", "no", "maybe"],
  "ballot_mode": "single_choice",
  "quorum": 0.5,                  // engine fraction; room config uses an absolute count
  "pass_threshold": 0.5,          // the winner must exceed this fraction
  "pass_threshold_comparison": "strict",
  "tie_break": "no_pass"          // no_pass | first_listed | random_seeded
}

Resolution algorithm:

Quorum check. If participation is below quorum, return outcome: "no_pass" with quorum_met: false.
Per-option tally. Sum votes per option.
Winner selection. The leading option wins only when its share exceeds 0.5. Exactly half is not a majority. If a custom generic mechanism has multiple leaders that clear its threshold, tie_break determines whether the result has no winner, uses the first listed option, or selects among the tied leaders with deterministic seeded randomness.
Output. { outcome: "pass" | "no_pass" | "tied", winner, per_option_score, cast_votes, eligible_voters, quorum_met, threshold_met, trace }.

Why “pure” matters operationally

The mechanism implementations ship in the open-source @grp-protocol/engine package. It takes a typed input and returns a typed output. No side effects, no I/O, no time-of-day dependencies. This means:

The mechanism can be re-run by any verifier holding the recorded choice inputs and parameters.
The mechanism can be tested with property-based tests (no fixtures or mocks).
The mechanism can run in a sim suite of synthetic agents to stress-test against adversarial scenarios.
Different rooms can run different mechanisms; the receipt records which.

Cross-references

Receipts — what the mechanism’s output becomes
Specification: Mechanisms — normative spec
Examples — different mechanisms across scenarios