**Artifact** from Bead: 31bd5380 · [canonical source](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/artifacts/anyhazard-user-model-critique-fused.md) · session 2026-06-03 · discussion: Talk: 31bd5380
**For:** Kaz, author of the AnyHazard User & Organization Management / Simtable Sessions / Layer Manager pitches. **From:** two sibling reviews (Claude + Gemini), integrated into one read. **Date:** 2026-06-03. **Source documents reviewed** (snapshot 2026-06-02): - [`effort-1-user-org-management.md`](https://redfish.acequia.io/kaz/pitches/anyhazard-user-model/effort-1-user-org-management.md) — User Manager - [`effort-1.1-simtable-session-discussion.md`](https://redfish.acequia.io/kaz/pitches/anyhazard-user-model/effort-1.1-simtable-session-discussion.md) — Simtable sessions - [`effort-2-layer-manager.md`](https://redfish.acequia.io/kaz/pitches/anyhazard-user-model/effort-2-layer-manager.md) — Layer Manager You don't need to navigate the source review beads to act on this. The provenance trail is at the bottom.
## Frame **AnyHazard is an app on Acequia.** Acequia is *both a pattern and a platform* — the **pattern** is a technical-and-governance composition (open protocols, domains, capability-discipline auth, distributed-origin substrate; governance per Ostrom-style observed features that successful commons exhibit) that anyone can implement. **The platform** is Redfish Group's service offering of the pattern — it manages custom domains, hosts deployments, and provides the infrastructure services so customers don't have to. The pattern can also be self-hosted by customers with their own IT capability. The relationship is analogous to **email**: SMTP/IMAP is the open protocol (the pattern); Microsoft 365 / Google Workspace / Zoho Mail are managed platforms supporting custom domains (`@yourcompany.com`); self-hosted Exchange / Postfix-Dovecot / Zimbra / Mailcow are the DIY route. Most customers use a managed platform; some run their own infrastructure; the protocol federates either way. AnyHazard is the emergency-response application; `realtime.earth`, `alert.live`, citizen tools, and news-media tools are sibling applications on the same platform. **AnyHazard's customers (fire departments, EMS, emergency management agencies) already have deep tech stacks** — AlertWildfire cameras, Technosylva, TabletCommand, Intterra, CAD, AVL, Cesium ION, Genasys/ZoneHaven, ATAK + TAK servers, IFDSS, Google Earth, more. The pitch should position AnyHazard not as yet-another-platform but as **the integration layer** for that existing stack, governed by the acequia pattern, with the **Incident Command System (ICS)** as the primary governance template for emergency-response acequias.
## Executive Summary The pitches are solid product specs in the GitHub/Slack SaaS register. The Acequia-as-substrate stance is correct; the Simtable reframe (*"the table is a rendering surface for permissions you already hold or granted on the fly"*) is the strongest single line in the three documents; the host/participant/observer vocabulary in effort 1.1 is clean; the N-of-M successor model is right-shaped; replacing Marcos with first-class platform action is the right kind of platform thinking. None of this should change. The work to do is **reframing**, not rewriting. Five recommendations in priority order: 1. **Foreground ICS as the primary governance template for emergency-response acequias.** ICS already solves the user-vocabulary problem the rest of this critique calls out — it mandates Common Terminology discipline across agencies. Adopting ICS terminology directly (Incident Commander, Command Staff, Section Chiefs, Unified Command, IMT, Area Command, Complex, transfer of command, demobilization) collapses several recommendations below into one structural move. 2. **Position AnyHazard as the integration layer for the customer's existing stack.** The fire department has already chosen its tools; AnyHazard's value is composing them, not competing with them. The integration pattern is "AnyHazard as a service-account on each external platform with access token + webhook." Twelve named platforms cluster into seven integration shapes (sensor / simulation / command-control / layer-source / zone-alert / tactical-federation / visualization-client). Add an "Integrations" section to effort-2 with the seven shapes; price on integration depth rather than seats. 3. **Adopt the two-layer model: participant layer + account layer.** Participant layer is free, anonymous-capable, URI-anchored (where the acequia governance work happens — for emergency response, where ICS lives). Account layer is for-pay, identity-required, funds higher-tier platform-infrastructure services (backup, TURN-server, transactions, subdomain/domain management, reverse proxying, mayordomo agents). Admin and user are account-layer roles; participant is a participant-layer relationship. This separates concerns the pitch currently interleaves. 4. **Foreground URI as the primitive; enable anonymous participation as the default.** A participant is *the sum of capabilities reachable from an identity URI*; identity URIs are convenient but not required. Anonymous participation (exercising a capability at a URI without holding a persistent identity) becomes the default, not a special-case "guest mode" — enables citizen URI submissions, anonymous witness reports, viewer-contributed imagery. This is the same direction the platform's chain-token capability discipline already operates; the user-facing vocabulary just needs to match. Anonymous participation, the URI bind/mount unifier (which collapses nine separate sharing/grant/federation/move features into one parameterized operation), and the apoptotic-signal lifecycle unifier all flow from this single reframe. 5. **Apply the register-split discipline (Document A / Document B) to the non-ICS surfaces; do a premature-implementation pass.** ICS adoption (R1) solves the register problem for emergency-response sections. The non-ICS surfaces (Simtable session mechanics, the Layer Manager catalog, cross-cutting platform features) still benefit from explicit splitting into Document A (user-rep vocabulary, no implementation nouns) + Document B (vocabulary→primitive mapping, numeric defaults, format lists). The premature-implementation table at the end identifies ~12 places where magic numbers, named protocols, or specific UI patterns occupy slots that would be more durable holding constraints. Mechanical fix; tidy pass; not a rewrite. The shippable UX additions Gemini's review identified — Global Acequia Passport (opt-in cross-subdomain identity), DIY-to-Enterprise device-promotion flows, offline-edge / fire-camp partition handling — extend the current model without restructuring and fit naturally inside the recommendations above.
## What the pitches get right - **Acequia as substrate.** *"Acequia identity is the substrate"* and *"this app uses that primitive directly rather than reinventing it"* (effort-1 §1) is exactly the right anchoring move. No parallel auth, no parallel storage. - **The Simtable reframe.** *"The table is a rendering surface for permissions you already hold or granted on the fly"* (effort 1.1 opening). The strongest line in the three documents — it dissolves a whole class of policy puzzles. - **No username/password.** Device-key authentication + invite/device-link flows; handles as display labels not credentials (effort-1 §1 decision 4). - **Marcos as bottleneck.** Naming the human bottleneck and replacing him with first-class platform action (effort 2 §3.4, §3.6). - **Successor model.** N-of-M ownership transfer that doesn't require the original owner's keys (effort-1 §3.3 F3.7) is right-shaped for institutional continuity. - **Host / participant / observer vocabulary** in effort 1.1 §2 — clean vocabulary work; this is what the rest of the spec should aspire to. - **NOTES blocks alongside polished spec** — the working trail of what survived editorial pressure is more useful to a reviewer than a single polished surface.
## Five recommendations, in detail ### R1. Foreground ICS as the primary governance template The Incident Command System is the standardized framework US emergency response has used since the 1970s, mandated by NIMS, used across fire / EMS / law enforcement / public health. It scales modularly (Type 5 single-resource → Type 1 national-catastrophic), supports live / training / reconstruction modes uniformly, and **mandates Common Terminology discipline** — the exact user-vocabulary problem R5 below addresses for non-ICS surfaces. For emergency response, ICS *is* the answer. The mapping into the platform vocabulary is direct: | ICS term | Platform mapping | |---|---| | Incident | An event-acequia; activates on dispatch; deactivates at demobilization | | Incident Commander (IC) | The acequia's mayordomo; single at any moment; transferable | | Command Staff (PIO, Safety, Liaison) | Role bundles bound to the IC's namespace | | Section Chiefs (Operations / Planning / Logistics / Finance) | Sub-mayordomos governing each section's sub-acequia | | Unified Command | Federation between agency-acequias | | IMT (Type 1–5) | Pre-organized template-acequias; tiers map to subscription tiers | | Area Command | An acequia-of-acequias coordinating multiple concurrent incidents | | Complex | A bound collection of related incident-acequias managed as one | | Transfer of Command | Mayordomo succession (formal version of N-of-M succession) | | Demobilization | Apoptotic stand-down; orderly resource release; audit finalization | | Common Terminology | Document A user-rep vocabulary (already mandated by ICS — adopt) | The pitch's existing host/participant/observer vocabulary (effort 1.1) extends naturally — IC is a host role; Section Chiefs are sub-host roles; Strike Team Leaders / Division Supervisors / Branch Directors are the operational hierarchy. The pitch shouldn't invent a new vocabulary where ICS already has one. **Note on broader acequia ecology.** ICS is the template for emergency-response acequias specifically. The pitch should acknowledge that other acequia kinds (citizen — Ring/mobile/GPS family-safety; news-media — editors + viewer URI submissions; sensor-network — alert.live ridgetop cameras with PTZ permissions, archiving, calibration) exist alongside and feed into emergency-response acequias via **cross-acequia URI sharing**. Citizens submit imagery to news and emergency-response acequias; sensor acequias expose live feeds to emergency-response acequias; emergency-response acequias publish curated public-information URIs back out. This isn't a special feature — it's URI bind/mount across namespaces (see R4). ### R2. Position AnyHazard as the integration layer for the customer's existing stack A customer like San Bernardino County Fire Department arrives with a deep tech stack already in place — AlertWildfire cameras they operate, Technosylva for modeling, TabletCommand for incident command, Intterra for analytics, CAD for dispatch, AVL for vehicle locations, Cesium ION for 3D terrain, Genasys/ZoneHaven for evacuation alerts, ATAK + TAK servers for tactical awareness, a home-hardening assessment app, IFDSS for federal fuels data, Google Earth for visualization. They've made tool choices. **AnyHazard's value is being the integration layer**, not yet-another-platform. The canonical pattern — stated by Stephen and already documented in the workspace's [google-earth-integration.md](https://redfish.acequia.io/guerin/docs/realtime-earth/google-earth-integration.md) ("Google Earth as a Duck-Typed Acequia Node") — is **AnyHazard as a service-account on each external platform, with an access token for read/write permissions and a webhook for callbacks/pub-sub.** Any HTTP-speaking platform can be duck-typed into the acequia substrate this way. The twelve named platforms cluster into **seven integration shapes**: | Shape | Example platforms | Acequia pattern | |---|---|---| | Sensor / live-source | AlertWildfire, AVL, CAD | Dynamic URI with `/latest`, `/stream`, `/params/*`, `/actions/*` | | Simulation as service | Technosylva | Submit input → poll/subscribe for output; runs as dynamic resources | | Command/control bidirectional | TabletCommand, ATAK+TAK | Mount external resources + push computed layers back | | Layer / tile source | Cesium ION, Intterra, IFDSS | Mount as read-only namespace | | Zone / alert | Genasys/ZoneHaven | Mount zone definitions; bind triggers for activation | | Tactical federation | ATAK+TAK (special) | Acequia-to-acequia federation; CoT-to-bind/mount bridge | | Visualization client | Google Earth, native viewers | Demand-signal request + situated-response payload | **AnyHazard's value-add once these are in place:** one coherent operating view across platforms; cross-source correlation ("camera frustums covering where Technosylva predicts the fire in 30 min"); acequia governance overlay (the SBCFD acequia's ICS role structure determines what each participant sees across all integrations, regardless of each underlying platform's internal permissions); re-publishing the integrated view to downstream consumers (next-jurisdiction handoff, news media, public information, after-action archive) as a first-class acequia resource. **Implications for the pitch:** add an "Integrations" section to effort-2 enumerating the seven shapes and supported platforms; add a "Customer stack" appendix with SBCFD's stack as the worked example; **re-anchor pricing on integration depth rather than seat count** (this is what customers actually buy); elevate the duck-typing principle to a stated design commitment (customers can self-onboard new integrations via the AnyHazard SDK, not wait for AnyHazard to ship every connector). Acknowledge the real risks: per-platform token + scope maintenance, API drift, rate limits, walled-garden resistance, latency for chained calls, security boundary, customer-governance-vs-acequia-governance cross-mapping.
### R3. Adopt the two-layer model — participant layer + account layer The pitch currently interleaves two concerns the model should keep separate: - **Participant layer** — free, anonymous-capable, URI-anchored. Where acequia governance work happens. For an emergency-response acequia, this is where the ICS structure lives, where bystanders submit imagery, where citizens consume public-information channels, where participants exercise capabilities without (necessarily) holding persistent identities. The platform doesn't charge for participation. - **Account layer** — for-pay, identity-required, tier-differentiated. Where billing lives. The **account** funds higher-tier platform-infrastructure services: backup, TURN-server for WebRTC NAT traversal, transactions between participants, subdomain/domain management, reverse proxying, mayordomo agents, always-on availability, federation infrastructure. **Admin** manages the account; **user** is a participant who has been granted a seat under an account with access to that account's funded services. The clean separation matters: **participation should never require an account; an account should never grant participation rights that weren't already accessible at the participant layer.** The account funds the infrastructure; the participant layer is where the activity happens. In email terms: anyone can send and receive email (participant layer; the SMTP protocol federates anyone); an account at a managed email platform (or self-hosted equivalent) funds the storage, anti-spam, custom domain, mobile sync, etc. (account layer). The platform's commercial model is convenience + operational reliability; the protocol stays open. A participant becomes a user of an account when they need higher-tier services. A guest joining a paid Simtable session doesn't need their own account — service access flows along the host's account-funded entitlements to all session participants. ### R4. Foreground URI as the primitive; enable anonymous participation; collapse nine features into one The pitch centers the *user* as primitive. The deeper Acequia vision — and the platform's existing chain-token capability discipline — centers the *URI* as primitive. **A participant is the sum of capabilities reachable from an identity URI**, plus capabilities held independently. Identity URIs are convenient (a place where capabilities accumulate) but not required. **Anonymous participation** (exercising a capability at a URI without holding a persistent identity) is the *default*, not a special-case feature. The substrate already operates this way at the cryptographic layer; the user-vocabulary just needs to catch up. Three consequences fall out of this single reframe: **Anonymous-capable submission flows become trivial.** A bystander at an incident captures a phone photo; they scan the QR code at the event location; they `POST` the photo URI to the event's `submissions/` endpoint; the event acequia accumulates a URI; no guest-user account is created, no identity invented. The same pattern serves citizen contributions to news-media acequias and witness submissions to sealed-incident URIs. **Nine separate share/federate/move features collapse to one parameterized operation.** Effort-1 F5.1 (share a resource), F3.8 (federation), F4.6 (council delegation), F6.4 (bring-your-own to session), F6.7 (Simtable-as-device), and effort-2 F1.8 (cross-source dedup hint), F4.2 (move between devices), F7.2 (ownership transfer), F7.4 (pinned org resources) are all **the same operation at different scope and TTL**: bind a resource URI into a destination URI's namespace, with attenuated permission, for some duration. The differences are parameters (which URI, which scope, what attenuation, what TTL), not separate features. The spec compresses significantly; the cross-source dedup hint becomes trivially correct because it's just rendering "this resource has N bindings into my namespace." The empirical word-count evidence is striking. Across the three pitches: **`device` appears 55 times; `upload` and forms 11 times; `link`/`linking` 14 times; `mount` / `bind` / `binding` (URI sense) 1 time** — and that one is incidental. The pitch is operating in a device-centric framing where the URI-mount framing would naturally collapse the separate features. **Lifecycle events unify under apoptotic-signal propagation.** F2.3 (logout), F2.4 (token revocation), F3.7 (successor transfer), F4.5 (key rotation), F4.8 (group expiry), F5.2 (session-only grants), F6.6 (end session), F7.3 (orphan recovery), F8 (soft/hard delete) — all the same shape: emit an apoptotic signal; cascade propagates through the chain-token graph; orphan recovery is the rare-failure case where the signal didn't reach the leaves (not a routine feature). The platform's chain-token revocation cascade (effort-1 §F5.6) already supports this; the user-vocabulary just hasn't named it. This is a *longer-horizon* recommendation than R1–R3. It's a directional commitment that shapes how the spec converges as the underlying frame keeps evolving. Not a near-term rewrite. ### R5. Register-split discipline on non-ICS surfaces + premature-implementation pass For the surfaces ICS doesn't already cover (Simtable session mechanics, Layer Manager catalog, cross-cutting platform features, account-layer / billing concerns), apply the **Document A / Document B split** explicitly:
- **Document A — Vocabulary Spec.** Audience: facilitators, training coordinators, fire chiefs, PIOs, the platform PM. Concepts, capabilities, user stories, policy levers in plain language. Does NOT use the words `userId`, `deviceId`, `kid`, `PS256`, `chain token`, `stored token`, `subdomain`, `WebDAV`, `STAC`, `OGC`, `GeoTIFF`, `MBTiles` (except in a single "Substrate" footnote pointing to Document B). - **Document B — Implementation Map.** Audience: implementers, integrators, auditors. The vocabulary→primitive mapping table, the data model, numeric defaults, format lists, validation regexes, capacity targets, protocol/auth details. Does NOT introduce new vocabulary that isn't in Document A. Effort 1.1 already lives nearly entirely in Document A register — that's the target for Document A across all efforts. In parallel, walk the **premature-implementation table** below and apply the mechanical fix: cast magic numbers as constraints + TBDs, move protocol/format names from spec body to the implementation map, defer UI specifics to a separate UX section. ~12 instances; not a rewrite. Shippable UX additions that fit naturally inside this work: **Global Acequia Passport** (opt-in cross-subdomain identity unification; Gemini's contribution); **DIY-to-Enterprise device promotion** (atomic transfer of device URI from `<person>/devices/X` to `<org>/devices/X`); **offline-edge / fire-camp partition handling** (ephemeral local grants at disconnected Simtables, reconciliation on uplink return, conflict resolution model).
## Findings appendix ### Premature-implementation table (R5) | Where | Current form | Suggested form | What's pinned | |---|---|---|---| | effort-1 §1 decision 4 | "Acequia's PS256 keypair" | "Acequia device key" | Specific JOSE algorithm | | effort-1 §3.1 F1.3 | "5-minute QR code + 6-character short code" | "Short-lived QR + short code (defaults per policy)" | Specific durations/lengths | | effort-1 §3.1 reqs | Handle regex `^[a-z][a-z0-9_-]{2,29}$` | "URL-safe slug, 3–30 chars" | Exact character set + length | | effort-1 §3.3 reqs | Successor "default 2-of-3" | "Threshold N-of-M, per-org" | Specific N/M without rationale | | effort-1 §3.6 reqs | "At least 10 simultaneous participants" | "Scale to operational target" | A number without basis | | effort-1 §F2.4 | "API tokens... stored tokens" | "External-tool access" | Implementation noun in feature name | | effort-2 §2 / §F5.3 | "STAC of resources" / "Lock STAC entry" | "Metadata records" / "Lock metadata" | Specific catalog standard | | effort-2 §3.3 F3.1 | Format list (GeoTIFF, GeoPDF, Shapefile, GeoJSON, KML/KMZ, OGC, MapServer, MBTiles) | "Common geospatial formats; coverage list in appendix" | MVP scope to specific list | | effort-2 §3.3 reqs | "QR... up to ~2 KB" | "QR... size limit per encoding" | QR version + encoding choice | | effort-2 §3.6 F6.5 | "Side-by-side state" conflict resolution | "Conflicts surfaced for user resolution; UX TBD" | Specific UI pattern | | effort-2 §3.8 F8.1 | "Default 30 days" recovery | "Configurable recovery window" | Specific duration | Pattern: the pitch reaches for a concrete value or technology name to make a feature feel definite; the value occupies a slot that would be more durable holding a property + TBD. Tidy mechanical fix. ### Structural gaps (R4 territory, abbreviated) | Gap | What the pitch has | What URI-as-primitive enables | |---|---|---| | User-as-primitive vs URI-as-primitive | Permissions are attributes of users; roles are bundles attached to users | Permissions are polarized GETs from participants to URIs; roles are binding patterns | | Bind/mount as unifier | Nine separate share/federate/move features (effort-1 F5.1, F3.8, F4.6, F6.4, F6.7; effort-2 F1.8, F4.2, F7.2, F7.4) | One parameterized binding operation | | Apoptosis-vs-necrosis lifecycle | Nine separate lifecycle mechanisms (F2.3, F2.4, F3.7, F4.5, F4.8, F5.2, F6.6, F7.3, F8) | Unified apoptotic-signal propagation through chain-token graph | | Logic-at-app vs logic-at-URI | Approval queues, federation flows, mode policy live in companion-app code | Live at the resource URI; companion app becomes a view; alternative clients become possible | | Audit-as-compliance vs audit-as-substrate | Audit log is compliance data | Audit log is the substrate for an attention/attribution ledger (advanced-wave accounting) | ### Acequia-as-pattern + Ostrom's commons-governance features The acequia governance pattern is Ostrom-style: she catalogued features that successful commons exhibit (clear boundaries, congruence between rules and local conditions, collective-choice arrangements, monitoring, graduated sanctions, conflict-resolution mechanisms, recognition of right-to-organize, nested enterprises). The pattern and platform already exhibit five of these strongly (boundaries, congruence, monitoring, graduated sanctions, right-to-organize). Three are opportunity areas where the platform could add first-class support: **collective-choice arrangements** (voting/proposals), **conflict-resolution mechanisms** (low-cost dispute venues), **nested-enterprise patterns** (acequia-of-acequias governance). These are real product opportunities and the platform's competitive positioning is "Ostrom-compatible commons-governance made easy."
## Provenance **Reviewer beads** (full working notes; this artifact is the integrated deliverable): - [Claude bead `31bd5380...`](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/) — full review notes; relevant for digging into any recommendation - [Gemini bead `9e1d87f5...`](https://redfish.acequia.io/guerin/.agents/9e1d87f5-a226-4d1a-be05-64c8d5cacf38/) — Gemini's independent review; the shippable UX additions (Passport, device promotion, offline-edge) originated here **Foundational vision frame** (cited from R4 in particular): - [Bead `874fce5b...`](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/) — the design-direction notes underlying the URI-as-primitive recommendation **Canonical platform docs** (cited from R3 and R5): - [acequia.io/documentation/platform/](https://acequia.io/documentation/platform/index.md) — Acequia platform implementation: user-authentication, three-mode JWT detection (chain / user / legacy device), stored-tokens UX, distributed-origin architecture - [google-earth-integration.md](https://redfish.acequia.io/guerin/docs/realtime-earth/google-earth-integration.md) — the canonical template for duck-typing external HTTP-speaking platforms as acequia participants (R2)
*This artifact is the deliverable. The reviewer beads above contain the longer working trail for anyone who wants it.*
## References (bead cross-links) - Bead: Acequia User Model & Architecture Bead · [canonical](https://redfish.acequia.io/guerin/.agents/9e1d87f5-a226-4d1a-be05-64c8d5cacf38/) - Bead: 874fce5b · [canonical](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/)