Minimente — Product Requirements Document

Product: Minimente — Digital Mental Wellbeing Platform for Workplaces Programme in scope: Stress Management (Programme #1) Document version: v4.0 — DRAFT FOR REVIEW (v2.0 amended per the v3 design review and the product owner's written response; provisional product decisions pending Minni's sign-off) Author: Synthesised from founder source material; reconciled against repo state; amended per the v3 review cycle Date: 2026-07-27 Owner / approver: Minni (founder, content author) Intended audience: Implementing engineering team (incl. coding agents), design, and the founder for content sign-off

Changes in v2.0. v1.0 was written from source documents alone, without reference to the codebase. v2.0 adds §1A (repo state), incorporates a previously unaccounted-for fourth source document (the March 2026 developer briefing deck, "Source D") and two prototype artefacts, updates §9 and §10 with what that material settles and fails to settle, and rewrites §11's phasing against verified reality. The headline finding is negative: no application code exists. No open question in §10 is closed by the repository. Four are better characterised, two are new. Section numbering from v1.0 is preserved throughout; §1A is inserted rather than renumbering.

Changes in v4.0 — changelog and decision trail. "v3" was not a document revision: it was an external product/design review of v2.0 (commissioned as "think 2027, not 2015 — do not rubber-stamp a historic user experience"), to which the product owner responded in writing, adopting most of it with amendments. v4.0 synthesises both. Section numbering is again preserved; new subsections are inserted, never renumbered; new requirement IDs extend their series rather than reusing numbers. The full item-by-item disposition log is Appendix A.1. What changed and why:

Rejected or amended from the v3 review, per the product owner: committing to a 5-point scale (test both instead — #11); any hard cap on modules per day (removed entirely — #1); "the Toolkit is the product" (reframed — the product is the skills; #3).

Items 1, 2, 5 and 7 reshape the programme Minni authored. They are recorded as recommended and provisionally adopted, pending Minni's sign-off, with reasoning left visible in the affected sections and OPEN rows so she can overturn any of them (Phase 0 item 1). Nothing in v4 closes the genuinely open questions — OPEN-02, OPEN-03, OPEN-05, OPEN-06, OPEN-10, OPEN-24 and the rest stand. The hard constraints are unchanged and non-negotiable: safeguarding is P0 (§8.3); no conversational AI, avatar, or chat (§4.3, §9.4); no diagnostic instruments (§2.3, §4.4); employer-anonymity is the central promise (NFR-PRIV-04); silent, desk-friendly, discreet (NFR-PLAT-02/05); WCAG 2.1 AA (§8.4).

---

1. Summary & Document Status

Minimente is a B2B digital mental-wellbeing product delivered as a mobile and web application. Its first (and currently only) programme is a guided, iCBT-informed stress-management course delivered as a sequence of short daily sessions (5–12 minutes) designed to be completed during a working day rather than in a therapy setting. Each daily session follows a fixed five-part rhythm — check-in, micro-lesson, guided exercise, reflection, daily takeaway — and from Day 1 the programme accumulates into a persistent, user-owned Personal Stress Toolkit. v4 framing (adopted): the product's purpose is building lifelong stress-regulation skills; the course creates that capability and the Toolkit is the persistent interface to it — the surface the user keeps when the course is over. v4 structure (provisional, pending Minni): the programme is a 10-module Core plus on-demand Extension modules (the former Days 11–15), unlocked in sequence but never calendar-locked (OPEN-18, FR-CORE-04). A set of Always-Available Emergency Tools sits outside the programme flow for acute stress moments. Organisations buy seats for employees; individual data stays private to the employee while organisations receive anonymised aggregate insight.

Document status and provenance. This PRD synthesises four founder/team-authored source documents and two prototype artefacts. Sources A–C were the basis of v1.0; Source D and the prototypes were discovered during the v2.0 repo reconciliation and were not available to v1.0.

Sources A, B and D all date from Feb–Mar 2026 and form a coherent March-2026 position. Source C (July 2026) is four months newer and revises that position — most importantly by renaming and re-scoping Modules 12–15 and by presenting all 15 modules as a linear sequence. Several conflicts that v1.0 read as internal inconsistencies within Source C are, in fact, Source C diverging from the March-2026 position (see OPEN-04, OPEN-18).

Where A/B/D and C disagree on module content, Source C wins. Where C is silent on framework-level concerns (emergency tools, personalisation rules, data collection, UX principles), Source B is retained. Business/commercial content is taken from A. Source D is treated as a proposal, not a decision — nothing in it was ever ratified or implemented (§1A).

v4.0 additionally incorporates two non-file inputs: the v3 external design review (2026-07-27) and the product owner's written response adopting most of it with amendments. Neither is a founder source: wherever they change the shape of the programme Minni authored, the change is recorded as provisional pending her sign-off, never as settled. Disposition log: Appendix A.1.

⚠️ This is a v4 draft pending Minni's review. It is not yet fully implementable, and no part of it has been built. Source C — the "just finished" content document — is materially incomplete: 4 of 15 modules (12, 13, 14, 15) contain screen structure only, with body copy replaced by editorial placeholders, and Module 11's psychoeducation and per-branch exercise scripts are likewise placeholders. Several module titles contradict the March-2026 outline. There is no crisis-safety design anywhere in the source material, which is a P0 blocker for a mental-health product — and the one artefact that was built (the prototype) contains no crisis flow, no disclaimer, and no privacy messaging either, confirming the gap is real rather than an artefact of documentation. Engineering can begin on architecture, the content-rendering engine, and Modules 1–10 immediately; Modules 11–15 can be built structurally but cannot ship user-facing text until Minni supplies it. Additionally, v4 provisionally adopts several product-shape decisions (sequence-lock, Core+Extensions, Daily-Action taxonomy, post-programme state) that only Minni can ratify — see the v4 changelog and Phase 0 item 1. See §10.

---

1A. Repo State as of 27 July 2026

Summary: the repository is empty. No application code exists. Nothing in §10 is resolved by the codebase, because there is no codebase.

v4.0 note. This section remains accurate: no application code exists as of 27 July 2026. This document (v4) supersedes PRD_v2.md. "v3" was a review-and-response cycle, not a document revision (see §1 provenance), and produced no code either — the only change to the repo between v2 and v4 is this file.

1A.1 What is actually in the repo

/Users/domward/Code/Minimente — verified by full recursive listing:

Minimente/
├── PRD_v2.md          ← v2.0 (superseded)
├── PRD_v4.md          ← this document
└── logs/
    ├── combined.log   0 bytes, created 13 May 2026, never written
    └── error.log      0 bytes, created 13 May 2026, never written

• Not a git repository. No .git, no history, no remote, no branches.
• No package manifest — no package.json, requirements.txt, go.mod, or equivalent. No stack has been chosen in the repo.
• No source code of any kind. No application, no server, no client.
• No data layer — no migrations, no schema, no seed data, no ORM config, no Supabase/Postgres project linked from here.
• No content — not one module, screen, or string of the programme is loaded anywhere. Modules 1–11's authored copy has never been imported.
• No configuration — no .env, .env.example, CI config, lockfile, linter, or formatter.
• No tests, and no test framework to run them.
• The two log files are the residue of a tool run on 13 May 2026 that produced no output. They are not evidence of an application.

The March 2026 briefing (Source D, slide 9) listed as step 03: "Set up project repo, CI/CD, and design system." That step was never performed. This directory is its unstarted placeholder. An independent corroboration exists in the founder's own project tracker (mission-control), which describes Minimente as "In-development personal app (local only). Scope TBD." with next steps "Define scope and reach initial working state; add git remote once shape is clear."

1A.2 What exists outside the repo

Four artefacts sit in ~/Desktop/Misc/MiNNi/, untouched since 11 March 2026. None is under version control.

1A.3 What the prototype implements — and what it proves

The prototype (E1) is a single-file React component with no persistence layer whatsoever: useState only, no localStorage, no fetch, no backend. All state is lost on reload. It implements Day 1 and nothing else.

Confirms (useful): - The 7-screen session structure is real and was independently implemented. SCREENS = ["welcome", "checkin", "lesson", "breathing", "reflection", "takeaway", "complete"] — matching §5.2's mapping of Source B's 5 parts onto Source C's 7 screens. Three sources now agree on this shape; it is the safest structural commitment in the document. - A visual language already exists — a defined palette ("Sage Calm meets clinical trust": #4A9B7F primary on #F7FAF8), slider, progress bar, and button components, and an animated BreathingSquare implementing the 4-4-4-4 box-breathing pacer of FR-M1-04. §11 Phase 1 item 9 should treat design as having a starting point, not a blank page. - The 5–12 min session claim and Day-1 copy are testable today — the prototype is runnable and could be timed with real users this week, ahead of any build.

Contradicts or fails to support (important): - Content is hardcoded as JSX, not data. Module 1's copy is inline in the component tree. This is the exact inverse of AD-01 ("content as data, not code"), the PRD's single most important architectural decision. The prototype must therefore be treated as a throwaway visual reference, not a foundation — building forward from it would bake in the coupling AD-01 exists to prevent. This is the most consequential repo-derived finding in v2.0. - "Over the next 14 days" is hardcoded in the welcome copy, and the home screen renders a 14 days badge and a 0 / 14 days progress bar. The prototype does not resolve OPEN-01; it is a fourth restatement of the unresolved 14 figure. - The Emergency Tools drawer is non-functional. It renders six tools as cards with cursor: pointer but no click handler — there is no tool content behind any of them. This is dead UI, and it independently confirms OPEN-06: the tools have never had scripts, in any source or artefact. - Zero crisis-safety content. No disclaimer, no "Need urgent help?" affordance, no helpline, no signposting, no escalation — the strings do not appear anywhere in the file. OPEN-10 is confirmed unaddressed in implementation as well as in documentation. - Zero privacy or anonymity messaging. No onboarding, no consent, no "your employer cannot see this" statement (NFR-PRIV-04) — indeed no auth or account concept at all. The product's central adoption promise has never been expressed in any built artefact.

1A.4 Reconciliation verdict

Net effect on §11: the plan does not move forward. It gains a preceding step — repo initialisation — that v1.0 assumed had already happened.

---

2. Product Overview & Positioning

2.1 Elevator pitch

A 10-day core programme of 5–12 minute daily sessions that teaches practical stress-regulation skills at your desk — building a personal Stress Toolkit you keep, with on-demand extension modules and always-available quick tools. Designed for real working days, not therapy sessions.

(v4 provisional wording under the Core+Extensions decision — OPEN-18/OPEN-01, pending Minni. The v2 pitch read "a 14-day … programme" against 15 delivered modules; the Core+Extensions structure retires both numbers at once. If Minni retains the linear model instead, revert to the v2 wording and resolve 14 vs 15.)

2.2 What Minimente is

• Guided self-help / iCBT. Short, structured exercises that build coping skills, sequenced so the user meets one key concept at a time.
• Skills-first (v4, per the product owner). The outcome sold and measured is durable capability — "I've learnt to regulate stress" — never content consumption or item collection. The course creates the capability; the Personal Stress Toolkit (§7.1) is the persistent interface that reinforces it.
• Microlearning. No information overload; no long reading blocks; one clear action per screen.
• Work-integrated. Designed for use during working hours, in an office or remote-work context, silently if needed.
• Low-threshold and anonymous to the employee, while being company-funded and measurable to the employer via anonymised aggregates.
• Evidence-informed. Guided digital care for anxiety, depression, and stress has demonstrated outcomes comparable to face-to-face care in real-world healthcare programmes (Source A cites HUS Finland, NHS). Work-focused programmes improve functioning.

2.3 What Minimente is explicitly NOT

These are hard product constraints, not marketing copy. They must be enforced in the UI, in content, and in the safeguarding flow.

• Not a replacement for clinical psychiatric care or for the company's occupational healthcare provider.
• Not a diagnostic tool. No screening instruments, no scores presented as clinical assessments, no diagnostic language anywhere in the product.
• Not suitable for psychological emergencies or crisis situations. The product must actively route users elsewhere in those situations (§8.3).
• Not a substitute for healthy organisational practices. Minimente does not fix workload, management, or culture problems and must not be positioned as doing so.
• Not a game (v4, binding anti-requirement). No streaks, badges, points, levels, leaderboards, or guilt mechanics ("you've missed 3 days") anywhere in the product — including under future "engagement" pressure. A stress product that manufactures stress about itself is self-defeating. FR-CORE-04's no-penalty stance and UX-09 enforce this.
• Not a monitoring device (v4, binding anti-requirement). No wearables integration and no passive physiological or behavioural monitoring, in any tier or phase. Passive sensing inside an employer-funded mental-health app is irreconcilable with the anonymity promise as employees will perceive it (NFR-PRIV-04), collects continuous special-category data the product does not need, and pushes towards medical-device classification. Reasoning recorded permanently in §9.4 so this is not "modernised in" later.

2.4 Why it exists (problem statement)

Work-related stress and burnout are rising; traditional therapy does not reach everyone; companies want measurable wellbeing solutions; early support prevents escalation, improves commitment, and reduces the productivity loss and sick leave associated with stress and burnout.

---

3. Target Users & Business Model

3.1 Market

• Core focus: B2B. Sold to organisations; company-funded access; workplace-integrated programmes; anonymised organisational insight; focus on work-related stress and functioning.
• Target segments: remote-first organisations, growth-stage companies; buying centre is HR / People Ops.
• Geography: Finland and/or English-speaking markets — undecided (§10, OPEN-09). Product must be built i18n-ready regardless.
• B2C is explicitly OUT OF SCOPE for v1. The future B2C variant (individual subscription, broader life-stress topics, no organisational reporting, fully private/self-directed) is a later extension. Do not build B2C billing, app-store subscriptions, or consumer onboarding in v1 — but do not design the data model in a way that makes an org-less user impossible.

3.2 Personas

P1 — "Hanna", HR / People Ops decision-maker (buyer, not primary user) - Needs: a defensible, low-risk wellbeing benefit; evidence it works; proof it is being used; something that does not create legal/privacy exposure; measurable data for leadership. - Interacts with: purchase/contract, seat provisioning, an anonymised organisational dashboard. - Fears: employees not using it; being seen to surveil employees; a wellbeing tool mishandling a distressed employee. - v1 implication: she needs aggregate usage and outcome reporting and seat management, and she must be structurally unable to see individual data.

P2 — "Jussi", employee end-user (primary user) - Context: busy working day, open-plan office or home desk, low motivation to start anything that looks like therapy, possibly worried his employer will find out he used it. - Needs: something that takes under 10 minutes, works silently, gives him something usable today, and is private. - v1 implication: anonymity guarantees must be explicit and visible at signup; sessions must be interruptible and resumable; audio must never be required.

P3 — Therapist / professional (Tier 2 & 3 only — POST-MVP) - Reads module-related data shared by the user, sends periodic messages, takes bookings. Not built in v1.

3.3 Pricing tiers (from Source A — unvalidated, see OPEN-12)

All tiers include: secure platform, progress tracking, anonymised company insights.

This maps to the three levels of professional support: (1) module library / self-help materials, (2) message a therapist, (3) book a therapist appointment.

⚠️ CONFLICT INTRODUCED BY SOURCE D (new in v2.0). The developer briefing (slide 7) defines the three levels differently: L1 self-guided digital program · L2 AI-enhanced personalization · L3 professional therapist referral. That is not a rewording — it replaces the entire Tier 2 product. Under Source A, Tier 2 is a human service (a therapist message) requiring clinical supply and governance; under Source D it is an algorithmic feature requiring none. Tier 3 likewise shifts from "book a live session" to "referral". The two readings imply different cost structures, different regulatory exposure, and different reasons a customer would pay 3–4× more. §4.1's recommendation to ship Tier 1 only is unaffected — Tier 1 is identical under both readings — but the tier ladder must be settled before any pricing is quoted to a pilot customer. See OPEN-25.

3.4 Programme roadmap (content, not v1)

Beyond Stress Management: Sleeplessness, Burn-out Prevention, Burn-out Recovery, Public Speaking, Interaction Skills, Self-Management Skills, Concentration Skills, Executive-level programmes. v1 must therefore treat "programme" as a first-class, multi-instance content entity — not hardcode a single stress course.

---

4. MVP Scope Recommendation

4.1 Recommendation: ship Tier 1 only

The MVP is Tier 1 (self-guided access): the Stress Management programme, the Emergency Tools, the Personal Stress Toolkit, progress tracking, reminders, and an anonymised org dashboard. Nothing else.

Rationale:

1. It is the only tier that is fully in Minimente's control. Tiers 2 and 3 require a supply of licensed therapists, professional liability arrangements, clinical governance, scheduling/calendar infrastructure, and a secure clinical messaging channel with retention and record-keeping obligations. None of this exists, and none of it is described in any source document. Building it would multiply both engineering scope and regulatory exposure.
2. Tier 1 is the substrate for Tiers 2 and 3 anyway. Both higher tiers are defined in Source A as "digital programmes plus X". Building the digital programme first is strictly on the critical path.
3. It is what the founder's own plan says. Source A: "Define MVP structure, starting with e.g. the Stress program."
4. It is pilotable. A pilot with one company client — the stated next step — needs a working self-guided programme, not a care marketplace.
5. Content readiness is the binding constraint, not tier features. With 4.5 of 15 modules missing copy, adding therapist workflows would be building around an unfinished core.

4.2 Scope table

4.3 Explicitly deferred, with reasons

• AI therapist / conversational AI / therapist avatar. Source A itself marks these as "ideas, unconfirmed". A conversational agent giving mental-health responses to distressed employees is a materially different regulatory and safety product (likely medical-device-adjacent in the EU). Do not build, do not prototype against real users, do not put in pilot marketing.
• Recommendation algorithm. Source A flags this as an open question. Three deterministic rules (§7.3) are sufficient and honest for v1.
• Teams integration. Source A writes it as "Teams?". Treat as a discovery item for the pilot customer, not a v1 commitment.
• Gamification and wearables (v4). Not deferred — excluded, as binding anti-requirements. See §2.3 for both, UX-09 and §9.4 for the reasoning. Listed here so nobody rediscovers them as "roadmap".

4.4 v1 success metrics

Grounded in the stated goal of "measurable data for organizations":

v4 note on comparability. "Core completion" (10 modules) is an easier bar than v2's "Day 14/15 completion" (15 modules). The ≥30% target is re-baselined, not achieved — pilot reporting must never present core-completion numbers as comparable to full-programme figures from earlier drafts or competitor claims. The stress-delta window likewise now spans only the core, giving the effect less time to show; treat the pilot delta as directional only (it already was).

Note the tension: the org buyer wants outcome measurement, but the product explicitly refuses diagnostic instruments. Recommendation: rely on the product's own non-clinical self-ratings (stress, energy, recovery, confidence) plus the Day-15 feedback screen. Do not add PHQ-9/GAD-7-style instruments in v1 — that would contradict §2.3 and change the regulatory posture.

---

5. Core User Journey & Daily Session Structure

5.1 End-to-end journey

1. Provisioning — Employer purchases seats; employees receive an invite (org invite code or verified work-email domain).
2. Onboarding — Account creation (pseudonymous), privacy explanation ("your employer cannot see your individual data"), not-a-crisis-service disclaimer with signposting, optional reminder-time setup.
3. Home screen (v4) — Today's session (primary CTA), "Right now" moment-of-need entry (§7.7), My Stress Toolkit (co-primary from Day 1 — FR-TK-09), Emergency Tools (always visible), search (§7.8), progress indicator.
4. Daily session (v4) — one module per day recommended; modules unlock in sequence on completion, never by calendar (FR-CORE-04). Core = Modules 1→10 (provisional — OPEN-18). Fixed five-part structure below; every session offers its practised exercise into the Toolkit (FR-CORE-07).
5. Between sessions — "Right now" and Emergency Tools available anytime; reminders fire per user configuration; Toolkit is browsable, editable, and its exercises directly runnable.
6. Core completion (Module 10) (v4) — the accrued Toolkit is curated into warning signs + action plan; the closure module (reflection letter, forward plan, programme feedback — M15 content) follows the core, its exact position folded into the OPEN-18 decision; the extension library is then offered on demand.
7. Post-programme (v4) — Home reconfigures to the Toolkit-primary steady state (§7.9): Toolkit + "Right now" + Emergency Tools + optional light check-ins + extensions. (Provisionally resolves OPEN-14.)

5.2 The five-part daily session (Source B, confirmed by Source C's screen structures)

In Source C this is realised as 7 screens: Welcome & Context → Check-in → Psychoeducation → Guided Exercise (1–n screens) → Reflection → Daily Action → Completion. Module 15 inserts an eighth screen type (Programme Feedback) before Completion.

5.3 UX principles (binding — from Source B)

• UX-01 One clear action per screen.
• UX-02 No long reading blocks; psychoeducation must be chunked and scannable.
• UX-03 A persistent progress indicator (within-session step and across-programme day).
• UX-04 Resume-later from any screen without data loss.
• UX-05 Silent-mode friendly: audio must never be required; text transcript always available; no autoplay audio; no sound by default.
• UX-06 Notifications/reminders are opt-in and user-scheduled.
• UX-07 Everything a user types is optional unless the exercise is meaningless without it; skip must always be possible.
• UX-08 (new in v4) Pacing language is invitational, never coercive: "Recommended", never "Locked", for anything gated only by pacing; suggestions to space sessions are dismissible and never enforced (FR-CORE-04).
• UX-09 (new in v4 — binding anti-requirement) No streaks, badges, points, levels, or guilt mechanics anywhere. Progress display is factual (modules completed, skills practised), never an unbreakable chain that can be "lost". See §2.3.

---

6. Functional Requirements by Module

6.0 Foundational requirement: content-driven rendering

FR-CORE-01 — The system shall render all module content from a versioned, server-delivered content document (JSON), not from hardcoded client screens. Modules, screens, screen types, copy, options, placeholders, button labels, and stored-field names are all content data.

FR-CORE-02 — The client shall implement a fixed library of screen component types and support any module composed from them. This is what makes Modules 12–15 buildable now and fillable later, and what makes future programmes (sleep, burnout) additive content rather than new code.

(v4) All EX_* guided-exercise screens render exercises by reference to the exercise library (FR-CORE-06): scripts, transcripts, audio assets, pacers, and default durations belong to the exercise object, not to the screen or module. A referencing screen may supply presentation context — duration preset, framing copy, follow-up reflection options (cf. Module 11's per-branch mini-reflections) — without duplicating exercise content.

FR-CORE-03 — Every module shall be gated by a copy_status flag (final | placeholder). A module with copy_status = placeholder shall not be released to production users. This lets Modules 11–15 be merged, tested, and reviewed without risk of shipping Finnish editorial placeholders to an employee.

FR-CORE-04 (amended in v4) — Modules shall unlock in sequence: completing module N immediately unlocks module N+1. There shall be no calendar gate and no daily cap — a motivated user may complete several modules in one sitting. After a completion the UI should suggest, and never enforce, spacing (e.g. "skills settle best with a break between sessions"), dismissible per UX-08. After a same-day completion the next module is labelled "Recommended for tomorrow"; the word "Locked" shall not be used for anything gated only by pacing. A missed day shall not penalise, reset, or lock the user out; catch-up is trivial by construction (unchanged from v2). Rationale: the iCBT evidence supports ordered content, not time-gated content — v2's calendar-lock was a proposed default, not a sourced requirement, and it punished exactly the motivated-user moments the product needs. Provisionally adopted pending Minni's sign-off — OPEN-13. Safeguarding coupling: see the NFR-SAFE-03 distinct-days amendment in §8.3.

FR-CORE-05 — Every screen transition shall persist state server-side so a session can be resumed on a different device.

FR-CORE-06 (new in v4) — Exercise as a first-class reusable object. Guided exercises shall be modelled as standalone, versioned content objects in an exercise library (exercises, §7.4): slug, title, type, full script, transcript, optional audio asset, default duration, adaptation copy (NFR-A11Y-04), locale variants, own copy_status. Modules, the Toolkit, Emergency Tools, the "Right now" entry (§7.7), search results (§7.8), and extension modules all hold references to exercises, and the client implements exactly one exercise runtime regardless of entry point. Referencing contexts may supply presentation overrides but never fork exercise content. Consequence: an exercise's script/audio/transcript is authored, versioned, and translated once — "Box Breathing" in Module 1, in the Emergency Tools drawer, and in a user's Toolkit is one object. (Generalises v2's FR-TK-05 and the breathing-reset ≈ Module-1 overlap; see AD-08.)

FR-CORE-07 (new in v4) — Toolkit accrual from Day 1. Every module shall declare the exercise(s) it teaches (modules.taught_exercise_id, §7.4 — v2's toolkit_tool_key made a real reference), and every module's Completion or Daily Action shall offer "Add today's tool to my Toolkit" — generalising v2's FR-M11-06 to all modules, idempotent per FR-TK-06, declinable per FR-STD-05. Module 10 thereby becomes curation of an already-populated Toolkit, not its creation (§6.2 M10 amendment, §7.1).

FR-CORE-08 (new in v4) — Daily Action ending taxonomy. The ACTION screen shall support five ending types, declared in content data: do_now (a micro-action completed in-screen — e.g. M5's micro-pause, done right there in 30 seconds), save_to_toolkit, implementation_intention ("when I notice X, I'll Y" — persisted and surfaced in the Toolkit; M10's action plan is this pattern), set_reminder (§7.5), and insight_only (text, no boolean — v2's FR-M4-04 variant). Reminders are the minority ending, used only where a time-anchored prompt genuinely fits (e.g. M8's boundary statement). Which ending each module uses is a content decision — OPEN-28, Minni; the v2 per-module actions stand until she reassigns them. Rationale: eight of ten core modules ended in "set a reminder" — 2015's answer to transfer-of-training, and a notification-fatigue machine. Do-not-modernise note: work-calendar integration is not an acceptable substitute — an employer-visible calendar event leaks participation (NFR-PRIV-04, NFR-PLAT-05).

FR-CORE-09 (new in v4) — Every captured output has a destination. Adopts OPEN-17's proposed resolution as a requirement: same-day operational items (M3 priority_task/deferrable_task, M9 chosen_response) shall surface on Home for the remainder of that day; durable personal artefacts (M4 noticed_thought, M6 balanced_thought, M8 boundary_statement, M12 supportive_statement, M15 future_stress_plan) shall be routed or offerable to the Toolkit. Nothing a user writes may be captured without a surface where they ever see it again.

6.1 Module matrix

v4 note. Under the provisionally adopted Core+Extensions structure (OPEN-18), Days 1–10 are the Core and Days 11–15 are Extension modules offered as an on-demand, any-order library after core completion. The "Day" column is retained for traceability to Source C; extension "days" are catalogue positions, not calendar days. Recommended handling of the closure module (M15): it becomes the core finale or fires on completion — folded into the OPEN-18 sign-off. Note the alignment this creates: all missing copy (11–15) now sits in the extension library, so the fully authored core is shippable while extensions land as a content pipeline (see Top Risk 1).

---

6.2 Modules 1–11 — Functional requirements

All modules share the following baseline requirements unless overridden:

• FR-STD-01 The system shall present the module's screens in the documented order and allow backward navigation without data loss.
• FR-STD-02 (amended in v4) The Check-in screen shall present a stress rating and an energy rating as tappable discrete scales (not drag sliders — NFR-A11Y-02), both required, plus any module-specific optional inputs; on submit it shall write a daily_checkin record stamped with module id and timestamp. Point count (5 vs 10) is deliberately undecided — OPEN-26; the sources specify 1–10, and every threshold in §7.3 and §8.3 is defined against that scale.
• FR-STD-03 After the Check-in submit, the system shall evaluate the personalisation rules in §7.3 and surface the corresponding suggestion non-blockingly.
• FR-STD-04 Reflection inputs shall be optional and skippable; the Continue action shall never be blocked by an empty reflection.
• FR-STD-05 The Daily Action screen shall offer one primary action and a secondary dismiss ("No thanks" / "Continue"); dismissal shall be recorded as an explicit decline, not as absence of data.
• FR-STD-06 The Completion screen shall write a module_completion event and offer navigation to Home and (per module) a secondary destination.
• FR-STD-07 (new in v4) Every module completion shall offer the module's taught exercise to the user's Toolkit per FR-CORE-07 — idempotent (FR-TK-06), declinable, with a decline recorded as an explicit decline (FR-STD-05).

---

Module 1 — Understanding Stress (Day 1) · 5–7 min

Goal: understand stress and the bodily responses related to it.

---

Module 2 — Recognising Stress Signals (Day 2) · 5–7 min

Goal: recognise personal early stress signals in order to respond earlier.

• FR-M2-01 Welcome copy shall explain that stress signals appear in body, thoughts, and behaviour before becoming overwhelming.
• FR-M2-02 Check-in shall add an optional free text "What feels most demanding right now?" alongside the standard sliders.
• FR-M2-03 Psychoeducation "Stress has early warning signs" shall present the three categories (body / thoughts / behaviour) as visually distinct groups, not prose.
• FR-M2-04 Guided exercise shall be an audio-guided Body Scan walking attention head → shoulders → chest → stomach → legs. Text transcript required. No data stored.
• FR-M2-05 Reflection: "Where did you notice stress in your body today?" → reflection_text_optional. Note: this prompt is identical to Module 1's; confirm with Minni whether that is intentional repetition or a copy-paste artefact (OPEN-16).
• FR-M2-06 Daily Action: reminder to notice stress signals during the day.
• FR-M2-07 Completion: "Day 2 complete".

---

Module 3 — Workload vs. Capacity (Day 3) · 5–7 min

Goal: understand workload vs. capacity and reduce overload.

• FR-M3-01 Psychoeducation "Stress grows when demands exceed capacity" shall define workload (what is expected) vs. capacity (what you can realistically handle) and state that capacity varies day to day.
• FR-M3-02 Guided exercise "Workload Prioritisation" shall present two text inputs: (a) one task that truly matters today → priority_task; (b) one task that can wait, be simplified, or be postponed → deferrable_task.
• FR-M3-03 Both inputs shall be saved and shall be retrievable to the user later that day (see OPEN-17 — the sources do not say whether these appear anywhere after the session; recommended: surface on Home for the remainder of the day).
• FR-M3-04 Reflection: "How does it feel to adjust your expectations for today?" — explicitly skippable.
• FR-M3-05 Daily Action: reminder to check workload.

---

Module 4 — Automatic Stress Thoughts (Day 4) · 5–7 min

Goal: recognise automatic stress thoughts without reacting to them.

• FR-M4-01 Psychoeducation "Stress thoughts happen automatically" shall include the three worked examples: "I'm already behind", "I should be handling this better", "If I don't do this perfectly, something will go wrong", and shall state the goal is noticing, not judging.
• FR-M4-02 Guided exercise "Noticing Automatic Stress Thoughts": normalisation copy + one text input "One stress-related thought I noticed" → noticed_thought.
• FR-M4-03 Reflection: "How did it feel to notice the thought without trying to change it?"
• FR-M4-04 Daily Action shall introduce cognitive defusion — thoughts are events in the mind, not facts. (Content requirement: this is a concept introduction, not a reminder-setting action; the ACTION screen must support a text-only variant with no boolean.)

---

Module 5 — Micro-Recovery During the Workday (Day 5) · 5–7 min

Goal: learn that small recovery moments during the day reduce stress.

• FR-M5-01 Psychoeducation "Recovery can be small": micro-recovery = short pauses signalling safety to mind and body (relax shoulders, look away from screen, breathe out slowly, stand up).
• FR-M5-02 Guided exercise "Micro-Recovery Pause" shall render the full script: feet on floor → relax shoulders → unclench jaw → look away → breathe → ask "What do I need for the next few minutes?". Audio + transcript. No data stored.
• FR-M5-03 Reflection: "What small recovery action would help you right now?"
• FR-M5-04 Daily Action: reminder to take one micro-pause today.

---

Module 6 — Thought Reframing (Day 6) · 5–7 min

Goal: reframe automatic stress thoughts into balanced perspectives.

• FR-M6-01 Psychoeducation "A thought is not the whole truth" shall explicitly state that reframing is not forced positivity — it is finding a more accurate and compassionate version.
• FR-M6-02 Guided exercise "Thought Reframing" shall present two text inputs — stress_thought (placeholder e.g. "I can't do anything right") and balanced_thought (placeholder e.g. "I'm capable of many things, but I'm feeling defeated right now") — with the three guiding questions displayed alongside: "Is this 100% true?", "Is there another way to see this?", "What would I say to a friend?".
• FR-M6-03 The system should pre-fill stress_thought with the user's noticed_thought from Module 4 as an editable suggestion. (Not specified in source; strongly recommended for continuity — needs Minni's confirmation.)
• FR-M6-04 Reflection: "How does the balanced thought feel compared to the original?"
• FR-M6-05 Daily Action: reminder to reframe one thought today.

---

Module 7 — Focus & Interruptions (Day 7) · 7–10 min

Goal: recognise personal distractions and protect attention via a focused work session. First multi-part exercise module.

• FR-M7-01 Psychoeducation "Protecting your focus": task-switching costs; focus is a matter of environment design, not willpower.
• FR-M7-02 Exercise part (a) "Identify Your Distractions" — EX_MULTI with options: notifications, email, other people, own thoughts, task-switching, social media/phone, "don't know where to start", Other (free text). → distractions[].
• FR-M7-03 Exercise part (b) "Choose Your Focus Strategies" — EX_MULTI: turn off notifications, close tabs, phone out of reach, single-task before checking messages, write down distractions, tell others you need uninterrupted time. → focus_strategies[].
• FR-M7-04 Exercise part (c) "Focus Window" — user names a task (focus_task) and selects a duration from 10 / 15 / 20 (recommended) / 25 minutes (focus_duration); buttons "Start Focus Window" and "Maybe later".
• FR-M7-05 The Focus Window timer shall run reliably when the app is backgrounded or the screen is locked, and shall fire a completion notification (respecting silent mode). On web it shall survive tab backgrounding; a server-side timestamp anchor is required rather than a client interval.
• FR-M7-06 The user shall be able to end the Focus Window early; ending early is a valid outcome, not a failure.
• FR-M7-07 Reflection shall be a single-choice: completed / got distracted but returned / stopped early → focus_outcome, plus optional free text.
• FR-M7-08 Daily Action: focus is a trainable skill.

---

Module 8 — Boundary Setting (Day 8) · 7–10 min

Goal: practise setting clear, respectful boundaries.

• FR-M8-01 Psychoeducation "Boundaries support sustainable work" shall state a boundary is not a rejection and shall include the example phrases: "I can do this, but not today", "I need to finish this before taking on something new", "Can we clarify what is most urgent?".
• FR-M8-02 The exercise shall first teach the Three-Step Boundary Method on its own screen: (1) acknowledge the request → (2) state your boundary clearly and respectfully → (3) offer an alternative if appropriate.
• FR-M8-03 A following practice screen shall present three text inputs: what is being asked (boundary_request), your boundary (boundary_statement), optional compromise (boundary_alternative). Only the second is meaningfully required; all shall be skippable.
• FR-M8-04 Reflection: free text on what the user noticed while practising.
• FR-M8-05 Daily Action: reminder to use the boundary sentence today. The reminder body should include the user's own boundary_statement.

---

Module 9 — Emotion Regulation at Work (Day 9) · 5–7 min

Goal: notice emotions early and respond intentionally rather than react.

• FR-M9-01 Psychoeducation "Emotions carry information": emotions are signals, not problems; pausing before reacting gives the thinking brain time to engage.
• FR-M9-02 Guided exercise "Pause – Identify – Choose" shall be delivered as three sequential steps:
• Step 1 – Pause: one slow breath, notice the feeling. No data.
• Step 2 – Identify: single-select from: frustrated, anxious, overwhelmed, disappointed, angry, embarrassed, guilty, sad, other (free text) → identified_emotion.
• Step 3 – Choose: free text "What response would help right now?" → chosen_response.
• FR-M9-03 Reflection: what changed after pausing.
• FR-M9-04 Daily Action: reminder to pause before reacting.

---

Module 10 — Personal Stress Toolkit (Day 10) · 7–10 min

Goal: curate the personal collection of stress strategies accrued since Day 1, and build a simple action plan. v4: this module curates the persistent Toolkit object (§7.1), which accrues from Day 1 (FR-CORE-07) — it no longer creates it.

v4 amendment. With Toolkit accrual from Day 1, this module's job shifts from creating the Toolkit to curating it — which is what parts (b) and (c) were always uniquely good at. FR-M10-02 (amended): part (a)'s option list shall arrive pre-checked with the items already in the user's Toolkit; the screen's purpose is review, pruning, and additions (including the two custom-tool fields), not first assembly. FR-M10-03…08 stand unchanged. Framing copy needs a light edit from Minni ("review your toolkit", not "build your toolkit") — flagged under OPEN-28's content pass.

• FR-M10-01 Psychoeducation "Different situations require different tools": 3–4 reliable strategies is enough.
• FR-M10-02 Exercise part (a) "Build Your Stress Toolkit" — EX_MULTI listing all previously practised exercises: Box Breathing, Body Scan, Notice stress thoughts, Reframe a thought, Micro-break, Focus Window, Set a boundary, Pause–Identify–Choose, Prioritise a task. Plus two free-text custom-tool fields. → toolkit_items[], custom_tools[].
• FR-M10-03 The option list in (a) shall be derived from the content model (each module declares the toolkit-eligible tool it teaches) rather than hardcoded, so that adding or reordering modules does not break this screen.
• FR-M10-04 Exercise part (b) "Identify Your Early Warning Signs" — EX_MULTI: body tense, racing thoughts, lose focus, irritable, overwhelmed, rushing, procrastinate/avoid, other → warning_signs[].
• FR-M10-05 Exercise part (c) "Create Your Action Plan" — EX_MAP. For each selected warning sign, the user selects a tool from a dropdown dynamically populated from the user's own selections in part (a), including their custom tools. The result is stored as ordered (warning_sign → tool) pairs → action_plan[].
• FR-M10-06 The action plan shall be persisted as part of the Personal Stress Toolkit and shall be editable later independently of this module.
• FR-M10-07 Daily Action: view/toolkit reminder.
• FR-M10-08 Completion "Day 10 complete" shall include an additional button "Go to My Stress Toolkit", confirming the Toolkit is a persistent, revisitable in-app destination — not a one-time exercise output.

---

Module 11 — Body-Based Stress Release (Day 11) · 8–12 min (variable)

Goal: recognise what the body needs and practise an appropriate body-based regulation strategy. First branching module.

⚠️ COPY GAP. Source C marks Module 11's psychoeducation body as "(Keep your existing text)" and does not spell out the four per-branch audio scripts. Module 11 is therefore NOT implementation-ready as user-facing content, despite being in the "complete" block. Structure below is buildable; text is not.

• FR-M11-01 Psychoeducation "Your body responds to stress, too". ❌ Body copy missing — must be supplied by Minni.
• FR-M11-02 Guided exercise "Choose Your Body Reset" shall present a single-choice branching card menu of four options: Calm Breathing, Stretch & Release, Shake Out Tension, Gentle Movement. → body_reset_choice.
• FR-M11-03 Each branch shall follow an identical 3-screen sub-structure: (i) exercise intro → (ii) audio-guided exercise → (iii) mini-reflection single-choice on immediate effect. The mini-reflection option sets differ per branch:

→ branch_effect (branch-scoped enum).

• FR-M11-04 ❌ All four branch audio scripts are missing ("keep existing"). Cannot be implemented.
• FR-M11-05 After the branch rejoins the main flow, a shared Reflection screen shall ask: (a) whether the reset met the need (need_met), (b) how the body feels now (body_state), (c) optional free text.
• FR-M11-06 Daily Action shall present "Add today's exercise to my Stress Toolkit" as a boolean; when true, the chosen branch exercise is appended to the user's Toolkit. This confirms the Toolkit accumulates state across modules, not only at Module 10.
• FR-M11-07 Branch content shall be modelled as content data (a branch node with n sub-flows), so additional body resets can be added without code changes.

---

6.3 Modules 12–15 — STRUCTURE ONLY (body copy NOT implementable)

🚫 BLOCKING NOTICE FOR THE IMPLEMENTING TEAM. In Source C, Modules 12–15 contain screen names, screen purposes, screen types, button labels, option lists, and stored-field names — but the actual prose (welcome text, psychoeducation body, exercise framing copy) is replaced with editorial placeholders: "(Keep your current text unchanged)" and the Finnish "(Pidä nykyinen tekstisi sellaisenaan)" ("keep your current text as is"). This indicates the author was editing an existing draft that did not survive into the exported copy.

These four modules may be built structurally and merged behind copy_status = placeholder, but MUST NOT be released to users until Minni supplies real copy. No copy may be invented by the implementing team — this is clinical-adjacent content and must come from the author.

---

Module 12 — Self-Compassion Under Stress (Day 12) · 7–10 min

Goal: recognise the inner critic, strengthen the supportive inner voice, practise self-compassion. ⚠️ Title mismatch: the outline at the top of Source C calls this "Self-Compassion at Work" (OPEN-04).

Missing for M12: Welcome body, psychoeducation body, guided-reflection framing copy, daily-action body. Title of record must be confirmed.

---

Module 13 — Understanding Your Emotional Needs (Day 13) · 7–10 min

Goal: recognise emotional needs, understand how unmet needs contribute to stress, identify a realistic self-care response. ⚠️ Title mismatch: outline calls this "Meaning & Motivation" — a substantively different topic, not just a rename (OPEN-04).

Missing for M13: Welcome body, psychoeducation body, guided-reflection framing, reflection body, daily-action body. Topic of record must be confirmed (emotional needs vs. meaning & motivation) — this is a content-design decision, not a copy edit.

---

Module 14 — Balance Your Battery (Day 14) · 8–10 min

Goal: recognise different sources of recovery, reflect on current recovery balance, choose one action to strengthen wellbeing. ⚠️ Title mismatch: outline calls this "Sustainable Habits" (OPEN-04). ⚠️ Icon corruption: the eight Recovery Wheel category icons came through as mojibake in the export (OPEN-05).

Recovery Wheel icons — RECONSTRUCTION, NEEDS CONFIRMATION. The following are best-guess replacements for the corrupted glyphs and must be confirmed or replaced by Minni/design before implementation:

Recommendation: do not use raw emoji for these at all. Emoji render inconsistently across platforms and are poor for accessibility. Use a proper icon set with alt text equal to the category name; treat the emoji list above only as semantic intent.

Missing for M14: Welcome body, psychoeducation body, all eight categories' example-activity lists, daily-action body, final icon set.

---

Module 15 — Moving Forward (Day 15) · 8–10 min

Goal: reflect on progress, consolidate learning, create a plan for future stress, and collect programme feedback. ⚠️ Title mismatch: outline calls this "Reflection & Long-Term Plan". Celebration emoji on the Completion screen came through corrupted (OPEN-05).

Missing for M15: Welcome body, psychoeducation body, letter-exercise framing, daily-action body, congratulations copy, celebration asset, Q3 option-list length decision.

FR-M15-01 The programme-feedback responses shall be stored separately from therapeutic content and shall be included in organisational aggregate reporting (as aggregates only, with the free-text field excluded from any org-visible report by default — see §8.2).

---

7. Cross-Cutting Systems

7.1 Personal Stress Toolkit (persistent, stateful, cross-module)

v4 framing (adopted, with the product owner's correction). The product's purpose is building lifelong stress-regulation skills; the Toolkit is the persistent interface to those skills — the course creates capability, the Toolkit reinforces it. The goal state is "I've learnt to regulate stress", never "I've collected ten tools": Toolkit copy and UI shall reflect skills practised, not items owned, with no collection mechanics (UX-09).

Mechanically, the Toolkit is not an exercise output — it is a first-class, persistent, user-owned in-app object with its own destination screen, reachable from Home (co-primary with Today's Session — FR-TK-09) and from module completion screens, accruing from Day 1 (FR-CORE-07) and becoming the primary surface after the programme (§7.9).

Requirements

• FR-TK-01 The system shall maintain one Toolkit per user, persisting indefinitely and surviving programme completion.
• FR-TK-02 (amended in v4) The Toolkit shall accumulate items from Day 1: every module completion offers its taught exercise (FR-CORE-07, FR-STD-07). The v2-specified module writes remain on top of this baseline: Module 10 (curation + custom tools + action plan), Module 11 (chosen branch exercise), Module 13 (reminder note), Module 14 (recovery action), and Module 15's future_stress_plan.
• FR-TK-03 Toolkit items shall be typed: built_in_exercise (links to a runnable exercise), custom_tool (user free text), reminder_note (free text), recovery_action (free text), action_plan_entry (warning-sign → tool pair), future_plan (long text), supportive_statement (from M12).
• FR-TK-04 The Toolkit shall be independently viewable and editable: users shall be able to add, rename, reorder, and remove items outside of any module.
• FR-TK-05 (clarified in v4) built_in_exercise items shall be directly runnable from the Toolkit — tapping "Box Breathing" plays the exercise standalone, without re-entering any module. (v4: a "runnable exercise" is a reference into the exercise library, executed by the single shared exercise runtime — FR-CORE-06.)
• FR-TK-06 Adding a duplicate item shall be idempotent (no duplicate rows).
• FR-TK-07 (amended in v4) The Toolkit shall render an explanatory empty state only before the user's first saved item — typically minutes into Day 1, not Day 10.
• FR-TK-08 Toolkit contents are private user content and shall never appear in organisational reporting, in any form.
• FR-TK-09 (new in v4) Home shall present the Toolkit as co-primary with Today's Session during the programme, and as the primary surface post-programme (§7.9).
• FR-TK-10 (new in v4) Toolkit items and saved durable outputs shall be discoverable via search (§7.8) — indexed and searched locally only (FR-SRCH-05).

7.2 Always-Available Emergency Tools

FR-ET-01 A set of short self-regulation tools shall be reachable from the home screen at all times, regardless of programme progress, day, or completion state — including before Day 1 and after Day 15.

FR-ET-02 Emergency Tools shall be usable without a check-in, without unlocking, and without affecting programme progress.

FR-ET-03 Initial tool set (Source B, marked non-exhaustive):

FR-ET-04 Each use shall write an emergency_tool_event (tool id, started_at, completed bool, entry point).

FR-ET-05 The quick thought-dump journal shall store free text privately to the user; it shall be deletable by the user.

FR-ET-06 Emergency Tools shall be available offline once cached.

❌ CONTENT GAP: No scripts exist for any Emergency Tool in any source document. Some overlap with module exercises (breathing reset ≈ Module 1; body scan ≈ Module 2), but grounding, thought-dump, desk stretch, safe place, and progressive relaxation have no authored content. See OPEN-06. This is a v1 blocker because Emergency Tools are the product's only acute-moment offering and are advertised on the home screen from Day 0.

v2.0 update — confirmed empirically, and a headcount discrepancy. The prototype (E1) renders an Emergency Tools drawer whose six cards have no click handlers and no content behind them. The gap is therefore not a documentation oversight: these tools have never existed as anything but a list of names. Separately, Source B lists seven tools; Source D (slide 6) and the prototype both list six — omitting Progressive relaxation. The table above retains Source B's seven per the §1 precedence rule. Minni should confirm whether progressive relaxation is in or out, since it changes the authoring count in OPEN-06 from five scripts to four.

FR-ET-07 The Emergency Tools surface shall also host the "Need urgent help?" crisis signposting entry point (§8.3). Emergency Tools are not a crisis service and the distinction must be visually and textually explicit.

FR-ET-08 (new in v4) Emergency Tools are a curated view over exercise-library objects (FR-CORE-06), not a parallel implementation: each tool references an exercise, runs in the shared exercise runtime, and where a tool and a module exercise share a script (breathing reset ≈ Module 1's Box Breathing; body scan ≈ Module 2's), they are literally the same object with an emergency-context duration preset. This removes the duplicate-authoring burden for the two overlapping tools — but the remaining tools still need scripts, and v4's "Right now" entry (§7.7) and search (§7.8) both increase Day-0 dependence on them: OPEN-06 is more critical in v4, not less.

7.3 Personalisation / recommendation logic

This is three deterministic rules, not a recommendation algorithm. Source A lists "recommendation algorithm for content" as an open question; Source B provides the following rules. For v1, the three rules are sufficient — implement them as declarative, config-editable rules and do not build ML.

FR-PR-01 Rules shall be evaluated immediately after check-in submission and shall never block progression through the session. FR-PR-02 Rules shall be expressed as data (condition + action + copy key), editable without a release. FR-PR-03 Rule firings shall be logged (rule_id, fired_at, accepted bool) so that rule usefulness can be measured during the pilot.

v4 scale coupling. PR-01's ≥ 7 and PR-02's ≤ 4 are defined against the historical 1–10 scale. If OPEN-26 lands on a different granularity, these cutoffs — and NFR-SAFE-03's — must be re-derived and re-signed-off by Minni/clinical, never rescaled arithmetically by engineering. The 10-point option leaves every threshold untouched.

⚠️ CONTRADICTION: PR-03 suggests a "professional support link", but Tier 1 (the MVP) has no professional support. This must be resolved. Recommended v1 behaviour: PR-03 surfaces a tier-aware destination — for Tier 1, a signposting card pointing to the employer's occupational-health provider and/or public services, configured per organisation at contract time; for Tiers 2/3 (later), the therapist message/booking flow. This overlaps heavily with the crisis-safety gap (§8.3) and should be designed together.

7.4 Data collection & candidate schema

Product-wide data collected (Source B): daily stress and energy ratings; module completion data; emergency tool usage; module-related additional data for therapists; general feedback. Source A additionally names mood as a daily metric — no module collects mood (OPEN-08).

Candidate schema

organizations
  id, name, country, locale_default, tier (1|2|3),
  crisis_resources_config (jsonb), created_at

org_seats
  id, org_id, invite_code, claimed_by_user_id NULL, claimed_at, revoked_at

users                                  -- pseudonymous
  id (uuid), org_id, auth_identifier_hash, display_name NULL,
  locale, timezone, created_at, deleted_at
  -- NOTE: no employee name/number required; see §8.2

programmes                             -- content, versioned
  id, slug ('stress-management'), title, day_count, version, published_at
                                       -- v4: day_count = core length under OPEN-18

exercises                              -- NEW in v4; first-class, reusable (FR-CORE-06, AD-08)
  id, slug ('box-breathing'), title, exercise_type,
  script_key, transcript_key, audio_asset_url NULL,
  default_duration_s, adaptation_copy_key NULL,
  locale, version, copy_status ('final'|'placeholder'), published_at

modules
  id, programme_id, day_index, theme, goal,
  duration_min, duration_max, copy_status ('final'|'placeholder'),
  is_extension BOOL,                   -- v4: Core vs Extension (provisional, OPEN-18)
  taught_exercise_id NULL              -- v4: FK exercises — what this module teaches and
                                       -- offers to the Toolkit (was toolkit_tool_key)

screens
  id, module_id, order_index, screen_type, title_key,
  body_key, config (jsonb),            -- options, placeholders, button labels, field names
  exercise_id NULL                     -- v4: EX_* screens reference the exercise library;
                                       -- config may carry per-context overrides (FR-CORE-06)

enrollments
  id, user_id, programme_id, started_at, current_day,
  completed_at NULL, last_active_at

session_states                          -- resume-later
  id, enrollment_id, module_id, current_screen_id,
  draft_answers (jsonb), updated_at

daily_checkins
  id, user_id, enrollment_id, module_id, occurred_at,
  stress_rating INT NULL, energy_rating INT NULL,
  recovery_rating INT NULL,             -- M14
  confidence_rating INT NULL,           -- M15
  optional_text TEXT NULL,
  extra (jsonb)                         -- self_talk_style, emotional_needs_awareness

screen_responses                        -- generic, heterogeneous by design
  id, user_id, enrollment_id, module_id, screen_id,
  field_name TEXT,                      -- e.g. 'balanced_thought', 'distractions'
  value_text TEXT NULL, value_num NUMERIC NULL,
  value_bool BOOL NULL, value_json JSONB NULL,
  is_sensitive BOOL DEFAULT TRUE, created_at

module_completions
  id, user_id, enrollment_id, module_id, completed_at,
  elapsed_seconds, branch_taken NULL     -- M11

toolkit_items
  id, user_id, item_type, exercise_id NULL, label TEXT,  -- v4: FK exercises (was tool_key)
  payload (jsonb), source_module_id, created_at,
  archived_at NULL, sort_order

action_plan_entries
  id, user_id, warning_sign TEXT, toolkit_item_id, created_at

emergency_tool_events
  id, user_id, exercise_id, entry_point, started_at,   -- v4: tools are exercises (FR-ET-08)
  completed BOOL, duration_seconds

right_now_events                        -- NEW in v4 (§7.7); routing signal only, never scored
  id, user_id, entry_state, routed_to, occurred_at
  -- excluded from org reporting in any form; no free text

reminders
  id, user_id, source_module_id NULL, kind, body_key,
  body_override TEXT NULL, scheduled_for, recurrence NULL,
  channel ('push'|'email'|'inapp'), status, fired_at NULL

personalisation_events
  id, user_id, rule_id, fired_at, context (jsonb), accepted BOOL NULL

programme_feedback
  id, user_id, enrollment_id, programme_rating INT,
  recommendation_score INT, favourite_module_id NULL,
  feedback_text TEXT NULL, submitted_at

safeguarding_events                     -- NEW; see §8.3
  id, user_id, trigger_rule, triggered_at,
  surfaced BOOL, user_response NULL

Design notes

• FR-DATA-01 screen_responses uses a generic field-name/value shape deliberately: the 15 modules write ~35 heterogeneous fields and future programmes will add more. Do not create one column per prompt.
• FR-DATA-02 Everything a user types (value_text, optional_text, reflection_letter) is special-category health-adjacent data. It shall be encrypted at rest with a separate key, shall be excluded from analytics pipelines by default, and shall never be exported to organisational reporting.
• FR-DATA-03 "Module-related additional data for therapists" (Source B) shall be gated behind an explicit, per-item, revocable user consent — and is out of scope for v1 since Tiers 2/3 are deferred. Model the consent flag now; do not build the sharing UI.
• FR-DATA-04 Users shall be able to export and delete all of their data (GDPR Arts. 15, 17, 20) — see §8.2.
• FR-DATA-05 (new in v4) There is deliberately no search_queries table, and none shall be added: search executes client-side and queries are never transmitted or persisted (§7.8, FR-SRCH-05, NFR-SEC-06). right_now_events stores the chosen route only — never free text — and is excluded from organisational reporting.

7.5 Notifications & reminders

v4: under FR-CORE-08, "set a reminder" is one of five Daily-Action endings and the minority case — most modules should end in do-now actions or Toolkit saves (assignment: OPEN-28). A real notification subsystem (not a client-local timer) is still required for the reminders that remain, the opt-in daily programme nudge, and the Focus Window.

• FR-NOT-01 The system shall support user-scheduled reminders created from Daily Action screens, with a default time suggestion and user override.
• FR-NOT-02 Channels: push (mobile/PWA), email fallback, in-app. All opt-in; a user who grants nothing must still be able to complete the programme.
• FR-NOT-03 A daily programme reminder ("today's session") shall be configurable at onboarding, with a user-chosen time and a per-day snooze.
• FR-NOT-04 Reminder bodies shall be able to embed user-authored content (e.g. Module 8's boundary_statement) — but such notifications shall not display sensitive user text on a locked screen unless the user opts in. Default: generic body.
• FR-NOT-05 Reminders shall respect the user's timezone and shall not fire outside a configurable window (default 07:00–20:00 local).
• FR-NOT-06 Module 7's Focus Window completion notification shall be reliable when backgrounded (§FR-M7-05).
• FR-NOT-07 The system shall never send a notification that reveals programme participation to a third party, and shall never notify an employer about an individual user for any reason.

7.6 Progress tracking & resume-later

• FR-PROG-01 (amended in v4) Home shall show programme progress (core module N of 10, plus extensions engaged — provisional per OPEN-18) and a within-session step indicator. Progress display is factual, never streak-framed (UX-09).
• FR-PROG-02 Any session may be abandoned mid-screen and resumed exactly where it was left, on any device (session_states.draft_answers).
• FR-PROG-03 Draft answers shall autosave on blur and on navigation, not only on submit.
• FR-PROG-04 A personal history view shall show the user their own stress/energy trend over time and their completed days. This is the user-facing half of "self-assessment and progress tracking" and must be framed non-diagnostically (no thresholds, no "you are stressed" labels).
• FR-PROG-05 The organisational dashboard shall show only aggregates (§8.2).

7.7 "Right now" moment-of-need entry (NEW in v4)

A stressed employee opens this app because they are stressed now, not because it is Day 6. v2's only now-shaped surface was the Emergency Tools drawer — which has no content behind it (OPEN-06). This section makes moment-of-need entry first-class, assembled almost entirely from parts the PRD already had: the routing-rule machinery (§7.3), the exercise library (FR-CORE-06), Emergency Tools, and the Toolkit. New authored content required: a handful of state labels and one routing table.

• FR-NOW-01 Home shall offer a "Right now" entry alongside Today's Session, available from Day 0 (before Module 1) and permanently post-programme (§7.9).
• FR-NOW-02 It shall be a single tap on a small set of non-scored state options — indicative set: Tense / Racing thoughts / Can't focus / Just checking in. Labels are content data authored by Minni. No numeric rating, no score, no threshold, no "rate your anxiety".
• FR-NOW-03 Each state routes via a declarative routing table (content data, same pattern as §7.3's rules) to one of: a specific exercise (library object), the user's own relevant Toolkit item once one exists, or today's module. Routing preference: the user's own saved tool for that state, else a sensible default exercise.
• FR-NOW-04 (hard boundary) This surface is routing, never assessment: no "you seem stressed" labels, no trends or history built from entry states, no diagnostic language (§2.3). If it ever scores, thresholds, or labels the user, it has become the screening instrument the product forbids. right_now_events store the chosen route only, are excluded from organisational reporting in any form, and shall not feed §7.3 or §8.3 rules in v1.
• FR-NOW-05 The "Need urgent help?" signposting (NFR-SAFE-02) shall be visible on this surface.
• FR-NOW-06 (dependency + safeguarding note) This surface shall not ship before the Emergency Tool scripts exist (OPEN-06): a moment-of-need entry with empty tools behind it is worse than no entry. Separately: users who mainly use "Right now"/Toolkit generate fewer check-ins, thinning NFR-SAFE-03's passive signal — the always-visible signposting (NFR-SAFE-02, FR-NOW-05) is the primary safety net, as §8.3 already establishes.

7.8 Search & retrieval (NEW in v4 — deliberately non-AI)

By 2027, retrieval is table stakes in any knowledge product. A user should be able to type "catastrophising" and land on Module 6, the thought-reframing exercise, and any related extension — with no AI: no LLM, no chat, no generated answers. Deterministic retrieval sits entirely inside the §4.3/§9.4 exclusions, and the architecture (AD-01, FR-CORE-06) already supports it.

• FR-SRCH-01 (corpus) Two distinct indexes: (a) content — module titles and psychoeducation bodies, exercise-library entries, extension modules; (b) personal — the user's own Toolkit items and saved durable outputs (FR-CORE-09). Free-text reflections and the thought-dump journal are excluded from the personal index by default (opt-in per user): surfacing someone's worst-day journal entry unasked, next to a breathing exercise, is a foreseeable harm rather than a feature.
• FR-SRCH-02 (non-AI by design) Deterministic keyword matching over a curated synonym/tag vocabulary authored as content data — e.g. "catastrophising", "worry spiral", "can't switch off" tagged to Module 6 / thought reframing. No embeddings service, no query reformulation, no generative answers. Vocabulary authoring: OPEN-27.
• FR-SRCH-03 (results) Typed, grouped results — Modules · Exercises · My Toolkit · Extensions — each deep-linking; exercise results are directly runnable (FR-CORE-06). Only released content appears: the index is built at publish time over copy_status = final, locale-appropriate content only — no placeholder or wrong-locale leakage via search.
• FR-SRCH-04 (entry points) Home and the Toolkit at minimum.
• FR-SRCH-05 (privacy — binding) Search executes entirely client-side: the content index ships inside the content bundle (the corpus is small — one programme and a bounded exercise library), and the personal index is built locally over the user's cached data. Queries over mental-health content are themselves sensitive: they shall never appear in a URL or GET parameter, never be transmitted to any server, and never be logged in analytics, telemetry, or crash reports (NFR-SEC-06, FR-DATA-05). No server-side search endpoint shall exist in v1 (AD-09). Search consequently works offline (NFR-PLAT-04).
• FR-SRCH-06 (crisis-term routing) Self-harm and crisis language is a foreseeable search. A locally evaluated, clinically reviewed crisis-term list (content data — OPEN-27) shall cause matching queries to surface the §8.3 signposting card pinned above any results — never a bare empty state, and never content results alone (NFR-SAFE-07). The event is logged de-identified as a safeguarding_event with rule id only; the query text is never logged. Transparency: the privacy notice shall disclose that a local, non-transmitted term list exists solely to surface help resources. This is independent of the NFR-SAFE-04 decision — routing on an explicit query is answering what the user asked, not scanning what they wrote — so it remains valid even if Minni chooses NFR-SAFE-04 option 1 (no scanning).
• FR-SRCH-07 (index lifecycle) The content index is versioned with, and invalidated by, the content bundle; the Content Service builds it at publish time (§9.2).

7.9 Post-programme steady state (NEW in v4 — provisionally resolves OPEN-14)

Courses end; products don't. The steady state is the renewal story the org buyer ultimately pays for, and under the v4 framing it is simply the product with the scaffolding removed: the skills interface, kept.

• FR-POST-01 Completing the core shall never present a dead-end. On core completion, Home reconfigures: Toolkit primary (FR-TK-09); "Right now" and Emergency Tools persistent; the extension library surfaced; search available.
• FR-POST-02 An optional light check-in shall remain available (user-initiated, or opt-in scheduled), feeding only the personal trend view (FR-PROG-04). Never mandatory, never nagged (UX-06, UX-09).
• FR-POST-03 Extension modules are completable in any order and at any pace; each deposits into the Toolkit per FR-CORE-07.
• FR-POST-04 Any exercise remains re-runnable from Toolkit or search indefinitely. Whether completed core modules are revisitable read-only or fully re-runnable is a small open detail recorded under OPEN-14 for Minni's sign-off.
• FR-POST-05 Post-programme activity appears in organisational reporting only as the standard aggregates ("sustained use" — §8.2A FR-ORG-01), under NFR-PRIV-05/10. This is the renewal evidence, produced with no new data collection.

---

8. Non-Functional Requirements

8.1 Security

• NFR-SEC-01 TLS 1.2+ in transit; encryption at rest for all stores.
• NFR-SEC-02 Free-text therapeutic content encrypted with a distinct key from operational data; key rotation supported.
• NFR-SEC-03 Authentication: passwordless email magic-link or org SSO. Session tokens short-lived with refresh; device revocation supported.
• NFR-SEC-04 Role separation enforced at the data layer: an org-admin role must be technically incapable of reading individual user records — not merely hidden in the UI. Enforce with row-level security or equivalent.
• NFR-SEC-05 Full audit logging of any staff/admin access to user-level data; internal access to free text requires break-glass with justification.
• NFR-SEC-06 No sensitive content in URLs, logs, analytics events, or crash reports. Scrub free text from error telemetry.

8.2 Privacy, GDPR & organisational reporting

The target market includes Finland/EU and the data is mental-health-related. Treat this as special category data under GDPR Art. 9.

• NFR-PRIV-01 A DPIA shall be completed before pilot launch.
• NFR-PRIV-02 Controller/processor roles shall be documented and contractually agreed. Recommendation: Minimente is the controller for employee wellbeing data and the employer is not — otherwise the employer arguably has access rights to employee health data, which destroys the product's core promise. This is a legal decision and must be made explicitly, not by default (OPEN-11).
• NFR-PRIV-03 Processing of health-adjacent data shall be on the basis of explicit consent obtained at onboarding, with a plain-language explanation and the ability to withdraw.
• NFR-PRIV-04 Onboarding shall state prominently and unambiguously: your employer cannot see your individual answers, ratings, or reflections. This directly serves the "low-threshold anonymous mental health service" positioning and is the single biggest driver of employee adoption.
• NFR-PRIV-05 (k-anonymity) Organisational reporting shall only display an aggregate when the underlying cohort is ≥ 10 active users; below that threshold the dashboard shall show "not enough data". No filtering/segmentation (team, role, office, tenure) that could reduce a cohort below the threshold shall be offered in v1.
• NFR-PRIV-06 Free-text fields shall never be surfaced in organisational reporting, in any aggregated, summarised, sampled, or AI-summarised form. (This includes Module 15's programme_feedback — quote-level feedback shall only be shared with the employer if separately and explicitly consented.)
• NFR-PRIV-07 Data subject rights: in-app export (machine-readable) and account deletion with hard delete within 30 days; deletion shall not require contacting the employer.
• NFR-PRIV-08 Data residency in the EU. Sub-processors documented and disclosed.
• NFR-PRIV-09 Retention policy defined per data class (recommendation: free text retained while account active + 12 months; aggregate metrics retained pseudonymously). Currently undefined in all sources.
• NFR-PRIV-10 (temporal k-anonymity — new in v4) NFR-PRIV-05 gates cohort size but not time-slicing: a daily aggregate over a just-above-threshold org still lets an employer infer the workforce's reaction to a specific internal event (a reorg announcement, a layoff rumour). Organisational aggregates shall therefore be reported at weekly or coarser granularity in v1, with no date-range filtering finer than a week.

8.2A Organisational dashboard & adoption kit — minimum specification (NEW in v4)

The buyer's surface was the least-specified thing in v2 (OPEN-22, filed P3) while being what the buyer actually pays for. v4 specifies it now; it is still built in Phase 3 (§11 item 16). Design principle, per the product owner: the employer isn't buying therapy, they're buying confidence — and the dashboard is also where the anonymity promise becomes visible and credible to both sides.

• FR-ORG-01 (minimum dashboard) Adoption funnel (seats invited → activated (Module 1 complete) → core completed), weekly aggregate stress & energy trend, core-completion rate, aggregate recommendation score, and post-programme sustained use (§7.9 FR-POST-05). All gated by NFR-PRIV-05 (k ≥ 10) and NFR-PRIV-10 (weekly-or-coarser). No individual-level view exists in any form (NFR-SEC-04).
• FR-ORG-02 (trust-framed threshold state) The below-threshold state is a designed feature, not an error: "Not enough participants yet — we intentionally show nothing until at least 10 employees are active, so no individual can ever be inferred." Treat this sentence as product copy and a sales asset, not an empty state.
• FR-ORG-03 (the anonymity wall) The dashboard shall include a permanent, plain-language statement of exactly what the employer can and cannot see. Showing the buyer the wall is how the employee promise (NFR-PRIV-04) becomes credible to both sides.
• FR-ORG-04 (leadership one-pager) An exportable (PDF) summary of FR-ORG-01's aggregates for the HR buyer to take to leadership.
• FR-ORG-05 (adoption kit) A launch kit for the organisation: invite email templates, manager comms guidance, a launch-plan checklist, and FAQ copy centred on the anonymity promise. Pure content, cheap to produce, and the direct mitigation for Top Risk 3 (single-digit activation). Ships as part of the pilot package.

Remaining open under OPEN-22: visual design; the per-org configuration UI (crisis resources and occupational-health contact — cf. §7.3 PR-03, NFR-SAFE-02); pilot-report format.

8.3 🚨 Safeguarding / crisis-safety flow — P0 GAP

None of the three source documents specify what happens when a user is in distress. The deck says the product is "not suitable for psychological emergency or crisis situations" — but says nothing about how the product detects, responds to, or routes such situations. For a mental-health product sold into workplaces, this is the most serious gap in the material and is a launch blocker, not a nice-to-have.

Minimum required design (proposed — requires Minni's and legal/clinical sign-off):

• NFR-SAFE-01 (Disclaimer) At onboarding, the user shall be shown and shall acknowledge a clear statement: Minimente is a self-help programme, is not a crisis service, does not provide diagnosis, and does not replace occupational healthcare or emergency services.
• NFR-SAFE-02 (Always-visible signposting) A persistent, low-friction "Need urgent help?" entry point shall be present on Home and within the Emergency Tools surface, showing country-configurable crisis resources (e.g. for Finland: emergency number 112, Mieli Crisis Helpline; for the UK: 999, Samaritans) plus the employer's own occupational-health contact where the organisation has provided one.
• NFR-SAFE-03 (Passive escalation rule) A safeguarding prompt shall be surfaced when a defined risk pattern occurs — proposed initial rule: stress_rating ≥ 9 on 3 of the last 5 check-ins, OR any check-in at 10. The prompt shall be supportive, non-alarming, non-blocking, dismissible, and shall offer both an Emergency Tool and the signposting resources. Written by Minni, not by engineering. v4 amendments: (a) the rule shall evaluate check-ins over distinct calendar days, not consecutive submissions — v4 removes the daily cap (FR-CORE-04), so several modules completed in one sitting must count as one day's signal or the "3 of the last 5" pattern becomes meaningless; (b) the numeric thresholds are defined against the 1–10 scale — if OPEN-26 changes the granularity they must be re-derived with clinical sign-off, never rescaled arithmetically by engineering (the 10-point option leaves them untouched).
• NFR-SAFE-04 (Free-text scanning — DECISION REQUIRED) The product collects extensive free text in which a user could disclose self-harm intent. There are three options and the founder must choose: 1. No scanning. Simplest and most privacy-preserving; relies entirely on always-visible signposting. Must be stated honestly in onboarding: no one reads what you write. 2. Client-side keyword prompt. A local, non-transmitted keyword check that surfaces the crisis resources card. No server-side flagging, no human review. 3. Server-side classification with human review. Requires a staffed response capability, a documented escalation protocol, and materially stronger consent language. Do not choose this without a clinical governance function. Recommendation for v1: option 2, combined with NFR-SAFE-02 and NFR-SAFE-03.
• NFR-SAFE-05 Under no circumstances shall a safeguarding event trigger a notification to the employer, HR, or a manager.
• NFR-SAFE-06 Safeguarding events shall be logged (safeguarding_events) in de-identified form for product-safety review only.
• NFR-SAFE-07 (search crisis routing — new in v4) A search whose query matches the locally evaluated crisis-term list (§7.8 FR-SRCH-06) shall surface the NFR-SAFE-02 signposting card pinned above any results — never a bare results list or empty state. Logged de-identified with rule id only; the query text is never logged. This is the explicit-query counterpart to NFR-SAFE-04 and is independent of whichever free-text-scanning option Minni chooses there: responding to what a user deliberately asks for is not surveillance of what they write.

8.4 Accessibility

• NFR-A11Y-01 WCAG 2.1 AA on both web and mobile.
• NFR-A11Y-02 (amended in v4) Check-in and rating inputs shall be tappable discrete controls (segmented scales with labelled endpoints), not drag sliders — resolving v2's internal tension, where this NFR criticised the very control the spec elsewhere mandated. They shall be keyboard-operable and screen-reader-announced, with a numeric entry alternative; each segment meets NFR-A11Y-07's target size. Point count (5 vs 10) is an open user-testing question — OPEN-26.
• NFR-A11Y-03 All audio-guided exercises shall have a complete, always-available text transcript (this is both an accessibility and a silent-office requirement).
• NFR-A11Y-04 Body-based exercises (Modules 2, 5, 11; desk stretch) shall include adaptation copy for users who cannot stand, move freely, or close their eyes.
• NFR-A11Y-05 Support OS text scaling to 200% without loss of function; respect reduced-motion preferences (relevant to breathing pacers and the Recovery Wheel).
• NFR-A11Y-06 Colour shall not be the sole carrier of meaning (relevant to the Recovery Wheel categories).
• NFR-A11Y-07 Minimum 44×44pt touch targets.

8.5 Platform parity, offline, and office-friendliness

• NFR-PLAT-01 Feature parity between mobile and web for all user-facing programme functionality. Push notifications and background timers may degrade gracefully on web.
• NFR-PLAT-02 Silent-mode friendly by default: no audio autoplay, no sound effects, no haptics unless enabled; the entire programme shall be completable with the device muted.
• NFR-PLAT-03 A "headphones recommended" hint before audio exercises, with an explicit "read instead" path.
• NFR-PLAT-04 Offline: today's module and all Emergency Tools shall be usable offline once cached; writes shall queue and sync on reconnect with conflict-free last-write-wins per field.
• NFR-PLAT-05 Discretion: the app shall not display large obvious "mental health" branding on screens likely to be visible to colleagues; consider a subdued visual mode. (Derived from the "low-threshold, anonymous, used at the desk" positioning; not explicitly in sources — confirm with Minni.)
• NFR-PLAT-06 Performance: session screens shall render in <1s on a mid-range device over 4G; module content shall be prefetched for the current day.

8.6 Internationalisation

• NFR-I18N-01 All user-facing strings shall be externalised into a translation layer from day one, including module content, option lists, button labels, and notification bodies. The source content already contains leaked Finnish; the market decision is unmade; retrofitting i18n into a content-heavy product is expensive.
• NFR-I18N-02 Content shall be versioned per locale, so an English module can be final while its Finnish translation is placeholder.

---

9. Technical Architecture Recommendation

Deliberately vendor-neutral; shapes and responsibilities, not brand names.

v2.0 update — a concrete stack was proposed in March 2026 and never ratified. Source D (slide 8) proposes: React Native (or PWA) | Node.js / Supabase | PostgreSQL | Vercel / Railway | Lottie (animations), with the guidance "Start with PWA for fastest time-to-market, migrate to native if needed." Slide 9 then lists "Decide tech stack: PWA vs React Native" as an open next step — so the deck proposes and defers in the same breath, and the repo contains no evidence any decision followed (§1A.1: no package manifest of any kind).

This is worth recording because Source D and this PRD converge independently: "start with PWA" matches AD-02, and "PostgreSQL" matches §9.1's Postgres-shaped primary DB with RLS (AD-04). Supabase in particular would satisfy AD-04 directly, since row-level security is native to it. That convergence is supporting evidence, not a decision. The stack remains formally open — see OPEN-24 — and one caution applies: the Lottie/React Native pairing in the deck was chosen with the breathing animation in mind, but the prototype already implements that pacer in plain React with CSS transitions, so animation tooling should not drive the platform choice.

v4 update — two additions to the shape below. (1) The Content Service additionally owns the exercise library (FR-CORE-06) and builds the client-side search index at content-publish time (§7.8); the client gains a single exercise runtime shared by modules, Toolkit, Emergency Tools, "Right now", and search results. (2) There is deliberately no server-side search endpoint in v1 — search ships as an index inside the content bundle and runs locally (AD-09). The diagram is otherwise unchanged from v2.

9.1 Shape

┌──────────────────────────────────────────────────────────┐
│ CLIENTS                                                   │
│  Responsive web app (PWA) — primary                       │
│  Mobile: same codebase wrapped, or thin native shells      │
│  ── Screen-component library (types: §6.0)                 │
│  ── Local content cache + offline write queue              │
│  ── Timer/pacer engine (box breathing, Focus Window)       │
└────────────────────────┬─────────────────────────────────┘
                         │ HTTPS / JSON
┌────────────────────────▼─────────────────────────────────┐
│ API GATEWAY  (authn/authz, rate limiting, tier gating)    │
└──┬──────────┬────────────┬──────────┬────────────┬───────┘
   │          │            │          │            │
┌──▼───┐ ┌───▼──────┐ ┌───▼─────┐ ┌──▼───────┐ ┌──▼─────────┐
│Ident.│ │ Content  │ │Programme│ │Notific-  │ │ Reporting  │
│& Org │ │ Service  │ │& Response│ │ation Svc │ │ & Aggreg.  │
│ Svc  │ │(versioned│ │  Service │ │(push/    │ │(k-anon     │
│      │ │ modules) │ │+ Toolkit │ │ email/   │ │ rollups)   │
└──┬───┘ └───┬──────┘ └───┬─────┘ │ schedule)│ └──┬─────────┘
   │         │            │       └──┬───────┘    │
┌──▼─────────▼────────────▼──────────▼────────────▼────────┐
│ PRIMARY DB (Postgres-shaped, EU region, RLS enabled)      │
│  + separate encrypted store/keyset for free-text content   │
│ OBJECT STORE: audio files, illustrations, icons            │
│ EVENT STORE: completions, tool usage, rule firings         │
└───────────────────────────────────────────────────────────┘
        ┌───────────────────────────────────────┐
        │ POST-MVP (tier-gated, not v1):        │
        │  Therapist Messaging Service (T2)     │
        │  Booking / Scheduling Service (T3)    │
        │  Clinician console                    │
        └───────────────────────────────────────┘

9.2 Component responsibilities

9.3 Key architectural decisions

• AD-01 — Content as data, not code. The single most important decision. Modules 12–15 lack copy; Modules 11–15 will change after review; new programmes are on the roadmap. A content-driven renderer means copy updates are a content publish, not an app-store release. It also lets QA test structure now and copy later.
• AD-02 — One codebase for web and mobile. A responsive PWA satisfies "mobile and web application", offline caching, and desk-based use, and avoids two content renderers. Native shells can be added for push reliability and app-store presence. Do not build separate iOS/Android/web content renderers.
• AD-03 — Generic response storage. ~35 heterogeneous fields across 15 modules, growing per programme. Use screen_responses (§7.4) rather than per-module tables.
• AD-04 — Row-level security for the privacy promise. The "your employer can't see this" guarantee should be enforced by the database, not by a UI filter.
• AD-05 — Separate keyset for free text. Enables narrower blast radius and cleaner "internal staff cannot read reflections" claims.
• AD-06 — Audio produced as files + transcripts, not TTS at runtime. Exercise scripts (Modules 1, 2, 5, 11, Emergency Tools) should be recorded once, stored in object storage, and always accompanied by transcript text. Production decision required: who records the audio, in which languages, and does v1 ship text-only? (OPEN-15)
• AD-07 — Server-anchored timers. Focus Window and paced breathing must not rely on client intervals surviving backgrounding.
• AD-08 (new in v4) — Exercise as a first-class object. One exercise library; modules, Toolkit, Emergency Tools, "Right now", search, and extensions hold references, never copies (FR-CORE-06). Scripts, transcripts, audio, and adaptation copy belong to the exercise and are authored and translated once. This generalises what v2 already implied (FR-TK-05's standalone-runnable exercises; the breathing-reset ≈ Box-Breathing overlap) and is the enabling decision for §7.7 and §7.8.
• AD-09 (new in v4) — Client-side search, zero server query exposure. The searchable corpus is small (one programme, ≤15 modules, a bounded exercise library): the index ships with the content bundle and executes locally, alongside a locally built index of the user's cached Toolkit and outputs. Queries never leave the device and appear in no URL, log, or telemetry (NFR-SEC-06, FR-DATA-05); search works offline (NFR-PLAT-04). Revisit only if the corpus outgrows client-side viability — and then only with a privacy design of equal strength.

9.4 Explicitly speculative — do not build in v1

• Microsoft Teams integration — Source A writes it as "Teams?" with no defined use case. Plausible future value (session reminders in the workflow, status-aware quiet hours), but requires a Teams app, tenant admin consent, and a privacy story about presence data. Discovery item for the pilot customer.
• AI therapist / therapist avatar in videos / AI idea exchange — Source A labels these "ideas, unconfirmed". Out of scope. Any conversational mental-health agent changes the product's regulatory classification in the EU and requires a safety framework that does not exist. Revisit only after v1 ships and with dedicated clinical governance. v4 reaffirms this after explicit challenge: the v3 review was invited to argue for conversational AI in 2027 and declined, on the merits — (a) EU AI-Act / MDR-adjacency exposure is pre-revenue-fatal; (b) the HR buyer's stated fear (§3.2: "a wellbeing tool mishandling a distressed employee") makes the absence of an AI therapist a sales asset in 2027, not a gap; (c) an open-ended generative surface would multiply the still-unresolved safeguarding gap (§8.3) unboundedly. The only AI-adjacent path left open is bounded, non-conversational personalisation (content ordering) — post-pilot, per §4.2/§4.3 — and OPEN-25's "L2 = AI" slide does not pre-authorise even that until Minni settles the tier ladder.
• AI-based personalisation — Source B's future-expansion list. Requires the pilot's data first. §7.3's three rules stand for v1.
• Wearables / passive physiological or behavioural monitoring — excluded, not deferred (new in v4). By 2027 passive sensing is table stakes in consumer wellness, which is exactly why it must be ruled out here explicitly: inside an employer-funded mental-health product it is irreconcilable with the anonymity promise as employees will perceive it (NFR-PRIV-04), collects continuous special-category data the product does not need, and pushes towards medical-device classification. Binding per §2.3; do not let a future roadmap "modernise" this in.

---

10. Open Questions & Risks

Ordered by severity. P0 = blocks launch. P1 = blocks build of the affected area. P2 = needs a decision before pilot.

Top risks

1. Content risk (highest). The project's premise — "the content is done" — is not true. Roughly 30% of the programme has no user-facing text, and the missing part is exactly the emotionally hardest content (self-compassion, emotional needs, closure). This is on the critical path and only Minni can clear it. v4 mitigation: under the provisionally adopted Core+Extensions structure, the missing module copy (11–15) no longer blocks launch — the core is fully authored — but it still gates the extension library and the closure module, and the Emergency-Tool scripts (OPEN-06) remain a hard launch blocker either way.
2. Safeguarding risk. Shipping a workplace mental-health product with no crisis flow is an unacceptable exposure for both Minimente and the pilot customer, and is likely to fail HR procurement review regardless. v4 note: the "Right now" entry (§7.7) and search (§7.8) both raise the prominence of acute-moment use — OPEN-10 and OPEN-06 are more critical in v4, not less, and both new surfaces are explicitly gated on that content existing (FR-NOW-06, OPEN-27).
3. Adoption risk. Employer-funded wellbeing tools commonly see single-digit activation. The anonymity promise is the primary mitigation and must be prominent, credible, and technically true.
4. Scope risk. Tiers 2 and 3 look like features but are operating models. Attempting them before Tier 1 is validated would stall the project again.
5. Trust/compliance risk. EU special-category data plus an employer relationship means a DPIA and clear controller assignment are prerequisites to a signed pilot, not follow-ups.
6. Prototype-as-foundation risk (new in v2.0). A runnable Day-1 prototype exists and looks convincing. It hardcodes content as JSX, has no persistence, and no auth — it is the direct opposite of AD-01. The risk is that its apparent completeness invites building forward from it, which would bake in the content/code coupling the architecture exists to avoid. Treat it as a visual and interaction reference to be reimplemented, never as a starting branch. Its palette, breathing pacer, and screen sequence are worth keeping; none of its data handling is.
7. Stalled-restart risk (new in v2.0). The March 2026 plan (Source D) proposed a 4–6 week MVP and produced a prototype, a briefing, and then nothing — the repo was never even initialised, and four months passed. The binding constraint on the restart is content and decisions from Minni (OPEN-03, OPEN-01, OPEN-18, OPEN-04, OPEN-10), not engineering capacity. Starting engineering without clearing Phase 0 would reproduce the same stall with more code to maintain.
8. Provisional-decision risk (new in v4). v4 provisionally adopts four decisions that reshape the programme Minni authored — sequence-lock (FR-CORE-04), Core+Extensions (OPEN-18/01), the Daily-Action taxonomy (OPEN-28), and the post-programme state (§7.9). They are recorded with their reasoning precisely so she can overturn any of them — but building against them before her sign-off (Phase 0 item 1) would reproduce the source-drift this document exists to prevent, with running code this time. Conversely, note the sign-off is one working session, not a project: the decisions are already argued and specified.

---

11. Suggested Next Steps & Phasing

Updated from Source A's Define → Design → Prototype → Pilot, reflecting that content is mostly — not fully — complete.

v2.0 status against reality (§1A). Nothing in this plan has been started. Phase 0: 0 of 5 items complete. Phase 1: 0 of 5. Phase 2: 0 of 5. Phase 3: 0 of 4. Phase 4: 0 of 4. The plan is not revised downward — it is revised to add a preceding step that v1.0 assumed already existed, and to record what the March-2026 prototype legitimately saves.

Two items get cheaper than v1.0 assumed: Phase 1 item 9 (design system) starts from an existing palette and component set rather than a blank page, and Phase 2 item 13 (internal timing test of the 5–12 min claim) can be run this week on the existing prototype, before any build — it needs no engineering at all and would de-risk the core session-length premise early. Everything else stands unchanged.

One item gets harder: Source D proposed a 4–6 week MVP covering Days 1–4. That estimate predates the discovery that ~30% of the programme has no copy and that no crisis-safety design exists. It should not be quoted to anyone.

v4 delta. The adopted changes are mostly requirement refinements sitting on the architecture already designed, but two are genuinely new build items — the exercise library + runtime (implicitly needed anyway: FR-TK-05 always required standalone-runnable exercises) and the client-side search index. Budget roughly one extra week in Phase 2; the owner's claim of "no material engineering increase" is approximately true, not exactly. One new gate is added to Phase 0: Minni's sign-off on the v4 provisional decisions (item 1). Two new authored artefacts join Phase 0: the "Right now" labels/routing table and the search vocabularies (item 5a).

Phase −1 — Initialise (days, not weeks) · owner: eng · NEW in v2.0 — prerequisite to everything

This is Source D's step 03 ("Set up project repo, CI/CD, and design system"), never performed. It is small, but it is genuinely blocking: there is currently nowhere to put code.

• 0a. git init the repo; establish the remote; commit this PRD (v4) and its predecessor (v2) as the first artefacts.
• 0b. Rescue the unversioned artefacts. minimente-prototype.jsx, minimente-prototype.html, the briefing deck, and the source-material zip exist only in ~/Desktop/Misc/MiNNi/ with no backup and no history. Commit them to a reference/ directory — explicitly as reference material, not as the application (see Risk 6). Source C (.docx) is not in the zip and should be exported from Drive and committed alongside them, since it is the canonical content source and currently exists only in Google Drive and in this PRD's summary of it.
• 0c. Ratify the stack (OPEN-24) and record the decision in-repo as an ADR.
• 0d. Scaffold: package manifest, lockfile, linter/formatter, test runner, CI, .env.example. No application logic.

Phase 0 — Unblock (weeks 1–2) · owner: Minni, in parallel with engineering setup

1. Resolve the structural decisions — canonical module titles/themes (OPEN-04); 14 vs. 15 days (OPEN-01); linear vs. core+optional (OPEN-18). v2.0 — promoted ahead of the authoring task, deliberately. OPEN-04 is not a naming cleanup: Module 13 is either "Meaning & Motivation" (March) or "Understanding Your Emotional Needs" (July), and since its body copy is missing either way, this decides which module gets written. Authoring before deciding risks writing the wrong module. v4: this same session now also ratifies (or overturns) the provisional decisions — sequence-lock (FR-CORE-04/OPEN-13), Core+Extensions incl. the closure module's position (OPEN-18/OPEN-01), Daily-Action endings (OPEN-28), the post-programme state (§7.9/OPEN-14), and the skills-first Toolkit framing (§7.1). One working session covers all of it; nothing in Phase 1+ that depends on these should start before it.
2. Recover or re-author Modules 12–15 body copy and Module 11's psychoeducation + 4 branch scripts (OPEN-03, OPEN-02). Highest priority single authoring task in the project, and the longest pole overall. First check whether the pre-edit draft still exists in Minni's working files or Drive version history — Source C's placeholders ("keep your current text unchanged") imply a prior draft that did not survive export, so recovery may be far cheaper than re-authoring.
3. Write the missing Emergency Tool scripts (OPEN-06) — four or five depending on the progressive-relaxation decision (§7.2).
4. Confirm the Recovery Wheel icons and the completion celebration asset (OPEN-05).
5. Decide the safeguarding model (OPEN-10) and draft its copy. - 5a. (v4) Author the "Right now" state labels and routing table (§7.7) and the search synonym + crisis-term vocabularies (OPEN-27) — small artefacts, produced alongside items 3 and 5 while Minni is already in the content.

Phase 1 — Define & Design (weeks 1–4) · engineering + design, in parallel

6. Ratify this PRD with Minni; close all P0/P1 open questions.
7. Specify the content JSON schema and the screen component types (§6.0) — this is the first engineering deliverable and everything else depends on it. v4: the schema now includes the exercise library (FR-CORE-06) as a top-level content entity, per-context exercise overrides, the Daily-Action ending taxonomy (FR-CORE-08), and the publish-time search-index build (AD-09, FR-SRCH-07).
8. Finalise the data model (§7.4) and the privacy enforcement design (RLS, key separation, k-anonymity threshold).
9. Design system: session shell, progress indicator, rating-control patterns, Toolkit, Emergency Tools surface, safeguarding card. v2.0: not a blank page — the prototype supplies a working palette, progress bar, button, and box-breathing pacer to extend or deliberately reject. Its 1–10 drag slider is now rejected by requirement (NFR-A11Y-02 as amended) and its category icons are raw emoji (§6.3 recommends against), so the existing components need reworking, not straight reuse. v4 additions: the Toolkit-first home (co-primary card, FR-TK-09), the "Right now" surface (§7.7), the tappable discrete rating control in both 5- and 10-point variants for the OPEN-26 test, and the §8.2A dashboard including its trust-framed threshold state (design now, build Phase 3).
10. Start the DPIA and settle the controller/processor question (OPEN-11).

Phase 2 — Prototype (weeks 3–8)

11. (v4 amended) Build the exercise runtime + exercise library first (FR-CORE-06 — everything references it), then the content renderer plus Modules 1–5 end-to-end, including check-in, personalisation rules, Toolkit accrual from Day 1 (FR-CORE-07/FR-STD-07), Daily-Action endings (FR-CORE-08), output destinations (FR-CORE-09), reminders, and resume-later.
12. Build Emergency Tools and the safeguarding/signposting flow before any external testing.
13. Internal test with friends/family (as Source A envisaged) on Modules 1–5, measuring the real per-session duration against the 5–12 minute claim. v2.0: a first pass at this is available immediately — the existing Day-1 prototype is runnable and its copy is final, so the session-length premise can be timed with real people during Phase 0/−1, months ahead of the built product. Cheapest available de-risking in the plan. v4: the same test also runs the OPEN-26 scale comparison (5- vs 10-point) — decide before pilot.
14. Build the Personal Stress Toolkit views and Modules 6–10 (Module 10 is the most technically involved: dynamic option population from the user's own prior answers — and under v4 it is a curation pass over the already-accrued Toolkit, FR-M10-02 as amended).
15. Build the extension modules (former 11–15) structurally behind copy_status = placeholder; wire copy in as Minni delivers it. - 15a. (v4) Build the "Right now" entry (§7.7) and client-side search (§7.8). Hold both dark until the Emergency Tool scripts (OPEN-06) and the OPEN-27 vocabularies exist — a moment-of-need surface with empty tools behind it is worse than none (FR-NOW-06).

Phase 3 — Pilot-ready (weeks 8–14)

16. Org provisioning, invite flow, and the organisational dashboard + adoption kit to the §8.2A specification (OPEN-22), including NFR-PRIV-10's weekly-or-coarser aggregation.
17. Accessibility audit (WCAG 2.1 AA) and a security review.
18. Full content QA pass: no placeholder text, no mojibake, no Finnish leakage in any released module. This should be an automated check in CI against the content documents, not a manual read-through.
19. Complete the DPIA; prepare the DPA template and privacy notice for the pilot customer.

Phase 4 — Pilot (weeks 14+)

20. Resume Minni's leads list and HR outreach with a working Tier 1 product.
21. Run one company pilot; instrument against §4.4's metrics.
22. Use pilot data to answer: pricing validation (OPEN-12), whether personalisation needs to be smarter than three rules, whether Teams integration matters (OPEN-21), post-programme sustained use (§7.9, FR-POST-05), Toolkit-offer acceptance rates (FR-STD-07 declines are a signal), and "Right now" routing usefulness (right_now_events).
23. Only then scope Tier 2 (therapist messaging).

---

Appendix A — Source reconciliation log

Extended in v2.0 with Source D (dev briefing, Mar 2026) and E (the prototypes). Where D and the prototype agree with B against C, the disagreement is a four-month content evolution, not an internal inconsistency — this reframes OPEN-04 and OPEN-18. v4.0 adds Appendix A.1, the disposition log for the v3 review-and-response cycle.

Appendix A.1 — v3 review / v4 adoption log (NEW in v4)

Disposition of every item in the v3 design review and the product owner's response. "Provisional" = adopted in this document but requiring Minni's sign-off (Phase 0 item 1) because it reshapes the programme she authored.

End of PRD v4.0 draft. (v2.0 closed with a stale "End of PRD v1.0 draft." footer; corrected here.)