1. Purpose
The PRD is the build contract between product, design, engineering, quality, security, and delivery. It defines what must exist in Aevum 1.0, what must not be diluted, and what can be deferred.
- Every major requirement in this document must be testable or reviewable.
- Every released user-facing control must have complete backend logic.
- Every core interaction must respect the local-first product policy.
2. Product Vision
Aevum 1.0 is a private, local-first intelligence companion that turns captured human thought into durable continuity. It should feel like a trusted cognitive operating layer, not a chatbot or note app.
Vision Statement
Help users think out loud, preserve what matters, and receive grounded reflection from their own evolving context.
1.0 Product Shape
Voice-first and text-capable capture, immediate local persistence, memory graph continuity, grounded companion responses, and clean import flows across device surfaces.
3. Goals and Non-Goals
Primary Goals
- Create a stable local-first thought capture and continuity system.
- Make the companion feel context-aware, private, and useful enough to form habit.
- Establish one canonical ingestion contract across all first-party input surfaces.
- Achieve an enterprise-grade foundation for privacy, control, and compliance readiness.
Non-Goals for 1.0
- Enterprise admin platform or organization-level tenancy.
- Broad external SaaS integration marketplace.
- Social or collaborative network features.
- Cloud-dependent primary cognition flows.
4. Users and Jobs to Be Done
| User | Core Job | Why Aevum Matters |
|---|---|---|
| Founder / Entrepreneur | Capture and retain strategic thought under pressure. | Preserves continuity across fragmented high-stakes thinking. |
| Builder / Product / Engineer | Track reasoning, tradeoffs, and unresolved logic. | Retains technical and product thought chains. |
| Executive / Leader | Think privately and clearly about direction and judgment. | Offers a trusted space for reflection. |
| Creative / Writer | Hold fragments until they mature into usable work. | Captures incomplete creative signal without loss. |
| Researcher / Analyst | Track idea evolution and pattern formation. | Creates continuity across long-horizon inquiry. |
| Personal Reflection User | Understand self-patterns and inner life over time. | Turns journaling into continuity and grounded reflection. |
5. Core Capabilities
Capture
- Voice capture
- Text capture
- Import capture
- Onboarding reply capture
Continuity
- Immediate root memory persistence
- Memory graph linkage
- Recent and relevant context retrieval
- Longitudinal pattern preservation
Companion Intelligence
- Persona-aware responses
- Context-grounded reflection
- Question-first response quality
- Reduced generic filler
Trust
- Local-first core operation
- Immediate visible ingestion feedback
- No hidden off-device first-party thinking path
- Deletion and privacy control readiness
6. Functional Requirements
FR-1 Capture and Ingestion
- All first-party inputs must route through one canonical ingestion boundary.
- Every user-triggered input must create an immediate visible root entry.
- Deferred enrichment must never create a second root node for the same input.
- Source provenance must be preserved truthfully.
FR-2 Dashboard Companion
- User can speak or type directly into the dashboard.
- Dashboard input must persist locally before deeper enrichment.
- Companion response must use real persona, session, and memory context when available.
- Companion must answer the user’s question before offering reflective prompts.
FR-3 Import and Omnichannel Ingestion
- Import route must open the actual import surface.
- Document import, OCR import, and audio import must appear in logs immediately.
- User must never receive queue-only success with no visible result.
FR-4 Onboarding and Persona Configuration
- Onboarding must present the approved persona set and companion framing.
- User must choose one primary persona and may choose one optional secondary persona.
- Persona selection must shape the starting companion behavior.
- Onboarding first reply must persist through the canonical ingestion contract.
FR-5 Memory and Retrieval
- System must store root thoughts, derived insights, and linked relations.
- Retrieval must be bounded and local.
- Retrieved context must be used in grounded response assembly.
FR-6 Device Experience
- iPhone is required baseline device.
- iPad and Mac are supported surfaces only if behavior is equivalent and complete.
- No control may appear on a device if the feature behind it is incomplete.
7. Non-Functional Requirements
| Area | Requirement |
|---|---|
| Privacy | Core first-party thinking flows must remain on-device by default. |
| Performance | Capture actions must feel immediate and must not require waiting for enrichment to complete. |
| Reliability | No user-facing control may silently fail or route into an incomplete backend path. |
| Security | Local data handling, deletion, and audit posture must be compatible with GDPR, SOC 2, ISO 27001, and DORA-relevant controls where applicable. |
| Accessibility | All major onboarding and capture controls must expose stable accessibility identifiers. |
| Observability | System behavior must be diagnosable via structured internal logs and deterministic test evidence. |
8. Core User Journeys
Journey A — First-Time Onboarding
- User opens Aevum.
- User experiences intro sequence.
- User selects primary persona and optional secondary persona.
- User receives first grounded companion prompt.
- User’s first response is captured and persisted locally.
Journey B — Daily Dashboard Capture
- User opens dashboard.
- User speaks or types a thought.
- Root entry is written immediately.
- Companion returns context-aware response.
- Background enrichment may continue without blocking UX.
Journey C — Import External Material
- User opens Import.
- User selects document, image/OCR, or audio.
- Imported content appears in logs immediately.
- Deferred enrichment structures and links the imported content.
9. Release Scope
| Release Tier | Scope | Status Intent |
|---|---|---|
| Baseline Alpha | iPhone core capture, dashboard, onboarding, local persistence, basic companion grounding. | Internal |
| Beta | Stable import flows, improved retrieval, stronger graph quality, compliance controls maturing. | Controlled external |
| 1.0 | Single canonical ingestion, polished companion quality, honest operational model, release evidence package. | Public/TestFlight or strategic pilot |
10. Acceptance Criteria
- Required: All first-party input surfaces use the canonical ingestion contract.
- Required: Imported items appear in logs immediately.
- Required: Companion uses real persona/session/memory context in the live path.
- Required: Package tests pass for the baseline module set.
- Required: No user-facing wording contradicts the runtime privacy model.
- Rejected if: Any visible UI control lacks real execution behind it.
11. Dependencies
- Canonical data model must be stable before deeper API and architecture freeze.
- Security/privacy baseline must be aligned before full operational readiness planning.
- Onboarding, ingestion, and response grounding must stay aligned across PRD, UX, and architecture documents.
12. Open Decisions
- Exact breadth of iPad and Mac parity in 1.0.
- How much retrieval sophistication is required for baseline grounded companion quality.
- Which enterprise controls are in-release vs readiness-phase only.
- What limited approved external services remain necessary without violating the local-first strategy.