diff --git a/README.md b/README.md
index 506767b..ef810e5 100644
--- a/README.md
+++ b/README.md
@@ -20,51 +20,11 @@ This project focuses on:
---
## ποΈ Project Structure
-
-```
-my-react-app/
-β
-βββ public/
-β βββ index.html
-β βββ favicon.ico
-β βββ assets/ # Static assets (images, fonts, icons)
-β
-βββ src/
-β βββ assets/ # App-level assets
-β βββ components/ # Reusable UI components
-β βββ features/ # Domain-driven modules
-β β βββ FeatureName/
-β β β βββ components/ # Feature-specific UI
-β β β βββ hooks/ # Feature-specific hooks
-β β β βββ services/ # API + logic
-β β β βββ FeatureName.tsx
-β β β βββ featureSlice.ts
-β β βββ ...
-β β
-β βββ hooks/ # Global reusable hooks
-β βββ layouts/ # Layouts (Header, Sidebar, Footer)
-β βββ pages/ # Route-based pages
-β βββ routes/ # Routing & guards
-β βββ services/ # API clients (Axios, Fetch)
-β βββ store/ # Global state (Redux/Zustand)
-β βββ styles/ # Global styles/themes
-β βββ utils/ # Helper functions
-β βββ App.tsx # Root component
-β βββ index.tsx # Entry point
-β βββ setupTests.ts # Test setup
-β
-βββ tests/ # E2E / integration tests
-β
-βββ .env # Environment configs
-βββ package.json
-βββ tsconfig.json
-βββ vite.config.ts
-βββ README.md
```
+
---
-
-## π§ Architecture Philosophy
+##π§ Architecture Philosophy
### 1. Feature-Based Design
@@ -107,6 +67,65 @@ Each feature contains:
---
+
+## ποΈ Visual Architecture & Data Flow
+
+To make onboarding seamless for new contributors, Commdesk relies on clear, unidirectional data flows and strict modular boundaries. Here is how our system operates under the hood.
+
+###1. Application Architecture
+
+The application is structured into distinct horizontal layers. Components never bypass layers to talk directly to the backend; all communication flows cleanly through state and service abstractions.
+
+
+
+What this shows:
+
+ - π¨ Presentation Layer (Blue): Handles rendering and user interaction.
+ - β‘ Feature Layer (Orange): Packages domain-specific business logic together.
+ - π§ State Layer (Purple): Acts as the single source of truth for app data.
+ - π Service Layer (Green): Manages external HTTP requests and interceptors.
+
+##2. Feature Module Organization
+
+To prevent spaghetti code, each feature module acts like its own mini-application. It exposes UI, isolates its business logic into React hooks, encapsulates API requests in services, and manages its own state slice.
+
+
+
+Why we organize this way:
+
+ - Components remain clean and "dumb"βthey just display data and pass events.
+ - Hooks handle complex calculations, validations, and state mapping.
+ - If an API endpoint changes, you only ever need to edit one file inside services/.
+
+##3. Request Flow (End-to-End Journey)
+
+Every user interaction follows a strict, predictable 9-step path from the browser to the backend database and back. This ensures application state stays synchronized with the server at all times.
+
+
+
+The Step-by-Step Lifecycle:
+
+ 1.Trigger: A user clicks a button or submits a form.
+ 2.Logic: A custom hook validates the input and prepares the payload.
+ 3.Dispatch: An action is dispatched to the Redux store (triggering a loading state).
+ 4.Network: The service layer sends an HTTP request to the backend.
+ 5.Update: Once the server responds, the Redux store updates immutably.
+ 6.Render: React detects the state change and automatically re-renders the UI.
+
+##4. State Management Flow
+
+When an action is dispatched, Redux determines whether it is a Synchronous update (like toggling a UI menu) or an Asynchronous update (like fetching data from an API).
+
+
+
+Key State Rules:
+
+ - Reducers must be pure: They calculate the new state without triggering side effects.
+ - Thunks handle async: Any code that relies on timers, promises, or network requests lives inside an Async Thunk.
+ - Single Source of Truth: Components never store global data in local state; they always read directly from the Redux Store using selectors.
+
+
+
## βοΈ Tech Stack
- βοΈ React (with TypeScript)