Validated, signed, in scope.
A phase change does not proceed under ALLOW unless the validated preconditions are met. Otherwise, DEFER to the named authority, or SYSTEM_UNVERIFIED if a precondition input cannot be evaluated.
Verticals / 2.3
Critical infrastructure & stadium safety.
Situational risk reading — never individual surveillance. The platform governs phases, role-based information delivery, and the authorization paths that hold under pressure.
01Stadium safety: crowd flow and emergency coordination
Stadium safety is a coordination problem with a hard real-time constraint. The platform reads situational signals from authorized inputs — sensor streams, gate counts, structural monitoring, weather, public transport status — and validates them against the venue's safety policy. The output is one of the canonical states, with the named human authorities (stadium safety lead, club, stewards, medical, emergency operators) receiving the information and the authorization request bound to their role.
What the platform does not do, by architecture: identify individual attendees; perform facial recognition; track individuals across the venue; build profiles of fans. The unit of governance is the situation, not the person.
02Evacuation governance: phase coordination, role-based information
An evacuation is a sequence of phases. Each phase has preconditions, named authorities for the phase change, and an information envelope to deliver to each role on the field — stewards receive different content from medical, who receive different content from the emergency operator. The platform governs the phase sequence under the venue's policy, validates the preconditions at each phase change, routes the phase-change authorization to the named human, and writes the phase, the authorization, and the information envelope to the chain.
The right information, the right role.
Each role receives the information envelope its policy defines for the active phase. Cognitive overload is prevented by design — the field interface delivers what the role needs, no more.
Stewards, medical, security, club.
Coordination across the venue's response is not implicit. The platform makes it explicit, deterministic, and reviewable after the fact.
03Emergency response: medical, weather, structural risk
Emergency categories share an operational shape — situational signal arrives, policy preconditions evaluate, a phase change is requested, named authorities authorize, the response sequence executes — even though the underlying triggers differ. The platform's role is to make the shape uniform: medical emergencies, weather events, structural risk all flow through the same governance kernel, with the policy difference encoded in the CL.
Critical principle
Situational risk reading, not individual surveillance. The platform is engineered explicitly to make this distinction architecturally enforceable, not policy-stated.
04Coordination with stewards, security, medical, club
Where the venue's authorized partners run their own operational systems — steward dispatch, medical command, security incident management — H.A.R.I. is designed to integrate via authorized API connections. The integrations are governed by the same provider management discipline as any other authorized integration. See API governance & provider management.
05Beyond stadiums: critical infrastructure
The same architecture extends naturally to other critical-infrastructure contexts where governance density is high and accountability matters: regulated utilities, transport hubs, public events, major construction sites. The vertical's deepest pilot work is in stadium safety, and extension into adjacent contexts is architecture-ready when scoped.
Status
Architecture-validated for stadium safety governance and emergency phase coordination. Pilot-ready when scoped and authorized — by venue operators, federations, leagues, or public safety authorities with the operational mandate to deploy.
Back to top