raghavs16/insurance_claim_intake

Purpose and Entry Points

This repository implements an AI-assisted claims-processing application: a browser form submits a claim, a Python backend runs it through an agent graph, persists claim data, and can use object storage for supporting files. The user-facing entry point is the Next.js page at frontend/src/app/page.tsx; backend HTTP startup is backend/src/api/main.py.

Frontend Client

The frontend is a Next.js/React application with the primary claim-submission UI in frontend/src/components/ClaimForm.tsx. frontend/src/services/claims.ts forms the client/server boundary, encapsulating requests from the UI to the backend. frontend/src/app/layout.tsx provides the application shell, while frontend/src/app/page.tsx composes the primary workflow.

API and Application Boundary

backend/src/api/main.py is the backend API layer and should own HTTP request validation, response shaping, and orchestration handoff. It separates browser-facing transport concerns from the claim-processing workflow implemented under backend/src/agents/. The backend is packaged as a container through backend/Dockerfile.

Agentic Claims Pipeline

The core processing architecture is an explicit graph-based agent workflow:

• backend/src/agents/graph.py defines graph topology and stage sequencing.

• backend/src/agents/state.py defines the shared workflow state passed between stages.

• backend/src/agents/nodes.py contains the processing nodes that inspect, enrich, assess, or route a claim.

Control flows from an API-submitted claim into graph initialization, across stateful nodes, and back to the API as a result. The graph/state split is the main boundary for extending decision stages without coupling them to HTTP or persistence code.

Persistence Layer

Database access is isolated under backend/src/database/. backend/src/database/models.py defines persistent domain entities, and backend/src/database/session.py owns database session/connection lifecycle. Schema bootstrapping, migration, seed, and verification assets are centralized in database/schema.sql, database/migrate.sql, and database/init.sql, making the relational database an infrastructure dependency rather than an agent-owned concern.

Document/Object Storage Boundary

backend/src/utils/s3.py provides the integration boundary for S3-compatible object storage, likely for claim attachments or evidence. Agent and API code should use this abstraction rather than directly embedding storage-client operations. backend/test_s3.py indicates this is a material external-service integration.

Deployment and Runtime Topology

The application has two containerized runtimes: Next.js frontend (frontend/Dockerfile) and Python backend (backend/Dockerfile). docker-compose.yml is the local multi-service composition point and likely coordinates these runtimes with the database and required environment configuration. Python dependencies are declared in backend/requirements.txt; frontend runtime dependencies are in frontend/package.json.