Pedestrian Realm 311
Hackathon Submission | Elasticsearch Agent Builder | Team Synaptic Weave
Elasticsearch | Elastic Agent Builder | ES|QL | Next.js | React | TypeScript | Claude
The Problem
Every day, city dispatchers process hundreds of 311 infrastructure complaints — crumbling curb ramps, broken sidewalks, inaccessible pedestrian crossings. For each one, they manually look up nearby assets, cross-reference ADA regulations, call utility companies to check for buried lines, and determine which department should handle the repair. That process takes 30 to 45 minutes per ticket. ADA violations get missed. Utility lines get struck by crews who weren't told about them. And the quality of that triage depends entirely on who's in the office and how stretched the team is that day. The person in a wheelchair is still waiting either way.
Design Approach:
Triage as a Systems Design Problem
The most important reframe was this: faster-and-inconsistent just fails at speed. The more meaningful goal was every complaint getting the same thorough analysis, regardless of when it comes in or who's handling it. That reframe changed the design target from "help dispatchers work faster" to "build a system that handles the analysis so dispatchers can focus on judgment calls and exceptions."
Three Principles Guided Every Decision:
- Conflict detection before routing — the most dangerous failure mode wasn't slow triage, it was incomplete triage. A crew dispatched without knowing there's a gas line 12 inches below the surface is a safety incident waiting to happen. The system surfaces constraints before routing, every time, without exception
- Routing matched to actual complexity — the system encodes routing logic explicitly. A complaint with both an ADA slope violation and an underground utility conflict routes to Specialized Engineering. A complaint with just a minor crack routes differently. Transparent, auditable, consistent
- The loop closes — most triage systems stop at dispatch. This one continues monitoring after the work order is created, tracking SLA compliance, flagging breaches, and updating the city's global compliance score when repairs complete
The ORCA Data Model
The backbone of the system is a single Elasticsearch index built using the ORCA data model — Objects, Regulations, Constraints, and Actions — with an object_type discriminator so all seven domain types coexist in one index. This keeps the entire municipal domain queryable in one place and makes ES|QL joins across object types clean and fast.
The entire domain — assets, regulations, utilities, departments, requests, work orders, compliance score — queryable in one place.
Seven Object Types Power the Entire System
- Infrastructure Asset — physical elements of the pedestrian network with condition data, slope measurements, and compliance status
- ADA Regulation — specific code sections with thresholds and violation criteria (Section 406: max 8.3% slope; Section 402: max 5.0%)
- Underground Utility Constraint — buried infrastructure with geo-coordinates, depth, buffer requirements, and utility company contact
- Department — routing destinations with capability profiles and SLA targets
- Service Request, Work Order, and Global Compliance Score — completing the full triage-to-completion lifecycle in a single unified index
The Agent Architecture
- Geo-asset lookup — finds all infrastructure within 200 meters of the complaint using Elasticsearch geo-distance queries
- ADA compliance check — compares asset measurements against regulation thresholds with specific code citations
- Utility conflict detection — identifies underground infrastructure within 100 meters with buffer requirements before any routing decision
- Department routing logic — maps the combination of violation types and constraints to the correct department automatically
Measured Outcome
The triage cycle drops from 30–45 minutes per ticket to under 30 seconds. But the more significant shift is qualitative: the quality of triage no longer varies with staffing, time of day, or individual dispatcher knowledge. The utility conflict check that might get skipped on a busy Friday afternoon runs automatically every time. That consistency is what makes the safety argument — and the equity argument. A broken curb ramp in one neighborhood gets the same analysis as one in another, regardless of which dispatcher picks up the queue.
Thirty seconds. Not thirty minutes. And the same thorough analysis every time.
What's Next
Real-time integration with city GIS systems for live infrastructure data, expanded coverage to traffic signals and stormwater assets, predictive SLA modeling based on department workload, and a citizen-facing portal where residents can track the status of their 311 reports in real time.
The system proved the concept. The infrastructure exists to scale it.
What I Learned
- Elastic Agent Builder is remarkably capable when the data model is well-designed — the combination of geo-distance search, regulation cross-referencing, and constraint detection in a single ES|QL workflow creates intelligence that would be difficult to replicate with traditional rule-based systems
- The single-index ORCA pattern — unifying 7 object types with an object_type discriminator — was the architectural decision that made everything else possible
- Designing the conflict check so it cannot be skipped was a more important decision than any UI consideration — constraints and consistency are design problems, not just engineering ones
- platform.core.execute_esql and platform.core.generate_esql are incredibly powerful built-in tools that let the agent reason about data in ways we hadn't anticipated
Skills Demonstrated
- Systems thinking through ORCA data modeling — 7 object types, single unified Elasticsearch index
- AI agent design — tool architecture, YAML workflow sequencing, conflict detection logic
- Technical design — Elasticsearch geo-spatial queries, ES|QL date math, Elastic Agent Builder, Next.js/React implementation
Project Links
Collaborator
- Michael Brown — development partner and co-architect of the Elasticsearch data model and agent tooling
Reflection
- This project started as "can an AI agent handle the full triage chain?" and ended with a working answer: yes, when the data model is designed right. The ORCA pattern — treating regulations, constraints, assets, and actions as first-class objects in a unified index — is what made the agent's reasoning possible. Without that foundation, the geo-queries, ADA checks, and routing logic would each be isolated lookups. Together, they form a reasoning chain.
Designing the conflict check so it cannot be skipped was a more important decision than any UI consideration.
