Introduction to the Pangea Treatise
This document introduces the foundational ideas behind Pangea — a framework for digital governance that bridges deliberative democracy with modern distributed systems. The full treatise is maintained separately; this page provides an architectural and philosophical orientation.
What is Pangea?
Pangea is a governance layer for communities that need structured decision-making without centralized authority. It combines:
- Proposal lifecycles with commit-reveal voting
- Role elections and transitive delegation chains
- Guardian oversight with sunset windows and emergency pauses
- Real-time collaboration via CRDTs on Cloudflare Durable Objects
Pangea does not prescribe a single governance model. It provides composable primitives that communities assemble into constitutions.
The name reflects the ambition: a connected landmass of self-governing groups, federated but sovereign.
Core Principles
Three axioms guide every design decision in the Pangea ecosystem.
Subsidiarity
Decisions should be made at the lowest competent level. A group that can resolve
a dispute internally should never need to escalate to a federation-level
tribunal. The guardian module enforces this by evaluating trigger conditions
before activating cross-group mechanisms.
In code, the trigger evaluation looks like this:
const report = await guardian.evaluateTriggers(groupId);
if (report.allConditionsMet) {
await guardian.openSunsetWindow(groupId, domain);
}
Transparency
Every state transition is auditable. Proposals move through a 7-state lifecycle
(draft → staged → vote_ready → tallying → final → archived) with each
transition recorded. The archive module provides immutable snapshots.
Use the proposalService.transition() method to advance state:
await proposalService.transition(proposalId, "vote_ready");
Transparency does not mean surveillance. K-anonymity floors in the viz module
ensure that analytics never expose individual behavior when group size is below
the privacy threshold.
Progressive Decentralization
Communities start with training wheels. Early groups operate in sim mode with
structural defaults. As participation grows and critical-mass thresholds are met,
the guardian module enables self-governance features incrementally.
Switching a group from sim to live mode is irreversible. Ensure the group
meets all critical-mass criteria before proceeding.
Architecture Overview
The Pangea codebase is organized into 19 modules across 4 tiers, from foundational infrastructure to user-facing slices.
Tier Model
| Tier | Purpose | Examples |
|---|---|---|
| T0 | Infrastructure | Identity, i18n, search |
| T1 | Core domain | Groups, proposals, voting |
| T2 | Governance | Guardian, delegations, elections |
| T3 | Presentation | Showcase slices, API playground |
Each module follows the composition root pattern: a composition.ts file
wires the service interface to its repository implementation1.
// src/modules/groups/composition.ts
export function composeGroupService(): GroupService {
const repo = process.env.PANGEA_USE_REAL_DB
? new SupabaseGroupRepository()
: new FixtureGroupRepository();
return new GroupServiceImpl(repo);
}
Use the PANGEA_USE_REAL_DB environment variable to toggle between fixture and
Supabase repositories during development. Fixtures are faster for iteration.
Getting Involved
The treatise is a living document. Contributions follow the standard PR workflow:
- Fork the repository
- Create a
feat/orfix/branch - Submit a pull request with conventional commit messages
- Wait for review — the guardian module enforces a comment period
Never push directly to main for structural modifications. All governance
changes require a PR with at least one review.
For questions, open a discussion in the repository or reach out through the community channels listed in the project README.
Footnotes
-
The composition root pattern ensures that no module directly instantiates its dependencies, making testing with fixtures trivial. ↩