**Note** from Bead: 31bd5380 · [canonical source](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-as-group-ics-template.md) · session 2026-06-03 · discussion: Talk: 31bd5380
This note responds to Stephen's reframe in turn 36 (2026-06-03): > *"AnyHazard is a given app using the acequia. And organizations will form acequias. Also events and scenarios are acequias. An acequia is a type of group. It applies governance and roles. A primary template for anyhazard acequias is the Incident Command System. We should definitely foreground that. And ICS includes emergency responder ICS and IMTs, fire, county EMS, area command, complexes, training scenarios vs live events vs incident reconstruction. But citizens too forming acequias. With Ring and mobile cameras and GPS of family and employees. And then news media with their imagery and acequias with their viewers for sharing URIs of their imagery from phone gallery and realtime streams. Including security cameras. And alert.live ridgetop cameras with PTZ permissions and archiving and calibration."* This is the **most significant reframe in the session**. It restructures how the pitch should present itself, what governance template gets foregrounded, and which other contexts the platform serves alongside emergency response.
## The reframe ### 1. AnyHazard is an app on Acequia (pattern + platform), not the platform itself The pitch's framing has been treating AnyHazard as the system; Stephen's correction is that AnyHazard is **one application** that uses Acequia. Other applications (`realtime.earth`, `alert.live`, citizen tools, news-media tools) sit alongside it. **"Acequia" here carries both senses** (per [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** — the technical-and-governance composition that AnyHazard implements. A fire department running its own infrastructure following the pattern still has an "AnyHazard on Acequia" deployment, even without using `acequia.io`. - **The platform** — `acequia.io`, Redfish Group's commercial service. Most fire departments without their own IT infra will use the platform; some with their own infra may self-host the pattern. This re-anchors the whole pitch: - The pitch should be written as "How AnyHazard uses Acequia (pattern + platform) to serve emergency-response work" rather than "AnyHazard's user model" - Cross-app considerations (realtime.earth, alert.live, etc.) become natural rather than special - Acequia primitives (chain tokens, identity, URI hosting, etc.) are the *foundation*; AnyHazard's job is to apply them well for its domain - **Both deployment paths are real**: most AnyHazard acequias will run on acequia.io (convenience); some will run on DIY infrastructure following the pattern (sovereignty / cost / regulatory reasons). The pitch should accommodate both paths from the start — even if MVP only ships the platform path, the pattern path should be the "Phase 2" rather than an afterthought ### 2. Organizations form acequias Organizations don't *contain* users in a flat hierarchy; **they form acequias** (Layer 2 of the word → Layer 3 — they instantiate the pattern). An organization is the *entity that initiates and governs* one or more acequias. The fire department forms an incident-response acequia; the news station forms a coverage acequia; the family group forms a personal-safety acequia. The org's account (account layer) funds the acequia's infrastructure. The acequia itself is the participant-layer governance container. ### 3. Events and scenarios are acequias too An event (a real incident, a planned exercise, a public gathering) is an acequia — temporary, formed around the event's purpose, dissolved or archived afterward. A scenario (a reusable simulation setup, a training template, an after-action review) is an acequia — possibly persistent, used to instantiate event-acequias when needed. This collapses what the pitch treats as separate concepts (organization vs group vs event vs scenario vs session) into **kinds of acequia**: - **Organizational acequia** — persistent; the fire department, the news station, the family-safety group - **Event acequia** — bounded; formed around a specific incident or gathering, dissolved/archived after - **Scenario acequia** — template; reused to instantiate event-acequias - **Session** — a meeting of an acequia (specific Simtable session, specific call, specific debrief gathering) A session is *not* itself an acequia — it's an event *at* an acequia. Persistent session URIs (from the earlier turn 22 work) are acequias; ephemeral sessions are meetings of an acequia. ### 4. An acequia is a type of group, with governance and roles In the pitch's existing vocab (effort-1 §3.4), "group" is a lightweight collaboration container. **Acequia** is a *specialized kind* of group — one that carries a **governance template** and **role structure**. Not every group is an acequia (some groups are just shared workspaces); every acequia is a group with governance attached. The governance template determines: - Roles available (e.g., for ICS: IC, Command Staff, Section Chiefs) - Role-assignment rules (who can assume which roles, succession patterns) - Decision-making structure (unified command, delegated authority, span-of-control) - Activation/deactivation lifecycle (when the acequia spins up, when it stands down) - Cross-acequia coordination (federation patterns, mutual aid)
## ICS as primary template for emergency-response acequias **The Incident Command System (ICS)** is the standardized hierarchical framework used across US emergency response (and adopted internationally) since the 1970s. NIMS (National Incident Management System) mandates it for federal disaster response; FEMA, fire services, EMS, law enforcement, and public health all use it. Stephen's directive: foreground ICS as the primary template for AnyHazard acequias. ### Why ICS - **Standardized across agencies and jurisdictions** — a fire chief from San Francisco and a fire chief from Albuquerque can drop into the same incident and the role structure is identical - **Proven over decades** — refined through actual incidents, post-incident reviews, doctrine updates - **Scales modularly** — Type 5 (single resource) → Type 4 (initial attack) → Type 3 (extended) → Type 2 (large multi-jurisdiction) → Type 1 (national/catastrophic) - **Supports training mode** — drills and exercises use the same structure as real incidents - **Supports incident reconstruction** — post-incident analysis uses the same vocabulary - **Common terminology** — explicit doctrine that all participants use the same words for the same things (which IS the user-vocabulary problem the fused critique calls out, already solved for emergency response by ICS) ### ICS terminology → Acequia vocabulary mapping | ICS term | Acequia / platform mapping | |---|---| | **Incident** | An event-acequia formed around the incident; activates on alarm/dispatch; deactivates at demobilization | | **Incident Commander (IC)** | The mayordomo of the incident-acequia; single person at any time; subject to succession (transfer of command) | | **Command Staff** (PIO, Safety Officer, Liaison Officer) | Role bundles bound to the IC's namespace; each holds a specific scope (public information, safety oversight, agency liaison) | | **General Staff Section Chiefs** (Operations, Planning, Logistics, Finance/Admin) | Sub-mayordomos of the incident-acequia's main functional sections; each governs their section's sub-acequia | | **Strike Team / Task Force / Division / Branch / Group** (operational sub-units) | Sub-acequias under the Operations Section's governance | | **Unified Command (UC)** | Federation between agency-acequias; multiple ICs share command at the incident URI; cross-agency mutual aid expressed as cross-acequia chain tokens | | **Incident Management Team (IMT)** | A pre-organized template-acequia that activates and deploys when an incident exceeds local capability; Type 1-5 IMTs are scenario-acequias of graduated capability | | **Area Command** | An acequia-of-acequias — coordinates multiple concurrent incident-acequias in a defined area | | **Complex** | A bound collection of related incident-acequias managed as one (e.g., a "fire complex" = multiple fires under one IMT) | | **Demobilization** | The acequia's apoptotic lifecycle — orderly stand-down, audit finalization, resource release | | **Transfer of Command** | Mayordomo succession (the ICS protocol is a specific formal version of the general N-of-M succession pattern) | | **Common Terminology** | The Document A user-rep vocabulary; ICS already mandates it, the pitch should adopt and extend | | **Span of Control** | Governance principle: supervisors manage 3-7 subordinates (advisory for acequia sizing) | | **Modular Organization** | Acequias scale up by activating more sub-roles and scale down by deactivating them | ### ICS modes (same governance, different temporal context) ICS is used in *three temporal modes*, all of which become acequia kinds: - **Live events** — real incidents in progress; the acequia is operating against time pressure with real-world consequences - **Training scenarios** — exercises, drills, sandbox runs; the acequia uses the same structure but with stipulated rather than real conditions; supports learning without consequence - **Incident reconstruction** — post-incident review, after-action analysis, debriefing; the acequia replays a past incident for learning purposes These aren't separate platform features — they're the same governance template (ICS-flavored acequia) activated against different temporal/factual conditions. The platform should support all three with the same vocabulary, with mode-specific affordances (e.g., scenario-acequias can be paused/rewound; live-acequias can't). ### ICS scope: who runs these acequias Stephen's list: - **Emergency responder ICS and IMTs** — the canonical use - **Fire** — wildland and structural fire response - **County EMS** — emergency medical services dispatch and coordination - **Area command** — coordinating multiple concurrent incidents - **Complexes** — multi-incident bound acequias (fire complexes are the most common type) Each of these is an organization (in the platform sense) that *forms ICS-flavored acequias* when needed. The org is the persistent container; the incident-acequias are the transient governance instances activated by events.
## Multi-template acequia ecology ICS is the primary template for emergency-response acequias, but **acequias come in many flavors**. Stephen named four broad categories: ### Citizen acequias Families, neighborhood groups, employee groups forming acequias around personal/community safety: - **Family safety acequia** — Ring doorbell cameras, mobile cameras, GPS location-sharing of family members, real-time alerts of unusual activity at home or family-member locations - **Neighborhood acequia** — coordinated neighborhood watch with shared camera feeds, incident reporting, mutual alerts - **Workplace acequia** — employee tracking (with consent), shared location of mobile employees, vehicle GPS for company fleets These are **peer-to-peer** rather than command-hierarchical. Governance is lightweight (family elder, neighborhood-watch coordinator, employer-as-account-holder). Different role template from ICS; same acequia pattern. ### News media acequias A news organization (TV station, online publication, citizen journalism collective) forms an acequia around incident coverage: - **Editor** — coordinates coverage, makes publication decisions - **Reporters / camera crews** — capture and submit imagery - **Viewers** — submit URIs of their own imagery (phone gallery, security cameras, real-time streams) to the news acequia's submission endpoint (this is exactly the [uri-as-primitive event-submission pattern](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/uri-as-primitive.md) — anonymous URI submission to a designated endpoint) - **Curators / verifiers** — vet submissions for authenticity, source The news-media acequia receives URIs *from* citizen-acequia members (or anonymous bystanders) and publishes curated subsets to its viewer audience. URI flow is bidirectional: viewers contribute imagery; the news acequia broadcasts curated coverage. ### Sensor-network acequias Organizations that operate sensor networks form sensor-acequias governing the sensors and their data. The canonical worked example is **alert.live** (Stephen's adjacent project): - **Ridgetop fire cameras** — pan-tilt-zoom (PTZ) cameras at high-elevation vantage points for wildfire detection - **PTZ permissions** — who can move the camera (because moving it changes what it captures); typically held by trained operators with situational awareness - **Archiving** — long-term retention of captured imagery for post-incident reconstruction and pattern analysis - **Calibration** — geo-referencing (where exactly is the camera pointing?), color calibration, focus calibration alert.live's acequia has roles like: - **Camera owner** (the org that owns the physical hardware) - **PTZ operator** (trained personnel with permission to move the camera) - **Viewer** (anyone with read access to the live feed) - **Calibrator** (technical role for geo-referencing and image quality) - **Archive maintainer** (manages long-term storage policy) The PTZ-operator role is interesting — it's a **capability that has to be exclusive at any moment** (only one person can be moving the camera at a time) and **transferable** (operator hands control to another operator). This is the host-role pattern (claim, transfer, exclusive at any moment) applied to a non-session resource. When an ICS acequia (a fire response) activates near alert.live's coverage area, **cross-acequia URI sharing** happens: the alert.live sensor-acequia's camera URIs become available to the fire-response acequia for situational awareness. The fire response doesn't need to "import" them — the URIs are bound under alert.live's namespace, and the ICS acequia's federation policy grants the fire IC's role visibility into the relevant camera URIs.
## Cross-acequia URI sharing — the integrative pattern The pattern that emerges across the four acequia kinds: > **Acequias share URIs across kinds.** Citizens contribute imagery URIs to news acequias and to emergency-response acequias. News acequias publish curated URIs to viewers. Sensor acequias expose live feeds to emergency-response acequias. Emergency-response acequias publish situational maps and progressions to news acequias and to public-information channels. This is the [URI-as-primitive](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/uri-as-primitive.md) frame in motion. **URIs flow across acequia boundaries via bindings.** Each acequia has its own governance (who can grant access to its URIs), but the URIs themselves are addressable across acequias. Specific flow examples: | From | To | URI flow | |---|---|---| | Citizen with phone photo | News media acequia | `POST <news-acequia>/submissions/` with the phone-photo URI (anonymous OK) | | Citizen with phone photo | Emergency-response acequia | `POST <incident-acequia>/witness-submissions/` with the URI (often anonymous, possibly with location) | | alert.live sensor acequia | Emergency-response (fire) acequia | Federation binding: the fire IC's mayordomo holds a chain token granting read on the relevant ridgetop-camera URIs | | Emergency-response acequia | News media acequia | The incident's PIO (Public Information Officer, ICS role) issues curated URI bindings to the news acequia | | Emergency-response acequia | Citizen acequias (public info) | The PIO publishes public situational-awareness URIs (evacuation maps, road closures, shelter locations) to a public-readable subspace | | News media acequia | Viewers | Curated URIs published to a public-readable channel | The substrate supports all of this with **the same bind/mount mechanism** (per [Gap 2 in gaps-to-acequia-mission.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/gaps-to-acequia-mission.md)). Cross-acequia URI sharing isn't a special feature; it's binding-as-usual across namespaces with appropriate governance gates.
## Implications for Kaz's pitch The pitch should: 1. **Open by establishing the frame**: AnyHazard is an app on Acequia; it serves emergency-response acequias (and adjacent uses) 2. **Lead with ICS as the primary template** for the user-organization vocabulary; map directly onto ICS terminology where possible 3. **Map "Organization" in the pitch to "an entity that forms acequias"** rather than to a flat container of users 4. **Reframe "Group" as "acequia"** when the group carries governance + roles; reserve "group" for governance-free shared spaces 5. **Treat events and scenarios as acequias**, not separate primitives — both are governance-bearing groups with specific temporal characters 6. **Acknowledge the broader acequia ecology** (citizen, news media, sensor-network) as adjacent first-class cases — AnyHazard isn't the only acequia kind on the platform 7. **Show cross-acequia URI flows** as the integrative pattern — what makes the platform useful for emergency response is that other acequia kinds (citizen, media, sensor) feed into emergency-response acequias via URI sharing This re-orients the pitch from "we're building an emergency-response app" to "we're building the emergency-response **acequia template** on Acequia, in a multi-template ecology where citizen, media, and sensor acequias also operate and feed each other URIs."
## Implications for the vocab work Several entries gain sharper framing: - **Acequia** (vocabulary entry) — a type of group: governance-bearing, role-structured, instantiated from a template (ICS, citizen, media, sensor, or other). The word's [four layers](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/acequia-the-word.md) are all alive; this entry foregrounds Layer 3 (the specific shared substrate a community is in) without suppressing the others. - **Group** — clarify as "shared collaboration container without specific governance"; acequia is the governance-bearing subset - **Organization** — entity that *forms* acequias; the persistent identity that funds the account that supports the acequia infrastructure - **Event / Scenario** — kinds of acequias (event-acequia, scenario-acequia), not separate primitives - **Session** — a meeting at an acequia (specific gathering within the acequia's persistent namespace) - **ICS-flavored acequia** — when the governance template is ICS, specific roles (IC, Command Staff, Section Chiefs, etc.) are available; other templates have other role sets - **Cross-acequia URI sharing** — the integrative pattern; uses bind/mount mechanism - **alert.live worked example** — concrete instance of a sensor-network acequia; appears in vocab as an example of PTZ-operator-role, archiving, calibration
## What this note doesn't decide - **How much ICS terminology to adopt verbatim vs translate** — the pitch could use "Incident Commander" directly (matches fire-chief audience expectations) or translate to "host" (matches the cross-acequia vocabulary). Best answer probably: use ICS terms in ICS contexts, use generic acequia terms in cross-template contexts. Kaz's call. - **Whether non-ICS acequia templates need to be specified before MVP** — citizen, media, sensor acequias are real use cases but the pitch's MVP is emergency response. The other templates can be enumerated in Document A and built incrementally. - **How to handle hybrid acequias** — a wildfire-response acequia might use ICS (operational structure) + sensor-acequia integration (alert.live cameras) + citizen-submission pattern (community-reported sightings) all at once. The vocab needs to accommodate this composition naturally; the URI-as-primitive frame already does.
## 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 four layers held in the word; this note foregrounds the Layer 3 / Layer 4 senses operationally - [account-layer.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/account-layer.md) — the two-layer model (participant + account); orgs that form acequias also fund accounts that support the acequia infrastructure - [uri-as-primitive.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/uri-as-primitive.md) — the URI-as-primitive frame; cross-acequia URI sharing is the integrative pattern in action - [user-representation-vocabulary.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/user-representation-vocabulary.md) — the broader vocab; should add Acequia as a vocabulary entry, recast Group/Organization/Event/Scenario in this light - [participants-and-resources-in-uri-sense.md](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/participants-and-resources-in-uri-sense.md) — URI patterns; should add acequia URI patterns + the alert.live sensor-acequia worked example - [fused critique](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/artifacts/anyhazard-user-model-critique-fused.md) — updated to include the ICS-foregrounding recommendation - ICS reference: [FEMA NIMS ICS documentation](https://www.fema.gov/emergency-managers/nims/components) (canonical source for ICS doctrine)