How shreya1111/university-query-system works
1. Overall shape
UniQuery is a single Python/Streamlit application organized as a feature-based monolith. app.py is the entrypoint, and pages/ contains the main user-facing screens for student, faculty, and admin workflows.
2. Presentation layer
The UI is split into reusable building blocks in components/ and shared look-and-feel in styles/. This layer assembles page headers, sidebar navigation, metric cards, ticket cards, notification cards, and other dashboard widgets used across the Streamlit pages.
3. Page routing and user workflows
pages/ maps directly to the product workflows: login/registration, ticket creation and tracking, AI chatbot, knowledge base search, notifications, dashboards, analytics, and admin/faculty panels. These pages are the main orchestration layer that calls into feature modules rather than embedding business logic directly.
4. Core application services
core/ holds shared infrastructure concerns such as configuration and database access. This is the boundary between UI/feature code and persistent storage, and is likely where environment settings and SQLite connections are centralized.
5. Authentication subsystem
features/auth/ provides login, registration, password handling, OTP/email support, session management, and the repository/service abstraction for user data. This subsystem is responsible for identity and access flow before a user can enter the role-specific pages.
6. Ticket management subsystem
features/ticket_management/ contains the ticket domain model, persistence layer, and service layer. It is the main transactional workflow: students create tickets, faculty update status and assignment, and admins monitor ticket lifecycle and throughput.
7. AI assistance subsystem
features/ai/ is a separate intelligence layer for query handling. It includes intent classification, priority prediction, sentiment analysis, department routing, auto-reply generation, summarization, and a chatbot wrapper. These models are backed by serialized artifacts in models/ and training data in data/training/.
8. RAG / knowledge base subsystem
features/ai/rag/ implements retrieval-augmented generation over university policy documents in data/rag/. Documents are loaded, chunked, embedded, stored in ChromaDB under vectorstore/, and retrieved to answer student questions from the knowledge base pages and chatbot flow. This is the main document-grounded answer path.
9. Analytics and reporting subsystem
features/analytics/ computes operational metrics such as department performance, ticket resolution, satisfaction, sentiment, and notification analytics. features/reports/ and features/analytics/reports/ generate downloadable outputs, with existing report artifacts stored in reports/ as text exports and CSV/PDF support in code.
10. Notifications and communication
features/notifications/ and features/analytics/notifications/ manage notification creation, storage, and delivery logic. This is the feedback loop that informs students and staff about ticket changes, automated responses, and system updates.
11. Persistent data stores
The application uses SQLite as the primary structured store in database/university.db with schema defined in database/schema.sql. Separate from that, the RAG subsystem persists embeddings in ChromaDB under vectorstore/chroma_db, and model artifacts are stored locally in models/.
12. Data preparation and machine learning assets
data/generate_datasets.py and the CSVs in data/training/ support model training for intent, priority, sentiment, and department routing. train_models.py appears to build the serialized classifiers used at runtime, making training an offline pipeline distinct from the Streamlit runtime.
13. Infrastructure and deployment boundaries
.devcontainer/, requirements.txt, and runtime.txt indicate a containerized Python deployment path, likely for consistent local development and hosting. The system is otherwise self-contained, with optional external LLM providers noted in the README (SambaNova, Gemini) as pluggable dependencies rather than core infrastructure.
Main entry points: pages Pages · core Core · service.py AI Service · rag RAG
Components 21
Presentation
Streamlit entrypoint, pages, and shared UI building blocks.
- App · Streamlit application entrypoint.
app.py - Pages · User-facing workflows and role-specific screens.
pages - Components · Reusable page elements and dashboard cards.
components - Styles · Shared CSS and theme definitions.
styles
Domain services
Feature subsystems for authentication, tickets, AI, analytics, and notifications.
- Core · Shared configuration and database access boundary.
core - Auth · Login, registration, sessions, OTP, and password handling.
features/auth - Tickets · Ticket domain model, repository, and service layer.
features/ticket_management - AI Service · Main AI orchestration for intent, routing, sentiment, and summaries.
features/ai/service.py - Chatbot · Chatbot wrapper used by the AI page flow.
features/ai/chatbot/chatbot.py - RAG · Retrieval-augmented generation pipeline over policy documents.
features/ai/rag - Analytics · Operational metrics for tickets, satisfaction, sentiment, and departments.
features/analytics - Reports · Report generation and export layer.
features/reports - Notifications · Notification storage and delivery logic.
features/notifications
Data and models
Persistent stores, training data, and serialized artifacts.
- SQLite DB · Structured application database.
database/university.db - Schema · Database schema definition.
database/schema.sql - RAG Docs · Source PDFs for the knowledge base and RAG pipeline.
data/rag - Training Data · Labeled datasets used to train runtime classifiers.
data/training - Models · Saved intent, priority, and sentiment model artifacts.
models - Vector Store · Persisted embeddings and retrieval index.
vectorstore/chroma_db - Report Files · Generated text report artifacts.
reports - Training · Dataset generation and model training workflow.
train_models.py
Connections 26
- App → Pages: routes to · Main UI navigation is organized through Streamlit pages.
- App → Components: assembles · Entry page uses reusable UI widgets.
- App → Styles: loads · Global styling is applied at startup.
- Pages → Auth: uses · Login, registration, and password flows delegate to auth services.
- Pages → Tickets: orchestrates · Ticket pages create, track, and update tickets.
- Pages → AI Service: invokes · AI and routing features are exposed in the chatbot and knowledge base pages.
- Pages → RAG: answers with · Knowledge base pages query the retrieval pipeline.
- Pages → Analytics: shows · Analytics dashboard pages render operational metrics.
- Pages → Reports: exports · Reports page generates downloadable outputs.
- Pages → Notifications: displays · Notifications page surfaces delivery and status updates.
- Auth → Core: depends on · Authentication relies on shared config and database access.
- Tickets → Core: depends on · Ticket workflow uses shared persistence infrastructure.
- AI Service → Chatbot: wraps · Top-level AI service includes chatbot interaction.
- AI Service → RAG: routes to · Document-grounded answers use retrieval when needed.
- AI Service → Models: loads · Runtime inference uses serialized classifiers.
- RAG → RAG Docs: indexes · Policy PDFs are ingested as source documents.
- RAG → Vector Store: stores embeddings · Chunks and embeddings are persisted for retrieval.
- Analytics → Tickets: analyzes · Operational metrics are derived from ticket data.
- Analytics → Notifications: measures · Notification analytics are computed from delivery data.
- Reports → Analytics: summarizes · Reports package analytics outputs for export.
- Notifications → Core: depends on · Notification persistence uses shared infrastructure.
- Training → Training Data: builds from · Model training consumes labeled CSV datasets.
- Training → Models: produces · Offline training writes serialized model artifacts.
- Core → SQLite DB: connects to · Database access is centralized in core infrastructure.
- Core → Schema: uses · Schema definition describes the structured store.
- Reports → Report Files: writes · Generated reports are stored as files.