System Requirements Document for vivid-multimodal

1. Introduction

The project is named vivid-multimodal. The product is a multimodal app built from the attached SOW (SOW_Website_Mobile_Backend_Database__1___1_.docx), covering website, mobile, backend, and database scope.

1.1 Source overview

SCOPE OF WORK

Multimodal Multilingual Educational Application

Website + Android/iOS Mobile App + Backend + Database

Document Item | Details

Source Requirement | Requirements_Summary_v1.1.pdf

Source Version | Version 1.1 — 5 October 2026

Development Accelerator | 8080.ai

Primary Delivery | Responsive Website + Android + iOS + Backend APIs + PostgreSQL Database

2. System Overview

2.1 Executive Summary

This Scope of Work defines implementation of the Website, Android/iOS mobile applications, backend/API layer, database, authentication, content management, learner progress, offline synchronization, interactive learning features, administration and production infrastructure described in Requirements_Summary_v1.1.

2.2 Backend Scope

The backend is a first-class application deliverable. It is responsible for secure access to product data, user state, content, progress, offline synchronization and administration.

Module | Example Endpoints | Responsibilities

Profile | /api/me, /api/profile | Profile, preferences and session context.

Courses | /api/courses, /api/courses/:id | Course metadata and availability.

Lessons | /api/lessons/:id | Lesson sections, content blocks and modes.

Content | /api/content/* | CRUD, approval and publishing.

Quiz | /api/quizzes/* | Questions, answers, attempts and scores.

Progress | /api/progress/* | Resume state, completion and timestamps.

Offline | /api/offline/* | Manifests, versions, sync and conflict handling.

Annotations | /api/annotations/* | Canvas annotation persistence.

Media | /api/media/* | Metadata and controlled asset access.

Search | /api/search | Approved-content search where required.

Admin | /api/admin/* | RBAC-protected administration.

Analytics | /api/analytics/* | Server-side product events/KPIs.

Health | /api/health | Health/readiness endpoint.

3. Functional Requirements

3.1 Website Scope

Area | Included Features

Entry/Onboarding | Entry, language selection, guest/login, calibration/profile setup.

Course Hub | Seven-day overview, day status, progress and resume.

Lesson | Text/audio/image modes, navigation and completion.

Quiz | Questions, submission, score/result and retry behavior.

Canvas | Image zoom, draw/annotate, save and resume.

Offline UX | Download state, availability and sync indicators.

Profile | Profile, language/preferences and progress.

Admin | Dashboard, users, courses, lessons, content, quizzes, KPIs and audit.

Responsive/Accessibility | Desktop/tablet/mobile responsive and WCAG-oriented implementation.

3.2 Offline-First Implementation

Capability | Implementation

Download manifest | Backend returns version, files, checksums/metadata and dependencies.

Local text | Structured lesson data in Expo SQLite.

Local media | Audio/images in Expo FileSystem.

Local progress | Write locally while offline.

Sync queue | Unique client event IDs for mutations.

Reconnect | Send queued operations to backend; process idempotently.

Conflicts | Explicit version/timestamp conflict rules.

Partial download | Track each asset and retry failed assets only.

Version changes | Detect outdated packs and update safely.

Completion | Prevent duplicate completion events.

The source acceptance test requires airplane-mode usage and then reconnect synchronization without duplicates.

3.3 Admin & Content Management

Role | Permissions

Student | Consume course, complete lessons/quizzes, annotate and manage own profile.

Content Manager | Create/edit lesson content, media and quizzes; submit/publish as permitted.

Lecturer/Admin | Manage content/users/reports/configuration and administrative actions.

• Course CRUD and ordering.
• Day/lesson CRUD.
• Section/content-block management.
• Hindi/English variants.
• Media asset management.
• Quiz/question management.
• Draft → review → approved → published workflow.
• Preview before publishing.
• Versioning/rollback strategy.
• User list and learner drill-down.
• KPI/progress dashboard.
• CSV export where required.
• Audit logging.

Learner context | Secure user/course/day/lesson context | Consumes context.

Content access | Approved-content APIs/data access | Retrieval/grounding.

Errors | Generic UI/retry handling | Provider/model errors.

3.4 Deliverables

Deliverable | Included

Web source code | Yes

Android/iOS source code | Yes

Backend/API source | Yes

PostgreSQL schema + migrations | Yes

Authentication/RBAC | Yes

Admin dashboard | Yes

Content management | Yes

Progress + synchronization | Yes

Offline lesson system | Yes

Canvas persistence | Yes

API documentation | Yes

Environment template | Yes

Automated/unit/integration tests | Yes, agreed scope

Deployment configuration | Yes

Store build/submission support | Yes

4. User Personas

4.1 Student

Role and goals. The Student is the primary learner. The Student consumes the course, completes lessons and quizzes, annotates content, and manages their own profile. The Student's goal is to progress through the seven-day course overview, resume where they left off, and complete lessons in their preferred mode.

Journey. The Student enters through entry and language selection, then proceeds as a guest or logs in. They complete calibration and profile setup, then reach the Course Hub, which presents a seven-day overview with day status, progress, and resume. Within a lesson, the Student uses text, audio, or image modes, navigates the lesson, and completes it. On mobile (Android and iOS), the Student completes onboarding and selects a Hindi or English preference. The Student can annotate lessons and quizzes and manage their own profile.

Inputs and decisions. The Student chooses language, login method (guest, email, Google, Apple, and/or phone OTP — exact launch methods pending confirmation), lesson mode, and profile settings. The Student decides when to resume, navigate, or complete a lesson.

Observable success. The Student can access the Course Hub, see day status and progress, resume a lesson, complete lessons and quizzes, annotate content, and manage their profile. The Student cannot perform admin or content operations (RBAC).

4.2 Content Manager

Role and goals. The Content Manager creates and edits lesson content, media, and quizzes, and submits or publishes them as permitted. The Content Manager's goal is to produce and maintain course material for the Student.

Journey. The Content Manager works within the admin and content management area to create or edit lesson content, media, and quizzes, then submits or publishes according to the permitted workflow. The Content Manager may also use the user list and learner drill-down to review learner activity.

Inputs and decisions. The Content Manager decides what content to create or edit and whether to submit or publish, subject to the permitted workflow. Exact content approval and publishing ownership is pending confirmation.

Observable success. Lesson content, media, and quizzes are created or edited and submitted or published as permitted. The Content Manager's exact permissions are pending confirmation.

4.3 Lecturer/Admin

Role and goals. The Lecturer/Admin manages content, users, reports, configuration, and administrative actions. The Lecturer/Admin's goal is to operate and oversee the platform.

Journey. The Lecturer/Admin uses the admin and content management area to manage content, users, reports, and configuration, and to perform administrative actions. The Lecturer/Admin can access the user list and learner drill-down.

Inputs and decisions. The Lecturer/Admin decides on user management, report review, configuration changes, and administrative actions. Exact permissions are pending confirmation.

Observable success. Content, users, reports, and configuration are managed, and administrative actions are performed. The Lecturer/Admin's exact permissions are pending confirmation.

4.4 Client/Product Owner

Role and goals. The Client/Product Owner is responsible for content approval, product decisions, branding, legal and privacy approval, accounts, and acceptance.

Journey. The Client/Product Owner reviews and approves content, makes product decisions, approves branding and legal/privacy matters, manages accounts, and provides acceptance.

Inputs and decisions. The Client/Product Owner decides on content approval, product direction, branding, legal and privacy approval, accounts, and acceptance.

Observable success. Content is approved, product decisions are made, branding and legal/privacy are approved, accounts are managed, and acceptance is provided.

4.5 Supporting Actors

Systems and AI are supporting actors, not human personas. The platform supports web (responsive browser) and mobile (Android and iOS) access, with RBAC ensuring the Student cannot perform admin or content operations. QA and acceptance cover responsive browser testing and learner/admin workflows.

4.6 Open Clarifications

• Confirm launch login methods: guest, email, Google, Apple, and/or phone OTP.
• Confirm exact Student, Content Manager, and Lecturer/Admin permissions.
• Confirm content approval and publishing ownership.

4.7 Necessary Defaults

• The exact launch login methods are not yet confirmed; the set listed is the candidate set from the clarification questions.
• The exact permissions for Student, Content Manager, and Lecturer/Admin are not yet confirmed; the permissions described are those stated in the source requirements and remain subject to confirmation.
• Content approval and publishing ownership is not yet confirmed; the Content Manager's submit/publish capability is described as permitted pending that confirmation.

5. Core User Flows

This chapter traces the end-to-end journeys that the accepted actors perform across the vivid-multimodal experience. Each journey is numbered and self-contained; it names the trigger, the participating actors, the handoffs between them, the observable result, and the supported failure or recovery path. Journeys are not a mandated sequence: a learner may enter at any supported point, and no journey requires another to have completed first unless the source explicitly states a dependency. Where the source leaves a behavior open, the default is labeled as such.

J1. First-time learner entry, language selection and profile setup

Trigger: A new visitor opens the web entry point or installs and launches the mobile app.

Actors: Learner (guest or registered), System (web or mobile client), Backend.

Steps:

1. The learner arrives at the entry/onboarding surface. The client presents entry, language selection, and the choice between guest and login.
2. The learner selects Hindi or English. The client records the preference and applies it to subsequent content surfaces.
3. The learner either continues as a guest or authenticates. On mobile, authentication and session persistence are supported; on web, guest/login and session expiry/logout behave as agreed.
4. The learner completes calibration and profile setup. The profile captures language and preferences.
5. The client confirms the profile and routes the learner to the course hub.

Handoffs: The client passes the selected language, guest-or-authenticated identity, and profile data to the Backend. The Backend returns the learner context used by later journeys.

Result: A learner with a persisted language preference and profile can reach the seven-day course hub.

Failure and recovery: If authentication fails or a session expires, the client returns the learner to the entry surface with the prior language selection retained where the client can preserve it. If profile setup is abandoned, the learner may resume it from the profile surface. Default (not specified in source): guest progress transfer to a registered account is an open clarification question; until confirmed, the client must not assume automatic transfer.

Continuation: The learner proceeds to J2.

J2. Course hub review and day selection

Trigger: The learner reaches the course hub after onboarding or returns to it later.

Actors: Learner, System (web or mobile client), Backend.

Steps:

1. The client requests the learner's course state from the Backend.
2. The hub displays the seven-day overview with day status, progress, and a resume affordance.
3. The learner inspects day status and selects a day or resumes the last position.
4. The client opens the selected day's lesson surface.

Handoffs: The Backend supplies day status and progress; the client renders it and passes the selected day identifier back when the learner proceeds.

Result: The learner is positioned at a specific day with visible progress and a resume point.

Failure and recovery: If course state cannot be loaded, the client shows an error state and offers retry. If the learner has downloaded content, the hub may reflect offline availability and sync indicators. Default (not specified in source): the exact visual treatment of day status is a design decision, not a functional requirement.

Continuation: The learner proceeds to J3.

J3. Lesson consumption across text, audio and image modes

Trigger: The learner opens a day or lesson from the hub.

Actors: Learner, System (web or mobile client), Backend, Content author (indirectly, through published content).

Steps:

1. The client loads the lesson and presents text, audio, and image modes.
2. The learner navigates between modes and moves through lesson sections.
3. The learner marks the lesson complete or advances to the next section.
4. The client records completion and progress.

Handoffs: The Backend serves lesson content and receives progress updates. On mobile, downloaded lessons are available offline; the client queues progress locally when disconnected.

Result: The learner has consumed the lesson in one or more modes and progress is recorded.

Failure and recovery: If media fails to load, the client shows an error state and allows retry. If the learner is offline, the client uses downloaded content and queues progress for later synchronization. If a lesson is not downloaded and the learner is offline, the client indicates unavailability.

Continuation: The learner may proceed to J4 (quiz), J5 (canvas), or return to J2.

J4. Quiz and Q&A flow

Trigger: The learner reaches a quiz or Q&A segment within a lesson or day.

Actors: Learner, System (web or mobile client), Backend.

Steps:

1. The client presents questions.
2. The learner submits answers.
3. The client sends the submission to the Backend for scoring.
4. The client displays the score or result and offers retry behavior where supported.
5. The result is persisted.

Handoffs: The client passes answers to the Backend; the Backend returns score/result and persists it. On mobile offline, the submission may be queued and synchronized later.

Result: The learner receives a score or result, and the attempt is persisted.

Failure and recovery: If submission fails, the client shows an error and allows retry. If offline, the client queues the submission and synchronizes on reconnect without duplicates. Retry behavior is supported as specified.

Continuation: The learner may return to J3, proceed to J5, or continue to the next day via J2.

J5. Interactive image canvas: zoom, draw, annotate, save and resume

Trigger: The learner opens an interactive image canvas associated with a lesson or day.

Actors: Learner, System (web or mobile client), Backend.

Steps:

1. The client loads the image and canvas tools.
2. The learner zooms, draws, and annotates.
3. The learner saves the canvas state.
4. The client persists the canvas state so it can be resumed later.

Handoffs: The client sends canvas state to the Backend for persistence; the Backend returns confirmation. On mobile offline, canvas state may be queued locally and synchronized later.

Result: The learner's annotations are saved and can be resumed.

Failure and recovery: If save fails, the client shows an error and allows retry. If offline, the client queues the save and synchronizes on reconnect without duplicates. Canvas persistence is a required deliverable.

Continuation: The learner may return to J3, J4, or J2.

J6. Offline lesson download and airplane-mode usage

Trigger: The learner chooses to download a lesson for offline use, or loses connectivity.

Actors: Learner, System (mobile client), Backend.

Steps:

1. The learner initiates a lesson download.
2. The Backend returns a download manifest containing version, files, checksums/metadata, and dependencies.
3. The client downloads the files and stores them locally.
4. The client shows download state and availability.
5. The learner enters airplane mode and consumes the downloaded lesson, including the offline guide-pack UI using supplied pre-authored content.
6. Progress is queued locally.

Handoffs: The Backend supplies the manifest and files; the client manages local storage and offline UI.

Result: The learner can use downloaded lessons without connectivity, with progress queued.

Failure and recovery: If a download fails or checksums do not match, the client reports the failure and allows retry. If storage is insufficient, the client indicates the problem. The source acceptance test requires airplane-mode usage followed by reconnect synchronization without duplicates.

Continuation: The learner proceeds to J7 on reconnect.

J7. Reconnect synchronization and conflict-safe progress merge

Trigger: The mobile client regains connectivity after offline usage.

Actors: System (mobile client), Backend.

Steps:

1. The client detects reconnect.
2. The client sends queued progress and any queued quiz submissions or canvas saves.
3. The Backend applies conflict-safe synchronization rules.
4. The client updates local state to reflect the synchronized result.
5. The client shows sync indicators.

Handoffs: The client passes queued items to the Backend; the Backend resolves conflicts and returns the authoritative state.

Result: Offline progress is synchronized without duplicates, and local state matches the Backend.

Failure and recovery: If synchronization fails, the client retains the queue and retries. If conflicts are detected, the Backend applies conflict-safe rules. Duplicate prevention is required.

Continuation: The learner continues with J2 or J3.

J8. Profile, language and preference management

Trigger: The learner opens the profile surface.

Actors: Learner, System (web or mobile client), Backend.

Steps:

1. The client displays profile, language/preferences, and progress.
2. The learner updates language or preferences.
3. The client saves the changes to the Backend.
4. The client confirms the update.

Handoffs: The client sends updated preferences to the Backend; the Backend persists them.

Result: The learner's profile and preferences are updated and reflected in subsequent content.

Failure and recovery: If save fails, the client shows an error and allows retry. If offline, changes may be queued and synchronized later.

Continuation: The learner returns to J2 or J3.

J9. Admin content authoring and publishing workflow

Trigger: An admin opens the admin dashboard to create or update course content.

Actors: Admin, System (admin web client), Backend.

Steps:

1. The admin accesses the dashboard, users, courses, lessons, content, quizzes, KPIs, and audit surfaces.
2. The admin performs course CRUD and ordering, day/lesson CRUD, section/content-block management, Hindi/English variant management, media asset management, and quiz/question management.
3. The admin moves content through the draft → review → approved → published workflow.
4. The admin previews content before publishing.
5. The admin publishes, with versioning and rollback available.

Handoffs: The admin client sends content changes to the Backend; the Backend persists them and makes published content available to learner clients.

Result: Content is authored, reviewed, approved, published, and versioned.

Failure and recovery: If publishing fails, the admin can retry or roll back to a prior version. Preview is available before publishing.

Continuation: The admin may proceed to J10.

J10. Admin learner monitoring and KPI review

Trigger: An admin opens the user list or KPI/progress dashboard.

Actors: Admin, System (admin web client), Backend.

Steps:

1. The admin views the user list and drills down into a learner.
2. The admin reviews KPI/progress dashboard data.
3. The admin exports CSV where required.

Handoffs: The Backend supplies user and progress data; the admin client renders it and supports export.

Result: The admin can inspect learner progress and export data.

Failure and recovery: If data cannot be loaded, the admin client shows an error and allows retry.

Continuation: The admin may return to J9.

J11. Session expiry and logout

Trigger: A session expires or the learner logs out.

Actors: Learner, System (web or mobile client), Backend.

Steps:

1. The client detects session expiry or the learner initiates logout.
2. The client clears session state and returns the learner to the entry surface.
3. The Backend invalidates the session as agreed.

Handoffs: The client notifies the Backend; the Backend invalidates the session.

Result: The session is ended and the learner is returned to entry.

Failure and recovery: If logout fails, the client clears local state and retries. Session expiry behavior is as agreed.

Continuation: The learner may re-enter via J1.

J12. Network and app lifecycle handling on mobile

Trigger: The mobile app transitions between foreground and background, or the network state changes.

Actors: System (mobile client), Backend.

Steps:

1. The client detects a lifecycle or network change.
2. The client pauses or resumes downloads, synchronization, or media playback as appropriate.
3. The client updates indicators to reflect the current state.

Handoffs: The client coordinates with the Backend when connectivity is available.

Result: The app behaves predictably across lifecycle and network changes.

Failure and recovery: If a transition interrupts an operation, the client resumes or retries when conditions allow.

Continuation: The learner continues with J2 or J3.

J13. Production build and store submission support

Trigger: The team prepares Android and iOS production builds.

Actors: System (build and release tooling), Backend.

Steps:

1. The team produces Android and iOS production builds.
2. The builds are prepared for store submission.

Handoffs: The builds connect to real APIs as required by the Definition of Done.

Result: Production builds are available for store submission.

Failure and recovery: If a build fails, the team corrects and rebuilds. This journey is a release activity, not a learner-facing flow.

Continuation: Not applicable.

Cross-journey conditions

• The Definition of Done requires web and mobile to connect to real APIs; loading, empty, error, and success states to be implemented; authorization to be verified; offline behavior to be verified where applicable; tests to be executed and results documented; and no feature to be marked complete solely because a UI exists.
• QA and acceptance cover responsive browser testing for learner and admin workflows, auth behavior including guest/login/session expiry/logout as agreed, offline download/airplane mode/progress queue/reconnect/duplicate prevention, canvas zoom/draw/save/resume, quiz submission/scoring/persistence, and content draft/publish/version behavior.
• Performance and scalability require offline-first access to downloaded lessons.
• The source leaves guest progress transfer to a registered account as an open clarification question; no journey assumes automatic transfer until that is confirmed.

6. Visuals Colors and Theme

[Design proposal; unspecified choices are defaults.]

Palette (light mode, authoritative): background #F4EDE1 (cream ground, ~70% of every screen), surface #FFFBF3 (panels, 1px #241F1A12 hairline — never a shadow), text #241F1A, primary #1E4B4A (deep teal — nav bar, section rules, day-panel headers, primary buttons), accent #D9572B (tomato — rationed to current-day marker, quiz submit, active canvas stroke), muted #8A7A66 (metadata and labels only, never body copy). Coded day colours: mustard #D9A227, walnut #6B4A2E, teal-light #7FA8A0 — each paired with #241F1A text for AA contrast. No pure #FFFFFF ground, no pure #000000 text, no #2563EB/#4F46E5 anywhere.

Typography: headings Fraunces (weight 600–700, high optical size, soft-terminal serifs; tracking -0.02em, sentence case, 0.95 leading at display sizes); body and all UI Jost (400/500, 0.08em uppercase tracking for eyebrow labels and day numerals, tabular numerals). Scale 1.333 modular on a 4/8pt rhythm: display 44px mobile → 128px desktop (clamp), h1 32→64, h2 24→40, h3 20→28, body 16→18, label 12→13 uppercase. Body measure capped at 34rem. Inter, Roboto, Poppins and system-ui are excluded from all headings and body text.

Shape and layout: modular panels with 8px radii and 2px honest borders — no pill buttons, no glass, no drop shadows, no 24px+ radii. Day cards are rectangular colour blocks with a teal header strip and a mustard progress bar underneath; the canvas tool rail is square 44px pictogram tiles. Section boundaries are full-column hard rules at #241F1A 12% opacity. 12-column modular grid, visible 24px gutters, persistent 72px left rail numbering the seven days; course hub is a 7-panel asymmetric grid (today spans 7 columns × 2 rows, completed days sit smaller in gallery sequence); admin reuses the identical grid with ruled rows and tabular numerals, no card float. Mobile collapses to one column with the day index as a horizontally scrollable numbered strip that can be brought fully into view.

Imagery: warm documentary photography of hands, notebooks and study desks in natural light; mid-century flat diagrams and playful pattern blocks as content openers; audio lessons rendered as a mid-century pattern-strip waveform, not a modern audio widget. No 3D renders, no gradient blobs, no stock people smiling at laptops.

Accessibility: headlines, wordmarks, labels, numbers, card text and controls stay whole inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling (clamp with its mobile size) to fit; nothing covers them. Imagery and decoration may crop, bleed, rotate or overlap freely. Scrollable rows may cross the container edge by design provided every item becomes fully readable as it passes; under prefers-reduced-motion they wrap or scroll so each item can be brought fully into view.

7. Signature Design Concept

[Design proposal; unspecified choices are defaults.]

Signature Design Concept — Warm modernism for a seven-day multilingual classroom. Muse: Charles & Ray Eames. vivid-multimodal is a multimodal, multilingual education platform (Hindi + English at launch) for students on low-end Android devices, plus content managers and lecturer/admins; the register is humane and encouraging — learning as a daily ritual, not a transaction — while holding dense course, quiz, canvas and admin surfaces. Warmth inside order, craft over chrome.

Signature moves: (1) Seven-panel day index — a vertical stack of numbered colour blocks (mustard, walnut, teal-light, tomato for today) that doubles as navigation; clicking a panel scrolls the lesson into view and the panel fills with a progress bar. (2) An oversized Fraunces statement spanning the viewport width with one word reversed out in tomato inside a teal rule, sized clamp(44px, 9vw, 128px). (3) Gallery-sequence lesson flow — each lesson section is a numbered panel with a teal header strip reading 'DAY 03 · SECTION 02', separated by full-width 12%-opacity rules, so the page reads like an exhibition wall. (4) Canvas tool rail of square 44px pictogram tiles with 2px borders and a tomato active stroke, plus a bottom 'saved locally / synced' ledger line in tabular Jost numerals showing version and checksum status. (5) Admin tables ruled like a poster grid with tabular numerals and a mustard/teal status chip system — no floating cards, no hover-lift.

Public entry (hero): a full-bleed cream stage split by a single vertical teal rule. The left 7 columns carry the oversized Fraunces statement 'SEVEN DAYS. TWO LANGUAGES. ONE LESSON AT A TIME.' with 'DAYS' reversed out in tomato inside the line; the right 5 columns hold the stacked seven numbered colour panels acting as the course index, with the primary CTA 'Start Day 1' pinned beneath the last panel in solid teal. A thin ruled footer line carries the 'हिन्दी | English' language toggle and the offline-pack status. No centred headline, no subtext-under-button stack, no gradient.

Avoid: blue–indigo accents on white; gradient-blob heroes and glassmorphism; Inter/Roboto/Poppins/system-ui for headings or body; grids of identical hover-lift cards with soft shadows; pill buttons and 24px+ radii; 3D renders, particle fields or WebGL scenes; bouncy spring micro-interactions; pure #FFFFFF grounds and pure #000000 text.

8. Interaction Model & Motion Direction

[Design proposal; unspecified choices are defaults.]

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: layered_2d

Landing Hero Motion Brief. Focal subject: the seven numbered colour panels of the day index, stacked against the cream stage and the oversized Fraunces statement. Thesis: on load, the seven panels rise into place in sequence (input) → each panel settles with its day numeral and colour block, the teal rule drawing down between the statement and the index (transformation) → the course index reads as a made object and 'Start Day 1' is immediately actionable (outcome). Motion vocabulary: film-like and gentle — panels reveal by a 240ms opacity + 16px rise, staggered 60ms across the seven-panel grid; the day index rail slides a 2px teal marker as you scroll; quiz feedback is an instant colour flip with no bounce; canvas tools have tactile 120ms press states. Nothing parallaxes, nothing loops, nothing bounces. Composed first frame: cream ground, teal vertical rule, Fraunces statement with 'DAYS' in tomato, seven panels at rest, CTA in solid teal, ruled footer with 'हिन्दी | English' and offline-pack status. Reduced-motion state: all panels and the statement render in their final positions with no rise or stagger; the day index remains a static numbered stack that still scrolls the lesson into view on click, and the language toggle and CTA stay fully usable.

9. Non-Functional Requirements

9.1 Backend Scope / Backend Engineering Requirements

• Typed request validation.
• Authentication and role-based authorization.
• Pagination/filtering/sorting for lists.
• Idempotent progress synchronization.
• Consistent HTTP status codes and error objects.
• Server-side validation for all writes.
• Transactions for multi-record operations.
• Rate limiting for sensitive/high-volume endpoints.
• Audit fields and audit logs where appropriate.
• Environment-based configuration and secrets management.
• API documentation.
• No production secrets in web/mobile bundles.

9.2 Database Scope / Database Quality

• Primary/foreign keys.
• Unique constraints for business identifiers.
• Indexes on user/course/lesson/language/status/timestamp fields.
• Versioning for published content and offline manifests.
• Database migrations in source control.
• Development/staging seed data.
• Backup and restore procedure.
• Least-privilege access.
• RLS/data-isolation policies where direct client access is used.

9.3 Security & Non-Functional Requirements

• HTTPS/TLS everywhere.
• No hardcoded credentials.
• Server-side RBAC.
• Learner data isolation.
• Input validation and safe output handling.
• Secure file upload/storage.
• Rate limiting.
• Audit logging.
• No sensitive details in error responses.
• Secure environment configuration.
• Backups and restore testing.
• OWASP-oriented security review.
• Privacy/consent controls required by the source specification.

The source requirement specifies a 99.9% target, auto-scaling backend, OWASP-oriented security, daily backups and privacy/compliance considerations.

9.4 Performance & Scalability

• Mobile-first performance for low-end Android devices.
• Optimized web payload and images.
• Lazy loading for non-critical assets.
• CDN for static/media assets.
• Indexed database queries.
• Pagination/cursors for large lists.
• Safe API caching.
• Offline-first access to downloaded lessons.
• Load only required course/day/lesson data.
• Monitoring of API latency, errors and mobile crashes.

9.5 QA & Acceptance

Test Area | Required Validation

Web | Responsive browser testing and learner/admin workflows.

Android | Real-device testing including low/mid-range device.

iOS | Real-device testing on supported iOS versions.

Auth | Guest/login/session expiry/logout as agreed.

RBAC | Student cannot perform admin/content operations.

Database | Constraints, migrations, indexes and isolation.

Offline | Download, airplane mode, progress queue, reconnect, duplicate prevention.

Canvas | Zoom/draw/save/resume.

Quiz | Submission, scoring and persistence.

Content | Draft/publish/version behavior.

API | Validation, authorization, errors and idempotency.

Security | Secrets, access control, uploads and common OWASP risks.

Release | Production builds and store readiness.

9.6 QA & Acceptance / Definition of Done

• Feature implemented in source control.
• Backend API connected.
• Database migration/schema included.
• Web/mobile connected to real APIs.
• Loading/empty/error/success states implemented.
• Authorization verified.
• Offline behavior verified where applicable.
• Tests executed and results documented.
• No feature marked complete solely because a UI exists.

10. Tech Stack

10.1 Executive Summary / Included Source Requirements

• Mobile-first responsive web application.
• Android and iOS using React Native + Expo.
• Seven-day guided course/lesson experience.
• Text, audio, images, quizzes/Q&A and interactive image canvas.
• Hindi and English at launch.
• Offline lesson downloads and offline progress.
• Student, content manager and lecturer/admin roles.
• Admin dashboard, KPIs and CSV/reporting where required.
• Authentication, learner profiles and progress synchronization.
• Content/media storage and operational data.

10.2 Feasibility Assessment

The requested Website + Mobile App + Backend + Database scope is feasible. The source requirement itself specifies Next.js, Node.js route handlers, Supabase PostgreSQL/Auth/Storage, React Native + Expo, offline storage and API-based services.

8080.ai is aligned with this type of full-stack work. Its public examples include React/React Native applications, REST backends, relational databases, authentication/admin functionality and complete application structures.

Area | 8080.ai Feasibility | Assessment | Notes

Responsive Website | High | Doable | Next.js + TypeScript + Tailwind CSS learning and admin UI.

Android + iOS | Medium–High | Doable with validation | React Native/Expo; real-device/store validation required.

Backend REST APIs | High | Doable | CRUD, auth-protected APIs, progress, content and admin.

PostgreSQL Database | High | Doable | Schema, indexes, constraints, migrations and RLS.

Authentication/RBAC | High | Doable | Managed auth plus server-side authorization.

Interactive Canvas | Medium | Doable | Custom web/mobile implementation and persistence.

Admin Dashboard | High | Doable | Content, users, progress and reporting.

10.3 Recommended Architecture

Layer | Technology | Responsibility

Web | Next.js + TypeScript + Tailwind CSS | Learner web and admin dashboard.

Mobile | React Native + Expo + TypeScript | Android/iOS learner apps.

State | Zustand | Client learning/session state.

Data Fetching | TanStack Query | Caching, retries, loading and synchronization.

Backend | Node.js + Next.js Route Handlers | REST APIs, authorization and business rules.

Database | Supabase PostgreSQL | Courses, lessons, users, progress, quizzes, annotations and operational data.

Auth | Supabase Auth | Guest/email/social authentication and sessions.

Audio/CDN | Cloudflare R2 + CDN | Application-managed audio delivery if required.

Offline | Expo SQLite + Expo FileSystem | Downloaded content, progress, audio/images.

Monitoring | Sentry | Error monitoring.

Analytics | PostHog | Product analytics.

CI/CD | GitHub Actions | Automated build/test/deploy.

10.4 Database Scope

PostgreSQL is recommended because the source requirement identifies PostgreSQL/Supabase as the database layer for lessons, user data, annotations, progress and future extensibility.

Domain | Core Tables / Entities | Purpose

Identity | users, profiles, roles, user_roles | Identity, learner profile and RBAC.

Courses | courses, course_versions, course_languages | Course metadata and language availability.

Lessons | lessons, lesson_sections, lesson_assets | Seven-day lesson structure.

Content | content_items, content_versions, content_approvals | Approved content lifecycle.

Media | media_assets, media_variants | Audio/image/document metadata.

Quiz | quizzes, quiz_questions, quiz_options, quiz_attempts, quiz_answers | Quiz configuration and attempts.

Progress | user_course_progress, user_lesson_progress, user_activity | Learning state and history.

Offline | offline_manifests, offline_sync_queue, sync_conflicts | Downloads and reliable reconnection.

Canvas | annotations, annotation_versions | Learner drawing/annotation state.

Preferences | user_preferences, language_preferences | Language/mode preferences.

Admin | audit_logs, admin_actions | Administrative traceability.

Notifications | notification_preferences, notification_events | Reminder/notification state.

10.5 Mobile App Scope — Android + iOS

• Single React Native + Expo codebase.
• Authentication and session persistence.
• Onboarding and Hindi/English preference.
• Course/day/lesson navigation.
• Text, audio and image lesson consumption.
• Quizzes and Q&A flows.
• Interactive image canvas.
• Progress and completion.
• Lesson downloads.
• Offline text/audio/images/quizzes/progress.
• Offline guide-pack UI using supplied pre-authored content.
• Local progress queue and reconnect synchronization.
• Conflict-safe synchronization.
• Network and app lifecycle handling.
• Android/iOS production build and store-submission support.

The source requirement explicitly specifies Expo SQLite for offline text/progress and Expo FileSystem for audio/images.

11. Assumptions and Constraints

11.1 Source overview

Status | Proposal / SOW baseline

11.2 Clarification Questions

1. Confirm whether Supabase is mandatory or alternatives are allowed.
2. Confirm Vercel + Supabase + Cloudflare R2 approval.
3. Confirm launch login methods: guest, email, Google, Apple and/or phone OTP.
4. Confirm whether guest progress must transfer to a registered account.
5. Confirm exact Student, Content Manager and Lecturer/Admin permissions.
6. Confirm content approval/publishing ownership.
7. Confirm whether the course is exactly seven days or configurable.
8. Confirm quiz types at launch.
9. Confirm whether web offline/PWA is required or mobile-only.
10. Confirm maximum offline storage per learner/device.
11. Confirm annotation export requirements.
12. Confirm KPI/CSV requirements.
13. Confirm push notification requirements.
14. Confirm content/media formats and licensing.
15. Confirm learner activity/log retention.
16. Confirm minor/under-18 learner requirements.
17. Confirm expected MAU/concurrent users for infrastructure sizing.
18. Confirm client ownership of cloud, domain and app-store accounts.

11.3 Recommended Delivery Phases

Phase | Work | Output

2. Foundation | Repo, CI/CD, DB, auth, backend | Platform foundation
3. Web | Learner + admin web | Connected website
4. Mobile | React Native/Expo | Android/iOS apps
5. Learning | Course/lesson/quiz/canvas/progress | Learning engine
6. Offline | Download/local DB/sync/conflicts | Offline-first mobile
7. QA | Device/browser/security/performance | QA report
8. Release | Production + stores | Go-live
9. Handover | Docs/source/accounts walkthrough | Production handover

11.4 Assumptions

• Client supplies approved content/media/branding.
• Client owns required cloud/app-store/domain accounts.
• Third-party service costs are excluded from development fees.
• Store review timelines are external.
• Requirements outside this SOW require change control.
• Architecture may be adjusted only with agreed technical justification.

11.5 Out of Scope

• YouTube integration.
• Video transcript extraction.
• Payments/subscriptions.
• Admin mobile app.
• Languages beyond agreed launch scope unless separately approved.

11.6 Risks & Mitigations

Risk | Impact | Mitigation

Implementation complexity | Medium | Architecture review, staged development and testing.

Offline sync complexity | High | Build/test synchronization early on real devices.

Content changes | Medium | Versioned/configurable content model.

Large media downloads | Medium | Manifests, compression, CDN and retry.

RBAC/security gaps | High | Server-side tests and database policies.

Store review delays | Medium | Prepare builds/assets early.

Low-end performance | Medium | Real-device testing and performance budgets.

11.7 Final Recommendation

YES — the requested Website + Android/iOS Mobile App + Backend + Database scope is feasible and is the correct separation of responsibilities for this project.

8080.ai can accelerate implementation of the web application, mobile application, backend APIs, database structures and admin workflows. Public 8080.ai examples demonstrate comparable React/React Native, backend and database architectures.

Treat 8080.ai as a development accelerator, not a substitute for engineering verification. The team should generate the project in controlled modules, review architecture, test real APIs/database behavior, validate offline behavior on physical Android/iOS devices and perform security/release review.

Team | Primary Ownership

Application Team | Website, Android/iOS, backend, PostgreSQL, auth, content, progress, offline sync, admin, deployment and external service integration contract.

Client/Product Owner | Content approval, product decisions, branding, legal/privacy approval, accounts and acceptance.

11.8 Source Basis

Primary source: Requirements_Summary_v1.1.pdf, Version 1.1, dated 5 October 2026.

• Core product/platform scope: lines 10–31.
• Offline requirements and offline guide pack: lines 125–190.
• Architecture and technology stack: lines 320–399 and 405–497.
• Service responsibility matrix: lines 742–874.
• Non-functional requirements: lines 730–741.

External validation: 8080.ai public project requirements/design examples were reviewed for React/React Native, backend, database, authentication and full-stack generation capabilities.

12. Glossary

This glossary defines terms as they are used in the vivid-multimodal project. It covers only concepts established by the supplied requirements.

Language availability — The set of languages in which a course is offered, tracked in the course_languages table. Hindi and English are the languages available at launch.

Course version — A specific revision of a course, held in course_versions, allowing course metadata to evolve while preserving prior states.

Seven-day lesson structure — The lesson model in which a course is organized into lessons, each composed of lesson sections and lesson assets (lessons, lesson_sections, lesson_assets).

Content item — A unit of learning content whose lifecycle is governed by content_items, content_versions and content_approvals, so that content moves through approval before publication.

Media asset — Audio, image or document material stored as media_assets, with derived renditions held in media_variants.

Quiz — An assessment configured through quizzes, quiz_questions and quiz_options, with learner attempts recorded in quiz_attempts and quiz_answers.

Progress — A learner's state and history across the course, captured in user_course_progress, user_lesson_progress and user_activity.

Offline manifest — The record in offline_manifests describing what a learner has downloaded for offline use.

Sync queue — The ordered set of pending changes in offline_sync_queue awaiting upload when connectivity returns.

Sync conflict — A divergence recorded in sync_conflicts when offline changes cannot be reconciled cleanly on reconnection.

Annotation — A learner's drawing or marking on content, stored in annotations with revision history in annotation_versions.

Preference — A learner's language or mode setting, held in user_preferences and language_preferences.

Audit log — The administrative traceability record in audit_logs, paired with admin_actions, capturing administrative activity.

Notification preference / event — Reminder and notification state held in notification_preferences and notification_events.

Role-based access control (RBAC) — The permission model built on users, profiles, roles and user_roles. Three roles are defined: Student, who consumes courses, completes lessons and quizzes, annotates, and manages their own profile; Content Manager, who creates and edits lesson content, media and quizzes and submits or publishes as permitted; and Lecturer/Admin, who manages content, users, reports and configuration and performs administrative actions.