# Problem Pattern Detector: Turning Student Complaints into Campus Intelligence > Source: > Published: 2026-10-08 10:35:09+00:00 Colleges receive a continuous stream of student feedback covering transportation, food services, hostel facilities, connectivity, infrastructure, academics, and other campus operations. The challenge is not simply collecting these reports. The challenge is identifying the **common patterns hidden across them**. A recurring operational issue may appear in many different forms. One student may report a delayed bus, another may report excessive waiting time, while another may describe missing a class because of the same delay. When these reports are reviewed independently, the broader issue can remain fragmented. We built **Problem Pattern Detector** to address this gap. Problem Pattern Detector is an **AI-powered campus intelligence system** that transforms naturally written student complaints into structured information and analyzes those reports collectively to identify recurring and emerging problems. The student experience is intentionally simple. A student only needs to describe the issue in natural language. The system determines the relevant department and extracts the important attributes automatically. For example, a report describing repeated delays on Route 3 during the morning period can be interpreted as: ``` { "department": "Transport", "issue": "Bus Delay", "location": "Route 3", "time": "Morning", "severity": "High", "short_summary": "Repeated morning delays on Route 3 are affecting student arrival times", "key_themes": [ "bus delay", "long waiting time", "late arrival" ] } ``` The system then uses this structured information together with other reports to identify broader patterns. The overall architecture is: ``` Student Complaint ↓ Next.js Frontend ↓ Python FastAPI Backend ↓ Ollama ↓ Gemma 4B ↓ Structured Complaint Data ↓ SQLite Database ↓ Pattern Detection Engine ↓ Admin Intelligence Dashboard ``` Students describe a campus problem in their own words. There is no requirement to understand the system's internal categorization or manually select a department. This reduces friction at the point of reporting while preserving the context contained in the original complaint. The complaint is sent from the Next.js frontend to our Python backend. The backend communicates with **Gemma 4B through Ollama**. Gemma is responsible for interpreting the natural-language report and extracting structured attributes such as: This converts unstructured feedback into data that can be analyzed consistently. The extracted information is stored in **SQLite**. Each report retains both its structured representation and the original student submission, allowing the system to connect detected patterns back to the supporting reports. This is the core of the system. The Pattern Detection Engine uses the structured reports to identify: For example, suppose multiple reports independently reference Route 3, morning service, extended waiting periods, and delayed arrival to class. Instead of presenting those as unrelated complaints, the system can surface a consolidated pattern such as: ``` Department: Transport Detected Pattern: Route 3 Morning Bus Delays Related Reports: Multiple reports describing delays, extended waiting times, and late arrival during the morning period. Priority: High ``` The important point is that the system is detecting a **pattern across reports**, rather than attempting to determine or prove a real-world root cause. The detected information is presented through an administrator dashboard. The dashboard provides visibility into: This gives administrators a higher-level view of campus problems without requiring them to manually inspect every report individually. **Problem Pattern Detector is not a chatbot and not simply a digital complaint form.** A conventional complaint workflow is primarily: ``` Student → Complaint → Administrator ``` Our workflow is: ``` Student ↓ Natural-Language Complaint ↓ AI Understanding ↓ Structured Data ↓ Pattern Detection ↓ Campus Intelligence ``` The key distinction is the **collective analysis of reports**. The AI layer is responsible for understanding language and converting unstructured complaints into a consistent representation. The application layer is responsible for deterministic operations such as: This separation keeps the architecture understandable and ensures that statistical insights are generated by application logic rather than being left entirely to the language model. | Component | Technology | |---|---| | Frontend | Next.js / React | | Backend | Python / FastAPI | | AI Model | Gemma 4B | | AI Runtime | Ollama | | Database | SQLite | | Pattern Detection | Python | | Communication | HTTP API | We use **Gemma 4B through Ollama** for local AI processing. This allows the prototype to perform complaint understanding without depending on a cloud AI API. It also keeps the architecture straightforward: ``` Next.js ↓ FastAPI ↓ Ollama + Gemma 4B ↓ SQLite ↓ Pattern Detection ``` The browser does not communicate directly with Ollama. All AI interaction is handled through the backend API. Consider the transport department. Several student reports may independently mention: These reports do not need to use identical wording to be related. The system structures the individual reports, compares their attributes, and identifies the recurring pattern. The administrator can then view the detected issue together with the supporting reports that contributed to it. This changes the administrative perspective from: **"We received several unrelated complaints."** to: **"Multiple reports indicate a recurring transport issue affecting Route 3 during the morning period."** The system is therefore intended to improve **visibility and prioritization**, not to automatically establish causality. As **Team VANTAGE**, we developed an end-to-end prototype covering: Our primary demonstration scenario focuses on **Route 3 morning bus delays** because it clearly illustrates the project's central idea: **multiple individual reports can reveal a larger campus-level pattern.** The same approach can be applied across categories such as: | Member | Contribution | |---|---| | **Prithivram** | GitHub Repository & Project Integration | | **Darshan B** | Frontend Development | | **Badma Sree Vignesh** | Backend Development | | **Dinesh Raj R** | Pattern Detection & AI Development | **GitHub Repository:** [[https://github.com/bprithivram-a11y/hacktoberfest-hack-day-coimbatore-x-init-club-and-idea-club](https://github.com/bprithivram-a11y/hacktoberfest-hack-day-coimbatore-x-init-club-and-idea-club)] **Demo Video:** [[https://youtu.be/k9qRPIVz8io](https://youtu.be/k9qRPIVz8io) ] Most complaint systems are designed to answer a simple question: **"What did one student report?"** Problem Pattern Detector is designed to answer a broader question: **"What patterns are emerging across the campus?"** By combining natural-language understanding with structured storage and application-level pattern detection, the system converts fragmented student feedback into a more useful view of campus operations. The goal is not to replace administrative decision-making. The goal is to provide better visibility into the problems that may otherwise remain hidden across individual reports. **Individual reports → Structured information → Detected patterns → Campus intelligence**