Purpose: Defines DeepFeel™ on two levels — as a wellness lifestyle brand and as a digital platform — and clarifies how the two connect.

DeepFeel™ is one master brand expressed through two layers. The brand defines what DeepFeel™ stands for — a wellness lifestyle built on "Deep in Feeling, Light in Living." The platform is how the brand reaches users — a mobile app, also named DeepFeel™, that connects every product, routine, reward, and collectible into one ecosystem. Same name. Same identity. Two layers of the same thing.

1.1.1 The Brand

Brand Tagline

Deep in Feeling, Light in Living.

Core Ecosystem Principles

1.1.2 The Engagement Layer — Dippie

Part of DeepFeel™. Dippie is the emotional and gamified engagement layer of the DeepFeel™ ecosystem — the collectible companion system that turns ordinary product ownership into a memorable, shareable, and repeatable journey. It is a platform-level brand asset, not a separate product, which is why it lives here inside the DeepFeel™ definition.

Dippie Definition

Collectible Companion System

Meet Dippie — DeepFeel™'s signature collectible companion characters.

Dippie is the collectible companion character system of the DeepFeel™ ecosystem — DeepFeel™'s signature characters that users collect through every product scan. Unlike a static mascot, Dippie is a living engagement layer designed to give every QR scan, product activation, and routine completion an emotional payoff.

Personality & mood

Mystery reveals

Earned via QR scan

Connective Role

Dippie is not a separate product. It is the emotional connective tissue that ties the DeepFeel™ platform, AcuSmart™ product module, loyalty wallet, referral system, and future product modules together into one cohesive experience.

The Role Dippie Plays

Across the user journey, Dippie acts as:

Collectible Stamp · 7 Impressions

Meet the Dippie cast

Each Dippie carries a distinct mood and meaning. Users collect them through mystery reveals after scanning official DeepFeel™ products — and the more they collect, the more emotional and visual variety the Passport gains.

01

01

Hero Wink

Confidence & charm

02

02

Seeking

Curiosity & discovery

03

03

Pressing

Focus & precision

04

04

Relieved

Comfort & release

05

05

Sleepy

Wind down & rest

06

06

Happy

Joy & reward

07

Rare

07

Secret Golden

Legendary & lucky

The 6 characters above form the base Dippie cast. A Golden Dippie exists as a rare mystery variant — not a 7th character, but a special golden version of any base Dippie, earned through low-probability reveals. More Dippie characters and campaign-specific Dippies will be added in future seasons — collect them all in your Dippie Passport.

Dippie System Mechanics

These are the system components that bring the role to life — the gameplay pieces that make Dippie collectable, shareable, and rewarding:

Dippie Vision

Everything above — the mystery reveals, the stamps, the Passport, the Golden Dippie, the milestones — is in service of one larger goal:

Purpose: Defines AcuSmart™ as the first product module under the DeepFeel™ platform and clarifies its two integrated components — the physical product and the digital companion experience.

1.2.1 AcuSmart™ Relief

Physical Product · The Bottle

A cooling herbal liniment, delivered with surgical precision.

AcuSmart™ Relief is a physical cooling herbal relief liniment formulated for external topical application — paired with a precision-engineered applicator that turns every drop into a targeted self-care ritual.

01

The Liniment

Cooling herbal formula for external topical application

02

The Applicator

Dippie MagRoller™ — 360° Precision Magnetic Bead

03

The Motion

Dispenses and rolls onto acupoints in one motion

AcuSmart™ Relief

Precision Relief System

Dippie MagRoller™

360° Precision Magnetic Bead

Cooling Liniment

Herbal formula

QR Activation

Bottle label

AcuSmart™ Relief · Precision Relief System

Where it's designed to be applied

AcuSmart™ Relief is designed for application across 13 common discomfort areas — see Section 2.4 for the full list.

The physical product experience

The role of AcuSmart™ Relief is to provide the hands-on side of self-care — a clear five-step ritual the user follows in the moment of use:

1.2.2 AcuSmart™ Module (the in-app experience)

AcuSmart™ Module is the first product module inside the DeepFeel™ mobile app platform. It's the in-app companion to AcuSmart™ Relief — the part of the AcuSmart™ system that lives on the user's phone. The module helps users understand where to apply, how to roll, how long to follow a routine, and how to use the product safely.

The module ships with 14 module-specific services spanning product education, QR activation, routine guidance, the 67 Relief Modes framework, safety, feedback, FAQ, and module analytics. This subsection is a high-level definition only — the canonical feature list with MVP success definitions for every service lives in Section 4.3 (AcuSmart™ Module MVP Scope). If you need to know what the module must do at MVP, go to 4.3.

1.2.3 How AcuSmart™ Works

At a high level, AcuSmart™ joins the physical product (Relief Liniment + Dippie MagRoller™) with the in-app companion experience (the AcuSmart™ Module) through a single QR-activated journey. The user buys the product through any channel, scans the QR inside the DeepFeel™ app, and the app handles verification, Dippie reveal, points, and module activation — then guides the user through area selection, a timed relief routine, and feedback. Over time the user returns to collect more Dippies, repeat routines, redeem rewards, and refer friends.

For the canonical 11-step product loop the MVP must validate end-to-end, see Section 4.1: MVP Scope Principle — that section is the single source of truth for the loop. For the screen-by-screen breakdown of each step in the loop, see Section 4.5: MVP Scope by User Journey.

Purpose: Defines DeepFeel™'s role as the foundation platform layer that hosts every product module and that each module inherits — the layers it spans, its capabilities, and its long-term vision. The canonical platform scope and feature list live in Section 4.2; the detailed platform-vs-module split lives in Section 2.3.

DeepFeel™ is the platform layer of the ecosystem. Everything shared across products — identity, commerce access, collectibles, rewards, governance — lives here, so each new module inherits it instead of rebuilding it. The sub-parts below define the platform in full: the layers it spans, its capabilities, and the vision it serves.

1.3.1 The Platform

1.3.2 Platform Vision

Everything above — the platform's capabilities and global-by-default architecture — points to one north-star outcome:

The vision expressed as the end-to-end engagement loop every product follows:

1.3.3 The three layers

Purpose: Defines AcuSmart™'s role as the first product module that sits on top of the DeepFeel™ platform, and what the module owns versus what it inherits. The full AcuSmart™ definition is in Section 1.2; the module MVP scope is in Section 4.3.

AcuSmart™ is the first product module inside the DeepFeel™ platform — a connected Precision Relief System that pairs a physical product with an app-guided experience. Where DeepFeel™ owns the shared ecosystem (1.3), AcuSmart™ owns everything product-specific that sits on top of it.

The module owns 14 product-specific services spanning product education, QR activation, routine guidance, the 67 Relief Modes framework, safety, feedback, FAQ, and module analytics. The canonical list with MVP success definitions lives in Section 4.3.

What AcuSmart™ is made of

App ecosystem logic

Purpose: Names the user groups DeepFeel™ is built for, at a glance. Full persona profiles, use cases, problems, and required screens for each user type live in Section 5: User Persona & Use Case.

DeepFeel™ serves 10 distinct user types across the product lifecycle. They fall into four natural clusters:

Purpose: Names the two categories of problems DeepFeel™ exists to solve — customer problems (user friction with the product and ecosystem) and business problems (operational gaps that block growth) — and maps each one directly to its concrete solution. The complete problem-by-problem mapping with platform features, module features, and success metrics lives in Section 6: Problem-Solution Mapping.

DeepFeel™ solves two kinds of problems in parallel. On the customer side, users face real friction buying, using, and returning to the product — they don't know where to apply it, how to use the roller, whether the product is official, or what to do after purchase. On the business side, the brand faces operational gaps that no single product launch can fix on its own — anonymous buyers, weak repeat purchase, fragmented sales channels, and operations teams that depend on developers for every change.

Customer Problems (illustrated through AcuSmart™)

AcuSmart™ — the first product module — is where customer friction shows up most concretely. The quotes below are AcuSmart™-specific because that's the first shipped product, and represent a highlight subset of the broader user-problem mapping in Section 6.2 (Master Problem–Solution Table). Platform-level customer problems (account trust, reward clarity, referral confusion, support friction) are covered in the business problems table below and mapped in full detail across all 22 problems in Section 6.2.

AcuSmart™ closes the gap between buying a topical relief product and knowing how to use it correctly. Each user pain point maps to a specific app solution.

Business Problems

On the business side, DeepFeel™ closes operational gaps that prevent the brand from converting anonymous buyers, retaining loyalty, supporting every sales channel, and operating without constant developer dependency.

Purpose: Summarizes what the MVP must include at a glance — the minimum complete system needed to prove the product loop. The complete MVP scope (platform features, module features, priorities, screens, data objects, analytics, exclusions, acceptance criteria) lives in Section 4: MVP Scope.

The MVP focuses on one strong complete loop that the user travels end-to-end — from opening the app, through registration, QR scan, product verification, Dippie reveal, points earned, AcuSmart™ activation, guided routine, completion, and return engagement. The canonical 11-step MVP core loop is defined visually in Section 4.1: MVP Scope Principle — please reference that section as the single source of truth. Every MVP feature in this group exists to support that loop.

The MVP is built in two layers — a foundation layer (DeepFeel™ platform) that every product module inherits, and a module layer (AcuSmart™) that sits on top of it.

Purpose: Summarizes the first post-MVP phase at a glance. The complete phased plan (Phases 2—5) is the Post-MVP Roadmap in Section 4.11, which is the single source of truth.

The MVP (Phase 1, Sections 4.1—4.10) now ships the full 67 Relief Modes and the engagement loops once planned for Phase 2 (My Dippie Passport, completion gift reward, Duplicate Dippie Strategy, routine history, favorite modes, notification inbox, and CRM reminders). With those folded into launch, the first post-MVP phase — Phase 2 — More AcuSmart™ Depth — deepens the guided wellness experience and adds the first retail touchpoint: 8 items — 7 guidance features plus retail chain store locations.

Phase 2 — More AcuSmart™ Depth + Retail Locations (8 items)

Purpose: Outlines expansion beyond Phase 2 — the directional Phases 3—5 that grow DeepFeel™ across retail-partner operations, country rollout, and future product modules. The canonical plan lives in Section 4.11.

Beyond Phase 2's deeper guidance, DeepFeel™ grows across commerce, country reach, and new product modules. These are directional phases, sequenced after launch.

Purpose: Provides the canonical one-sentence description of DeepFeel™, plus the approved supporting lines for the platform, the first module, and the engagement layer. For positioning rules that govern how these are used, see Section 2.1.

Supporting lines

Purpose: The one-screen summary of what this document specifies — the DeepFeel™ platform, the AcuSmart™ first module, and the build principle that governs both. Every section that follows expands on this.

DeepFeel™ is one global mobile app ecosystem built for product education, QR-based activation, customer loyalty, Dippie collectible engagement, rewards, referrals, country-specific commerce access, and future product module expansion. It is designed as one global platform that hosts multiple product modules — with standardized points and rewards logic worldwide, country-specific stores and local e-commerce by currency, auto-applied country and language logic that users can adjust in Settings, CMS-managed content, developer-ready requirements, and operation-ready governance.

AcuSmart™ is the first product module under the DeepFeel™ platform — a connected Precision Relief System that pairs a physical cooling external-use relief liniment and the Dippie MagRoller™ precision applicator with an app-guided experience: QR-based product activation, Dippie collection, points earning, safety guidance, 67 guided relief modes, 67-second routine sessions, post-routine feedback, and repeat engagement.

This document specifies the DeepFeel™ platform foundation and the complete AcuSmart™ module so the MVP can be built, reviewed, translated, and operated at scale.

Purpose: States where DeepFeel™ is headed — the north-star vision, the principles that govern every decision, and the phased trajectory from MVP to full platform. Positioning rules that enforce this direction live in Section 2.1; the phased plan lives in Section 4.11.

DeepFeel™'s north-star vision — to be the global wellness platform available to anyone, anywhere — is defined in Section 1.3.2 (Platform Vision). This section translates that vision into the principles and phased trajectory that guide every product decision.

Direction principles

Trajectory

Purpose: Defines the strategic positioning of each layer in the DeepFeel™ ecosystem — what DeepFeel™ is as a platform, what AcuSmart™ is as a product module, and what Dippie is as an engagement brand asset. Every marketing, sales, retail, and content decision must align with these positions.

2.1.1 DeepFeel™ Positioning

For the full definition of DeepFeel™ as a brand and as a platform, see Section 1.1. This section defines the positioning rules — how every team (marketing, sales, retail, content, customer support, legal, PR) must describe DeepFeel™ to customers, partners, and stakeholders.

Approved Positioning Vocabulary

Positioning Rules Every Team Must Follow

For the complete list of capabilities the DeepFeel™ platform delivers (account, QR, Dippie, wallet, rewards, referral, CRM, admin/CMS, analytics, and more), see the App System Document (Section 7).

2.1.2 Global vs Localized Split

To keep the app simple and globally accessible, DeepFeel™ uses a strict split between global standardized systems and localized presentation layers.

2.1.3 AcuSmart™ Positioning

For the full definition of AcuSmart™ (physical product + digital module + how it works), see Section 1.2. This section focuses on the positioning rules every team — marketing, retail, content, packaging, customer support — must follow when describing AcuSmart™ to customers.

At a high level, AcuSmart™ should always be positioned as a guided self-care product experience — never as a medical treatment, disease cure, diagnostic tool, or replacement for medical advice. The detailed approved vocabulary, prohibited language, and full claims compliance rules every team must follow live in Section 2.6: AcuSmart™ Claims Positioning.

2.1.4 Dippie Positioning

Dippie is positioned as DeepFeel™'s emotional engagement layer — the collectible companion system that crosses every product module. For the full breakdown of Dippie's nine roles (mascot, guide, collectible stamp, emotional engagement layer, social sharing asset, repeat-purchase motivator, campaign character, loyalty engine, and connective tissue), see Section 1.1 → Dippie (The Role Dippie Plays).

For all customer-facing communication, Dippie should be presented as a collectible character system earned through product scans — never as a standalone product, a tradeable asset, or a financial instrument.

Purpose: Defines the full DeepFeel™ system architecture — the platform layer that powers all shared infrastructure, and the product module layer that houses AcuSmart™ and future product modules.

The architecture is organized in two clear layers. The Platform Layer provides shared infrastructure used by every product module — account, QR, loyalty, rewards, referral, notifications, support, admin, and analytics. The Product Module Layer houses product-specific experiences — starting with AcuSmart™ and designed to scale into future DeepFeel™ product modules. The diagram below shows the structural tree; the canonical feature lists with success definitions live in Section 4.2 (platform) and Section 4.3 (AcuSmart™ module).

DeepFeel™ Mobile App Ecosystem Platform (Global)
|
├── Platform Layer
|     ├── Country / Region Auto-Detect & Settings
|     ├── Language Auto-Apply & Settings
|     ├── Account / Login System (Global)
|     ├── User Profile / Me
|     ├── Product Catalogue
|     ├── QR Scan & Product Activation (Global)
|     ├── Product Verification
|     ├── Dippie Collectible System (Global)
|     ├── Loyalty Points Wallet (Global)
|     ├── Rewards Redemption
|     ├── One-Tier Referral (Global)
|     ├── Notifications / CRM
|     ├── Help & Support
|     ├── Privacy / Consent
|     ├── Admin / CMS
|     ├── Analytics Dashboard
|     └── Governance / Operations Controls
|
└── Product Module Layer
      |
      ├── AcuSmart™
      |     ├── Relief Liniment Product Education
      |     ├── Precision Roller Usage Guide
      |     ├── QR-Based Activation
      |     ├── Guided Relief Routines
      |     ├── 67 Relief Modes
      |     ├── Discomfort Area Selection
      |     ├── Safety Guidance
      |     ├── Dippie Unlock / Stamp Logic
      |     ├── Routine Feedback
      |     └── AcuSmart-Specific Analytics
      |
      └── Future Product Modules

Purpose: Defines the complete scope each layer owns — DeepFeel™ owns the shared app ecosystem; AcuSmart™ owns the product-specific experience. This section enumerates every feature each layer is responsible for, the navigation each one exposes, the user journey through both layers, the AcuSmart™ module's user flow and content structures, and the safety + claims positioning that governs all AcuSmart™ communication.

At a Glance: What Belongs to AcuSmart™ vs DeepFeel™

Before diving into the detailed feature lists, here's the quick comparison — who owns what across 11 key areas:

Ownership Inventory: What Each Layer Owns

The complete responsibility split. The platform owns everything shared across products; the module owns everything specific to the AcuSmart™ product experience.

The subsections below break each area down in detail — starting with the full platform and module feature lists.

2.3.1 DeepFeel™ Platform Scope

DeepFeel™ owns the shared app ecosystem — the foundation layer every product module inherits. For the full platform definition, see Section 1.3.1. The complete DeepFeel™ platform feature list with MVP success definitions lives in Section 4.2 (DeepFeel™ Platform MVP Scope) — that table is the canonical reference for every platform feature the system must deliver.

At an architectural level, the platform owns 19 shared services spanning country & language, account & consent, home, product catalogue, QR scan & verification, Dippie Passport, wallet, rewards, referral, notifications, profile, support, admin/CMS, analytics, and governance. The canonical row-by-row list — with MVP success definitions for each service — lives in Section 4.2 (DeepFeel™ Platform MVP Scope).

2.3.2 AcuSmart™ Module Scope

AcuSmart™ owns the product-specific experience inside DeepFeel™ — what users do once they've activated the AcuSmart™ module. For the full AcuSmart™ definition (Relief + Module + How It Works), see Section 1.2. The complete AcuSmart™ module feature list with MVP success definitions lives in Section 4.3 (AcuSmart™ Module MVP Scope) — that table is the canonical reference for every module feature the system must deliver.

At an architectural level, the AcuSmart™ module owns 14 product-specific services covering product education, QR activation, routine guidance, the 67 Relief Modes framework, safety, feedback, FAQ, and module analytics. The canonical row-by-row list — with MVP success definitions for each service — lives in Section 4.3 (AcuSmart™ Module MVP Scope).

2.3.3 App Ecosystem Logic

The correct logic is:

DeepFeel™ App
= Main ecosystem platform

AcuSmart™
= First product module inside DeepFeel™

AcuSmart™ Bottle
= Physical product — Relief Liniment + Dippie MagRoller in one

Relief Liniment
= Cooling herbal liquid inside the bottle

Dippie MagRoller
= 360° Precision Magnetic Bead on top of the bottle

DeepFeel™ App AcuSmart Module
= Digital companion experience

2.3.4 Platform vs Product Module Navigation

Each layer has its own navigation surface. The DeepFeel™ app exposes the ecosystem-level navigation; AcuSmart™ exposes the product-module navigation inside the app. The list below shows the full navigation surface for each layer — not the MVP bottom-tab subset, which is defined in Section 15.3.

Home
Shop
Services
Rewards
Me

AcuSmart™ Home
Product Guide
Discomfort Area
Relief Modes
Routine Detail
Safety Guide
Routine Session
Routine Complete
Feedback
History (Phase 2)

2.3.5 AcuSmart™ User Flow

The AcuSmart™ user experience crosses both layers — the DeepFeel™ platform handles app entry, country/language, registration, QR scan, Dippie reveal, and loyalty actions; the AcuSmart™ module handles product activation, discomfort selection, routine guidance, application, and feedback. For the canonical end-to-end purchase-to-engagement flow, see Section 1.2.3: How AcuSmart™ Works.

2.3.6 Module Status States

Every product module on the DeepFeel™ platform exists in one of four states. The platform decides which state to show based on the user's activation status and country / region. This logic is defined once at the platform level so every future module behaves consistently; the canonical per-screen requirements and copy live in the linked sections.

Purpose: Defines the two parallel content systems AcuSmart™ uses for routine entry — user-friendly discomfort areas (what users feel) and structured relief modes (the 67 guided routines).

Discomfort Areas

Instead of only "acupoints," AcuSmart™ is structured around user-understandable discomfort areas:

Neck
Shoulders
Upper Back
Lower Back
Joints
Muscles
Arms
Legs
Knees
Wrists
Ankles
Post-activity tension
Daily body stiffness

Routine Entry Options

Users can enter AcuSmart™ routines through any of these paths:

Discomfort Area
Concern
Daily Routine
Dippie Mood
Recently Used
Recommended Routine

67 Relief Modes Structure

The 67 relief modes are framed as guided external application and relief routines, organized into five categories. The "67" in "67 Relief Modes" is a brand number — the total size of the mode library — and is also reflected in a signature 67-second guided session used as the default timer length across the system. Most modes follow this 67-second pattern; some modes (e.g., wind-down routines) may run longer or shorter where the experience requires it. The 67-second timer is the canonical default unless a specific mode is configured otherwise in the CMS.

67 AcuSmart™ Relief Modes
|
├── Body Area Relief Modes
|     ├── Neck Relief
|     ├── Shoulder Relief
|     ├── Upper Back Relief
|     ├── Lower Back Relief
|     ├── Joint Relief
|     ├── Muscle Relief
|     ├── Leg Relief
|     └── Arm Relief
|
├── Daily Lifestyle Modes
|     ├── After Work Reset
|     ├── Post-Exercise Relief
|     ├── Desk Worker Relief
|     ├── Travel Tension Relief
|     ├── Morning Mobility
|     └── Evening Wind Down
|
├── Product Application Modes
|     ├── Gentle Application
|     ├── Cooling Relief Routine
|     ├── Dippie MagRoller™ Routine
|     ├── Targeted Area Routine
|     └── Quick 67-Second Reset
|
├── Dippie Mood Modes
|     ├── Confidence Mode
|     ├── Explorer Mode
|     ├── Deep Focus Mode
|     ├── Ahh Mode
|     ├── Wind Down Mode
|     └── Daily Reset Mode
|
└── Secret / Campaign Modes
      └── Golden Dippie Lucky 7 Mode

Purpose: Defines the product-specific external-use safety rules that must appear in all AcuSmart™ communication, packaging, and in-app guidance.

Because AcuSmart™ includes a physical topical liniment, the safety section must include product-specific external-use rules.

AcuSmart™ Safety Guidance

For external use only.
Do not apply to broken, irritated, or wounded skin.
Avoid contact with eyes, mouth, and sensitive areas.
Wash hands after use if product contacts fingers.
Do not use excessive pressure with the Dippie MagRoller™.
Stop use if irritation, rash, burning discomfort, dizziness, or unusual reaction occurs.
Keep out of reach of children.
Consult a healthcare professional if symptoms are severe, persistent, unusual, or worsening.
Do not use as a replacement for medical care.

Purpose: Defines the approved and prohibited claims boundaries for all AcuSmart™ customer-facing copy, packaging, marketing, and in-app content.

All AcuSmart™ customer-facing copy, packaging, marketing, and in-app content must follow these claim boundaries.

May help provide cooling relief
Supports targeted external application
Helps guide users to apply product correctly
Supports daily self-care
Helps users follow a structured relief routine

Cures pain
Treats arthritis
Heals injury
Eliminates migraine
Medical treatment
Clinically guaranteed relief

Purpose: Defines how admin/CMS responsibilities and analytics events are split between the DeepFeel™ platform and the AcuSmart™ module — so operations, PM, and engineering teams know which layer owns what.

2.7.1 Admin / CMS Separation

Analytics and CMS responsibilities are split cleanly between the two layers: DeepFeel™ admin governs ecosystem-wide settings; AcuSmart™ CMS governs product-specific content. For the full MVP admin/CMS scope and feature list, see Section 4.6 (MVP Admin / CMS Scope).

2.7.2 Analytics Separation

Analytics events are also separated by layer. Platform analytics track ecosystem-wide behavior; module analytics track AcuSmart™-specific behavior. Both feed into the same DeepFeel™ analytics dashboard. For the complete MVP analytics event list, see Section 4.8 (MVP Analytics Events).

Purpose: Defines the 14 foundational pillars that make up the complete DeepFeel™ system — covering platform, product, engagement, loyalty, operations, and governance. Every feature, screen, and decision must trace back to at least one pillar.

Purpose: Ensure customers understand how to use the physical product correctly after purchase, so better usage drives satisfaction and repeat purchase.

Purpose: Reduce post-purchase confusion and help users feel confident using the product without relying only on packaging or promoters.

Purpose: Connect anonymous offline/online buyers to a verified user account through the universal QR scan, working across every purchase channel.

Purpose: Increase repeat engagement, repeat purchase, and long-term customer value through points, rewards, and the Dippie collectible system — making the app emotionally memorable, not only functional.

Purpose: Drive repeat purchase — critical for commercial growth and retail sell-through — using collection, points, rewards, and in-app buy-again journeys.

Purpose: Acquire new users at lower cost while encouraging existing users to share the ecosystem.

Purpose: Support the physical retail channel — ensuring buyers from pharmacies, resellers, and roadshows get the same verified app experience, and reducing support load created by QR, usage, and routine questions. Retail store locations arrive in Phase 2; promoter demo and retail training modes in Phase 3.

Purpose: Let customers buy DeepFeel™ products directly in the app. In-app purchase is the MVP sales channel (Malaysia only at MVP, paid via senangPay); international markets and payment (HitPay / Stripe) follow with Phase 4 country expansion.

Purpose: Scale beyond one market without rebuilding the app, using a strict global-vs-localized split so new countries launch as a setting, not a new product.

Purpose: Turn anonymous buyers into verified, registered users and generate first-party customer data and business intelligence the business owns.

Purpose: Ensure DeepFeel™ is not limited to AcuSmart™ — the platform must support additional product modules later using the same reusable infrastructure.

Purpose: Defines collectible-specific KPIs so the Dippie loop can be measured as a growth and engagement system, not only as a visual reward.

Measurement Rule

Dippie collectibility metrics must be reviewed alongside QR scan, rewards, referral, commerce, and routine-completion analytics so the team can understand whether Dippie increases repeat behavior beyond one scan.

MVP Core Loop

Purpose: Defines the shared platform systems DeepFeel™ must launch with — the foundation layer that powers AcuSmart™ and every future product module.

DeepFeel™ is the main app ecosystem platform. Its MVP must include the shared systems needed for AcuSmart™ and future product modules.

Purpose: Defines the AcuSmart™ product module systems required at launch — the physical product plus digital guidance experience that proves the first module loop.

AcuSmart™ is the first product module under DeepFeel™. Its MVP must focus on proving the physical product plus digital guidance experience.

AcuSmart™ MVP Must Include — 14 Module-Specific Services

The MVP scope for the AcuSmart™ module is the canonical list below — 14 product-specific services that the module owns. Items like QR scan infrastructure, product verification, Dippie reveal mechanics, points crediting, and support ticket plumbing are platform-level and belong to DeepFeel™ — see Section 4.2 for those. Every item in this list must ship in V1.

1.  AcuSmart™ Product Introduction
2.  Relief Liniment Usage Guide
3.  Dippie MagRoller™ Usage Guide (360° Precision Magnetic Bead)
4.  QR-Based Module Activation
5.  Discomfort Area Selection
6.  Guided Relief Routines
7.  67 Relief Modes Framework
8.  Timer / Session Guide
9.  Safety Guidance (external-use warnings)
10. Routine Completion Screen
11. Feeling Feedback (post-routine)
12. AcuSmart™ Product FAQ
13. AcuSmart™ Analytics
14. MVP Relief Modes Content (priority routines first)

AcuSmart™ MVP Feature Detail

The table below expands each MVP item with its rationale and acceptance definition.

Purpose: Defines the priority tiering of MVP features so engineering, design, and operations all agree on what must ship first, what should ship soon after, and what can wait.

P0 4.4.1 Must Build for Launch

These are non-negotiable. Without these, the DeepFeel™ and AcuSmart™ MVP loop is incomplete. The complete P0 feature lists with success definitions live in Section 4.2 (DeepFeel™ Platform — 20 features) and Section 4.3 (AcuSmart™ Module — 14 features). The table below summarizes P0 by category.

P1 4.4.2 Should Build Soon After MVP

These should be planned for shortly after launch, once the core loop is stable. They strengthen the experience without adding new product complexity. The table below groups P1 features by category — for the full post-MVP plan with timing context, see Section 4.11 (Post-MVP Roadmap).

P2 4.4.3 Future / Scale Features

These should not block MVP launch. They require usage data, regulatory work, or operational maturity that the MVP cannot deliver. The table below groups P2 deferrals by category and reason.

Purpose: Defines the MVP scope from the user's perspective — six distinct journeys covering every essential flow from first app open to support request. Each card below groups screens by the journey they support. For the canonical full-platform screen inventory (284 screens across MVP and future phases), see Section 14: Screen Inventory Table.

Open app
→ App auto-detects country / region (IP, device)
→ App auto-applies default language
→ Register / sign in (no country confirmation step)
→ Accept terms
→ Land on Home
→ See Home dashboard: Search with QR Scan, AcuSmart™ quick entry, Dippie Passport preview, points summary
→ (Optional) Change country / language anytime in Me → Country / Region & Language

User buys AcuSmart™
→ Opens Scan
→ Scans QR
→ Product verified
→ Dippie revealed
→ Points earned
→ AcuSmart™ activated

Open AcuSmart™
→ Product Guide
→ Select Discomfort Area
→ View Recommended Routine
→ Read Safety Guidance
→ Follow Application Step
→ Complete Timer
→ Submit Feedback

User scans QR
→ Points credited
→ Wallet updates
→ User views points history
→ User views rewards
→ User redeems when eligible

User opens Referral
→ Copies or shares code
→ Friend registers
→ Friend scans first valid QR
→ Referrer earns points

User has issue
→ Opens Help
→ Selects issue type
→ Reads FAQ or submits ticket
→ Support team reviews scan/wallet data

Purpose: Defines the admin and CMS systems required so the operations team can manage country, language, products, QR codes, Dippies, rewards, content, users, support, and analytics without developer involvement.

The MVP cannot rely on developers to manually change everything. A basic admin/CMS is required.

Admin Must Manage

Purpose: Defines the minimum data objects the MVP must support — the canonical list of entities the backend, database, and CMS schema must implement.

The MVP must include these minimum data objects:

Purpose: Defines the canonical analytics event names the MVP must instrument — the events product, engineering, and BI teams will use to measure the entire user journey.

4.8.1 DeepFeel™ Platform Events

4.8.2 AcuSmart™ Module Events

Purpose: Defines what the MVP explicitly excludes — the items every team must intentionally NOT build so scope creep is prevented and launch timeline is protected.

These should be clearly excluded from MVP to prevent scope creep.

Purpose: Defines the soft-launch readiness gate — the complete checklist that must pass before the MVP is considered ready to ship to real users. This is the master MVP checklist covering the entire platform end-to-end. Section-specific acceptance criteria for individual systems (country / region in 8.21, localization in 9.16, account & login in 10.18) intentionally restate the items most critical to that system — they are scope-appropriate per-section gates, not duplicates. If an item appears in both 4.10 and a section-specific gate, both must pass.

The MVP is considered ready for soft launch only when:

Purpose: Defines the phased expansion plan that grows DeepFeel™ from a strong MVP (Phase 1) into a full platform across depth, commerce, country, and future product modules. This section sits at the end of Section Group 4 because it directly extends the MVP scope into Phase 2 and beyond.

The MVP defined in Sections 4.1—4.10 is Phase 1 — and now also ships the full 67 Relief Modes, My Dippie Passport, Duplicate Dippie Strategy, Trade with Friends share post, reward lock logic, completion gift reward after 6 normal Dippies, Golden Dippie 1g Gold Bar claim flow, more Dippie animations, routine history, favorite relief modes, notification inbox, improved CRM reminders, points expiry reminders, and reward redemption history. It also ships the in-app store — catalogue, cart, checkout, and payment for AcuSmart™ products and Dippie accessories, with buy-again and QR product verification — as the only sales channel at launch. Once Phase 1 is stable and validated, future phases expand DeepFeel™ further:

Product Overview
→ Product Guide
→ Usage Routine
→ QR Points Rule
→ Rewards
→ FAQ
→ Safety
→ Analytics

Purpose: Defines the canonical user types DeepFeel™ and AcuSmart™ must serve, with a one-line summary of who each user is. Full persona profiles — including why each user needs DeepFeel™, why they need AcuSmart™, their key use case, and required app screens — live in Section 5.2: User Persona & Use Case Document.

Internal Teams

The user types above include internal operators. For organizational clarity, these map to the following internal teams:

Purpose: Deep-dive persona profiles for each user type defined in Section 5.1 — capturing who they are, what they ask, why they need DeepFeel™ and AcuSmart™, their key use case, and the app screens required to support them. Section 5.1 names who the users are; this section explains how the product serves each one.

5.2.1 New AcuSmart™ Buyer

How do I use this product?
Where should I apply it?
How much pressure should I use?
How long should I roll?
Which direction should I roll? (360° precision rolling)
Can I earn points?
What is Dippie?
Why do I need to scan QR?

5.2.2 Existing DeepFeel™ Customer

5.2.3 Pharmacy / Retail Buyer

5.2.4 Online Buyer

5.2.5 Wellness Self-Care User

5.2.6 Collector / Gamified User

5.2.7 Referral User

5.2.8 Promoter / Retail Staff

5.2.9 Customer Support User

5.2.10 Admin User

Purpose: Maps every user need to its corresponding DeepFeel™ platform response and AcuSmart™ module response — clarifying which layer of the system addresses which need.

Purpose: Establishes the core separation principle between the DeepFeel™ platform and the AcuSmart™ product module, and defines the structural logic every product decision must follow.

DeepFeel™ and AcuSmart™ must be separated clearly:

Product Logic Structure

The product logic should always follow this structure:

Purpose: The complete mapping of every user and business problem to the people who experience it, why it matters, the DeepFeel™ platform solution, the AcuSmart™ module solution, and the success definition. Every entry follows the 5-step product logic structure from 6.1.

Purpose: Deep-dive expansion of the platform-level problems from Section 6.2 — for each major problem, this section provides the full context, the platform feature set that solves it, the AcuSmart™ connection, and the measurable success metric. Section 6.2 is the one-line summary; this section is the operational detail PMs, engineers, and analytics teams need to actually ship the solution. The 5 problems expanded here are representative examples — the full mapping of all 22 problems lives in Section 6.2.

Purpose: Deep-dive expansion of the AcuSmart™ module problems from Section 6.2 — for each problem, this section provides the full context, the module feature set that solves it, and the measurable success metric. Section 6.2 is the one-line summary; this section is the operational detail the product, content, and engineering teams need to ship the module. The 5 module problems expanded here are representative examples — the full mapping of all 22 problems lives in Section 6.2.

Purpose: Maps each persona from Section 5 to their signature problem and the corresponding DeepFeel™ / AcuSmart™ solution. For full problem definitions, see Section 6.2. For full persona profiles, see Section 5.2. This table answers: "Which solution serves which persona?"

Purpose: Organizes problems by where they happen in the user's journey — before purchase, during purchase, first app use, activation, product use, after routine, repeat engagement. For full problem definitions, see Section 6.2. This view answers: "At what stage do problems occur, and what is the DeepFeel™/AcuSmart™ response at each stage?"

Purpose: Inverts the lens — starts with each feature in the system and names the specific problem it exists to solve. Useful for engineering and design teams who need to justify (or de-prioritize) any feature against a real user or business need. For full problem definitions, see Section 6.2. This view answers: "Why does this feature exist?"

Purpose: Defines the 11 P0 problems that the MVP must solve at launch. These are the non-negotiable problems behind every MVP feature — if any P0 problem is unsolved, the MVP is incomplete.

P0 P0 Problems to Solve in MVP

Purpose: Defines the problems that should explicitly NOT be solved in MVP — and the reason why. These are valid future problems, but solving them now would distract scope, delay launch, or build on data/behavior the platform has not yet proven.

Purpose: Consolidates every problem area in the system to its single most important success metric — giving the product, marketing, BI, and operations teams one canonical KPI per problem domain. The 15 problem areas here consolidate the 22 problems in Section 6.2 into measurable domains. If a metric in this list moves in the right direction, the corresponding problem is being solved.

These metrics are diagnostic indicators — they tell us whether each specific problem is being solved. They complement (but are different from) the MVP success targets folded into each objective in Section 3, which set the absolute numeric thresholds the MVP must hit at launch (e.g., "registration completion rate ≥ 60%"). Section 3’s per-objective targets ask "is the MVP healthy overall?"; this section says "is each specific problem actually getting solved?"

Purpose: Confirms that every solution mapped in Section 6.2 can actually be built, and surfaces the dependency each one hangs on. This closes the "validate each solution is buildable" requirement by giving engineering one place to sign off feasibility before scope is locked.

Tier legend: Standard = well-understood app functionality, no blocker · Moderate = standard but needs careful backend work · Dependency-risk = buildable, but hangs on a named backend, data layer, or third-party · Regulatory = build is trivial; the gate is legal/compliance.

Scope note: The highest-risk concepts (AI diagnosis, AR body detection, live consultation, Dippie trading) are already excluded from MVP in Section 6.9, so they are not assessed here.

Purpose: Provides a high-level summary of what the master App System Document is, who owns it, and how it relates to the foundation work in Chapters 1, 2, and 3.

7.1.1 Document Title

7.1.2 Scope & Purpose

The App System Document is the complete operational specification for the DeepFeel™ platform and AcuSmart™ Module. While Section Groups 1–6 of this document focus on product foundation (definition, architecture, business objectives, MVP scope, user personas, problem-solution mapping), the App System Document extends into:

7.1.3 Document Owners

The App System Document is owned by the Product Management function and contributed to by every functional team. Each section has a designated owner team responsible for keeping the content current.

Purpose: Lists the master App System Document sections and current HTML section groups. Each section is a structured chapter inside the full document — view the complete content via the link in Section 7.3. This table of contents is reproduced inline so readers can scan the document scope without leaving this page; the actual content of each section lives in the external document.

The App System Document is organized into a master structure of 12 section groups and 62 top-level sections, which expand into 127 detailed subsections covering document control, vision, MVP scope, system architecture, AcuSmart™ specifications, content systems, design, technical, compliance, and launch operations.

1.  Document Control
2.  Executive Summary
3.  DeepFeel Platform Vision
4.  Business Objectives
5.  Product Ecosystem Strategy
6.  Target Users
7.  User Problems & Solutions
8.  Platform Positioning
9.  Product Module Strategy
10. MVP Scope
11. Global Expansion Strategy
12. Global Country / Region & Language System
13. Localization & Translation Requirement
14. Account & Login System
15. App Sitemap & Information Architecture
16. Screen Inventory Table
17. Platform Navigation Rules
18. Platform User Flow System
19. Product Catalogue Requirement
20. Product Module Template
21. AcuSmart™ Module Requirement
22. AcuSmart™ Feature Requirements
23. AcuSmart™ Content System
24. AcuSmart™ 67 Relief Mode Master Database
25. Concern-to-Routine Mapping Table
26. AcuSmart™ Content Writing Guide
27. Safety & Compliance
28. Claims & Language Guidelines
29. UI/UX Design System
30. Key UI Components
31. Visual Asset System
32. Content Writing Standard

33. Multilingual / Localization
34. Loyalty Points System
35. QR Scan-to-Earn System
36. Reward Redemption System
37. One-Tier Referral System
38. Loyalty Anti-Fraud Rules
39. Customer Wallet & Ledger
40. CRM & Engagement System
41. Technical Architecture
42. Data Structure
43. CMS / Admin Dashboard
44. Analytics & Event Tracking
45. Success Metrics
46. QA & Testing Plan
47. User Testing Plan
48. Developer Handoff Package
49. Design Handoff Requirements
50. Accessibility Requirements
51. Error, Empty & Edge States
52. Notification System
53. Product Guide System
54. Routine History & Feedback
55. App Permissions
56. Security & Privacy
57. Legal & Compliance Documents
58. Version Roadmap
59. Launch Plan
60. Launch Checklist
61. Operations & Ownership
62. Master Release Sign-Off
63. (additional sections as roadmap evolves)

Purpose: Provides the direct link to the complete App System Document. The 62-section breakdown shown in Section 7.2 is a table of contents only — the comprehensive content for every section lives at the external link below.

The full App System Document is published as a standalone reference at the URL below. Every section listed in Section 7.2 expands into its complete content there — including diagrams, tables, schemas, copy guidelines, navigation maps, data structures, design specifications, and launch checklists.

7.3.1 What's Inside the Full Document

The full document expands every section listed in 7.2 with:

• Complete written specifications for each system
• Diagrams, sitemaps, and architecture trees
• Data schemas and database structure tables
• Copy guidelines, content standards, and localization rules
• Screen-by-screen navigation maps
• UI component definitions and design tokens
• Loyalty, QR, referral, and wallet business rules
• Safety, claims, and legal language guardrails
• QA test cases and launch checklists
• Operations and ownership matrix

7.3.2 How to Use This Reference

Purpose: DeepFeel™ is designed as a global app ecosystem platform that can be used by anyone in the world.

The app should not be built as separate country apps. Instead, DeepFeel™ operates as one global platform, while country / region settings only control selected local layers such as default language, in-app store availability & local payment gateway, local currency display, product availability display, support contact, timezone, and optional country notices.

This section acts as a global-local rulebook, not a place to repeat detailed QR, points, Dippie, referral, rewards, admin, legal, or analytics logic. Those details are documented in their own relevant sections.

8.1.1 Global Standardized Systems (Primary 9)

These are the 9 primary global systems — the user-visible surfaces that are the same for every user worldwide regardless of country / region. For the full canonical list of all 14 global systems (including supporting infrastructure like points rules, routine history, core safety framework, and analytics structure), see Section 8.3: What Remains Global. Section 8.3 is the authoritative source; this subsection lists only the most user-facing nine.

8.1.2 Country / Region Controlled Layers

These layers adapt based on the user's detected or selected country / region — they are presentation and localization layers only:

8.1.3 How Country / Region Is Detected

The app auto-detects the user's country / region on first open using low-friction signals:

The user is never asked to confirm country during registration. Country / region is applied silently. Users can change country / region anytime under Me → Settings.

8.1.4 Boundary Rule

Purpose: Defines the single guiding principle that governs the entire global / local split — globalize the product experience, localize the buying experience. Every rule in Sections 8.3–8.22 derives from this principle.

8.2.1 One Standardized Global Ecosystem

DeepFeel™ should maintain one standardized global ecosystem — every user, in every country, gets the same core systems with the same logic. The canonical list of 9 primary global systems is defined in Section 8.1.1, with additional supporting global systems (points rules, routine history, core safety framework, analytics structure) detailed in Section 8.3.

8.2.2 What Country / Region Should Mainly Control

Country / region settings should mainly control the buying and localization layers — default language, in-app store availability & local payment gateway, local currency display, product availability, local support, optional country notice, timezone, local campaigns, and unsupported country fallback. The canonical list of 10 country-controlled layers is defined in Section 8.1.2, with the per-layer behavior detailed in Section 8.4.

8.2.3 App Availability vs Store Availability

These are two different things and must not be confused:

Purpose: The canonical list of all 14 global systems that remain standardized worldwide, regardless of country / region. This is the authoritative source — Section 8.1.1 lists the primary 9 user-facing systems as a quick reference; this section is the complete inventory. If a system appears here, country / region cannot change it.

Purpose: Expands the canonical country-controlled layer list from Section 8.1.2 with a description of how each layer adapts to the user's selected country / region. The canonical list of layers themselves is defined once in 8.1.2 — this table adds the behavior per layer.

Purpose: Defines the strict priority order DeepFeel™ uses to decide which country / region to apply for any given user — preventing the app from accidentally overriding a logged-in user's saved country. Language priority is owned by Section 9.3.

DeepFeel™ should use a clear priority order to decide country / region:

Priority 1: Logged-in user's saved country
Priority 2: Last local app setting, for logged-out returning users
Priority 3: IP-detected country
Priority 4: Device region
Priority 5: Global fallback

Important Rule

This prevents the app from automatically changing a user's country simply because the user travels overseas.

For the corresponding language priority order, see Section 9.3: Language Priority Rule.

Purpose: Defines the privacy-respecting boundary for how DeepFeel™ detects country and language at app launch — using low-friction signals only, and never requesting precise GPS location during onboarding.

Country auto-detection should use low-friction signals.

Use IP location, device region, or device language for country/language defaulting.
Do not request precise GPS location during onboarding.

When Precise Location Permission Is Allowed

Precise location permission should only be requested when the user opens location-based features such as:

Store locator
Near me
Find nearby outlet
Map navigation

This avoids unnecessary onboarding friction and improves user trust.

Purpose: Defines exactly how country / region should behave in every user state — guest, logged-in, logged-out returning, detection failure, travel, and manual change. Language behavior is owned by Section 9.3.

For the corresponding language behavior by user state, see Section 9.3: Language Priority & User-State Behavior.

Returning User Launch

For a returning logged-in user, launch loads the saved global account, country / region, and language, then drops the user into the global Home:

Open DeepFeel™ App
→ App loads user’s global account
→ App loads saved country / region
→ App loads saved language
→ User enters global DeepFeel™ Home

Every global system (account, wallet, points, Dippie Passport, referral, scan history, AcuSmart™ activation, rewards, routine history) continues exactly where the user left off — see Section 8.3: What Remains Global.

Purpose: Defines the exact first-launch sequence so the user can sign up without being forced to confirm country and language manually — reducing onboarding friction while still applying the correct localization.

DeepFeel™ should reduce onboarding friction by not forcing the user to confirm country and language during first launch.

Open DeepFeel™ App
→ App auto-detects country / region using IP location or device signal
→ App applies default language based on detected country
→ User signs up or signs in
→ User accepts global terms and optional country notice, if applicable
→ User enters global DeepFeel™ Home

Where Users Can Change Country / Region and Language Later

User can change country / region and language later in:

Me → Settings → Country / Region & Language

Purpose: Defines how a logged-in user can change country / region and language anytime after first launch, and which local layers update as a result of that change.

Users should be able to change country and language anytime.

Me
→ Settings
→ Country / Region & Language
→ Change Country / Region
→ Change Language
→ App updates local language options, in-app store availability & payment gateway, currency display, support contact, timezone, and optional country notice

Purpose: Defines exactly what changes — and what does not — when a user manually changes their country / region. Changing country / region should affect only local layers.

8.10.1 Changing Country Affects

When the user changes country / region, every layer in the canonical list defined in Section 8.1.2 updates to the new country's configuration. The 10 layers are: default language & options, in-app store availability & payment gateway, currency display, product availability display, local support contact, optional country notice, timezone, local campaign visibility, and unsupported country fallback. For the per-layer behavior, see Section 8.4.

8.10.2 Changing Country Does Not Affect

Every global system stays exactly the same — country / region cannot reset or relocate any of them. For the canonical list of all 14 global systems that remain unchanged, see Section 8.3: What Remains Global (quick-reference list of the primary nine is in Section 8.1.1).

Purpose: Provides the canonical in-app copy shown to the user when they change country or region. The message confirms exactly which layers will update and reassures the user that no global account data will be affected.

Use this copy inside the app:

Purpose: Defines the relationship between country and language — country sets the default language, but language remains an independent user preference the user can change at any time.

Country determines the default language, but language is still a user preference.

Country determines default language.
User can manually change language anytime.

Examples

Malaysia user can choose English, Chinese, or Bahasa Malaysia.
Singapore user can choose English or Chinese.
Japan user can choose Japanese or English, if English is enabled.
Unsupported country defaults to English.

Detailed language priority, language behavior, language settings flow, and the full supported language matrix are owned by Section 9: Localization & Translation Requirement (see Section 9.5 for the Supported Language Matrix). Section 8 owns country / region logic; Section 9 owns language and translation logic.

Purpose: Defines how DeepFeel™ behaves for users in countries that are not yet officially supported. Because DeepFeel™ is a global app, every user must still be able to use the core platform — local layers may degrade gracefully, but the global ecosystem stays fully functional.

Because DeepFeel™ is a global app, users from unsupported countries must still be able to use the core platform. Every global system defined in Section 8.1.1 (and detailed in Section 8.3) remains fully available, including registration, sign-in, QR scan, product verification, Dippie collection, points earning, wallet, AcuSmart™ activation, guided routines, referral, and global support.

The local presentation layers defined in Section 8.1.2 (and detailed in Section 8.4) may be hidden or replaced with a global fallback — including in-app store availability, local currency pricing, local campaigns, and local support contact.

Fallback Message

The following message should appear in-app when a user in an unsupported country encounters missing local layers:

Purpose: Defines the boundary between what the country / region section covers (high-level availability flags) and what belongs in the In-App Store & Commerce layer (catalogue, cart, checkout, payment, orders).

Country / region controls local buying options only at a high level.

The detailed commerce logic is documented in the In-App Store & Commerce layer (feature group 20.4 ACU-F094–F098, screens 14.x, flow 16.13).

Whether in-app purchase is available in the region
Which currency is displayed
Which payment gateway applies (senangPay MY; HitPay/Stripe intl in Phase 4)
Whether product is available, coming soon, or out of stock

Product catalogue & pricing
Stock status
Cart logic
Checkout logic (MVP)
Payment via senangPay (MVP, Malaysia)
Order confirmation & history
Order status tracking (placed → shipped → delivered)
Shipping coverage
Return / exchange policy
Retail store locations (Phase 2)
International payment — HitPay/Stripe (Phase 4)

Purpose: Defines the strict separation between global points (which never localize) and local currency (which only appears in buying-related information). Points are a worldwide value; currency is a buying display.

Points = global.
Currency = local commerce display only.

Currency should be used for buying-related information only.

Purpose: Defines the canonical product availability statuses a country / region may carry. Even though DeepFeel™ is global, product selling availability may differ by country — and the app must display the right status for each market.

Even though DeepFeel™ is global, product selling availability may differ by country.

Purpose: Defines how timezone is determined and what user-facing systems depend on it. Timezone is relevant to country / region because it affects user communication and campaign timing.

Timezone should be based on the user's selected country / region or device timezone.

Timezone Is Used For

Routine reminders
Campaign start and end time
Support business hours
Push notification timing
Daily streak reset
Seasonal campaign timing

Example

Sleepy Dippie reminder should be sent at 9:00 PM user local time.

Purpose: Defines the canonical list of configuration items every country / region record must carry, and the purpose each one serves in the DeepFeel™ platform.

Purpose: Provides a concrete JSON example showing how a single country / region record should be structured in the CMS / admin and consumed by the app. Malaysia is used as the reference example.

{
  "country_code": "MY",
  "country_name": "Malaysia",
  "region_status": "active",
  "default_language": "en",
  "available_languages": ["en", "zh-Hans", "ms"],
  "currency": "MYR",
  "timezone": "Asia/Kuala_Lumpur",

  "store_locator_enabled": true,
  "in_app_store_enabled": true,
  "product_availability_status": "available",

  "support": {
    "use_global_support": true,
    "local_support_available": true,
    "email": "support@deepfeel.com.my",
    "whatsapp": "+60XXXXXXXXX"
  },

  "legal": {
    "global_terms_version": "GLOBAL-TC-v1.0",
    "global_privacy_version": "GLOBAL-PP-v1.0",
    "country_notice_required": true,
    "country_notice_version": "MY-NOTICE-v1.0"
  },

  "fallback": {
    "unsupported_country_message_enabled": false
  }
}

Purpose: Defines the admin capabilities required so the operations team can configure country / region settings without developer dependency. Detailed admin roles, permissions, audit logs, and approval workflow are documented separately in the CMS / Admin Dashboard section.

Admin should be able to configure country / region settings without developer dependency.

Admin Should Manage

Country / region
Default language
Available languages
Currency
Timezone
Store locator availability
In-app store availability
Product availability
Local support contact
Optional country notice
Local campaign visibility
Unsupported country fallback

Detailed admin roles, permissions, audit logs, and approval workflow should be documented under the CMS / Admin Dashboard section.

Purpose: Defines the complete checklist that must pass before the global country / region system is considered MVP-ready. Every box below is non-negotiable for launch.

This section is ready for MVP when:

Purpose: States why localization and translation are required, and clarifies what this section does and does not cover.

DeepFeel™ is a global app ecosystem that can be used by anyone in the world. Localization and translation are required to make the app understandable, usable, and trustworthy across different languages, regions, and future markets.

This section defines how DeepFeel™ handles language detection, language preference, translation coverage, fallback behavior, CMS translation management, QA review, and developer handoff.

This section should focus only on language and translation logic.

Purpose: States the four-part guiding principle every localization decision must follow.

DeepFeel™ should not force users to choose a language before sign-up unless detection fails or the user manually opens language settings. In other words, users should not be forced to select language manually during onboarding — language is auto-applied based on the detected country / region and device language.

The app should follow this logic:

Open DeepFeel™ App
→ Detect country / region or device signal
→ Apply default supported language automatically
→ Let user sign up or sign in quickly
→ Allow language change later in Settings

Language is treated as a user preference, not a mandatory onboarding step — there is no manual language selection screen during first onboarding.

Purpose: Defines the strict 5-tier priority order DeepFeel™ uses to decide which language to apply at any moment.

DeepFeel™ should decide app language using the following priority:

Priority 1: Logged-in user's saved language
Priority 2: Last local app language setting
Priority 3: Device language, if supported
Priority 4: Detected country / region default language
Priority 5: English fallback

Important Rule

This prevents the app language from changing unexpectedly when the user travels.

Behavior by User State

The priority order above resolves to the following behavior in each user state:

Purpose: Defines the language-specific step inside the Settings flow, and clarifies which surfaces are affected by a language change — and which are not. The parent Settings path is owned by Section 8.9: Country / Region & Language Settings Flow.

Language is changed inside the path defined in Section 8.9. The language-specific step is:

... → Country / Region & Language
→ Language
→ Select preferred language
→ App reloads translated content
→ Preference is saved to user profile

9.4.1 Language Change Should Affect

9.4.2 Language Change Should Not Affect