WarrantyHub: Digital Warranty & Service Management Platform

### **Enhancement Justification** User requested a fundamental shift in the cloud provider from AWS to Microsoft Azure. The requirement has been updated to replace AWS-specific services (S3, EKS, Cognito, and the cloud provider itself) with their direct Azure counterparts (Azure Blob Storage, AKS, Azure AD B2C) as per the modification request. ### **Formalized Requirement** **Frontend Technologies:** - **Mobile Frontend:** Shall be built with React Native 0.7x. - **Web Frontend:** Shall be built with Next.js 14 (React). **Backend Technologies:** - **Runtime & Framework:** Shall be built with Node.js (v20.x) and the NestJS Framework (v10.x). - **API Specification:** The API shall be a hybrid of REST and WebSocket. **Data & Storage:** - **Primary Database:** Shall be PostgreSQL 16 with the PostGIS extension. - **Caching Layer:** Shall use Redis 7.x. - **Search Functionality:** Shall be powered by OpenSearch. - **File Storage:** Shall use **Azure Blob Storage**. **Cloud & DevOps Infrastructure:** - **Cloud Provider:** The cloud provider shall be **Microsoft Azure**. - **Container Orchestration:** Shall be managed by **Azure Kubernetes Service (AKS)**. - **CI/CD Pipeline:** Shall use GitHub Actions. - **Infrastructure as Code:** Shall be implemented with Terraform. - **Identity Provider:** The identity provider shall be **Azure Active Directory B2C**.

### **Enhancement Justification** This requirement was updated to maintain consistency with the strategic platform change specified in REQ-TEC-001. The deployment target has been changed from AWS to Microsoft Azure to resolve a direct contradiction. ### **Formalized Requirement** - The platform shall be built using the technology stack specified in Section 6.2 (REQ-TEC-001). - The platform shall follow a microservices architecture. - The platform shall be deployed on **Microsoft Azure**. - All infrastructure shall be managed via Terraform (Infrastructure as Code). - The system shall comply with standard data protection practices, including encryption for all Personally Identifiable Information (PII) at rest and in transit.

### **Enhancement Justification** This requirement was updated to align with the technology stack modification in REQ-TEC-001. The backend infrastructure deployment target has been changed from AWS to Microsoft Azure to resolve a direct contradiction. ### **Formalized Requirement** - The entire backend infrastructure shall be deployed on **Microsoft Azure**. - The system shall maintain separate, isolated environments for Development, Staging, and Production. - The client mobile application shall require iOS 14 or newer. - The client mobile application shall require Android 8.0 or newer. - The client web portals shall require a modern web browser (Chrome, Firefox, Safari, Edge).

### **Enhancement Justification** This requirement has been updated to replace AWS-native services with their Azure equivalents to align with the platform change in REQ-TEC-001. This ensures the reliability and disaster recovery strategy is consistent with the chosen Azure technology stack. ### **Formalized Requirement** - The primary database (**Azure Database for PostgreSQL**) shall be configured for automated daily snapshots. - Automated database snapshots shall have a retention period of 30 days. - Point-in-time recovery shall be enabled for the primary database. - Database snapshots and file storage (**Azure Blob Storage**) shall be replicated to a secondary Azure region for disaster recovery. - The system shall be deployed across multiple **Availability Zones** within an Azure region. - In case of a failure in one Availability Zone, traffic shall be automatically routed to healthy instances in other zones.

### **Enhancement Justification** This requirement is updated to replace AWS-specific security services with their Azure counterparts as mandated by the platform shift in REQ-TEC-001. This ensures the security architecture is natively integrated with the Microsoft Azure ecosystem. ### **Formalized Requirement** - All user access shall be authenticated via **Azure Active Directory B2C**. - Authentication shall enforce OTP-based login. - API access shall be controlled using short-lived JWT access tokens. - A strict Role-Based Access Control (RBAC) model shall be enforced at the API Gateway and re-verified at the microservice level. - Database Row-Level Security (RLS) shall be used as a secondary defense layer. - All data shall be encrypted in transit using TLS 1.2 or higher. - All data stored in databases (Azure Database for PostgreSQL), file storage (Azure Blob Storage), and caches (Azure Cache for Redis) shall be encrypted at rest using platform-managed keys via **Azure Key Vault**. - All application secrets, including database credentials and API keys, shall be stored and managed securely using **Azure Key Vault**. - The system shall undergo regular vulnerability scanning and penetration testing.

### **Enhancement Justification** To align with the Azure platform migration, AWS-specific integration services have been replaced with their designated Azure equivalents. This ensures a cohesive and native cloud architecture and fills a gap identified during the impact analysis. ### **Formalized Requirement** - The system shall integrate with Firebase Cloud Messaging (FCM) for sending push notifications. - The system shall integrate with **Azure Communication Services** for sending transactional emails. - The system shall integrate with an SMS provider (e.g., Twilio) for sending OTP messages. - The system shall integrate with a Mapping Provider (e.g., Google Maps, Mapbox) for displaying technician location and calculating ETAs. - Communication between microservices shall occur via REST APIs and a message queue (**Azure Service Bus**). - The Location Service shall use WebSockets for real-time communication with clients.

### **Enhancement Justification** The logging target has been updated from an AWS-specific service to Azure Monitor Logs to align with the strategic move to the Azure cloud platform. This change leverages Azure's native observability features for a more integrated monitoring solution. ### **Formalized Requirement** - The system shall use Prometheus to scrape performance metrics from all services and infrastructure. - Key metrics including API latency, error rates, CPU/memory utilization, and queue lengths shall be collected. - All services shall output structured JSON logs. - All logs shall be aggregated into a centralized **Azure Monitor Logs** workspace. - The system shall integrate OpenTelemetry into all services to enable distributed tracing. - The system shall use Grafana to create dashboards for visualizing metrics and logs. - The system shall use Alertmanager to send critical alerts to the on-call engineering team via Slack and PagerDuty.

The system shall be a cloud-native, multi-tenant system. The system shall be designed as a centralized hub connecting consumers, brands, and service centers. The system shall be built on a microservices architecture. The system shall expose a set of REST and WebSocket APIs for consumption by client applications.

The system's operation shall depend on the availability and performance of third-party services including FCM, SES, and Mapping APIs, which must meet their respective SLAs. The system's functionality shall depend on the device's GPS for technician tracking. The system's functionality shall depend on the device's camera for QR code scanning and photo uploads.

The system shall allow a User to register a product by providing Brand, Model, Serial Number, and Purchase Date. The system shall allow a User to select a Brand from a list or add a new one pending admin approval. The system shall allow a User to input a Warranty Duration. (Enhanced - Change) The system shall auto-populate the Warranty Duration field for known brand/model combinations, but this field shall remain editable by the user. Justification: Resolves the contradiction between auto-calculation and manual input, providing a flexible and user-friendly approach. The system shall allow a User to upload an invoice photo or PDF during product registration. The system shall create a digital warranty card upon successful product registration. The system shall securely store an uploaded invoice and link it to the registered product. The system shall auto-calculate the warranty expiry date based on the provided purchase date and warranty duration. The system shall allow Users to categorize products into predefined categories (e.g., Mobile, Electronics, Home Appliances, Furniture, Vehicles). (Enhanced - Addition) The system shall allow a User to add multiple warranties to a single product, each with its own duration and document. Justification: Addresses a critical real-world use case for complex products, making the platform more robust. (Enhanced - Addition) The system shall allow a User to edit the details of a registered product. Justification: Provides essential data management capabilities that users expect, ensuring data accuracy and lifecycle management. (Enhanced - Addition) The system shall allow a User to delete a registered product. Justification: Provides essential data management capabilities that users expect, ensuring data accuracy and lifecycle management. (Enhanced - Addition) The system shall provide a 'Transfer Ownership' feature allowing a user to initiate a transfer of a product record to another registered user via email/phone number. Justification: Provides essential data management capabilities that users expect, ensuring data accuracy and lifecycle management. The system shall send a notification to the recipient of a product transfer, who must accept or reject the transfer. The API for product registration shall have a 95th percentile (P95) response time of less than 500ms.

The system shall generate a unique digital warranty card for each registered product warranty. (Enhanced - Change) The system shall allow a user to toggle between multiple warranty cards if a product has more than one. Justification: Directly supports the requirement for complex warranties. Each digital warranty card shall display the Warranty Expiry Date. Each digital warranty card shall provide a link to view the uploaded Terms and Service Conditions document. Each digital warranty card shall display a color-coded badge indicating the warranty status. (Enhanced - Change) The warranty status badge shall be Green if the warranty is valid. Justification: Provides more proactive and useful information to the user than a simple binary status. (Enhanced - Change) The warranty status badge shall be Amber if the warranty will expire within 30 days. Justification: Provides more proactive and useful information to the user than a simple binary status. (Enhanced - Change) The warranty status badge shall be Red if the warranty is expired. Justification: Provides more proactive and useful information to the user than a simple binary status. Each digital warranty card shall provide a clear link to its associated invoice.

The system shall allow a User to raise a service request from a product's digital warranty card. The service request form shall pre-populate product details (Brand, Model, Serial). The service request form shall require the User to select a type of issue from a dropdown or enter free text. The service request form shall require the User to provide a detailed description of the problem. The service request form shall allow the User to upload photos or videos of the issue. The service request form shall capture the User's address and contact information. The service request form shall allow the User to select preferred visit date and time slots. Upon submission, the system shall create a service request ticket with the status 'Requested'. The system shall notify the appropriate service center when a new ticket is created. The system shall allow a User to track the status of a service request in real-time through the following stages: Requested, Acknowledged, Technician Assigned, Technician On The Way, Work In Progress, Resolved/Closed. (Enhanced - Addition) The system shall allow a User to cancel a service request before a technician has been assigned. Justification: Provides necessary user control over their requests. (Enhanced - Addition) Upon resolution, the system shall allow the User to view a service summary, including notes from the technician and parts used. Justification: Enhances transparency. (Enhanced - Addition) The system shall allow a User to initiate a 'Dispute' if they are unsatisfied with a resolution. Justification: Creates a crucial feedback and escalation loop that builds user trust. A disputed ticket's status shall be changed to 'Disputed', and the Brand Administrator shall be notified.

The system shall provide a web panel for Service Center Admins. The Service Center Panel shall display all incoming service requests for their associated brands. (Enhanced - Addition) The Service Center Panel shall allow admins to filter and search requests by status, date, brand, or technician. Justification: A fundamental requirement for managing a list of service tickets efficiently. The Service Center Panel shall allow admins to assign and re-assign requests to specific technicians. The Service Center Panel shall allow admins to view technician availability and current workload. The Service Center Panel shall allow admins to update service notes and add details of parts used. The Service Center Panel shall allow admins to close service tickets after completion. (Enhanced - Addition) The Service Center Panel shall allow admins to manage their roster of technicians (add, edit, deactivate profiles). Justification: Makes the technician management feature well-defined. The system shall provide a mobile application or view for Technicians. The Technician view shall display a list of jobs assigned to that technician. The Technician view shall provide access to customer and product details for each assigned job. The Technician view shall allow a technician to update their job status (e.g., 'On The Way', 'Work In Progress'). (Enhanced - Addition) The Technician app shall, with permission, share the technician's location data when their status is 'On The Way'. Justification: Makes the technician tracking feature feasible and well-defined. The Technician view shall allow a technician to enter service completion notes, including parts used. The Technician view shall allow a technician to mark a job as 'Resolved' to close the ticket.

The system shall automatically check a product's warranty validity against its expiry date when a service request is raised. The system shall flag the service request ticket as 'In Warranty' or 'Out of Warranty'. The system shall allow a Service Center Admin or Brand Admin to view the warranty status of a claim. The system shall allow an Admin to approve or reject a claim for free service or parts. (Enhanced - Addition) The system shall require an Admin to provide a reason for rejecting a claim. Justification: Provides essential transparency to the customer. Reasons for rejection shall be visible to the user. The system shall maintain a complete history of all claims, resolutions, and spare parts used for each product. (Enhanced - Addition) The system shall maintain an audit trail that logs which admin approved or rejected a claim and the timestamp of the action. Justification: Critical for accountability and resolving potential disputes.

The system shall provide a secure, centralized digital storage vault for all invoices uploaded by a user. The system shall allow a user to view, download, or share their stored invoices. The system shall allow a user to search for invoices by product name, brand, or category. (Enhanced - Addition) The system shall allow a user to filter invoices by a purchase date range. Justification: Makes the search functionality more powerful and useful.

The system shall provide a secure web portal for registered brands. The Brand Dashboard shall display analytics related to the brand's products. The Brand Dashboard shall include widgets for: Total registered products, Active vs. Expired warranties, and Volume of ongoing service requests. (Enhanced - Addition) The Brand Dashboard shall include a widget for the Average resolution time for service requests. Justification: Provides deeper, more actionable insights for brands. (Enhanced - Addition) The Brand Dashboard shall provide an analysis of frequent fault patterns based on 'Type of issue' data. Justification: Provides deeper, more actionable insights for brands. (Enhanced - Addition) The Brand Dashboard shall display the geographic distribution of registered products and service requests. Justification: Provides deeper, more actionable insights for brands. The system shall allow a Brand Admin to export all reports in CSV and PDF formats.

The system shall provide a mobile application for end-users. The mobile app shall allow a user to add a product by scanning a barcode or QR code with the device's camera. The system shall attempt to pre-fill Brand and Model fields based on a scanned code. The system shall require the user to manually enter or verify the serial number after scanning. The mobile app shall allow a user to view all their registered products and digital warranty cards. The mobile app shall allow a user to raise a new service request. The mobile app shall allow a user to track the status of ongoing service requests. (Enhanced - Change) The mobile app shall display the technician's live location on a map and provide an updated ETA when the technician's status is 'On The Way'. Justification: Makes the requirement more specific, testable, and aligned with modern user expectations.

(Enhanced - Addition) The system shall provide a Super Admin portal for managing platform-wide operations. Justification: This new module is a critical addition that defines the foundational business processes required to operate the platform's B2B ecosystem. The Super Admin portal shall provide a workflow to review and approve new brand registration requests. The Super Admin portal shall allow an admin to associate brands with specific product categories. The Super Admin portal shall provide a workflow to review and approve new service center registration requests. The Super Admin portal shall provide an interface to link approved Service Centers to one or more Brands, defining their service relationship. The Super Admin portal shall provide user management for platform administrators.

All user interfaces shall have a clean, intuitive, and responsive design. The mobile app shall follow platform-specific (iOS/Android) human interface guidelines. All web panels shall be fully responsive and functional on screen sizes from desktop monitors down to tablets. All user interfaces shall comply with Web Content Accessibility Guidelines (WCAG) 2.1 Level AA. A consistent branding theme (logo, color palette, typography) shall be applied across all web and mobile interfaces.

The user mobile app shall require access to the device camera for scanning barcodes/QR codes. The user mobile app shall require access to the device camera for uploading photos/videos of product issues. The technician mobile app shall require access to the device's GPS for real-time location sharing. The user mobile app shall require location services to display the technician's position on a map.

All communication between clients and the backend shall be over HTTPS using TLS 1.2 or higher. Real-time location updates shall use Secure WebSockets (WSS). The standard data format for all API requests and responses shall be JSON.

The 95th percentile (P95) latency for all standard API endpoints shall be below 250ms. Core web panel pages shall achieve a Largest Contentful Paint (LCP) of less than 2.5 seconds. Location updates from the technician's device to the user's map display shall have a latency of less than 2 seconds.

The platform shall have a target uptime of 99.9%, excluding planned maintenance. Planned maintenance windows shall be scheduled during off-peak hours. Users shall be communicated to in advance of planned maintenance. In the event of a non-critical service failure, the core functionality of the platform (e.g., raising service requests) shall remain operational (graceful degradation).

The system shall be able to scale horizontally to handle load. Microservices shall be configured with Horizontal Pod Autoscalers (HPA) to automatically adjust the number of running instances based on CPU and memory usage. The system shall be designed to support an initial load of 10,000 concurrent users. The database architecture shall use read replicas to offload read-heavy queries.

All code shall adhere to defined linting rules and style guides. All backend services shall have a minimum of 80% unit test coverage. All API endpoints shall be documented using the OpenAPI specification. The microservices architecture shall ensure high modularity and low coupling between components.

The system shall send automated warranty expiry reminders to users at 30 days and 7 days before expiry. (Enhanced - Addition) The system shall allow users to set and receive recurring service schedule reminders for products with maintenance needs (e.g., AC servicing). Justification: Expands the feature to cover a key user need from the original requirements. The system shall send a push notification to the user when a service request is successfully created. The system shall send a push notification to the user when a technician has been assigned to their service request. The system shall send a push notification to the user when a technician's status is 'On The Way', including an ETA. The system shall send a push notification to the user when a service request status is updated to 'Resolved' or 'Closed'. (Enhanced - Addition) The system shall send a push notification to the user when their warranty claim has been Approved or Rejected. Justification: Improves user experience and reduces the need for manual status checks. (Enhanced - Addition) The system shall send a push notification to the user when a new message is received in the service ticket chat. Justification: Improves user experience and reduces the need for manual status checks. (Enhanced - Addition) The system shall provide a settings area where users can manage their notification preferences. Justification: Improves user experience and reduces the need for manual status checks.

The system shall provide Brand Admins with reports on Product Registration Trends (by model, region). The system shall provide Brand Admins with reports on Warranty Status Distribution (Active vs. Expired). The system shall provide Brand Admins with reports on Service Request Volume & Trends. The system shall provide Brand Admins with reports on Average Service Resolution Time. The system shall provide Brand Admins with reports on Frequent Fault Pattern Analysis. All Brand Admin reports shall be exportable to CSV and PDF. The system shall provide Service Centers with reports on Ticket Volume (by brand, status). The system shall provide Service Centers with reports on Technician Performance (tickets closed, resolution time). The system shall provide Super Admins with reports on Platform Usage Statistics (active users, products registered). The system shall provide Super Admins with reports on the Brand and Service Center Onboarding Funnel.

The system shall provide a unified web and mobile platform for consumers to manage product warranties, invoices, and service requests. The system shall provide a backend portal for Brands to view product analytics and manage service escalations. The system shall provide a portal for Service Centers to manage incoming service requests and assign technicians. The system shall provide a mobile application or view for Technicians to manage their assigned jobs. The system shall include features for user registration, product management, digital warranty cards, and service request lifecycle management. The system shall include features for warranty claim verification, automated reminders, and a secure invoice vault. The system shall provide role-based dashboards for different user types. The system shall provide real-time tracking of a technician's location for service visits. The system shall implement secure, role-based access control for all user types.

The system shall not provide direct e-commerce functionality for selling products or extended warranties. The system shall not process payments for out-of-warranty services. The system shall not provide inventory management for spare parts for service centers. The system shall not provide direct integration with brand or service center ERP systems beyond the defined APIs. The system shall not provide Human Resource management features for service centers or brands.

The system shall enforce a strict Role-Based Access Control (RBAC) model. A 'User' role shall only be permitted to access and manage their own data. A 'Technician' role shall only be permitted to view and update details of jobs specifically assigned to them. A 'Service Center Admin' role shall be permitted to view all tickets for their center, manage their technicians, and assign jobs. A 'Brand Admin' role shall be permitted to view all data and analytics related to their brand, manage service claims, and oversee associated service centers. (Enhanced - Addition) A 'Super Admin' role shall be permitted to manage the onboarding of brands and service centers and oversee the entire platform. Justification: Necessary to manage the platform itself and the B2B onboarding process. The system shall use secure, One-Time Password (OTP) based login for all users. All Personally Identifiable Information (PII) and sensitive documents shall be protected using standard data encryption at rest and in transit.

### **Project Overview: WarrantyHub Platform** The system is a comprehensive web and mobile platform designed to centralize product warranty and service management for Indian consumers and brands. It bridges the communication gap between users, service centers, and manufacturers. ### **Core User Features** - **Product & Warranty Management**: Users can register their purchased products by entering details like brand, model, serial number, and purchase date. They will manually input the warranty duration (e.g., 12 months) to automatically calculate the expiry date. - **Digital Vault**: Each registered product will have a digital warranty card with a color-coded status (Valid/Expired). The platform also serves as a secure digital vault for storing and searching all product invoices. - **Service Requests**: Users can raise service requests directly from the app, describing the issue, attaching photos/videos, and suggesting a preferred time for the technician's visit. - **Status Tracking & Alerts**: Users receive push notifications and can track the status of their service requests (e.g., Requested, Assigned). They will receive updates on the technician's status, including an "On The Way" notification and an Estimated Time of Arrival (ETA). - **Custom Reminders**: The system will send automated reminders for upcoming warranty expirations. Users can also create their own custom, recurring reminders for periodic maintenance like AC servicing or RO filter changes. - **Simplified Product Entry**: The mobile app will feature a barcode/QR code scanner to help pre-fill product information like brand and model where available, though users will need to manually enter the unique serial number. ### **Service Center & Technician Features** - **Service Ticket Management**: A dedicated panel allows service centers to view all incoming service requests for their assigned brands. - **Dispatch & Workflow**: Service centers can assign requests to specific technicians, who can then view their assigned jobs. - **Job Updates**: Technicians and service centers can update service notes, track the parts used, and update the job status, culminating in closing the ticket upon resolution. ### **Brand Administrator Features** - **Centralized Dashboard**: Brands get access to a backend dashboard providing high-level analytics. - **Key Metrics**: The dashboard will display data on total registered products, the number of active warranties, ongoing service requests, and common fault patterns reported by users. - **Reporting**: Brands can export this data in CSV/PDF format for internal analysis and reporting. - **Warranty Verification**: The platform facilitates the verification of warranty claims, allowing brand admins or service centers to approve or reject claims based on system data. ### **System-Wide & Security Features** - **Role-Based Access Control (RBAC)**: The system will enforce strict permissions for each role: User, Service Center, Technician, and Brand Admin. - **Secure Access**: User authentication will be secured with OTP-based login mechanisms. - **Data Protection**: All sensitive user and product data will be protected using standard data encryption protocols.

### 1. User Product Registration Users can register products they purchase by entering: - Brand - Model - Serial number - Purchase date - Upload invoice photo/PDF - <<$Change>>User enters the warranty duration (e.g., 12 months, 24 months), from which the system calculates the expiry date.<<$Change>> - Categorize products: Mobile, Electronics, Home Appliances, Furniture, Vehicles, etc. #### Enhancement Justification - **Requirement Modified**: "Auto-calculate warranty period." - **Reasoning**: The original requirement is technically infeasible as it presupposes a universal, publicly accessible database of warranty periods for all products, which does not exist. The revised approach makes this feature practical by having the user provide the warranty duration—information readily available on their purchase documents. This preserves the core goal of establishing an accurate warranty expiry date within the system. ### 2. Digital Warranty Card - Generate a digital warranty card for each product. - Show expiry date, terms, and service conditions. - Color-coded badge (Valid / Expired). ### 3. Service Request Module - Raise service request with: - Type of issue - Photos/videos - Preferred visit time - Track status: Requested → Assigned → Technician Visiting → Resolved. ### 4. Service Center & Technician Panel - Service centers can: - View incoming requests - Assign technicians - Update service notes - Close service tickets after completion ### 5. Warranty Claim Verification - Check warranty validity. - Approve or reject claim. - Maintain history of claims & spare parts used. ### 6. Reminders & Alerts - Warranty expiry reminders. - <<$Change>>Allow users to set custom, recurring service reminders for their products (e.g., 'AC Service every 6 months', 'RO Filter Change in 90 days').<<$Change>> - Push notification for technician assignment. #### Enhancement Justification - **Requirement Modified**: "Service schedule reminders (AC servicing, vehicle service, RO filter change)." - **Reasoning**: Similar to the warranty period issue, automatically knowing the manufacturer-recommended service interval for every product is infeasible due to the lack of a centralized, public database. The enhanced requirement empowers the user to set their own custom reminders, which fully achieves the functional goal in a flexible and technically viable manner. ### 7. Invoice Vault - Secure digital storage for all past invoices. - Search by product, brand, category. ### 8. Brand Dashboard - Brands can view: - Total registered products - Active warranties - Ongoing service requests - Frequent fault patterns - CSV/PDF export for reporting. ### 9. User Mobile App (Simple) - <<$Change>>Add product by scanning its barcode/QR code to auto-fill Brand and Model where possible. User must manually verify details and enter the unique serial number.<<$Change>> - View warranty cards. - Request service. - <<$Change>>Receive status updates on the technician's journey, such as 'On The Way' and an Estimated Time of Arrival (ETA) updated by the service center/technician.<<$Change>> #### Enhancement Justification - **Requirement Modified**: "Add product quickly using barcode/QR scan." - **Reasoning**: Standard product barcodes (UPC/EAN) identify a product type (SKU), not a unique item's serial number. This change sets a realistic expectation that scanning is a helper function to accelerate data entry, not a complete solution, correctly emphasizing that manual entry of the unique serial number is still required. - **Requirement Modified**: "Track technician arrival." - **Reasoning**: The original wording implies real-time GPS tracking, which is a significant technical undertaking requiring a separate, unmentioned technician application. The revised requirement provides valuable progress information to the user via status updates (e.g., ETA), which is feasible within the scope of the described system without the complexity and privacy implications of live GPS tracking. ### 10. Security & Permissions - Role-based access: User, Service Center, Technician, Brand Admin. - OTP-based login. - Standard data encryption.