· Product & AI Workflow

How a user moves through Mindlid v2 — from onboarding to a completed four-session program — and the product architecture principles that support orchestration, multilingual delivery, reliability, and continuity.

Wellness disclaimer: Mindlid is a therapy-inspired, non-clinical emotional wellness and self-help product. It is not a substitute for professional support. If you are in crisis, contact a qualified professional or local emergency services.

Public architecture note: This page shows an illustrative product and AI workflow. Production implementation details, internal service names, model routing, thresholds, and operational controls have been simplified or omitted.
Toggle to reveal high-level orchestration, reliability, multilingual handling, and state continuity. Click any screenshot to enlarge.
1

Stage 1Onboarding

The user picks a language (English or Turkish), moves through static intro screens, and answers 10 profile questions in a chat-style intake. Answers are collected locally — no AI call per answer — and submitted together at the end.

Language & intro screensbundled EN/TR copy
→
10 profile questionscurrently returned in English
→
Submit all answers togetherone batch, no per-answer AI
→
Profile summary createdstored, powers everything later

Architecture principles · onboarding

Profile context

  • A structured profile context is created after onboarding
  • Input: complete answer set
  • Output: reusable profile context for later stages

Design principle

  • Profile context is created once and reused across later stages.
  • Language handling is kept separate from the core personalization flow.
Language selection screen
Language pick
Profile intake questions
Profile intake
2

Stage 2Program creation

The user enters their main challenge (or chooses a program type). Mindlid names the program, writes its description, and builds the four predefined steps. Language handling happens before the core program logic so the same workflow can serve supported languages.

Main challenge enteredsafety & limit checks on raw input
→
Program named & describedfrom challenge + profile summary
→
Four steps builtpredefined STEP configurations
→
User starts programdisplay text localized if Turkish

Architecture principles · creation

Language handling

  • User input is normalized for the core workflow when needed.
  • Localized display is handled separately from program generation.

Program generation

  • Creates a program name and description
  • Inputs: profile context + main challenge
  • Outputs: structured program framing for the user

Program structure

  • Builds four predefined session stages
  • Program and session display text is localized through the language layer when needed
Program creation — choose type
Program creation
Program details with four steps
Program ready
3

Stage 3One program, four steps

Every program is the same four-step arc. Each step defines what that part of the program should ask, collect, and generate — and each is completed through one live session. Session data accumulates: every step carries everything learned before it.

Stage 1 · Session 1

Recognize

Focus, trigger, emotions, body sensations, intensity, next small step

Interaction length: bounded
state carries forward
Stage 2 · Session 2

Identify

Automatic thought, possible core belief, cognitive distortions, next small step

Interaction length: bounded
cumulative state carries forward
Stage 3 · Session 3

Test & Expand

Evidence for/against, balanced thought, SMART experiment, next small step

Interaction length: bounded
cumulative state carries forward
Stage 4 · Session 4

Commit

Action plan, If-Then plan, confidence, ending intensity, next-time reminder

Interaction length: bounded
final cumulative state

Vocabulary

Step vs session

  • A step defines the purpose of that stage; a session is the user's live interaction with it. One program ≈ four sessions.

Framework ≠ workflow

  • Program frameworks define the type of guidance; the runtime workflow shown here is the shared delivery pattern.
4

Stage 4Session runtime — repeated for each session stage

The user talks with Mindlid in short guided exchanges. Each turn, the session orchestrator decides whether to keep exploring or move to controlled completion. Language handling happens invisibly around the core interaction.

User turnmessage submitted
→
Language handlingnormalize input when needed
→
Guardrail checkbounded interaction
→
Session orchestratorguides the exchange and collects structured state
continue → response shown, loop repeats complete → controlled completion unexpected output → fallback completion path interaction bound reached → controlled completion
Session completion layercloses the stage consistently and prepares validated state for continuity
→
Localized displayrender in the selected language
→
Assistant turn shownin the selected language
Each exchange updates the latest cumulative session state so context can carry forward until the stage completes.

Architecture principles · per exchange

Context used

  • Current user message
  • Profile context + main challenge
  • Relevant session context
  • Prior cumulative session state
  • Current stage configuration

Structured outputs

  • User-facing response content
  • Stage progress and completion status
  • Updated cumulative session state

Operational support

  • Language-processing support
  • Operational metadata for reliability and observability
Live session chat
Live session
5

Stage 5Session close & what the user sees

When a session completes, its structured state is snapshotted and the app shows the collected session data directly — focus, trigger, emotions with intensities, the plan. This programmatic display is the active user-facing output: there is no AI-generated session summary.

Final session snapshotvalidated session state retained
→
Carries into program statefeeds the next session
→
Values localized for displayfree text only; numbers unchanged
→
Programmatic UI displaye.g. Anxiety: 5

Architecture principles · continuity

State continuity

  • Each completed session retains a validated structured snapshot.
  • Relevant completed state is carried into the next session to preserve continuity.

Display path

  • Free-text values are localized through the language layer when needed.
  • Structured values are rendered programmatically for a predictable user-facing result.

Reliability principle

  • Key session results are rendered from validated structured state rather than an unconstrained free-form summary.
Session data display — Recognize
Step 1 data
Session data display — Identify, cumulative
Step 2 — cumulative
✓

Stage 6Next session, or program complete

After each completed session the next one activates, carrying the full accumulated state forward. After session 4, the program is complete — the user keeps the whole structured record of what they recognized, identified, tested, and committed to.

Session N completeN < 4 → activate session N+1
→
Session 4 completeprogram complete

Continuity

Cumulative continuity

  • Each completed stage adds validated context to the program record.
  • Later sessions can build on what was established earlier without exposing implementation-specific state objects.
Completed program with progress
Program complete

Public architecture principles

Public case-study view. Production implementation details, internal identifiers, routing choices, thresholds, and operational controls are intentionally omitted or generalized.