Modules Overview

​

Module Map

---

​

All Modules

---

​

Module Purpose and Data Ownership

Each module in Aarokya has a clearly bounded responsibility. Understanding what each module owns — and what it delegates — is the key to understanding the system.

​

Auth Module

Purpose: Prove who the user is, and issue credentials they can use for everything else. Data it owns:

• users table — the canonical identity row. One row per phone number.
• otp_sessions table — short-lived (10 minute) records of in-flight OTP challenges.
• user_sessions table — long-lived per-device session records, each holding a hashed refresh token.

Key design decision — OTP only, no passwords: Gig workers use multiple devices and frequently share phones with family. Passwords create account recovery debt (forgotten credentials → support calls → account lockouts). Phone OTP is already the login primitive they use for every UPI transaction. It also aligns with Aadhaar-linked KYC when insurance underwriting requires identity verification. Key design decision — per-device sessions: Each successful OTP verification creates a new user_sessions row tagged with device info. Logout revokes only that device’s session. A user on a shared phone can log out without affecting sessions on their other devices.

​

User Profile Module

Purpose: Capture the personal details needed for insurance eligibility, KYC, and personalisation. Data it owns: It shares the users table with Auth. Auth creates the row; User Profile reads and writes the profile fields (name, DOB, gender, address, occupation, employer, Aadhaar last-4). Key design decision — profile_complete flag: Rather than blocking login until the profile is filled, Aarokya lets the user in immediately and uses a computed profile_complete flag (name fields present) to gate the onboarding screen. This avoids friction on first login. Key design decision — Aadhaar last-4 only: Storing a full Aadhaar number would make Aarokya’s database a high-value PII target. The last 4 digits are enough for identity confirmation (“is this the right person?”) without storing the full national ID. The client is responsible for sending only the last 4 digits — the backend never receives the full number.

​

Wallet Module

Purpose: Maintain a ring-fenced health savings account for each user, funded by contributions from the user, employers, or platforms, and spendable only on healthcare. Data it owns: customer_wallets table. One wallet per user. Stores transcorp_wallet_id, balance, provisioning status, and a local JSONB ledger. Key design decision — auto-provisioning on login: Provisioning happens in the background after the first OTP verify. The user never has to click “create wallet.” By the time they navigate to the wallet tab, it is ready (or nearly so). This reduces the number of steps required before the user can transact. Key design decision — async wallet creation: Calling Juspay’s API synchronously during login would make login latency dependent on an external service. If Juspay is slow or unavailable, users couldn’t log in. Async provisioning isolates the login path from external dependency latency.

​

Insurance Module

Purpose: Let users browse Narayana Health plans, get a personalised premium quote, pay, and hold active policies. Forward claims to NH for adjudication. Data it owns: insurance_plans (plan catalogue), insurance_policies (purchased policies), policy_dependants (covered family members). Key design decision — Aarokya does not adjudicate claims: Claims are forwarded to Narayana Health’s API. NH handles underwriting, hospitalisation networks, TPA, and settlement. Aarokya’s role is the distribution channel — making it easy to buy and simple to submit, not to become an insurance company.

​

Call Doctor Module

Purpose: Let users describe symptoms conversationally (via AI), produce a structured clinical summary, and connect them with a real doctor via the Aathma platform. Data it owns: chat_sessions (session state, Aathma reference, lock timestamp), chat_messages (turn-by-turn conversation history). Key design decision — session immutability after LOCK: Once a session is submitted and Aathma assigns a doctor, the session is permanently locked. A patient cannot edit their symptom description after a doctor has already been briefed. This preserves clinical integrity — the doctor acts on the summary they received, and the record cannot be altered retroactively. Key design decision — AI triage before human doctor: Routing every call directly to a doctor would require a large pool of on-call physicians. The Nama Agent pre-collects structured information (chief complaint, duration, severity, medications, allergies), enabling the doctor to be immediately productive rather than spending time on intake.

---

​

Cross-Module Data Flow

---

​

Module Dependencies

---

​

Shared Infrastructure