**Note** from Bead: 31bd5380 · [canonical source](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/ostrom-and-acequia-governance.md) · session 2026-06-03 · discussion: Talk: 31bd5380
[Elinor Ostrom](https://en.wikipedia.org/wiki/Elinor_Ostrom) (1933–2012) won the 2009 Nobel Prize in Economics for her work documenting how communities successfully govern common-pool resources without centralized state control or full privatization. Her **8 design principles** are features she catalogued from studying *successful* commons institutions worldwide — including NM acequias, Swiss alpine grazing commons, Japanese village forestry, Spanish huertas, Philippine zanjeras, and many others. The principles don't *prescribe* how to govern a commons; they *describe* features that long-lived, robust commons institutions tend to exhibit. This note enumerates the 8 principles, maps each to acequia (pattern + platform) features, and identifies where the platform's current implementation already exhibits the feature, where it's a stretch, and where work remains. **Context within the broader vocab work**: this note is the deep-dive companion to [acequia-the-word.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-the-word.md), which foregrounds "acequia as pattern + platform." The governance pattern aspect — Ostrom's contribution — gets full treatment here so the main vocab note can reference it without growing further. **Important framing** (carried from Stephen's turn 37): *the actual governance rules are self-determined by the acequias themselves. Ostrom observed good patterns that persisted and tried to catalogue the features.* Each specific acequia writes its own rules; successful ones tend to exhibit these features. The pattern + the platform should **support** these features without *prescribing* the specific rules an acequia adopts.
## The 8 principles For each principle: Ostrom's statement (paraphrased) → what it means concretely → mapping to **the acequia pattern** (what the technical pattern enables / requires) → mapping to **acequia.io as a platform implementation** (current support, gaps, what Redfish Group might prioritize). ### 1. Clearly defined boundaries > *Individuals or households with rights to withdraw resource units from the common-pool resource (CPR) must be clearly defined, as must the boundaries of the CPR itself.* **Concretely**: who is a member of this commons, and what is the commons? Both must be unambiguous so resource use can be governed. **Acequia pattern**: clearly defined membership in an acequia. Boundaries of the acequia's resource scope (which URIs are under this acequia's stewardship). Identity-URIs + acequia membership-bindings carry this — a participant is or isn't a member; an acequia governs or doesn't govern a given URI subtree. **acequia.io platform**: subdomain isolation per the canonical platform docs gives clear boundaries (users in one subdomain can't access another's resources). User registration creates explicit membership bindings (owner / editor / viewer / pending roles). The platform supports this directly. ✓ **Gap**: cross-acequia federation (effort-1 §3.8 of Kaz's pitch) needs explicit cross-boundary protocols so federation doesn't blur boundaries. ### 2. Congruence between appropriation/provision rules and local conditions > *Rules restricting time, place, technology, and quantity of resource units should relate to local conditions and to rules requiring labor, materials, and money.* **Concretely**: the costs members contribute (saca labor, money) should be proportional to the benefits they extract; rules should match local conditions, not be one-size-fits-all from outside. **Acequia pattern**: each acequia writes its own rules per local conditions. The pattern doesn't impose universal rules; it provides primitives (capability tokens, scope attenuation, policy URIs) that acequias use to define their own appropriation/provision balance. **acequia.io platform**: per-subdomain policy supports local rule-setting. Stored-token scopes (custom paths) let acequias define what resources they manage and how. The two-layer model (free participant layer + paid account layer) supports the "contributions match benefits" property — pay-for-use of infrastructure scales with usage. ✓ **Gap**: the platform should make rule-setting at the per-acequia level as easy as possible — the more rigid the platform, the less an acequia can match local conditions. The pitch's role-template system (effort-1 §F3.2) is the right shape; needs to be *flexible*, not prescriptive. ### 3. Collective-choice arrangements > *Most individuals affected by operational rules can participate in modifying the operational rules.* **Concretely**: those who use the commons should have voice in changing how it's governed. Bottom-up rule-modification, not top-down. **Acequia pattern**: governance URIs exposed for participant interaction. Voting / consensus / proposal-and-acceptance flows live at policy sub-URIs that members can `POST` to. Mayordomo coordinates but doesn't unilaterally dictate. **acequia.io platform**: the canonical platform docs describe the owner / editor / viewer / pending roles and member-management endpoints. **Gap**: collective-choice mechanisms (voting, proposal-acceptance, member-driven policy changes) aren't currently first-class platform features. They could be implemented per-acequia using the existing primitives (a `<acequia>/proposals/` URI with submission policy; a voting protocol via chain tokens) but the platform doesn't ship affordances for this. ⚠ Opportunity area. ### 4. Monitoring > *Monitors, who actively audit CPR conditions and appropriator behavior, are accountable to the appropriators or are the appropriators.* **Concretely**: someone watches whether members follow the rules and whether the commons is in good condition. The monitors are members or report to members — not external enforcers. **Acequia pattern**: per-acequia audit log (`<acequia-URI>/audit/`) — append-only, signed, transparent to members. Members monitor their own commons. **acequia.io platform**: audit logs are part of the platform's design (every state-changing action produces an audit-log entry per the pitch's effort-1 §F3.6). ✓ The platform supports this directly. Augment with **member-visible audit views** (not just admin-visible) for fuller monitoring. **Gap**: who has access to read the audit? If only the mayordomo/owner can see it, Ostrom's principle is half-met. Member-visible audit (with appropriate privacy) closes the loop. ### 5. Graduated sanctions > *Appropriators who violate operational rules are likely to be assessed graduated sanctions (depending on the seriousness and the context of the offense) by other appropriators, by officials accountable to the appropriators, or by both.* **Concretely**: rule violations have consequences — but proportional, not all-or-nothing. First offense is a warning; repeated offenses escalate; serious offenses can lead to exclusion. **Acequia pattern**: per-acequia sanction-binding patterns. Roles can be attenuated (downgrade from editor to viewer), bindings revoked (`DELETE` from member roster), with apoptotic cascade. The pattern *enables* graduated sanctions; the specific schedule is per-acequia. **acequia.io platform**: role downgrade endpoints exist (`PATCH /auth/users/:userId` changes role/paths). Revocation is supported. **Gap**: graduated-sanction *protocols* (what counts as a violation, escalation steps, appeals) aren't platform features — they'd live in each acequia's governance policy. The platform supports the mechanism; the rules are per-acequia. ### 6. Conflict-resolution mechanisms
> *Appropriators and their officials have rapid access to low-cost local arenas to resolve conflicts among appropriators or between appropriators and officials.* **Concretely**: when members disagree, there's a venue and a process to resolve the disagreement quickly and cheaply, without escalating to outside authority. **Acequia pattern**: per-acequia dispute URIs / arbitration role / arbitration sessions. Conflict-resolution happens within the acequia's namespace, with the acequia's chosen process. Federation can support cross-acequia disputes via mutually-trusted arbitrators. **acequia.io platform**: the pitch's approval queue (effort-1 §F3.4) is the closest existing primitive — a venue where requests/disputes can be reviewed. Doesn't currently extend to general dispute resolution. **Gap**: conflict-resolution venues aren't first-class platform features. Could be built per-acequia using existing primitives (dispute URIs, voting, time-bounded resolution processes). Opportunity area. ⚠ ### 7. Minimal recognition of rights to organize > *The rights of appropriators to devise their own institutions are not challenged by external governmental authorities.* **Concretely**: governments / external authorities don't crush the commons-governance institution from outside. The commons is allowed to exist and govern itself. **Acequia pattern**: the entire technical pattern is designed to *not require* a central authority. Capability discipline, no central AS, distributed-origin substrate, federation rather than centralization — all of it enables right-to-organize by making external suppression structurally difficult. **acequia.io platform**: the platform itself respects right-to-organize (it doesn't claim to be the only valid acequia substrate; the DIY path is the explicit alternative). ✓ The deeper question is whether *legal/regulatory environments* recognize the right; that's not a platform feature but a contextual property. **Manifesto alignment**: this principle is the *political theory* the manifesto rests on — "neither capitalism nor socialism but commons-governance by owners." The platform implements the technical pattern; the political work of preserving right-to-organize is also part of the project. ### 8. Nested enterprises > *Appropriation, provision, monitoring, enforcement, conflict resolution, and governance activities are organized in multiple layers of nested enterprises.* **Concretely**: large commons aren't governed flat — they're organized into nested levels, each with its own governance scope, federating to the next level up. **Acequia pattern**: acequia-of-acequias (per the ICS Area Command pattern in [acequia-as-group-ics-template.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-as-group-ics-template.md)). Sub-acequias under a parent acequia. Federation between sibling acequias. The technical pattern's URI-tree composition and bind/mount semantics support nesting natively. ✓ **acequia.io platform**: subdomain composition + groups + sub-groups are the existing affordances. Cross-org federation (effort-1 §F3.8) supports inter-acequia coordination. Area-Command-style nesting (acequia-of-acequias) maps to bound collections of org URIs. **Gap**: the platform's explicit support for nested-acequia governance (cross-level audit aggregation, federated decision-making, escalation paths) is partial — the primitives exist but the patterns aren't fully spec'd. Opportunity area.
## Summary table | # | Ostrom's principle | Acequia pattern support | acequia.io platform status | |---|---|---|---| | 1 | Clearly defined boundaries | Identity-URIs + membership-bindings + scope attenuation | ✓ Subdomain isolation + role-based scope | | 2 | Congruence (rules ↔ local conditions, costs ↔ benefits) | Per-acequia policy URIs; capability primitives, not prescribed rules | ✓ Per-subdomain policy + two-layer capacity model | | 3 | Collective-choice arrangements | Governance URIs exposed for participant interaction (voting/proposal) | ⚠ Not currently a first-class platform feature; opportunity area | | 4 | Monitoring | Per-acequia audit log (append-only, signed) | ✓ Built into the platform; needs member-visible audit views | | 5 | Graduated sanctions | Role attenuation + revocation with apoptotic cascade | ✓ Mechanism present; the schedules are per-acequia | | 6 | Conflict-resolution mechanisms | Per-acequia dispute URIs + arbitration roles | ⚠ Not currently first-class; opportunity area | | 7 | Minimal recognition of rights to organize | No central authority; capability discipline; distributed-origin substrate | ✓ Pattern is designed for this; political context separate | | 8 | Nested enterprises | Acequia-of-acequias; sub-acequias; cross-acequia federation | ⚠ Primitives exist; nested-governance patterns not fully spec'd | **Where the pattern + platform exhibit Ostrom's features strongly (✓):** boundaries, congruence, monitoring, graduated sanctions, right-to-organize. **Where work remains (⚠):** collective-choice (voting/proposals), conflict-resolution mechanisms, nested-enterprise patterns. **All three could be first-class platform-supported features** that any acequia could opt into without inventing them from scratch.
## What this means operationally Ostrom's principles aren't prescriptions — they're features the pattern + platform should **enable** (and the platform might explicitly **support**) so that any specific acequia can adopt the principles that fit its context. **For the platform (acequia.io / Redfish Group):** - Lean into supporting Ostrom's features as platform affordances. The three ⚠ areas (collective-choice, conflict-resolution, nested-enterprise patterns) are real product opportunities. - The acequia.io platform's competitive position is "we make Ostrom-compatible commons-governance easy." - The audit-log + member-visibility combo is a notable quick win — already mostly there; expose audit to members. **For acequias using the pattern (whether on acequia.io or DIY):** - Use Ostrom's principles as a *self-assessment checklist*. "Are our boundaries clear? Are our monitoring mechanisms accessible to members? Do we have a low-cost dispute-resolution venue?" - Don't over-formalize. Ostrom's evidence is that *successful* commons exhibit these features through *self-determination*, not external imposition. The principles are diagnostic, not prescriptive. **For the Kaz / AnyHazard pitch:** - The ICS template (per [acequia-as-group-ics-template.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-as-group-ics-template.md)) already exhibits most of Ostrom's features (clear boundaries via incident scope; congruence via NIMS scaling; monitoring via the audit-log + after-action reviews; graduated sanctions via demobilization + role-revocation; conflict-resolution via Unified Command negotiation; nested via Area Command + Complexes). Worth surfacing this alignment — ICS is *already* Ostrom-compatible governance. - Where ICS-acequias might want platform support beyond what ICS doctrine provides: collective-choice flows for non-emergency planning, conflict-resolution venues for cross-jurisdictional disputes, nested-governance affordances for Complex-level decisions. - Citizen / news media / sensor-network acequias have different governance shapes and will exhibit Ostrom's features differently. The platform should support the *features* (boundaries, monitoring, etc.) without prescribing the *forms*.
## Related - [acequia-the-word.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-the-word.md) — the pattern + platform foregrounding; this note is the governance-aspect deep dive - [acequia-as-group-ics-template.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-as-group-ics-template.md) — ICS exhibits Ostrom's features for emergency-response acequias - [user-representation-vocabulary.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) — the vocabulary references this note for governance-as-self-determined-features - The manifesto: [https://acequia.org/acequia-manifesto.md](https://acequia.org/acequia-manifesto.md) — political-theoretical context for principle #7 - [Ostrom on Wikipedia](https://en.wikipedia.org/wiki/Elinor_Ostrom) — biographical + work summary - Ostrom, *Governing the Commons: The Evolution of Institutions for Collective Action* (Cambridge University Press, 1990) — the original work; the 8 principles appear in Ch. 3 and following - [project_ecology](c:/Users/steph/.claude/projects/c--Users-steph-Documents-sites/memory/project_ecology.md) — broader Redfish/Simtable/Acequia ecosystem context