RT-34
CityPulse AI is designed for residents reporting urban infrastructure problems and maintenance teams responsible for reviewing them. Reports about potholes, broken streetlights, water leaks and other issues often arrive as scattered messages, photos or voice recordings with incomplete details. Operators must interpret each report, identify possible duplicates and decide what needs attention. CityPulse AI turns these submissions into structured incident reports, highlights missing information, suggests priorities and flags potential duplicates. A human operator reviews the findings and creates a work order, aiming to reduce manual triage and make maintenance decisions more consistent.
Preliminary score
- Value for the user17.5 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI18.5 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing14.0 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility7.0 / 15
Data requirements, running costs and a clear next step.
- Originality5.0 / 10
A meaningful difference from common solutions.
What the judges wrote
- GPT-6 AstraPreliminary67/100
- Strengths
- Your project addresses a concrete municipal triage bottleneck while keeping operators in control of duplicate merging and work orders. Your reported 53-test suite covers workflow, persistence and error handling, with useful findings on blank inputs, rate-limit bypasses and misleading priority indicators. You clearly distinguish synthetic duplicate tests and mocked AI responses from unverified live-model performance.
- To improve
- Your next validation should demonstrate the complete workflow with live AI on representative reports, measuring triage time and duplicate precision against manual review. Your input validation, trusted-proxy configuration and dashboard priority mapping need fixes backed by regression tests. Your feasibility plan should estimate per-report AI costs, define media retention requirements and identify a small maintenance-team pilot with explicit success criteria.
- Claude Opus 5.5Preliminary57/100
- Strengths
- Your written submission describes a full multimodal intake pipeline: text, photos, audio via Whisper and sampled video frames are turned into structured incidents with duplicate flags and a human-reviewed work-order step. Your testing section is unusually honest and specific. It reports 53 automated tests and a 12-case synthetic duplicate benchmark that you rightly call too small to prove accuracy. It also names concrete defects: whitespace-only titles were accepted, spoofed forwarding headers bypassed rate limits, and dashboard priority used AI severity instead of calculated priority. Keeping a human in the loop before any duplicate merge is a sensible design choice for nearby but separate incidents.
- To improve
- Your repository README contains only a title, so judges cannot verify the architecture, prompts or code structure. Add a real README with setup steps, screenshots and an outline of the pipeline. Name the adoption metric this track asks for, such as operator triage minutes per report or duplicate-merge precision. Then measure it against manual processing on a realistic batch of reports, ideally with live model calls rather than mocks. Feasibility is thin: estimate the cost per report for Groq vision, audio and LLM calls, describe what real data a municipality would need to provide, and set a concrete next step such as a pilot with one district maintenance team.
The team
Riyad Ezimov
product
Togrul AliyevLead
developer