Ksp-Crime-AI

dashboard
auth page
trends using graph with custom filters.
ai chat auto detects the type of response and gives in normal form tables graphs and explains and make sql query to data base.
network clusters and ai summary of connections made by matching areas of cases and village area beat etc.
create account page
create account district and police station fetch from backend dynamicly
network of cases graph
hotspot and risk score logic made by calculating severe crime type date and how sevierie the crime is.
hotspot map

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for Ksp-Crime-AI

Inspiration

Crime data exists for almost every city, but it usually sits locked away in raw spreadsheets, PDF reports, or fragmented government portals — hard for citizens, journalists, or even local police departments to actually use. We wanted to build something that could take any city's raw crime records and instantly turn them into insights: hotspots, trends, predictions, and patterns that would otherwise take analysts days to uncover manually. The idea for Ksp-Crime-AI came from a simple question: what if analyzing a city's crime data was as easy as uploading a CSV?

What it does

Ksp-Crime-AI is an AI-powered crime analysis platform that ingests crime incident data and automatically generates:

Hotspot detection — geographic clustering to identify high-crime zones on an interactive map
Trend analysis — time-series breakdown of crime by type, day, hour, and season
Predictive insights — a model that forecasts likely crime categories/locations based on historical patterns
Natural-language summaries — plain-English reports explaining what the data shows, so non-technical users (citizens, journalists, local officials) can understand it instantly
Conversational chat interface — ask questions in plain language and get answers with memory of prior context in the conversation, powered by Groq-hosted GPT-OSS 20B
Smart auto-visualization — the chat automatically detects whether a query needs a simple text answer, a table, a chart/graph, or a map with clusters, and renders the right view without the user selecting it manually
Role-based access control (RBAC) — each user only sees crime data they're authorized for, enabling safe multi-city/multi-department deployment from a single platform

The key design goal was generalizability: the platform isn't hard-coded to one city's dataset. It works with any city, any crime dataset, as long as the data is mapped to a small set of standard fields — with only minor schema configuration required to onboard a new dataset.

The chat assistant also has role-based data access control (RBAC) — every user only sees the crime data they're scoped/authorized to see, so the same deployment can safely serve multiple departments, cities, or user roles at once without data leaking across boundaries.

How we built it

Data ingestion layer: A configurable schema-mapping module that lets any raw crime dataset (different column names, formats, date conventions) be normalized into a standard internal schema (incident type, location, timestamp, coordinates) — this is what lets us plug in a new city's data with only a few config changes instead of rewriting code.
Backend/processing: Python (pandas, scikit-learn) for cleaning, clustering (e.g. DBSCAN/KMeans for map-based hotspot detection).
Conversational AI layer:
- Model: Groq-hosted GPT-OSS 20B for fast, low-latency inference on chat queries.
- Context memory: Redis is used to store per-session conversation context, so the assistant remembers earlier questions in a chat and can answer follow-ups without the user repeating themselves.
- Auto response-type detection: incoming queries are automatically classified into the right output format — a plain text answer, a data table, a chart/graph, or a map with clusters — so the same chat interface can intelligently decide how to visualize an answer instead of the user having to pick a view manually.
- RBAC-aware querying: every query is scoped at the data layer based on the logged-in user's role/permissions, so the AI only ever queries and summarizes data the user is allowed to access.
Frontend: An interactive dashboard combining maps (with cluster visualization), charts, and dynamic tables, all driven by the chat interface's auto-detected response type.
Deployment: Hosted so judges/users can test it live with sample datasets from multiple cities.

Challenges we ran into

Schema inconsistency — every city/police department formats crime data differently (different column names, date formats, category labels). Designing a flexible-but-simple mapping config that could handle this without becoming overly complex took several iterations.
Data quality — real-world crime data often has missing coordinates, duplicate entries, or inconsistent categorization, which required robust cleaning logic.
Balancing accuracy vs. generalization — a model tuned too specifically to one city's crime patterns didn't generalize well to another; we had to design the pipeline to retrain/recalibrate per-dataset rather than relying on a single fixed model.
Making AI output trustworthy — ensuring the natural-language summaries stayed factually grounded in the actual data rather than generating misleading or overconfident claims.
Enforcing RBAC at the AI layer — it wasn't enough to restrict access in the UI; we had to make sure the LLM's underlying data queries themselves were scoped per-user, so a permission boundary couldn't be bypassed just by asking the chatbot differently.
Reliable auto-detection of response type — getting the system to consistently pick the right output format (text vs. table vs. graph vs. map) for a given query, instead of defaulting to one format, took careful prompt/classification design.
Low-latency conversational memory — using Redis to persist per-session context so follow-up questions felt natural, while keeping response times fast with Groq-hosted inference.

Accomplishments that we're proud of

Built a genuinely dataset-agnostic pipeline — we tested it by swapping in crime data from more than one city and only needed to update the schema-mapping config, not the core logic.
Combined classical data science (clustering, trend analysis) with an AI/LLM layer to make the output accessible to non-technical users, not just analysts.
Delivered a working end-to-end product (data in → insights out) within the hackathon timeframe.

What we learned

How much of "AI for public data" work is actually about data engineering and schema design, not just modeling.
Techniques for building flexible ETL/config systems that can adapt to messy, inconsistent real-world government data.
How to combine statistical/ML outputs with generative AI to make technical insights understandable to a general audience.
The importance of grounding AI-generated text in real computed statistics to avoid hallucinated conclusions in a sensitive domain like crime data.

What's next for Ksp-Crime-AI

Broader city onboarding — build a self-serve UI so any city/organization can upload their own dataset and configure the schema mapping without needing developer help.
Real-time data feeds — integrate with live open-data APIs from police departments for continuously updated insights instead of static uploads.
Deeper predictive modeling — improve forecasting accuracy with more advanced spatio-temporal models.
Public-facing safety tool — a citizen-facing version that shows safety scores for neighborhoods to help with everyday decisions (e.g. where to live, safe routes).
Partnerships — explore collaboration with local police departments or civic-tech organizations to pilot the tool with real official data.