CommonGround — Product Requirements Document

Version: 2.0 Date: 2026-04-14 Quality Score: 88/100

Executive Summary

CommonGround is a modular, open-source collective sense-making system for groups that govern shared resources. It replaces the comment-thread-and-voting model of existing governance tools with a structured deliberation process built on three core objects: Issues, Perspectives, and Decision Records.

The product embeds a constitutional governance framework — 11 principles with a two-tier hierarchy — that ensures power remains visible, contextual, and revocable. There are no fixed roles. Authority is delegated per-issue by the group and can be recalled at any time through referendum.

CommonGround is the governance engine within the broader Integral Commons ecosystem — the layer that lets any group think together well enough to govern themselves. It is the foundation the other layers build on.

Problem Statement

Current situation: Groups that govern shared resources — co-ops, land trusts, collectives, boards, community organizations — struggle to:

Existing tools fail because they focus on:

None support ongoing collective reasoning.

Proposed solution: A structured deliberation system where every issue is persistent, iteratively refined, and resolved through transparent process — with a constitutional framework that prevents power capture and ensures the group retains sovereignty over its own governance.

Primary competitor: Loomio and similar governance tools. CommonGround differentiates through structured perspective taxonomy, constitutional governance primitives, liquid delegation, civic memory, and (in Phase 2) AI-assisted sense-making.

Product Goals

Core Goals

  1. Improve quality of collective understanding
  2. Reduce cognitive and emotional load of governance
  3. Preserve decision memory (“why we think what we think”)
  4. Make disagreement legible, not adversarial
  5. Enable adaptation without fragmentation

Non-Goals

Success Metrics (Qualitative)

Success looks like:

Not measured by: DAUs, time on platform, engagement rates.

Proof of concept: People keep coming back to use it (retention as signal of genuine value).

Target Users

Primary Users

Small-medium groups (5-200 people) with real decision power:

Secondary Users

Not Designed For

CommonGround Constitutional Framework (v2)

The system enforces 11 governance principles organized in a two-tier hierarchy. The first tier is inviolable — no group decision can override these. The second tier is deliberable — groups can adjust these through their own governance process.

Tier 1: Inviolable Principles

These cannot be overridden by any decision. They protect the commons, individual rights, and the group’s ability to self-govern.

Principle 8 — Removal Due Process Members subject to removal may participate in deliberation, may not block final decisions, and are entitled to a transparent process with defined criteria and thresholds.

Principle 10 — Commons Protection No decision may privatize shared infrastructure, restrict exit rights (data, identity, participation), or undermine the revocability of governance. This principle is supreme — when it conflicts with any other principle, it wins.

Principle 11 — Forkability Any group may fork the system and its governance, provided interoperability standards are maintained.

Tier 2: Deliberable Principles

These are defaults that groups can adjust through CommonGround’s own governance process, building precedent in Civic Memory.

Principle 1 — Bootstrap The initial governance method is established via consent.

Principle 2 — Revocability All delegations are revocable. No delegation may be made irrevocable.

Principle 3 — Bounded Referendum Right Any member may initiate a referendum if supported by a minimum threshold of members or stake relevant to the decision’s scope. Prevents spam and introduces signal.

Principle 4 — Scope and Subsidiarity Decisions should be made at the lowest level competent to address them. Only those materially affected participate in referenda.

Principle 5 — Temporal Stability Delegations and decisions have defined stability periods during which they cannot be challenged except under exceptional conditions. Prevents governance thrashing.

Principle 6 — Rate Limiting Members are subject to limits on how frequently they may initiate referenda or governance actions within a given time window. Prevents overload and bad-faith actors.

Principle 7 — Deliberation First All referenda must include a structured deliberation phase before voting.

Principle 9 — Participation Integrity Decisions require quorum thresholds, diversity of participation (to avoid capture), and transparent rationale.

Conflict Resolution

When deliberable principles conflict with each other (e.g., Bounded Referendum vs. Temporal Stability), the tension becomes an Issue that the group resolves through CommonGround, creating precedent in Civic Memory. Inviolable principles always take precedence.

Core Conceptual Model

Central Object: Issue / Problem Space

An Issue is:

Each Issue flows through statuses: Open > Exploring > Decided > Reopened > Archived

Authority Model: Liquid Delegation

There are no fixed roles (no admin/member class distinction). All members have equal base capabilities. Authority is contextual:

Bootstrap Process

  1. Founder creates the space, names it, describes its purpose
  2. Founder invites members
  3. System opens the group’s first Issue: “How should we make decisions?”
  4. Founder proposes the initial governance profile
  5. Members add Perspectives and may object
  6. Resolved via hardcoded consent process (the one decision that uses the meta-method)
  7. The result becomes the group’s first Decision Record — visible, revisable, the foundation of their Civic Memory

Functional Requirements (Phase 1 — MVP)

Issue Creation and Structure

Each Issue includes:

Required fields:

Structured sections:

Status transitions:

Perspectives (Not Comments)

Users submit Perspectives — first-class objects, not threaded comments.

Default perspective taxonomy (configurable per-space):

  1. Values — “This matters because…”
  2. Risk — “What could go wrong…”
  3. Equity — “Who’s affected, who’s excluded…”
  4. Feasibility — “Can we actually do this…”
  5. Relational — “How does this affect us as a group…”
  6. Temporal — “How does this play out over time…”

Additional flags:

Phase 1 behavior:

Groups can: rename types, add types, remove types, via YAML/JSON configuration.

Decision Records

When a decision occurs, the system captures:

A Decision Record is required to move an Issue to “Decided” status. This is system-enforced.

Civic Memory / Issue Timeline

Each Issue has a timeline showing:

Purpose: preserve “why we think what we think” — the group’s institutional memory.

Quorum System (Three-Tier)

Stall mechanism: If awareness quorum isn’t met within the deliberation period, the system extends the period and the digest highlights the Issue. If still unmet after extension, the Issue is marked “Stalled — insufficient participation” and cannot proceed to decision.

Manual Summaries

Notifications and Rhythm

Spaces

Authentication and Access

Data Export

Decision Method Architecture

The MVP ships with one decision method: consent-based process.

Pluggable Architecture

The decision method layer is designed as a pluggable module. Groups select their method per-Issue or set a default. The consent method is the default.

Future Methods (Roadmap)

Research and implementation roadmap for additional decision methods:

Community can contribute additional methods via the open-source module system.

Customization and Modularity

Open-Source Architecture

Groups can: add fields, rename concepts, disable features, fork freely.

Governance Profiles (Phase 3)

Optional starting-point configurations:

Fully customizable. Published as community-contributed templates.

UX Principles

Technical Requirements

AI Sense-Making Layer (Phase 2)

Capabilities

Hard Constraints

AI does NOT:

AI outputs are:

Architecture

Phased Roadmap

Phase 1: The Human-Powered System (3-4 months)

Phase 2: AI Layer + Decision Methods

Phase 3: Federation + Ecosystem

Risks and Mitigations

RiskProbabilityImpactMitigation
Over-structuring alienates usersMediumHighConfigurable schemas, sensible defaults, Slow UX
AI mistrust undermines sense-making layerMediumMediumFull transparency, editability, opt-out, Phase 2 (not launch dependency)
Power capture despite constitutional frameworkLowHighVisible delegation, referendum right, Commons Protection principle
No pilot user — building in a vacuumHighHighPublish governance framework first for community feedback, seek design partners actively
Adoption friction for non-technical groupsHighMediumHosted deployment, governance setup wizard, lightweight defaults
Tool becomes symbolic (not tied to real decisions)MediumHighDecision Records required for status change, Civic Memory creates accountability
Solo dev scope exceeds capacityHighMediumPhase 1 is human-powered (no AI dependency), ruthlessly narrow MVP
Bootstrap paradox — groups can’t agree on initial governanceLowMediumHardcoded consent meta-method, founder proposes, group affirms or adjusts
Silent majority — decisions made by small active subsetMediumHighThree-tier quorum, stall mechanism, awareness tracking
Constitutional principle conflicts create gridlockLowMediumTwo-tier hierarchy, inviolable principles take precedence, conflicts become Issues

Two Artifacts

1. The CommonGround Governance Framework

A standalone, published, versioned document describing the 11 constitutional principles, the liquid delegation model, the bootstrap process, the two-tier hierarchy, and the decision method architecture.

2. CommonGround the Software

The reference implementation of the governance framework.

Future Vision: Integral Commons Ecosystem

CommonGround is the foundation layer of a broader ecosystem:

These modules build on CommonGround’s governance primitives and are years away. The constitutional framework and deliberation system must prove themselves first.

Glossary

This PRD was developed through interactive requirements gathering and adversarial stress-testing. Quality score: 88/100. Remaining gaps: detailed acceptance criteria per feature, accessibility requirements, performance targets, authentication architecture, business model.