**Artifact** from Bead: F5b21ea4 · [canonical source](https://redfish.acequia.io/guerin/.agents/f5b21ea4-2b73-4c8b-96f0-892f63ad86cf/2026-06-04/artifacts/anyhazard-as-the-digital-architecture-for-ics.md) · session 2026-06-04 · discussion: Talk: F5b21ea4
## The digital architecture for the Incident Command System **Bead:** `f5b21ea4-2b73-4c8b-96f0-892f63ad86cf` · **Date:** 2026-06-06 **Status:** Working concept piece for AnyHazard product positioning. Stephen has used this descriptor — *the digital architecture for ICS* — as a core framing of the platform's purpose. This document captures it as a deliverable suitable for pitches, foundational briefs, and external positioning. Audience: ICS practitioners (incident commanders, division supervisors, fire chiefs, emergency managers); decision-makers at fire agencies, counties, and state emergency-management offices; foundation and infrastructure funders. **Companions:** [citizen-direct-and-agency-via-substrate.md](../notes/citizen-direct-and-agency-via-substrate.md), [intelligence-blindness-and-the-digital-acequia.md](intelligence-blindness-and-the-digital-acequia.md), [epidemic-sousveillance.md](epidemic-sousveillance.md), [santa-fe-rfei-data-platform.md](santa-fe-rfei-data-platform.md) (the 2019 RFEI that named the architecture).
## The claim The Incident Command System was designed to push decision authority to the lowest competent level. *Distributed mission command*, in military terms. The Incident Commander provides intent; Division Supervisors, Section Chiefs, Strike Team Leaders, and Single Resources act on local judgment within doctrinal scope. The whole hierarchical structure — Operations, Planning, Logistics, Finance — is a coordination framework for *delegated authority*, not a chain of orders. The dominant digital data architecture for ICS, organized around ESRI's centralized GIS hosting model, **imposes a hub-and-spoke data flow on a peer-to-peer authority structure.** Every cross-Division exchange routes through a central authoritative service. Every citizen contribution has to enter via an institutional intake pathway. Every mutual-aid arrival has to authenticate against the host organization's hub before the data plane recognizes them. The data architecture does not mirror, shadow, or match the human ICS authority architecture — even when operators have field connectivity, accounts with edit privileges, mobile applications, and live pub/sub on operational layers. AnyHazard with Acequia™ is the digital data architecture that mirrors ICS. Peer-to-peer data flow between Division Supervisors, Section Chiefs, and adjacent ICS roles. Selective coordination through corridors instead of routing through a hub. Citizens integrated as Single Resources via capability exercise at incident URIs. Cross-jurisdictional mutual aid via direct capability flow between organizational domains. **The doctrine is peer-to-peer; the substrate is peer-to-peer; the data flow matches the authority flow.**
## The data-architecture mismatch The technical claim is about *where the data goes in the protocol*, not about whether operators have tools they like or field connectivity they can reach. In WUI environments with cellular or radio data infrastructure, agencies on ESRI's platform may already have field-editable layers, mobile applications, accounts with edit privileges, and live pub/sub on operational data. Operators can push edits and subscribe to changes from the field. The capability is there. What is *not* there is a data architecture that **mirrors, shadows, or matches the human authority architecture of the Incident Command System.** ICS distributes decision authority horizontally. Division Supervisors coordinate seam-to-seam with adjacent Divisions, peer-to-peer. Section Chiefs coordinate among themselves at the Section level. Strike Team Leaders work tactical objectives within their authority. Single Resources contribute back up at their level. Mutual-aid units integrate at the role they are filling. Citizens-as-Single-Resources enter at the level where their contribution applies. *The human architecture is peer-to-peer with selective escalation upward.* The dominant digital data architecture under ESRI's model — and the broader pattern under centralized GIS hosting — is *hub-and-spoke*. Every edit, every layer update, every cross-Division exchange, every citizen contribution, every mutual-aid ingestion routes through a central authoritative service owned by the host organization. The hub holds the authoritative state; clients pull from and push to the hub; in the data plane clients do not talk directly to each other. **That is the architectural mismatch.** The human ICS architecture is peer-to-peer; the data flow is hub-and-spoke. The doctrine treats adjacent peers as authorized to exchange information directly; the data layer routes every such exchange through a hub that has no doctrinal role in the coordination. Even when the hub is fast, available, well-administered, and reachable from the field — the data flow does not mirror the human authority structure. Consider what this would look like in the *social* ICS. Adjacent Division Supervisors coordinate seam-to-seam in the social architecture by using the tactical channel directly and by meeting face-to-face at a drop point — unfolding a paper map on the hood of a pickup, sketching agreements, reporting back to Ops with a coordinated plan. *Mission command working as designed.* Imagine instead that every Division-to-Division communication had to route through *dispatch*. Division A calls dispatch to relay messages to Division B; dispatch records and forwards; B receives and replies through dispatch. Operators would reject this as absurd; they would never accept a social architecture that routed every peer coordination through a non-participant in the coordination. **That is what the data architecture imposes.** Every peer-to-peer data exchange between Division Sups, between Sections, between agencies, between citizens and the operational picture — routes through the hub. *The hub is the digital dispatch.* Operators have accepted it in the data layer (often without recognizing it) because the alternative architecture has not been widely available. AnyHazard with Acequia™ is the digital data architecture that mirrors ICS. Each role in the ICS structure operates at a peer-addressable URI under its organizational domain: IC, Section Chiefs, Division Supervisors, Strike Team Leaders, Single Resources, mutual-aid partners, citizens-as-Single-Resources. Data exchanges between roles route peer-to-peer in the data plane, with selective coordination through corridors, *exactly as the human authority structure operates*. The hub is not eliminated — it is repositioned. Instead of being the routing center for every exchange, it becomes one node among many, used when peer-to-peer routes are unavailable, when the doctrine specifically requires central authoritative state, or when archival and audit roles demand it. The point is *technical*. It is about where the data flows in the protocol — A → hub → B vs A ↔ B — not about which tools operators prefer to use. The doctrine and the data architecture should agree. Today they do not.
## What the data-architecture mismatch produces The hub-and-spoke data flow produces specific operational consequences under ICS doctrine that should not exist under a doctrinally-aligned data architecture. They are not failures of operator competence, institutional will, or tool availability. They are direct technical consequences of routing every data exchange through a hub that has no doctrinal role in the coordination. - **Division-to-Division as hub-traversed exchange.** When Division Supervisors coordinate tactical status, the data flow goes A → hub → B and B → hub → A, even when A and B are physically adjacent and operationally peer. Every exchange traverses a hop that has no doctrinal role. In contested-bandwidth conditions (WUI, dense incident, smoke-affected radio, congested networks) or when the hub itself is bandwidth-constrained, hub-trip latency stacks against rapid local coordination. The doctrine treats A and B as peers; the data architecture treats them as siblings of the hub. - **Citizen and mutual-aid data isolation.** Ground intelligence — a citizen photo with geolocation, an evacuee status report, an arriving strike team's situational awareness from another jurisdiction — has no peer-to-peer ingestion path into the host org's operational data layer. The architecture provides only the institutional intake pathway: PIO scrape, federation setup, manual account onboarding. The data exists, often with operational relevance and geolocation baked in; the architecture has no peer-route for it. - **Multi-agency unified command as parallel data planes.** When two ICS structures need to unify, the human coordination happens in conference rooms and on shared radio nets, exactly as doctrine designs. The data architectures remain parallel: each org's hub is the authoritative source for its own jurisdiction; cross-org synchronization requires explicit federation setup that no one did in advance. Doctrine requires one operational picture; the architecture maintains two. New Mexico's COVID response in 2020 is the canonical case (see [epidemic-sousveillance.md](epidemic-sousveillance.md)) — parallel ICS structures persisting because no data architecture exposed a unification path even when the doctrine demanded one. - **Single Resources as data endpoints, not participants.** ICS Single Resources — strike teams on the line, dozer crews, individual responders, sensors, drones — are intended in doctrine to contribute situational data at their level of authority. Under hub-and-spoke architecture they are primarily *consumers* of information pushed down from the hub. Their contributions back up require publishing workflows most do not have credentials or training to operate. The data architecture treats them as endpoints; doctrine treats them as participants. - **Post-incident data silos.** The operational data layer lives in the host org's hub; cross-org learning requires explicit consent flows that take months. After-action reports become narrative PDFs; the operational data itself stays siloed. The next incident's IC starts from a data architecture that has not inherited prior incidents' lineage. - **Forced data fusion at the hub instead of at the edge.** Beyond routing topology, the architecture decides where data fusion happens. Hub-and-spoke requires raw data to traverse to the central service before fusion can occur. Consider two Divisions with three crews each — six crews total — each generating GPS location, photos, and video during a single operational period. A typical haul: twenty videos at roughly 500 MB each; thirty photos at roughly 12 MB each. Roughly 10 GB of raw operational media generated in a single shift across two divisions. The Operations Section Chief does not need the raw 10 GB. They need crew center points, a derived 3D plume model (Gaussian Splatting from video, for example), derived perimeters, time-of-arrival estimates, and simplified plume vectors with spotting data — a few hundred kilobytes of structured derived product. *That fusion can happen at the edge — on phones and laptops in the field — if the data can travel face-to-face between collaborating devices and horizontally between adjacent crews and Divisions.* Under hub-and-spoke, the raw 10 GB has to traverse the wide-area network to the hub for fusion to occur there. Bandwidth cost: thousands of times what is actually needed. Latency cost: the operational picture lags by the time it takes raw data to upload over contested networks. Compute cost: edge processors (phones, laptops in the field) sit idle while the centralized service is overwhelmed. In each case the underlying technical issue is the same. **The data flow does not mirror the doctrinal authority flow.** The human ICS architecture is distributed and peer-to-peer; the data architecture is centralized and hub-routed; the mismatch produces operational consequences even when the human operators are competent and the digital tools work as designed for their intended (hub-centric) use cases.
## What AnyHazard with Acequia™ restores The architecture maps each ICS role to a peer-addressable URI under that role's organizational domain. A CalFire Division Supervisor working a fire is reachable at a URI under `calfire.ca.gov`'s namespace; an adjacent county's Strike Team Leader at a URI under the county's `.gov` namespace; a citizen reporter at a URI under their personal device's identity (anonymous or authenticated per the policy of the URI they're reporting *to*). Each domain is its own *acequia* — its own authentication and authorization regime — with its own internal rules. The Acequia™ substrate (peer-to-peer plus cloud, with WebRTC, websocket-tunneling, and discovery infrastructure as the connective tissue) is what lets capability tokens flow *across* domain boundaries, honored by the receiving acequia, on a per-incident, per-policy basis. When the data flow mirrors the human authority flow, the operational consequences named above disappear by construction. Each role's data routes to the roles ICS doctrine authorizes it to flow to; the hub is no longer the routing center for every exchange. - **Division-to-Division as peer data exchange.** Adjacent Division Supervisors exchange tactical status directly between their devices' operational layers, peer-to-peer in the data plane. The data routes through the substrate rather than traversing a central hub. Hub-trip latency under bandwidth contention drops to single-hop cost. *Data flow matches authority flow.* - **Citizen and mutual-aid as peer-addressable participants.** A citizen contributes data into the operational picture by exercising a capability at the incident URI, per the policy at that URI — anonymous if the policy permits, attributed if it requires. A mutual-aid strike team presents its home-org credentials at the incident URI; the host acequia recognizes the federation token and grants scoped access. The architecture provides peer-to-peer ingestion routes that doctrine has always assumed should exist. PIO and the formal institutional intake pathways do not disappear; they continue as one route among several. - **Multi-agency unified command as shared incident URI subscription.** Two ICS structures coordinate via incident URIs that each org's internal sections subscribe to. Each org retains its internal command structure and its data sovereignty within its acequia; the shared operational picture is mutually maintained at the shared URIs. *Doctrine and data architecture agree.* - **Single Resources as data contributors.** Strike teams, dozer crews, individual responders, sensors, and drones become peer-addressable participants in the operational data layer. They contribute back into the picture for their level of authority through capability flows the substrate provides natively. They are no longer architectural endpoints. - **Post-incident data lineage.** The operational data layer persists at the incident URI; cross-org learning happens through selective republishing of capability tokens. The next incident's IC inherits the data architecture of prior incidents, scoped by capability and policy at each URI. - **Data fusion at the edge, with bidirectional summary propagation.** When data exchanges happen peer-to-peer, fusion happens where it makes sense — on the phones and laptops that generated the raw media, or on a Division Sup's tablet aggregating across the crews in their Division. Two Divisions' six crews exchange raw photos and video peer-to-peer with each other and with their Division Sups; the Division Sups' devices generate the 3D plume model, derived perimeters, time-of-arrival estimates, and spotting vectors locally; only the structured derived products — crew center points, plume vectors, perimeters, ETA estimates — propagate up to Ops. The Ops Chief receives a kilobyte-scale operational summary. *And* the Ops Chief can pull raw underlying data on demand via the substrate — peer-to-peer back to the source — when they need it. **Bidirectional data flows by design: summaries propagate up; raw detail is reachable on demand; nothing centralizes by default.** The substrate does not replace ICS roles, tools, radio nets, conference rooms, paper maps, the IC's authority, or any of the operational practices the human ICS architecture provides. **It replaces hub-routed data flow with peer-to-peer data flow that mirrors the human authority structure, and it relocates data fusion from the centralized hub to the edge where the data lives.** The IC still issues intent; Section Chiefs still organize their sections; Division Supervisors still coordinate seam-to-seam at the drop point with paper maps on the pickup hood; Single Resources still execute tactical objectives. The architectural claim is about where the data flows in the protocol and where the fusion happens in the compute layer — and both now match the human authority structure.
## The COVID case as proof of the structural argument New Mexico's COVID response in 2020 produced an unambiguous test of the architectural diagnosis. The NM National Guard and the NM Department of Health each stood up their own Incident Command System. *Two ICS structures, same emergency, supposedly unified command.* The structures did not unify operationally — Guard became logistics-focused; DOH attempted contact tracing and modeling and then gave up on contact tracing — and the architectural reason is the one named above: there was no substrate that supported peer-to-peer ICS coordination across jurisdictional boundaries. The COVID case is documented in [`epidemic-sousveillance.md`](epidemic-sousveillance.md) at this bead. The standard reading is institutional failure (governor didn't sign the citizen-app authorization; federal Google OAuth was refused; Trump didn't act). The architectural reading is sharper: *the institutional failures were forced by the absence of a substrate that would have made unified command operationally sustainable.* Doctrine said unify; architecture didn't expose a unification path; institutions defaulted to parallel structures. Architecture-doctrine mismatch is the cause; institutional incoherence is the symptom. This frame matters because it tells ICS practitioners — the buying audience — that the COVID failure they remember was *not* a doctrinal failure or a personnel failure or a political failure (though those were also present). It was an *architectural* failure that no amount of doctrinal recommitment or better leadership would have fixed. Fixing it requires the substrate that matches the doctrine. That is what AnyHazard with Acequia™ provides.
## What this means for the AnyHazard pitch The product positioning that emerges is sharp and competitively differentiated. **AnyHazard does not compete with ESRI on GIS-platform features.** It competes on *architectural fit with ICS doctrine*. ESRI's incumbent advantage is enormous, but their architectural commitment is precisely the mismatch this document names. They cannot easily move because their entire stack and business model is committed to centralized authoritative-data hosting; the alternative requires a different substrate from the ground up. AnyHazard with Acequia™ is that substrate. The pitch in one sentence: *the digital architecture that finally implements what the Incident Command System was designed to be — distributed mission command, peer-to-peer between Divisions and Sections and Agencies and citizens, with selective coordination through corridors that don't bottleneck local action.* Every ICS-trained operator will recognize the architectural mismatch and the proposed answer. The doctrine has been peer-to-peer; the data architecture has been hub-and-spoke; the mismatch has been producing operational consequences for decades, regardless of how good the hub-side tools have gotten. The substrate that matches the doctrine has a doctrinal endorsement, an operator-experience tailwind, and a failure-mode evidence base (Camp Fire, Paradise, COVID, every multi-agency unified command that splintered into parallel data planes). The citizen-direct strand from [citizen-direct-and-agency-via-substrate.md](../notes/citizen-direct-and-agency-via-substrate.md) sharpens too. A citizen on the substrate is not a "civilian reporter" or a "user"; they are a Single Resource in the ICS sense, contributing within doctrinal scope, integrated into the operational picture via the same substrate that connects all the institutional roles. The agency-vs-citizen tension that the citizen-direct note works to dissolve has its principled resolution here: the ICS frame already includes both; the substrate is what lets the inclusion actually function digitally.
## Notes - This document is *positioning*, not *specification*. The specific protocol design (which URIs, which capability tokens, which federation discovery, which fallback paths) belongs in a technical companion that has not yet been written. The protocol-level work is what the new interconcept bead [`8f966e8b-...`](https://redfish.acequia.io/guerin/.agents/8f966e8b-5347-4d1c-b39f-c5bc8fae6523/) opens space for via Vector 5 (federation as cross-domain capability flow). - The ICS-doctrine framing in this document is intentionally non-technical on the GIS side. Operators don't need a GIS-architecture critique to recognize the operational pattern; they live it. The argument lands in the operator's experience, not in the platform-feature comparison. - The COVID and Camp Fire references should be handled with care in any external use. Both are documented in this bead's artifacts; both are politically charged. The substrate critique works on its own merits and does not need to be hung on partisan readings of either event. - "AnyHazard with Acequia™" is the platform's positioning name in this framing. Internally the components are separable (AgentScript, RealtimeEarth, AnySurface, LiveTexture as named in the 2019 RFEI); externally the pairing of the product surface (AnyHazard) with the substrate technology (Acequia™) communicates both the operator-facing application and the substrate-architectural commitment that distinguishes it. - **Capture mechanisms vs the architecture itself.** This document is about the AnyHazard ICS information architecture — *the peer-to-peer propagation substrate that connects ICS roles across acequias*. It is *not* about the capture mechanisms that feed input into the architecture. Capturing a marked-up paper map into the digital layer (photo + georectification + sketched-overlay vector extraction) is an AnySurface capability — Redfish's projected-AR / surface-interaction technology — that operates *upstream* of the AnyHazard architecture. Other capture mechanisms (tablet markup, voice annotation, drone-imagery ingestion, sensor feeds, typed input, LiveTexture realtime camera capture, third-party APIs) similarly feed in upstream. Conflating the capture-mechanism with the architecture muddies both arguments. The architecture's claim — *peer-to-peer propagation across ICS roles via cross-acequia capability flow, doctrinally aligned with mission command* — stands independent of which specific input mechanism happens to feed it. - For follow-up work that the interconcept bead could productively host: a worked URI-and-policy design for the ICS roles named in this document (IC, Section Chiefs, Division Supervisors, Strike Team Leaders, Single Resources, mutual-aid partners, citizen contributors); the federation pattern between agency `.gov` domains and the AnyHazard substrate; the discovery and tunneling infrastructure that makes the substrate function across the NAT/firewall reality of operational networks.
## References (bead cross-links) - Bead: 8f966e8b · [canonical](https://redfish.acequia.io/guerin/.agents/8f966e8b-5347-4d1c-b39f-c5bc8fae6523/)