System Requirements Document for scamshield

1. Introduction

ScamShield is an AI-powered scam and fraud detection platform that helps users identify potentially fraudulent messages, screenshots, and website links. Its tagline is "Know before you trust." and its short explanation is "Check suspicious messages, screenshots, and links before you act."

This document specifies the first version of ScamShield: a professional, mobile-first web application delivering only the frontend foundation and navigation. The audience is ordinary adults — not security analysts — who need to turn a vague "this feels off" into a graded, defensible read before they act on a suspicious message, screenshot, or link.

This first stage deliberately does not build the entire application. It establishes the screens, navigation, component architecture, and states that later stages will extend. No AI API is connected, no payment/subscription functionality is added, and no fake scam detection results are produced.

2. System Overview

ScamShield v1 is a frontend-only, mobile-first web application with a responsive desktop layout. It presents a public landing screen, an authenticated dashboard, three checking workspaces (message, screenshot, link), a reserved results structure, a history destination, and a profile/settings screen, tied together by a bottom navigation bar (Home / Check / History / Profile) that becomes a left rail at ≥1024px.

The product is built from reusable components with proper loading, error, and empty states, accessible buttons, labels, and form controls, and a polished, serious security-product appearance. All analysis, OCR, and URL-detection backends remain unconnected in this stage; each checking workspace displays a clear placeholder indicating the analysis engine will be connected in a later development stage, and the results screen is a UI structure only, containing no fabricated detection results.

2a. Product Interpretation and Delivery Boundary

ScamShield's current delivery is a frontend foundation: the screens, navigation, and component system that a real startup MVP needs, without any live detection capability. Users can move through the product, submit content into the checking workspaces, and see honest, clearly labeled placeholders where analysis will later appear. Nothing in the current version claims to detect, score, or clear anything.

Access is application-owned. Because checks, history, and account preferences must persist to the correct person and be resumable, the product establishes identity on first use through Sign Up and verifies returning users through Login. Both entry surfaces are anonymously reachable; the protected destinations (Dashboard, Check, the three checking workspaces, Results, History, and Profile/Settings) require a verified session. The public Landing/Home screen remains openly reachable and is the entry point for the checking journey.

The following are explicitly out of scope for this stage: connecting any AI API; implementing OCR or AI for screenshots; implementing real URL analysis; adding payment or subscription functionality; generating fake scam detection results; and adding any features not requested. The "Upgrade to Premium" section on the Dashboard is a presentation block only — it does not process payments or change entitlements. The Results screen reserves the structure for risk level, risk score, warning indicators, explanation, recommended action, and a Report Scam button, but displays no invented values.

Future stages will connect the analysis engine and adopt non-guaranteeing language such as "Low Risk", "Suspicious", and "High Risk" rather than asserting that a message is or is not a scam.

2b. Page Content and Component Coverage

Landing/Home screen

• Information/state: ScamShield logo/name; tagline "Know before you trust."; short explanation "Check suspicious messages, screenshots, and links before you act."; professional security-focused visual design.
• Primary action: "Check for a Scam" button (routes into the checking journey).
• Supporting action: "How It Works" secondary button.
• Domain entities: Brand identity (name, tagline), product explanation.
• Component responsibilities: Brand header/wordmark, hero block, primary CTA, secondary CTA, security-focused visual treatment.
• States: Static public content; no loading/empty/error states required beyond standard page render. If the "How It Works" content is unavailable, the control remains present and inert rather than showing fabricated content.

Login

• Information/state: Returning-user verification form (identifier and credential fields) with accessible labels.
• Primary action: Submit credentials to establish a verified session.
• Supporting actions: Navigate to Sign Up; return to Landing/Home screen.
• Domain entities: User identity, session.
• Component responsibilities: Form container, labeled inputs, submit control, inline validation messaging, link to Sign Up.
• States: Loading (submission in progress), error (invalid credentials or failed submission with recovery guidance), success (redirect to Dashboard or the intended protected destination).

Sign Up

• Information/state: First-use enrollment form collecting only the minimum information needed to establish an account.
• Primary action: Create the account and establish a verified session.
• Supporting actions: Navigate to Login; return to Landing/Home screen.
• Domain entities: User identity, account.
• Component responsibilities: Form container, labeled inputs, submit control, inline validation messaging, link to Login.
• States: Loading, error (validation or submission failure with recovery guidance), success (redirect into the protected experience). No unnecessary personal information is collected.

Dashboard

• Information/state: Three main checking options — Check a Message, Check a Screenshot, Check a Link; Recent Checks; Protection Status; Upgrade to Premium section.
• Primary actions: Select one of the three checking options to enter its workspace.
• Supporting actions: Open a recent check; view Protection Status; view the Upgrade to Premium section.
• Domain entities: Check type, recent check entries, protection status, premium presentation.
• Component responsibilities: Protection Status panel with circular gauge; three check tiles (1-column → 3-column grid); Recent Checks ruled table with tier chip, truncated preview, right-aligned tabular timestamp; Premium bordered inset band.
• States: Loading (while recent checks and status resolve), empty ("No checks yet" as a single centered shield pictogram plus one line of muted copy), success (populated ruled table), error (recoverable message with retry). The Upgrade to Premium section is presentational and does not process payment.

Check

• Information/state: Bottom-navigation destination that routes users to the message, screenshot, and link checking workflows.
• Primary actions: Choose Check Message, Check Screenshot, or Check Link.
• Supporting actions: Return to Dashboard.
• Domain entities: Check type.
• Component responsibilities: Check-type selector/route list, consistent screen header (uppercase eyebrow, large title, hairline rule).
• States: Static routing surface; each destination owns its own loading/error/empty states.

Check Message screen

• Information/state: Large text input area with placeholder "Paste a suspicious message here..."; clear placeholder indicating the analysis engine will be connected in a later development stage.
• Primary action: "Analyze Message" button.
• Supporting actions: Clear/reset the input; navigate back to Check.
• Domain entities: Submitted message text.
• Component responsibilities: Labeled large textarea, submit button with rotating bezel loading treatment, "Engine not connected yet" inset notice panel directly below the form.
• States: Empty (placeholder visible, submit disabled or inert), loading (bezel ring traces the button capsule), success (notice panel confirms the engine is not yet connected — no analysis result), error (recoverable message with retry). The button does not perform real AI analysis.

Check Screenshot screen

• Information/state: Upload image button; drag-and-drop area where appropriate; preview of the uploaded image; clear placeholder indicating analysis will be connected later.
• Primary action: "Analyze Screenshot" button.
• Supporting actions: Replace/remove the selected image; navigate back to Check.
• Domain entities: Uploaded image file, preview.
• Component responsibilities: Upload control, 12px-radius dropzone, image preview, submit button with bezel loading treatment, "Engine not connected yet" notice panel.
• States: Empty (dropzone prompt), loading (upload/preview processing and submit bezel), success (preview shown and notice panel confirms no OCR/AI yet), error (unsupported file or failed upload with recovery guidance). No OCR or AI is implemented.

Check Link screen

• Information/state: URL input; clear placeholder indicating real URL analysis is not yet implemented.
• Primary action: "Check Link" button.
• Supporting actions: Clear the input; navigate back to Check.
• Domain entities: Submitted URL.
• Component responsibilities: Labeled URL input, submit button with bezel loading treatment, "Engine not connected yet" notice panel.
• States: Empty (input prompt), loading (bezel ring), success (notice panel confirms no real URL analysis yet), error (invalid URL format or failed submission with recovery guidance).

Results screen

• Information/state: UI structure only, reserved to eventually display risk level, risk score, warning indicators, explanation, recommended action, and a Report Scam button. No fake analysis results are generated.
• Primary action: Report Scam button (structure present).
• Supporting actions: Return to the originating check or Dashboard.
• Domain entities: Risk level, risk score, warning indicators, explanation, recommended action.
• Component responsibilities: 270° arc risk gauge with tick marks at 0/25/50/75/100 and tabular score numerals; tier label in uppercase micro-type (Low Risk teal / Suspicious amber / High Risk signal red); warning indicator list; explanation block; recommended action block; Report Scam button.
• States: Empty/reserved (structure visible, no values populated, explicit notice that analysis is not yet connected), loading (bezel treatment), error (recoverable message). No fabricated results appear in any state.

History

• Information/state: Revisitable list of prior checks, consistent with Recent Checks on the Dashboard.
• Primary actions: Open a prior check; return to its results structure.
• Supporting actions: Return to Dashboard or Check.
• Domain entities: Prior check entries (type, preview, timestamp, tier chip).
• Component responsibilities: Ruled data table with hairline rows, left tier chip, truncated content preview, right-aligned tabular timestamp.
• States: Loading, empty ("No checks yet" shield pictogram plus one line of muted copy), success (populated rows), error (recoverable message with retry).

Profile/Settings screen

• Information/state: Account information; subscription status; privacy settings; notification settings; Logout.
• Primary actions: Adjust privacy settings; adjust notification settings; Log out.
• Supporting actions: Review account information and subscription status.
• Domain entities: Account, subscription status, privacy preferences, notification preferences, session.
• Component responsibilities: Account information panel, subscription status panel (presentational — no payment flow), privacy settings controls, notification settings controls, Logout control.
• States: Loading (while preferences resolve), success (current values shown), error (recoverable message with retry), empty (no preferences set yet, showing defaults). Logout ends the session and returns to the public entry.

3. Functional Requirements

FR-1 — Frontend foundation and navigation (explicit). As a Scam Checker, I should be able to use a professional mobile-first web application that delivers only the frontend foundation and navigation, so that later stages can extend it cleanly.

• Trigger/input: Opening the application.
• Observable result: All specified screens render and all navigation links work.
• Access state: Public entry reachable anonymously; protected destinations require a verified session.
• Failure/recovery: If a route fails to render, a recoverable error state is shown with a path back to a working destination.
• Continuation: The user proceeds into the checking journey.
• Provenance: explicit.

FR-2 — Brand identity (explicit). As a Scam Checker, I should see the ScamShield name and the tagline "Know before you trust." presented in a modern, trustworthy, professional cybersecurity/fintech style, so that the product reads as a serious security tool.

• Trigger/input: Viewing the Landing/Home screen.
• Observable result: Logo/name and tagline are visible with strong readability and accessible contrast.
• Access state: Public.
• Failure/recovery: Not applicable to static brand content.
• Continuation: The user reads the short explanation and chooses a next action.
• Provenance: explicit.

FR-3 — Landing/Home screen content (explicit). As a Scam Checker, I should see the short explanation "Check suspicious messages, screenshots, and links before you act.", a primary button "Check for a Scam", and a secondary button "How It Works", so that I understand the product and can begin.

• Trigger/input: Viewing the Landing/Home screen.
• Observable result: Explanation text and both buttons are present and operable.
• Access state: Public.
• Failure/recovery: If the "How It Works" content is unavailable, the control remains present without fabricated content.
• Continuation: "Check for a Scam" routes into the checking journey; "How It Works" presents explanatory content.
• Provenance: explicit.

FR-4 — Dashboard checking options (explicit). As a Scam Checker, I should see three main checking options — Check a Message, Check a Screenshot, and Check a Link — so that I can choose the right check.

• Trigger/input: Opening the Dashboard.
• Observable result: Three check tiles are presented in a 1-column → 3-column grid.
• Access state: Requires a verified session.
• Failure/recovery: If tiles fail to render, a recoverable error state with retry is shown.
• Continuation: Selecting a tile opens the corresponding checking workspace.
• Provenance: explicit.

FR-5 — Dashboard Recent Checks (explicit). As a Returning User Reviewing History, I should see Recent Checks on the Dashboard as a ruled data table, so that I can return to a prior check.

• Trigger/input: Opening the Dashboard.
• Observable result: Ruled rows with a left tier chip, truncated content preview, and right-aligned tabular timestamp.
• Access state: Requires a verified session.
• Failure/recovery: On failure, a recoverable error message with retry is shown.
• Continuation: Selecting a row opens that check's results structure.
• Provenance: explicit.

FR-6 — Dashboard Protection Status (explicit). As a Scam Checker, I should see a Protection Status panel with a circular gauge, so that I can read my protection state at a glance.

• Trigger/input: Opening the Dashboard.
• Observable result: A full-width Protection Status panel with a circular gauge.
• Access state: Requires a verified session.
• Failure/recovery: If status cannot resolve, the panel shows a recoverable state rather than an invented value.
• Continuation: The user proceeds to a check.
• Provenance: explicit.

FR-7 — Dashboard Upgrade to Premium section (explicit). As a Scam Checker, I should see an Upgrade to Premium section as a bordered inset band, so that I am aware of the future premium offering.

• Trigger/input: Opening the Dashboard.
• Observable result: A bordered inset band presenting the premium section.
• Access state: Requires a verified session.
• Failure/recovery: Not applicable to presentational content.
• Continuation: No payment or subscription action occurs in this stage.
• Provenance: explicit.

FR-8 — Check Message workspace (explicit). As a Scam Checker, I should be able to paste a suspicious message into a large text input area with the placeholder "Paste a suspicious message here..." and press "Analyze Message", so that I can submit a message for future analysis.

• Trigger/input: Text entered into the large textarea; "Analyze Message" pressed.
• Observable result: A clear placeholder indicates the analysis engine will be connected in a later development stage; no real AI analysis is performed.
• Access state: Requires a verified session.
• Failure/recovery: If submission fails, a recoverable error message with retry is shown.
• Continuation: The user can revise the text or move to another check.
• Provenance: explicit.

FR-9 — Check Screenshot workspace (explicit). As a Scam Checker, I should be able to upload an image via an upload button or drag-and-drop area, preview the uploaded image, and press "Analyze Screenshot", so that I can submit a screenshot for future analysis.

• Trigger/input: Image selected via upload or dropped onto the dropzone; "Analyze Screenshot" pressed.
• Observable result: The uploaded image is previewed; a clear placeholder indicates analysis will be connected later; no OCR or AI is implemented.
• Access state: Requires a verified session.
• Failure/recovery: Unsupported files or failed uploads produce a recoverable error with guidance.
• Continuation: The user can replace the image or move to another check.
• Provenance: explicit.

FR-10 — Check Link workspace (explicit). As a Scam Checker, I should be able to enter a URL and press "Check Link", so that I can submit a link for future analysis.

• Trigger/input: URL entered into the input; "Check Link" pressed.
• Observable result: A clear placeholder indicates real URL analysis is not yet implemented.
• Access state: Requires a verified session.
• Failure/recovery: Invalid URL format or failed submission produces a recoverable error with guidance.
• Continuation: The user can correct the URL or move to another check.
• Provenance: explicit.

FR-11 — Results screen structure (explicit). As a Scam Checker, I should see a Results screen UI structure reserved for risk level, risk score, warning indicators, explanation, recommended action, and a Report Scam button, so that results can be displayed once analysis is connected.

• Trigger/input: Arriving at the Results screen from a check.
• Observable result: The reserved structure is visible with no fabricated analysis results.
• Access state: Requires a verified session.
• Failure/recovery: If the structure fails to render, a recoverable error state is shown.
• Continuation: The user returns to the originating check or Dashboard.
• Provenance: explicit.

FR-12 — Profile/Settings content (explicit). As a Returning User Reviewing History, I should see account information, subscription status, privacy settings, notification settings, and Logout, so that I can review my account and adjust preferences.

• Trigger/input: Opening Profile/Settings.
• Observable result: All five sections are present; privacy and notification settings are adjustable; Logout ends the session.
• Access state: Requires a verified session.
• Failure/recovery: If preferences fail to load or save, a recoverable error with retry is shown.
• Continuation: The user returns to the Dashboard or logs out to the public entry.
• Provenance: explicit.

FR-13 — Bottom navigation (explicit). As a Scam Checker, I should have a simple mobile-friendly bottom navigation with Home, Check, History, and Profile, so that I can move between destinations.

• Trigger/input: Tapping a navigation item.
• Observable result: The active item is indicated with a sliding amber pill; the destination opens.
• Access state: Public items reachable; protected destinations require a verified session.
• Failure/recovery: If a destination fails to load, a recoverable error state is shown.
• Continuation: The user continues within the chosen destination.
• Provenance: explicit.

FR-14 — Responsive desktop layout (explicit). As a Scam Checker, I should be able to use the application on desktop, so that the experience is not limited to mobile.

• Trigger/input: Viewing at desktop widths.
• Observable result: The bottom navigation becomes a left rail at ≥1024px with the same sliding indicator; content is constrained to a max-width of 1120px.
• Access state: Same as mobile.
• Failure/recovery: Not applicable to layout adaptation.
• Continuation: The user continues the same journey.
• Provenance: explicit.

FR-15 — Self-service enrollment (required_inference). As a Scam Checker, I should be able to create an account through Sign Up before first protected use, so that my checks and preferences persist to me.

• Trigger/input: Choosing Sign Up from the public entry.
• Observable result: An account is established and a verified session begins.
• Access state: Sign Up is anonymously reachable.
• Failure/recovery: Validation or submission failures show recoverable guidance.
• Continuation: The user enters the protected experience.
• Provenance: required_inference.

FR-16 — Returning verification (required_inference). As a Returning User Reviewing History, I should be able to verify my identity through Login before accessing protected checks, history, dashboard, and settings, so that I can resume my prior state.

• Trigger/input: Choosing Login from the public entry.
• Observable result: A verified session is established and the intended protected destination opens.
• Access state: Login is anonymously reachable; protected destinations require the verified session.
• Failure/recovery: Invalid credentials show a recoverable error with guidance.
• Continuation: The user resumes their prior work.
• Provenance: required_inference.

FR-17 — No fabricated analysis (explicit). As a Scam Checker, I should never see fake scam detection results, so that I am not misled about the product's current capability.

• Trigger/input: Any interaction with a checking workspace or the Results screen.
• Observable result: Only clearly labeled placeholders appear; no invented risk levels, scores, or verdicts.
• Access state: Applies wherever checks or results are shown.
• Failure/recovery: Not applicable — this is a prohibition.
• Continuation: The user understands analysis will be connected later.
• Provenance: explicit.

FR-18 — Non-guaranteeing language (explicit). As a Scam Checker, I should see language such as "Low Risk", "Suspicious", or "High Risk" rather than any claim that something is or is not a scam, so that I am never given a false guarantee of safety.

• Trigger/input: Any risk-related copy or tier label.
• Observable result: Tier language is used; no guarantee of safety is asserted.
• Access state: Applies wherever risk language appears.
• Failure/recovery: Not applicable — this is a prohibition.
• Continuation: The user interprets results with appropriate caution.
• Provenance: explicit.

FR-19 — Security and privacy constraints (explicit). As a Scam Checker, I should be confident that API keys are not exposed in frontend code and that unnecessary personal information is not collected, so that my use of the product is safe.

• Trigger/input: Any use of the application.
• Observable result: No API keys appear in frontend code; only necessary information is collected.
• Access state: Applies throughout.
• Failure/recovery: Not applicable — these are prohibitions.
• Continuation: The user continues with confidence.
• Provenance: explicit.

FR-20 — Component architecture and states (explicit). As a Scam Checker, I should experience a clean, component-based, reusable interface with proper loading, error, and empty states and accessible controls, so that the product feels polished and usable.

• Trigger/input: Any interaction.
• Observable result: Reusable components render consistent loading, error, and empty states; buttons, labels, and form controls are accessible.
• Access state: Applies throughout.
• Failure/recovery: Errors are recoverable with clear guidance.
• Continuation: The user continues without dead ends.
• Provenance: explicit.

4. User Personas

Scam Checker

The Scam Checker is the primary end user: an ordinary adult who has received something suspicious — a text at 11pm, a link that feels wrong, a screenshot a relative forwarded — and wants to know whether it is risky before acting. They are not a security analyst; they want a tool that reads as engineered, exact, and quietly trustworthy, with zero playful energy.

• Product context: Arrives from the public Landing/Home screen, reads the tagline and short explanation, and begins the checking journey.
• Primary goal: Turn a vague "this feels off" into a graded, defensible read on a suspicious message, screenshot, or link.
• Distinct accepted responsibilities: Choosing the correct check type on the Dashboard; submitting content in the Check Message, Check Screenshot, or Check Link workspace; viewing the Results screen structure with risk level, risk score, warning indicators, explanation, and recommended action.
• Relevant inputs or decisions: The suspicious message text, the screenshot image, or the URL; the decision of which check type to use; the decision to submit.
• Interactions with other accepted participants: Establishes identity through Sign Up on first use and verifies through Login on return; the Returning User Reviewing History is the same person in a later session.
• Observable success: They can submit suspicious content and see a clearly labeled placeholder that analysis will be connected later, without any fake results.

Returning User Reviewing History

The Returning User Reviewing History is the same adult returning to the product after prior use. Their work is different from first-time checking: they are not starting a new investigation but resuming, reviewing, and managing.

• Product context: Returns to the application and verifies through Login to reach protected destinations.
• Primary goal: Revisit prior checks and manage account and privacy preferences.
• Distinct accepted responsibilities: Reviewing prior checks via the History destination and Recent Checks on the Dashboard; managing account information, subscription status, privacy settings, notification settings, and logout on Profile/Settings.
• Relevant inputs or decisions: Which prior check to reopen; which privacy and notification preferences to adjust; whether to log out.
• Interactions with other accepted participants: The Scam Checker is the same person at an earlier point; both share the same account and history.
• Observable success: They can navigate back to prior checks and adjust their account and privacy preferences.

5. Core User Flows

Flow 1 — First-time Scam Checker: understand the product and begin a check

1. The Scam Checker opens ScamShield and lands on the Landing/Home screen (public, no session required).
2. They see the ScamShield logo/name, the tagline "Know before you trust.", and the short explanation "Check suspicious messages, screenshots, and links before you act."
3. They press the primary button "Check for a Scam" (or the secondary "How It Works" to read more first).
4. Because protected destinations require a verified session, they are routed to Sign Up (anonymously reachable) to establish identity on first use.
5. They complete the minimum required enrollment information and submit.
6. Observable result: A verified session begins and they arrive at the Dashboard.
7. Failure/recovery: If enrollment validation or submission fails, an inline recoverable error with guidance is shown and they can correct and resubmit.
8. Continuation: They proceed to choose a check type.

Flow 2 — Scam Checker: check a suspicious message

1. From the Dashboard, the Scam Checker selects Check a Message (or reaches it via the Check destination in the bottom navigation).
2. They arrive at the Check Message screen and see a large text input area with the placeholder "Paste a suspicious message here...".
3. They paste the suspicious message text.
4. They press "Analyze Message".
5. Observable result: The button shows a rotating bezel loading treatment, then a clear placeholder appears indicating the analysis engine will be connected in a later development stage. No real AI analysis is performed and no result is fabricated.
6. Failure/recovery: If submission fails, a recoverable error message with retry is shown; the entered text is preserved.
7. Continuation: They can revise the text, return to the Check destination, or open the Results screen structure.

Flow 3 — Scam Checker: check a suspicious screenshot

1. From the Dashboard, the Scam Checker selects Check a Screenshot (or reaches it via the Check destination).
2. They arrive at the Check Screenshot screen and see an upload image button and a drag-and-drop area.
3. They upload an image via the button or drag and drop it onto the dropzone.
4. Observable result: The uploaded image is previewed.
5. They press "Analyze Screenshot".
6. Observable result: A clear placeholder indicates analysis will be connected later. No OCR or AI is implemented and no result is fabricated.
7. Failure/recovery: If the file is unsupported or the upload fails, a recoverable error with guidance is shown and they can choose another image.
8. Continuation: They can replace the image, return to the Check destination, or open the Results screen structure.

Flow 4 — Scam Checker: check a suspicious link

1. From the Dashboard, the Scam Checker selects Check a Link (or reaches it via the Check destination).
2. They arrive at the Check Link screen and see a URL input.
3. They enter the suspicious URL.
4. They press "Check Link".
5. Observable result: A clear placeholder indicates real URL analysis is not yet implemented. No result is fabricated.
6. Failure/recovery: If the URL format is invalid or submission fails, a recoverable error with guidance is shown and they can correct the input.
7. Continuation: They can correct the URL, return to the Check destination, or open the Results screen structure.

Flow 5 — Scam Checker: view the reserved Results structure

1. After submitting a check, the Scam Checker arrives at the Results screen.
2. Observable result: They see the reserved UI structure for risk level, risk score, warning indicators, explanation, recommended action, and a Report Scam button — with no fabricated analysis results and an explicit notice that analysis is not yet connected.
3. Failure/recovery: If the structure fails to render, a recoverable error state is shown with a path back.
4. Continuation: They return to the originating check or the Dashboard.

Flow 6 — Returning User Reviewing History: resume and review prior checks

1. The Returning User Reviewing History opens ScamShield and chooses Login from the public entry (anonymously reachable).
2. They submit their credentials.
3. Observable result: A verified session begins and they arrive at the Dashboard (or the intended protected destination).
4. Failure/recovery: If credentials are invalid, a recoverable error with guidance is shown and they can retry or navigate to Sign Up.
5. They review Recent Checks on the Dashboard — a ruled data table with a left tier chip, truncated content preview, and right-aligned tabular timestamp.
6. They open the History destination via the bottom navigation to see their prior checks.
7. Observable result: Prior checks are listed; if none exist, the empty state shows a single centered shield pictogram plus one line of muted copy.
8. They select a prior check to open its Results screen structure.
9. Continuation: They return to the Dashboard or proceed to a new check.

Flow 7 — Returning User Reviewing History: manage account and preferences

1. From the Dashboard, the Returning User Reviewing History opens Profile/Settings via the bottom navigation.
2. Observable result: They see account information, subscription status, privacy settings, notification settings, and Logout.
3. They adjust their privacy settings and notification settings.
4. Observable result: The adjusted preferences are reflected in the interface.
5. Failure/recovery: If preferences fail to load or save, a recoverable error with retry is shown.
6. They may review their subscription status (presentational only — no payment flow occurs in this stage).
7. They choose Logout.
8. Observable result: The session ends and they return to the public entry.
9. Continuation: They can log in again or continue browsing the public Landing/Home screen.

Flow 8 — Scam Checker: navigate across the product

1. From any destination, the Scam Checker uses the bottom navigation — Home, Check, History, Profile.
2. Observable result: The active item is indicated by a sliding amber pill, and the chosen destination opens.
3. On desktop (≥1024px), the bottom navigation becomes a left rail with the same sliding indicator, and content is constrained to a max-width of 1120px.
4. Failure/recovery: If a destination fails to load, a recoverable error state is shown with a path back to a working destination.
5. Continuation: The user continues within the chosen destination.

6. Visuals, Colors, and Theme

The creative direction is "Precision instrument calm for a fraud-detection shield", with MARQ by Garmin as the muse. The emotional register is alert but calm, authoritative without menace — instrument-panel seriousness rather than gaming RGB. The product lives on graphite; there is no blue anywhere and no decorative gradients.

Color tokens (dark mode)

• Amber #E8A33D is the single instrument accent: primary CTA, active nav indicator, focus rings, needle marks, one highlighted metric.
• Teal #3FBFA8 is reserved strictly for the "Low Risk" / protected state and for verified/privacy confirmations; it never appears as decoration.
• Muted #8A929B is used for micro-labels, units, timestamps, and secondary copy.
• Risk tiers are coded as instrument accents: Low Risk = teal #3FBFA8, Suspicious = amber #E8A33D, High Risk = signal red #E0523F (used only inside the risk gauge, never as a page accent).
• The only permitted gradient is a subtle top-down luminance falloff on the gauge bezel.

Typography

• Headings: Saira Condensed, weights 600–700; uppercase for section and screen titles with 0.04em tracking; sentence case for the hero headline at very large scale with tight 0.96 leading.
• Numerals: Always tabular, set in Saira Condensed 600 — risk scores, counts, and timestamps read as instrument output.
• Micro-labels: Uppercase Barlow 600 at 11–12px with 0.12em tracking.
• Body: Barlow.
• Scale: 1.25 modular on a 4/8pt rhythm — hero clamp(44px, 9vw, 96px) / screen title clamp(26px, 5vw, 40px) / section title 20px / body 16px / label 12px / micro 11px; line-height 1.05 for display, 1.55 for body.

Shape language

Instrument geometry: circular gauges and bezels, ruled 1px data rows, chamfered 2px-cornered panels (near-sharp, not pill), capsule only for the primary CTA and the bottom-nav active pill. Concentric ring motifs for the risk gauge and the shield mark; hairline dividers between every data row; small tick marks along panel edges suggesting a dial scale. Radii: 2px (panels), 999px (CTA + active nav), 12px (upload dropzone).

Layout

Mobile-first single column with a fixed bottom nav (Home / Check / History / Profile) that becomes a left rail at ≥1024px; content max-width 1120px. The Dashboard is a ruled instrument stack: a full-width Protection Status panel with a circular gauge, then three check tiles as a 1-column → 3-column grid, then Recent Checks as a ruled table (not cards), then the Premium block as a bordered inset band. Every screen opens with a condensed uppercase eyebrow, a large title, and a hairline rule. Numbers align right in tabular columns.

Imagery

No stock people, no illustration for its own sake. The visual language is engineered texture and macro material: brushed titanium grain, sapphire-glass edge highlights, topographic contour lines as a faint background layer, and a single macro shot of a phone screen at an angle with a blurred suspicious message (used as an abstract, unreadable texture — never as a fake result). Diagrams are schematic: a shield outline, a link-chain pictogram, and a message-bubble pictogram, drawn in 1.5px stroke at 24px on a 24px grid, monochrome in muted with amber on active.

7. Signature Design Concept

The public entry is a full-bleed graphite ground (#101215) with a faint topographic contour layer at 4% opacity. It is left-aligned, not centered:

• A condensed uppercase eyebrow reads "SCAM & FRAUD DETECTION".
• The tagline "Know before you trust." is set in Saira Condensed 600 at clamp(44px, 9vw, 96px), stacked across three lines so the word "trust." lands alone and spans nearly the full viewport width.
• Directly beneath it, a hairline rule with three tick-marked segments.
• Then the sentence "Check suspicious messages, screenshots, and links before you act." in Barlow 16px at 60% width.
• Beneath that, one amber capsule CTA "Check for a Scam" and a text-link secondary "How It Works" with a 1px underline offset.

The dominant visual element is an oversized circular instrument gauge anchored to the right edge on desktop (bleeding off the viewport) and reduced to a 180px arc behind the headline block on mobile. Its bezel is brushed-metal grey with a single amber needle at rest and the label "ANALYSIS ENGINE — NOT YET CONNECTED" in 11px uppercase muted beneath it. There is no gradient blob, no centered stack, and no blue button.

This concept recomposes only accepted content, states, and controls — the brand name, tagline, explanation, both CTAs, and the honest "not yet connected" status. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The oversized circular instrument gauge with a brushed bezel and a single amber needle, anchored to the right edge on desktop and reduced to a 180px arc behind the headline on mobile.
• Input → transformation → outcome thesis: On load, the gauge needle sweeps from 12 o'clock to its resting position and the score counts up once, resolving into the resting instrument state labeled "ANALYSIS ENGINE — NOT YET CONNECTED" — expressing measurement under pressure without ever implying a fabricated result.
• Motion vocabulary: Precise and mechanical — 160–220ms ease-out on state changes, no bounce; a slow rotating bezel ring for loading states; a 120ms slide for the nav active indicator; a 12px rise with opacity for scroll reveals, once per panel.
• Composed first frame: Graphite ground with the faint topographic contour layer; the eyebrow, three-line tagline with "trust." alone, hairline rule with three tick-marked segments, the explanation sentence, the amber capsule CTA, and the underlined secondary link — with the gauge already present at its resting position.
• Reduced-motion state: All decorative motion stops under prefers-reduced-motion, leaving the gauge at its resting value and the content fully readable.

9. Non-Functional Requirements

• NFR-1 — Mobile-first responsiveness (explicit). The application is mobile-first and responsive on desktop; the bottom navigation becomes a left rail at ≥1024px with the same sliding indicator, and content is constrained to a max-width of 1120px. Rationale: the product is used in moments of anxiety on a phone, but must remain usable on desktop.
• NFR-2 — Readability and accessible contrast (explicit). The interface uses strong readability and accessible contrast; ink-light text #F2F0EB on #101215 yields approximately 15:1 contrast. Rationale: a serious security product must be legible under stress.
• NFR-3 — Accessible controls (explicit). Buttons, labels, and form controls are accessible, with visible focus rings in amber. Rationale: explicit technical requirement.
• NFR-4 — Component-based architecture (explicit). The codebase uses a clean, component-based architecture with reusable frontend components. Rationale: explicit technical requirement and ease of later extension.
• NFR-5 — Loading, error, and empty states (explicit). Proper loading, error, and empty states are implemented throughout. Rationale: explicit technical requirement; prevents dead ends.
• NFR-6 — No exposed API keys (explicit). API keys are never exposed in frontend code. Rationale: explicit security constraint.
• NFR-7 — Minimal data collection (explicit). No unnecessary personal information is collected. Rationale: explicit privacy constraint.
• NFR-8 — No safety guarantees (explicit). The application never claims it can guarantee that something is safe; future risk language uses "Low Risk", "Suspicious", or "High Risk". Rationale: explicit constraint protecting users from false assurance.
• NFR-9 — Runs successfully with working navigation (explicit). The application runs successfully and all navigation links work. Rationale: explicit acceptance requirement.
• NFR-10 — Readable text and controls stay whole (direction). Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...)) to fit, with no other element covering them. Imagery, decoration, and motion may be cropped, bled, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control. Rationale: accessibility and the direction's own precedence rule.
• NFR-11 — Reduced motion (direction). All decorative motion stops under prefers-reduced-motion, leaving the gauge at its resting value. Rationale: accessibility.

10. Tech Stack

• Frontend: React (component-based, reusable components), mobile-first responsive layout.
• Styling: CSS with the token set defined in Section 6 (graphite ground, amber instrument accent, teal protected state, Saira Condensed headings, Barlow body).
• Backend integration: Not connected in this stage. No AI API, no OCR, no URL analysis, and no payment/subscription integration. The architecture is kept modular and easy to extend so these can be connected in a later development stage.
• Storage: Not required for this frontend foundation beyond what is needed to hold session and preference state for the accepted identity and settings journeys.
• Deployment: Standard web application delivery; no Kubernetes requirement is established by the source.

11. Assumptions and Constraints

Constraints (binding)

• Do not build the entire application yet; for this first stage, build only the frontend foundation and navigation.
• Do not connect any AI API yet.
• Do not add payment/subscription functionality yet.
• Do not create fake scam detection results.
• The "Analyze Message" button must NOT perform real AI analysis; a clear placeholder must indicate the analysis engine will be connected in a later development stage.
• Do not implement OCR or AI for the Check Screenshot screen yet.
• Do not implement real URL analysis for the Check Link screen yet.
• The Results screen is UI structure only; do not generate fake analysis results.
• Do not expose API keys in frontend code.
• Do not collect unnecessary personal information.
• Do not claim that the application can guarantee that something is safe.
• The future system should use language such as "Low Risk", "Suspicious", or "High Risk" rather than guaranteeing that a message is or is not a scam.
• Do not add unnecessary features that were not requested.
• The generic indigo/blue-on-white SaaS template is forbidden for this project.

Assumptions

• [Assumption — required_inference] Application-owned identity is established through Sign Up on first use and verified through Login on return, because checks, history, and preferences must persist to the correct person and be resumable. Both entry surfaces are anonymously reachable; protected destinations require a verified session.
• [Assumption — required_inference] The "Check" bottom-navigation destination routes users to the message, screenshot, and link checking workflows, and the "History" destination provides a revisitable view of prior checks consistent with Recent Checks on the Dashboard.
• [Assumption — required_inference] Analysis, OCR, and URL-detection backends remain unconnected in this frontend foundation, with no fabricated results.
• [Assumption] The "Upgrade to Premium" section and the subscription status on Profile/Settings are presentational in this stage and do not process payments or change entitlements.
• [Assumption] The "How It Works" secondary button presents explanatory content; if that content is not yet authored, the control remains present without fabricated content.

12. Glossary

• ScamShield: The product name; an AI-powered scam and fraud detection platform.
• Scam Checker: The primary end user who submits suspicious content to learn whether it is risky before acting.
• Returning User Reviewing History: The same adult returning to review prior checks and manage account and privacy preferences.
• Check: A submission of a suspicious message, screenshot, or link for future analysis.
• Check Message / Check Screenshot / Check Link: The three checking workspaces for the respective content types.
• Results screen: The reserved UI structure that will eventually display risk level, risk score, warning indicators, explanation, recommended action, and a Report Scam button.
• Risk tier: The graded read expressed as "Low Risk" (teal), "Suspicious" (amber), or "High Risk" (signal red, gauge only) — never a guarantee that something is or is not a scam.
• Protection Status: The Dashboard panel with a circular gauge summarizing the user's protection state.
• Recent Checks: The ruled data table on the Dashboard listing prior checks.
• Analysis engine: The future backend that will perform scam and fraud detection; not connected in this stage.
• Instrument gauge: The circular dial motif used for the hero, Protection Status, and the risk score display.