Commons Governance

---
name: commons-governance
description: "Govern shared resources well using Elinor Ostrom's design principles for the commons — applied to AIOS shared substrate: multi-operator vaults, collaboration spaces, company-synced infrastructure, and multiple agents writing one git repo. Use when designing rules for a shared space, deciding who-decides-what across collaborators or agents, preventing tragedy-of-the-commons or write-collision dynamics, setting boundaries on a shared repo/folder, or standing up collab/company governance. Distributed authority done right, grounded in governance science rather than top-down control."
---

# Commons Governance — sharing a resource without a boss

A shared vault, a collaboration space, a company-synced infra repo, a single git repo written by a fleet of agents — these are all **commons**: resources many actors draw on and modify. The naive failure is "tragedy of the commons" (everyone optimizes locally, the shared thing degrades — merge collisions, clobbered files, drift). The naive fix is top-down control (one owner gates everything → bottleneck, "move information to authority"). Elinor Ostrom's Nobel-winning work showed a third way: **self-governed commons that work, via specific design principles.** This skill applies them to AIOS shared substrate.

The eight principles, applied, with sources: [`references/ostrom-design-principles.md`](references/ostrom-design-principles.md).

## The eight principles, applied to AIOS shared substrate

1. **Clear boundaries** — define exactly what's shared and who the participants are. (Which folders/repos are the commons? Who has access? `custom/` and personal vault are explicitly *not* the commons.)
2. **Rules fit local conditions** — match the rules to *this* group's actual usage, don't import generic policy. (A two-person space and a ten-person company need different rules.)
3. **Collective-choice arrangements** — those affected by the rules can change the rules. (Authority moves to the information — the people doing the work shape how the space works.)
4. **Monitoring** — the state of the commons is visible to participants. (Sync trackers, status commands, a shared changelog — everyone can see drift.)
5. **Graduated sanctions** — responses to problems are proportional, starting gentle. (A first collision → a nudge and a convention; not a lockdown.)
6. **Conflict-resolution mechanisms** — cheap, fast ways to resolve disputes. (A defined merge/conflict protocol, a clear escalation path.)
7. **Recognized right to organize** — the group's authority to govern itself is respected, not overridden from outside. (A company/space owns its namespace; canonical doesn't reach in.)
8. **Nested enterprises** — for larger systems, govern in layers. (Personal `custom/` → `<company>/` namespace → canonical: three nested scopes, each self-governing.)

## How to apply (the workflow)

1. **Draw the boundary first (Principle 1).** Name precisely what's shared and who participates. Most shared-space pain is an undrawn boundary — personal content leaking into the commons, or unclear membership.
2. **Set the smallest rule set that fits (2 + 3).** Don't import a heavy policy. Write the few rules this specific group needs, and make them changeable by the group.
3. **Make state visible (4).** A commons no one can monitor degrades silently. Ensure there's a tracker/status surface everyone can read.
4. **Define the conflict path before the conflict (5 + 6).** Decide the merge/collision/dispute protocol up front, graduated and cheap. (For agents on one repo: scope every `git add`, never `-A`; commit fast to release the lock; a known re-sync path.)
5. **Respect the layer (7 + 8).** Govern at the right scope. Personal stays personal; a company governs its namespace; only the genuinely-universal rises to canonical. Don't govern down into a layer that owns itself.

## The AIOS-native instances this lens governs

- **One git repo, many agents.** Classic commons. The collision risk (whoever commits first sweeps others' in-flight files) is a tragedy-of-the-commons dynamic; the fix is path-scoped staging + fast commits + a known protocol (Principles 5–6), not a single committer.
- **Collaboration spaces (`/aios:collaborate`).** A shared work substrate with external collaborators — needs explicit boundaries, fitted rules, and a conflict path.
- **Company-synced infra (`/aios:company`).** A company namespace is a nested, self-governing enterprise (Principle 8): it owns its layer, governs its own rules, and only universal pieces graduate upstream.

## Worked example

*Standing up a two-person collaboration space.* Naive: share a folder and hope. Commons lens: (1) name exactly which folder is shared and that personal vaults are out of scope; (2) write the two rules that actually matter for two people; (3) agree either can change them; (4) point both at the sync status; (6) agree the conflict protocol (who resolves a merge, how). Five minutes of Ostrom up front prevents the slow degradation that kills shared spaces.

## Relationship to the rest of the system

This is the governance-science backing for "Trust Is Architecture" and "move authority to information," and it's the lens for `/aios:collaborate` and `/aios:company`. Where `sustainable-cadence` governs the operator's capacity and `leverage-points` chooses where to intervene, this one governs *shared* resources across multiple actors.