Integral Commons

Role: Solo — Product Design, Systems Architecture, Product Strategy Status: Documentation complete · Phase 1 build in progress

Overview

This is a project about what technology for communities could look like if it didn't optimize for engagement, profit, or efficiency.

Integral Commons is an open-source, six-layer commons operating system for neighborhoods, communities, and municipalities that want to coordinate without surrendering their data, decisions, or sovereignty to a platform. Local Commons is its neighborhood-scale entry point — a digital and social operating system that replaces the fragmented patchwork of WhatsApp threads, spreadsheets, and informal trust networks with an integrated coordination layer for resource sharing, mutual aid, and collective governance.

Neither is trying to be a platform. That distinction is the point.

The problem

The coordination infrastructure available to most neighborhoods is either extractive (Nextdoor, Facebook Groups), inadequate (Signal threads, shared spreadsheets), or incomplete. Loomio handles decisions but not resources. Sharetribe handles resources but not decisions. Nobody handles care.

But the deeper problem isn't about tools. Most people won't ask for help publicly — even in a community they trust. Unpaid organizers absorb coordination costs until they burn out. Care work is invisible and undervalued by every platform that counts engagement instead of contribution. Historical divisions don't disappear because a new app appears. And neighborhoods that ignore the non-human commons they depend on — the watershed, the urban tree canopy, the soil — are slowly governing their own depletion.

Designing for coordination without designing for these human and ecological realities produces platforms that look functional in demos and collapse in practice.

Design approach

Start with constitutional constraints, not the happy path

Most product design starts with the user journey. I started with the constitutional layer — the inviolable principles that would govern every design decision across every layer of the system.

Seven Tier 1 principles emerged: revocability of all authority delegations, due process for anyone subject to removal, commons protection as the supreme principle (no decision may privatize shared infrastructure), forkability (any community can fork governance and leave with their data), holonic nesting (higher layers cannot override lower layer sovereignty), mandatory deliberation before any decision, and accountability of the constitutional framework to the communities that use it — not to the organization that built it.

Establishing these upfront meant that features couldn't be added later that violated them. More usefully, it gave me a clear rejection criterion: when a proposed feature would make the governance process faster or more efficient at the cost of one of these principles, the feature was rejected. Speed is not the goal.

Design against platform instincts

Every design choice in Integral Commons has a corresponding temptation that was explicitly refused.

Why not add a like button? Because likes optimize for popularity, and the most popular contribution is not the same as the most needed one.

Why not send push notifications? Because a commons tool that demands constant attention replicates the attention economy it's supposed to be an alternative to.

Why not score trust? Because when people know their behavior is scored, they perform for the metric rather than the community. The most important community work — holding space for someone in grief, showing up when it's inconvenient, the conversation that keeps two neighbors from becoming enemies — is invisible to any platform and should remain so.

The UX principles codify this explicitly: slow UX, action over expression, lurking as legitimate, non-participation as legitimate. Anti-metrics are named alongside metrics: page views, session length, post volume, and reaction counts are all not tracked.

Design for the people who won't use it

The default user assumption in most civic tech is a digitally literate, time-available, English-speaking person willing to engage. That person is real and the platform serves them well. But they are not most people in most neighborhoods.

Local Commons treats the following as Phase 1 design constraints — not future roadmap items:

• People in survival mode who cannot engage with a digital platform
• Elderly residents without smartphones
• Undocumented neighbors who cannot provide identity documentation to a database
• People who need help more than they can give, possibly permanently
• The local ecosystem — which has a stake in governance decisions about land and water but cannot advocate for itself

The anonymous membership model addresses several of these directly. An organizer vouches for a neighbor's belonging without the platform holding any identifying information. The accountability link is human, not digital. This protects domestic violence survivors, undocumented residents, and anyone with legitimate reasons to distrust a database.

Every core workflow also has a documented offline equivalent. The 5-phase governance protocol has a facilitation card deck. The Resource Registry has a paper format. The Needs & Offers board has a physical analogue. These aren't fallbacks — they're proof that the platform augments human capacity rather than replacing it.

Make asking for help feel like a gift, not an admission

The hardest design problem in the mutual aid layer isn't technical. It's psychological. Most people would rather go without than post a Need publicly — even in a community they trust. Shame is real, and it is design-generatable or design-reducible.

The interface frames posting a Need as a contribution to the community's self-knowledge — not an admission of weakness. Language throughout is warm and neutral, never transactional. There are no public metrics that expose who is a net receiver. Receiving is explicitly treated as a form of contribution: a neighbor who allows someone to help them is giving the community the gift of being useful.

This is intentional counter-programming to market logic, which equates receiving with deficit.

The system

Six interdependent layers

Integral Commons is structured as six layers, each independently useful, together forming a commons operating system:

These layers are not a hierarchy. They are nested holons — each is a whole in itself and part of something larger.

Local Commons in depth

Phase 1 focuses on Local Commons — the proving ground for the neighborhood use case. It bundles five interdependent sub-layers:

Resource Registry — A shared inventory of tools, skills, spaces, and land available in the neighborhood. The invisible made visible. A member can register a tool in under three minutes; a Steward can approve a checkout request in a single tap.

Needs & Offers — Structured mutual aid board. Not a feed. Not a comment thread. A system designed for completion, not engagement. Needs and Offers are first-class objects with deadlines and resolution states — they exist to close, not to accumulate.

Lightweight Governance — A 5-phase decision protocol: Attention → Perspecting → Integration → Decision → Memory. No decision can skip deliberation and proceed directly to a vote. Quorum is calculated against affected members, not total membership — a decision about the community garden requires quorum from garden participants.

Stewardship Record — Descriptive participation history, never evaluative. Records what members have been part of without translating participation into a score. The platform takes no position on what a good community member looks like.

Local Economy — A time credit system with an architectural firewall between gift exchanges and credit-tracked exchanges. Gift exchange is the default. Credits are opt-in. The firewall is enforced at the data model level so accounting logic cannot creep into the gift economy as the platform evolves.

The 5-phase governance protocol

The governance layer is the most technically interesting design problem in the system. The protocol isn't a form — it is the crystallization of a collective sense-making process.

Attention frames the issue and identifies who is affected. Quorum thresholds are calculated against this group, not the whole neighborhood.

Perspecting must surface multiple lens types before integration can begin — Values, Risk, Equity, Feasibility, Relational, Temporal. The platform detects when perspectives are clustering without engaging each other (the "parallel monologue" signal) and prompts the facilitator to address it before advancing.

Integration requires a manually authored summary. No AI generation. The facilitator must articulate where shared understanding exists and where genuine disagreement remains. One round of revision is built into the phase.

Decision supports consent-based resolution by default. Secret ballot is available for any decision on any member's request — social pressure in small groups is real. Paramount objections must be reasoned claims of harm, not preferential disagreements.

Memory produces a Decision Record that enters Civic Memory. A 24-hour review window precedes finalization — any affected member may flag a factual error.

Decisions affecting land, water, outdoor space, or non-human life trigger an additional governance requirement: the local ecosystem must be named as an affected stakeholder, and at least one Perspective must address ecological impact before the Integration phase can close. The neighborhood may still make ecologically harmful decisions. The requirement is that they make those decisions knowingly, with the impact named and recorded.

Tensions that remained live

Time credits vs. care. When care work enters a credit system it becomes visible and valued — which is good. It also becomes transactional — which may damage it. The design response is to make gift exchange the default, keep credits strictly opt-in, and maintain an architectural separation between the two at the data model level. But the tension is managed, not resolved.

Participation as norm vs. participation as burden. The governance layer needs quorum. The platform must not guilt people for non-participation. The resolution — calculating quorum against affected members, allowing passive presence to count toward awareness quorum — reduces burden while maintaining deliberative integrity. Whether this is enough is an empirical question that only pilots can answer.

Steward labor. Local Commons runs on the labor of neighborhood Stewards. Every feature that allows members to self-serve is one fewer task for a Steward. But organizing has irreducible human elements. Burnout is named as the highest-probability failure mode in the risk model, structural rather than personal, and the Steward load distribution alert is a mitigation not a solution.

Reflections

This project started as a question: what would civic infrastructure look like if it optimized for something other than engagement? It became a design problem I couldn't put down.

The most challenging part was governance design — not because it's technically hard, but because it requires holding genuine political commitments. Every decision about quorum thresholds, deliberation windows, and constitutional constraints represents a view about how power should work in a community. These can't be framed as neutral defaults. They're values that need to be documented, named, and contestable.

The most clarifying discovery was that the constraints made the design better. Designing for people who won't engage led to a governance model that's more honest about how participation actually works. Designing for shame reduction produced a mutual aid UX with less friction and more dignity. Treating non-human stakeholders as a governance requirement — not a feature — produced a richer model for what a commons is actually accountable to.

The constraints weren't limiting. They were generative.

Integral Commons is open-source (AGPL-3.0). All non-code assets — governance templates, facilitation guides, documentation — are licensed under Creative Commons BY-SA.