**Note** from Bead: 31bd5380 · [canonical source](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-the-word.md) · session 2026-06-03 · discussion: Talk: 31bd5380
The word "acequia" carries multiple resonances. This note **foregrounds two** of them — the pattern and the platform — and treats the other resonances (the historical NM institution, the shared substrate "we" are building, the governance-features-Ostrom-cataloged) as inline context rather than coequal layers in the foreground. **Revision note** (2026-06-03 turn 37+38): an earlier draft of this note had a *four-layer reading* of the word (historical / governance-pattern / shared-substrate / platform) and proposed a "both-and naming" convention. Stephen pushed back through several rounds: - "Ambivalence" is literal — multiple senses simultaneously, both-and resolution (turn 34). ✓ Held throughout this rewrite. - The pattern I had as "governance pattern" was incomplete — there's a **technical pattern** too, and that one is the more formally specifiable. The governance pattern, per Ostrom, is *self-determined per acequia*; she catalogued features successful instances exhibit but didn't write a rulebook. - The platform is **Redfish Group's commercial service offering** (acequia.io with associated domains + documentation); analogous to WordPress.com vs WordPress.org or Gmail vs running your own email server — DIY-with-the-pattern is the alternative for those who don't want to pay. - **Foreground the two**: (1) the pattern, (2) the platform. The four-layer reading is gone. Companion: [ostrom-and-acequia-governance.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/ostrom-and-acequia-governance.md) — full enumeration of Ostrom's 8 design principles with acequia/platform mapping.
## 1. The pattern **An acequia is a pattern.** Two coequal aspects with different characters: ### 1a. The technical-architectural pattern (formally specifiable) A specification for composing web technologies in a particular peer-and-gateway configuration: - **Domains** as identity anchors (each parcela has its own domain, or sub-resource under one) - **Data formats and protocols** — WebDAV for resource publishing, JSON/markdown for documents, content-addressable storage for chains, etc. - **Cloud servers and OS-level servers** — coexisting peers in the substrate; not one centralized infrastructure - **Apps** — first-class participants in the pattern, addressable at URIs, exercising capabilities - **Capability-discipline auth** — chain tokens, no central authorization server; each holder can attenuate and delegate - **Distributed-origin architecture** — the same logical path served by potentially many nodes; routing decided per request This aspect is **formally specifiable**. You could write a conformance spec: "Does this implementation speak WebDAV per RFC 4918? Does it issue chain tokens per the JOSE spec with the documented `parent`/`depth`/`max_depth` claims? Does it provide the standard `/auth/users/`, `/auth/chains/`, `/auth/stored-tokens/` URI surfaces?" Pass/fail. An implementation is or isn't acequia-conformant in the technical sense. The canonical platform docs ([acequia.io/documentation/platform/](https://acequia.io/documentation/platform/index.md)) are *one* expression of this technical pattern; Redfish Group's `acequia.io` implements it; in principle anyone could implement the spec. ### 1b. The governance pattern (Ostrom-style observed features, self-determined) The acequia is also a **governance pattern** — but a different *kind* of pattern from the technical one. Following [Elinor Ostrom's work on commons](https://en.wikipedia.org/wiki/Elinor_Ostrom): > *"The actual governance rules are self-determined by the acequias themselves. She just observed good patterns that persisted and tried to catalogue the features."* — Stephen, turn 37 Ostrom didn't write a prescriptive rulebook for how to govern a commons. She studied successful commons (acequias among them) and **catalogued features that successful instances tend to exhibit**: clearly defined boundaries, congruence between rules and local conditions, collective-choice arrangements, monitoring, graduated sanctions, conflict-resolution mechanisms, recognition of rights to organize, nested enterprises. Eight features in total ([Ostrom's 8 design principles](https://en.wikipedia.org/wiki/Elinor_Ostrom#Design_principles_for_Common_Pool_Resource_(CPR)_institutions)). Successful commons-governance instances tend to exhibit these features *but each instance writes its own rules*. The governance pattern is **family-resemblance**, not specification. For acequias: each specific acequia (the fire department's incident-response acequia, the family-safety acequia, the news-media coverage acequia) writes its own rules. The successful ones will tend to exhibit Ostrom's cataloged features. The technical pattern (1a) is what *enables* this self-determination — by providing no central authority that would foreclose it. **Full enumeration of Ostrom's 8 + mapping to acequia / platform features**: [ostrom-and-acequia-governance.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/ostrom-and-acequia-governance.md). ### Why the two aspects are coequal Neither is primary. The technical pattern *enables* the governance pattern (no central authority → governance can be self-determined). The governance pattern *shapes* the technical pattern (commons-governance discipline → cryptographic-capability architecture rather than centralized authorization). They co-arise. Either alone is incomplete: - Technical pattern without governance = a federated protocol with no community life (like a dormant standard nobody uses) - Governance pattern without technical pattern = a commons community with no shared infrastructure (just talk and intent) The historical NM acequias have both: the *technical* pattern is the physical ditches + water-allocation conventions + meeting structure; the *governance* pattern is parciante stewardship + mayordomo coordination + saca obligations.
## 2. The platform — Redfish Group's service offering of the pattern **Acequia-the-platform is Redfish Group's commercial service offering of the pattern.** It includes (planned and current) custom-domain registration and management, so customers can run their acequias under their own domains (e.g., `acequia.sbcfd.gov`) or under Redfish-provided subdomains — not just at `acequia.io` specifically. `acequia.io` is where the canonical scripts and docs are deployed; the platform's capability extends to managing customer-branded acequia deployments under whatever domain the customer wants. This is the **open-pattern-plus-managed-platform** model — extremely common across web infrastructure. ### Canonical analogy: email (SMTP/IMAP) **The cleanest analogy** is the relationship between the *email protocols* and the *managed email platforms* — including the custom-domain story: | | Pattern (open) | Self-hosted | Managed platform | |---|---|---|---| | What it is | SMTP / IMAP / POP3 protocols (RFCs) | Run your own server | Pay a service to run it for you | | Examples | (the spec itself) | Microsoft Exchange Server, Postfix + Dovecot, Zimbra, Mailcow, Mail-in-a-Box, iRedMail | Microsoft 365 / Exchange Online, Google Workspace, Zoho Mail, FastMail, Migadu | | Custom domain | (handled at the protocol level — anyone owns their domain via DNS MX records) | Yes — you point your MX records at your own server | Yes — managed platforms onboard your domain (`@yourcompany.com`) under their infrastructure | | Federation | ✓✓ Native — any conforming server interoperates with any other | ✓ Your server interoperates with everyone | ✓ Managed-platform users interoperate with self-hosted users | | Server-side governance | (per-deployment) | ✓ You set spam rules, abuse policies, deliverability | ✓ Platform handles it for you | | Trade-off | (it's a protocol — no trade-off) | Full control, operational burden, expertise required | Convenience, vendor relationship, less control | **Why this maps cleanly to acequia:** - The pattern (SMTP/IMAP analog = the acequia technical composition + governance discipline) is what makes interop possible. You don't need everyone on the same platform; you need everyone on the same pattern. - The platform (Microsoft 365 analog = Redfish Group's acequia service) handles infrastructure burden for customers who don't want it: domain registration, hosting, backup, federation infrastructure, mayordomo agents, etc. Customers can bring their own domain (`acequia.sbcfd.gov`) and have it managed. - Self-hosting is possible (Exchange / Postfix-Dovecot / Mailcow analog = running the acequia pattern on your own infrastructure). Most customers won't, but the option being available is part of why the pattern stays open — you're never locked in to any one platform. - Federation is native to the protocol, not a feature of any specific platform. Your acequia interoperates with someone else's acequia regardless of which managed platform (or none) is hosting either. **Important correction** to an earlier draft: an earlier version of this note used Gmail as the platform analog. Gmail can't be self-hosted (it's tied to Google's infrastructure), which breaks the analogy at exactly the point that matters — the DIY-vs-managed trade-off. Microsoft 365 / Exchange and the broader managed-vs-self-hosted email space is the right reference because both paths exist. Stephen flagged this on 2026-06-03; corrected. Phrasing for the manifesto/pitch: > *Acequia is to web technologies what email is to messaging — an open pattern that anyone can implement, with a managed platform (Redfish Group's service offering) for customers who don't want to run their own. Like email, customers can bring their own domain (e.g., `acequia.sbcfd.gov`) and have it managed, or they can run the whole stack themselves. Either way, acequias federate: an acequia at a fire department's own infrastructure interoperates with one on the managed platform.* ### Supplementary analogies (for different reader contexts) **Web server cluster (Apache, Nginx, Kubernetes) vs cloud (AWS / Azure / GCP)** — captures DIY-vs-cloud crisply for tech audiences. You can run your own web server on bare metal or rent the infrastructure-as-a-service. The pattern (HTTP, hostname-based routing, TLS termination, load balancing) is open and standard; the cloud providers offer managed implementations. **Caveat**: web servers aren't federated in the email/acequia sense — each web server is sovereign and they don't peer with each other automatically. This analogy captures the DIY-vs-cloud trade-off but misses the federation property. **DNS servers (Bind, PowerDNS, Knot) vs Cloudflare DNS / Route53 / NS1** — DNS is *the most federated system in existence*. The pattern (DNS protocol, zone files, NS records) is open; the commercial providers (Cloudflare/Route53/etc.) offer managed DNS. Anyone can run their own authoritative nameserver and it interoperates with every other DNS server on the planet. **Strength**: maximum federation. **Weakness**: DNS governance is shallow (zone control); doesn't capture the group-membership-and-governance-rules aspect. **Nextcloud self-hosted vs commercial Nextcloud hosting** (Hetzner Storage Share et al.) — closest analog in the *files-and-collaboration domain* (which is where AnyHazard's resource management lives). Open project, optional commercial hosting, real federation via OCM (Open Cloud Mesh) / Federated Cloud Sharing. **Strength**: closest to AnyHazard's domain. **Weakness**: lower mainstream recognition. These three supplementary analogies cover three different reader contexts (tech-cloud, tech-protocol, files-and-collab). Lead with email; supplement as needed depending on audience.
## The resonances we used to foreground as separate layers The earlier four-layer reading treated *the historical institution*, *a replicable governance pattern*, *the shared substrate of the moment*, and *the platform* as four coequal layers. The new reading collapses to two foregrounded entries (the pattern + the platform); the other resonances are still alive but as inline context rather than coequal foreground: - **The historical NM acequias** are the *source of the metaphor* and the *empirical evidence base* (Ostrom catalogued features from real acequias; the manifesto draws authority from 400+ years of working examples). They're not a separate layer — they're the grounding both the pattern and the platform draw from. - **A specific shared substrate "our acequia"** is what a community gets when they instantiate the pattern (or use the platform). Not a separate layer — it's the operational result of using either the pattern or the platform. - **The Ostrom-style governance features** are catalogued in 1b above and detailed in [ostrom-and-acequia-governance.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/ostrom-and-acequia-governance.md). When the word "acequia" is used, **all of these resonances are alive simultaneously** (the both-and reading from turn 34 still holds). The two-foreground / others-inline structure isn't a contradiction of the both-and; it's a re-weighting of which resonances get the most prose attention.
## How to write in this frame Practical guidance for spec writers using the word "acequia": - **Default to bare "acequia"** unless you have a specific need to narrow. The bare word holds both pattern and platform resonances alive. - **When you mean specifically the pattern** (the technical/governance composition that others could implement): say "the acequia pattern" or "the pattern." - **When you mean specifically the platform** (acequia.io / Redfish Group's service): say "Acequia" capitalized, or "acequia.io," or "the platform." - **Don't say "the Acequia substrate" expecting it to mean only the platform** — it can also mean the substrate any acequia provides (Layer 3 of the old reading). When you mean the platform's substrate specifically, say "acequia.io's substrate" or "the platform's substrate." - **In marketing / outward-facing writing**, the bare word "acequia" doing both-and work is the point — leave it un-narrowed unless a specific clarification helps. - **In normative spec / technical writing**, qualify when the distinction matters; otherwise the bare word is fine. The Ostrom-aware governance angle: - **Don't write "the acequia governance rules"** as if they're a specification — the rules are self-determined per acequia. Write "the acequia's governance" (this acequia, those rules) or "the governance pattern" (the meta-pattern of self-determined commons governance with observed features). - **When citing the cataloged features**, point to Ostrom's design principles ([ostrom-and-acequia-governance.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/ostrom-and-acequia-governance.md)) rather than asserting "acequias work like X."
## What this means for the rest of the vocab work After this rewrite: - **[user-representation-vocabulary.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) Vision-Frame Primitives Acequia entry** — should be updated to reference this two-foreground reading + the email-server analogy - **[account-layer.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/account-layer.md)** — the account layer is what the **platform** (acequia.io) charges for; DIY-acequia has its own equivalent (free, but you carry the operational burden — like running your own email server) - **[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)** — acequias can be served via the platform OR via DIY infrastructure following the pattern; both are real paths - **[fused critique](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/artifacts/anyhazard-user-model-critique-fused.md)** — frame-setting section should clarify "AnyHazard is an app on Acequia (the platform), implementing the acequia pattern, in an ecosystem where other acequia instances may run on alternative infrastructure"
## Related - [ostrom-and-acequia-governance.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/ostrom-and-acequia-governance.md) — Ostrom's 8 design principles enumerated with acequia / platform mapping - The manifesto: [https://acequia.org/acequia-manifesto.md](https://acequia.org/acequia-manifesto.md) — the canonical statement of vision; uses "acequia" across all resonances - Canonical platform docs: [https://acequia.io/documentation/platform/index.md](https://acequia.io/documentation/platform/index.md) — one specific implementation of the technical pattern - [user-representation-vocabulary.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) — broader vocabulary that depends on this framing - [account-layer.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/account-layer.md) — the account layer the platform monetizes - [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 as primary template for emergency-response acequias - [project_ecology](c:/Users/steph/.claude/projects/c--Users-steph-Documents-sites/memory/project_ecology.md) memory — Redfish Group / Simtable / Acequia ecology - [reference_acequia-vocabulary](c:/Users/steph/.claude/projects/c--Users-steph-Documents-sites/memory/reference_acequia-vocabulary.md) memory — load-bearing governance terms