s-harish2005/sih_backend_voxnova

Purpose and entry points

This repository implements a Django backend organized around accounts, complaint handling, and rewards, plus a separate Python AI service for complaint classification and duplicate detection. Primary server entry points are backend/manage.py, backend/backend/asgi.py, and backend/backend/wsgi.py; the AI process is rooted at ai_services/main.py.

Django application boundary

The Django project configuration and top-level URL composition live in backend/backend/settings.py and backend/backend/urls.py. Feature modules follow Django’s app structure, exposing HTTP behavior through app views and, where present, app URL modules. The backend can run under synchronous WSGI or asynchronous ASGI deployment.

Accounts domain

The accounts app owns user/account persistence and request/response representation:

• backend/accounts/models.py

• backend/accounts/serializers.py

• backend/accounts/views.py

• backend/accounts/urls.py

Schema evolution is captured in backend/accounts/migrations/, including multiple migrations that modify user-related fields. This app is the likely identity/profile boundary consumed by complaint and reward workflows.

Complaint lifecycle and AI integration

The complaints app is the central workflow domain, with persistence, API serialization, and HTTP handlers in:

• backend/complaints/models.py

• backend/complaints/serializers.py

• backend/complaints/views.py

backend/complaints/ai_clients.py forms the integration boundary between Django complaint operations and the separate AI service. Complaint creation or processing can therefore remain in Django while model-oriented classification and duplicate analysis are delegated over a client boundary rather than embedded in request handlers.

AI service

The standalone AI service separates inference/analysis concerns from the Django runtime:

• ai_services/main.py

• ai_services/classifier.py

• ai_services/duplicate.py

classifier.py represents complaint categorization logic, while duplicate.py represents similarity or duplicate-complaint analysis. Its independently declared dependencies in ai_services/requirements.txt indicate it is deployable and scalable separately from the backend, with backend/complaints/ai_clients.py as its expected consumer.

Rewards domain

Rewards is an independent Django app responsible for reward-related state and operations:

• backend/rewards/models.py

• backend/rewards/views.py

• backend/rewards/migrations/0001_initial.py

Its separation from complaints suggests rewards are a downstream or adjacent business capability rather than part of the AI service. Any coupling to account or complaint events should cross Django app model/view boundaries rather than the AI-service boundary.

Persistence and operational flow

The checked-in development database is backend/db.sqlite3; Django models and migrations define the durable schema for accounts, complaints, and rewards. The primary control flow is: client request → project URL routing → app view → serializer/model persistence; complaint-specific paths may additionally call ai_clients.py → AI service → classifier/duplicate result → complaint workflow response or stored update. Production infrastructure is not specified beyond Django’s ASGI/WSGI interfaces, SQLite development storage, and the separately runnable AI Python service.