1. Purpose
This document ensures Aevum is built around understandable human use rather than internal taxonomy. Personas exist to shape the starting companion behavior, not to permanently classify the user.
- Personas must be clear, non-ambiguous, and easy to self-select.
- Journeys must reflect how people actually arrive, return, capture, and stay.
- Onboarding must feel companion-like, not like a quiz or enterprise form.
2. Persona Model
Model Rule
Aevum uses a two-layer persona system:
- Visible user persona: a clear real-world role or life mode the user recognizes immediately.
- Hidden cognitive mapping: internal defaults that shape how the companion starts responding.
Selection Rule
- User must select one primary persona.
- User may select one optional secondary persona.
- Persona selection is reversible and not treated as permanent identity.
3. Approved Personas
The following set is the approved Aevum 1.0 onboarding persona model.
4. Onboarding Experience
Onboarding Intent
The onboarding screen is not a classification tool. It is the user’s first moment of being understood.
Approved Heading
“What feels most like you right now”
Approved Supporting Copy
This helps Aevum shape your starting experience. You can change this later.
Interaction Rules
- User selects one primary persona.
- After primary selection, the screen softly auto-scrolls to reveal secondary selection and Continue.
- User may select one optional secondary persona.
- The same persona cannot be selected twice.
- QWEN / local companion startup occurs only after Continue.
First Companion Prompt Rule
The first prompt must feel specific and natural, not vague or theatrical. If local model grounding is unavailable, deterministic fallback copy must still feel useful.
5. Core Journey Map
| Journey | User Intent | Aevum Requirement |
|---|---|---|
| First Launch | Understand what this is and whether it fits them. | Clear introduction, low-friction persona selection, first useful companion moment. |
| Immediate Thought Capture | Get a thought out quickly before it disappears. | Fast capture, immediate save, visible result, no waiting for enrichment. |
| Return for Reflection | See whether Aevum remembers what matters. | Grounded context retrieval and continuity in response. |
| Import Existing Material | Bring in prior context to strengthen memory. | Importer is discoverable, import is visible immediately, no invisible queue-only path. |
| Habitual Use | Make Aevum part of daily cognition. | Reliable capture, low friction, increasing usefulness over time. |
6. Retention and Habit Loop
Retention Thesis
Users stay when Aevum feels like it remembers what matters and becomes more useful as their context grows.
Habit Loop
- User has thought, pressure, or fragment.
- User captures it quickly.
- Aevum reflects it back with continuity.
- User feels understood.
- User returns because value compounds.
Retention Risks
- Companion responses feel generic.
- Imports disappear or feel invisible.
- Memory continuity is not surfaced.
- Onboarding feels abstract instead of recognizing the user.
7. Emotional UX Requirements
- Aevum must feel calm, private, and non-performative.
- It must not sound like therapy filler, generic AI filler, or enterprise jargon.
- It must feel perceptive early, but never invasive.
- User should feel recognized in under 3 seconds on the onboarding persona screen.
- The product should invite thought, not pressure the user into explaining themselves.
8. Journey States and Outcomes
| State | Required Product Outcome |
|---|---|
| Empty State | User understands what to do next and why it is worth doing. |
| First Capture | User sees immediate proof that the thought was saved. |
| Companion Reply | User receives a grounded answer, not generic acknowledgment. |
| Import Completed | User sees imported material as visible memory/log entries. |
| Return Session | User experiences continuity across time. |
9. Acceptance Criteria
- Required: Persona model matches the approved 10-persona set.
- Required: Onboarding heading and interaction behavior match the approved baseline.
- Required: User can complete onboarding with one primary and optional secondary persona.
- Required: First companion interaction persists through the canonical ingestion path.
- Required: Core journeys are supported end-to-end without dead controls or invisible processing.
- Rejected if: persona cards become vague archetypes or onboarding becomes form-like and impersonal.