Code-Grounded Strategic Document

Single Master HTML

Aevum Feature & Capability Master

This document articulates what Aevum is capable of today, what systems and features make those capabilities possible, and why the existing codebase is larger than a simple note-taking app. It is intentionally grounded in current repository evidence, while separating active capability from partial, prototype, inherited, and visionary layers.

Interpretation rule: A large codebase only creates enterprise and valuation value if it resolves into defensible capability layers. This document maps those layers so Aevum can be discussed as a platform thesis rather than as a bundle of screens.

Current Product Class

iPhone-First Local Intelligence Prototype

Real iPhone app, shared iOS code for iPad behaviour, no confirmed Mac product surface.

Platform Thesis

Personal Intent Operating Layer

More than capture: memory graph, persona adaptation, local inference, structured persistence, and bounded automation primitives.

Strategic Value Driver

Integrated Sovereign Stack

UI, memory, inference, graph, shortcuts, widgets, privacy posture, and local API are all represented in one codebase.

1. Status Legend

Active Partial Stub / Prototype Absent / Not Production-Realized

Major = user-visible or architecture-critical. Minor = supporting or narrow-surface. Derived = capabilities that emerge from combinations of systems. Inherited = platform or framework-level leverage captured by the implementation.

2. What Aevum Is Becoming

Aevum is not structurally organized like a simple journaling app. The codebase expresses an operating model with five simultaneous layers:

capture surfaces for thought intake
local persistence and memory modeling
intelligence and behavioural routing
graph and reflective interfaces
multi-surface invocation via widgets, shortcuts, and local API

That matters strategically because valuation at platform scale typically comes from control of an integrated workflow layer, not from any single screen. The Aevum codebase already contains the early structure of such a layer, even though some surfaces remain partial or prototype-bound.

3. Major Capabilities

Capability	Type	Status	What it means	Primary enabling features
Intent Capture	Major	Active	User can capture thought-like inputs by voice and text through the main app.	Dashboard, VoiceCaptureView, CaptureSheet, StartDictationIntent, QuickCapture widget
Local Memory Persistence	Major	Active	Captured information can be persisted locally in SwiftData-backed storage.	CoreMemoryManager, MemoryEntry, MemoryEngine, SwiftData model container
Structured Event Ingestion	Major	Partial	Queue-based ingestion exists for multiple flows but startup semantics still need hardening.	IntelligencePipeline, EventQueueActor, AevumEvent, ProcessedEvent, GraveyardEvent
Local AI / SLM Inference	Major	Partial	On-device inference stack and model management exist, including download/runtime management.	PhiEngine, SLMDownloadManager, MLXBridge, PhiSandboxView, local API
Persona-Adaptive Behaviour	Major	Partial	The system attempts to adapt responses, framing, and prompting to persona/state.	PersonaProfile, PersonaAdaptiveEngine, PersonaQuestionMatrix, persona files, ResponseStrategyEngine
Memory Graph Navigation	Major	Partial	User can access a graph-oriented representation of memory relationships.	KnowledgeMapView, MemoryGraphEngine, GraphNode, GraphConnection, NodeInspectorSheet
Timeline / Narrative Memory View	Major	Partial	User can inspect stored items through a timeline interface.	LifeTimelineView, MemoryEntry, edit timeline flow
Cross-Surface Invocation	Major	Partial	App functionality can be invoked from widgets, App Intents, and local HTTP.	Widget bundle, AppIntents, local API listener, deep-link capture
Sovereign Privacy Posture	Major	Active	The codebase is intentionally shaped around local-first storage and explicit consent surfaces.	PrivacyManifestoView, biometric lock, local store, local API, consent flows

4. Capability Stack By Layer

Layer A — User Interaction Layer

Purpose: expose an emotionally legible, fast, high-frequency capture surface.

Orb-led dashboard interaction
Voice capture and transcription UI
Manual text capture
Capture Sheet with mode selection
Onboarding and persona selection flows
Settings, privacy, consent, and diagnostics overlays

Strategic value: this is the layer that turns Aevum from a backend into a product habit.

Layer B — Memory And Persistence Layer

Purpose: store not just notes, but structured cognitive artifacts.

MemoryEntry as primary memory unit
AevumEvent and processed event classes
graph nodes, connections, patterns, insights, relationships, prompts
persona and session state models
local SwiftData container and store file

Strategic value: richer memory primitives create differentiation versus commodity capture products.

Layer C — Intelligence Layer

Purpose: determine how captured input is evaluated, compressed, responded to, or reframed.

BehaviourIntelligenceLayer
InstantProcessor
IntelligencePipeline and EventQueueActor
TrustUsageGovernor
ResponseStrategyEngine and ResponseComposer
CognitiveCompressor, PurposeEvaluator, QuestionSynthesisEngine

Strategic value: this is the logic core that converts Aevum from storage into an operating system for intent.

Layer D — Inference And Model Runtime Layer

Purpose: execute and manage local intelligence with optional remote file acquisition.

Phi inference runtime
MLX bridge and sandbox
model download management
Cloudflare R2-backed file download path
local API inference endpoint at port 8080

Strategic value: ownership of local execution reduces dependence on third-party AI services and supports premium privacy positioning.

Layer E — Invocation, Distribution, And Edge Access

Purpose: make the system callable from the operating system, not just from an app screen.

App Intents for thought logging and dictation launch
Siri-adjacent invocation surfaces
widgets for quick capture and daily brief positioning
local listener for controlled external execution hooks

Strategic value: operating-system presence increases defensibility and daily frequency.

5. Feature Inventory By Classification

Feature	Classification	Status	Why it exists	Business meaning
Orb-based dashboard	Major	Active	Creates a signature interaction pattern for thought capture.	Brand identity and retention lever
Voice transcription capture	Major	Active	Reduces friction and supports ambient use.	Habit frequency and differentiated UX
Text capture	Major	Active	Guarantees a reliable low-latency fallback path.	Core reliability
Capture mode hub	Major	Partial	Unifies voice, text, camera, gallery, habit, calendar, import/export entry points.	Platform expansion surface
OCR/document ingestion	Major	Partial	Brings screenshots, files, and external artifacts into local memory.	Data gravity and user lock-in
Habit capture	Minor	Partial	Turns recurring self-observation into structured signals.	Behavioural dataset growth
Legacy/import-export narrative	Minor	Partial	Signals that Aevum aims to absorb prior life/context inputs.	Migration and depth positioning
Timeline memory browsing	Major	Partial	Lets users review accumulated history.	Retention and trust
Knowledge map visualization	Major	Partial	Shows non-linear memory relationships.	High-value product differentiation
Persona engine	Derived	Partial	Combines persona storage, strategy, and prompt variation.	Personalization moat
Response strategy and hooks	Derived	Partial	Shapes the emotional and cognitive quality of output.	Perceived intelligence quality
Contribution prompts / feedback loop	Minor	Partial	Captures signals about user engagement and failure handling.	Learning and product tuning
Pipeline observability	Minor	Partial	Provides internal metrics around graph/pipeline dynamics.	Operability and QA leverage
Local inference sandbox	Major	Partial	Creates a controlled environment for local model interaction.	R&D and future premium capability
Cloudflare R2 model download path	Inherited	Partial	Allows large local intelligence assets to be fetched without turning core logic into cloud dependency.	Distribution efficiency with sovereign runtime thesis
Local inference API	Major	Partial	Exposes an internal/external execution hook to local clients.	Tooling, automation, and extensibility
Widgets	Derived	Partial	Pushes capture and brief interactions to the home screen.	Frequency and OS-level distribution
Shortcuts/App Intents	Derived	Partial	Makes Aevum callable by the system and other automations.	Workflow embedding
Siri conversational layer	Minor	Stub / Prototype	Represents a future native conversational invocation path.	Strategic optionality, not current release strength
External sync connectors	Minor	Stub / Prototype	Represent future system-of-record expansion.	Future data gravity, not present revenue claim
Mac product	Major	Absent	Not yet present as a current grounded product surface.	Future expansion, not current value credit

6. Why The Codebase Is Large

The codebase is large because it is already partitioned into product, intelligence, persistence, inference, graph, capture, security, UI, widget, and invocation layers. That is not accidental complexity alone. It reflects a platform ambition.

CoreMemory models a richer memory ontology than a note list.
IntelligenceEngine contains many orchestration and behavioural components, not just a single prompt call.
PhiInferenceEngine introduces a runtime, download, and execution plane for local intelligence.
MemoryGraphEngine indicates graph-native interpretation of stored user data.
UIComponents carries many surface-specific experiences, not just one screen.
ShortcutsIntegration and Widgets extend Aevum into the operating system.
SecurityLayer and privacy/consent views encode a sovereign-product stance.

In investor language, the significance is not “many files.” It is that Aevum already encodes multiple defensibility vectors: interface signature, private local memory, inference runtime ownership, OS-level distribution, and a graph/personalization thesis.

7. Strategic Differentiators Already Visible In Code

1. Sovereign Runtime Positioning

The system strongly favors local storage and local intelligence execution, with Cloudflare R2 used as a file-distribution layer rather than as the primary operating brain.

2. Memory Graph Orientation

Aevum is not content-addressable notes only. It structurally leans toward relationships, patterns, personas, signals, and insights.

3. Behavioural Layering

There are multiple engines governing routing, compression, synthesis, questioning, and engagement, which is closer to a behavioural operating layer than to a static archive.

4. OS-Level Presence

Widgets, deep links, App Intents, and local API hooks suggest an ambition to be callable from the user’s environment, not only opened manually.

8. What Still Limits The Current Product Story

Startup and bootstrap behaviour still need hardening.
Not all capture paths are equally proven.
Some integration surfaces overstate current maturity.
Testing is deeper in packages than at end-to-end app lifecycle level.
Cross-device parity is still more conceptual than operational.

These do not erase the strategic value of the codebase. They do mean that near-term execution value comes from stabilization and truth alignment, not from claiming the full future system already exists.

9. Valuation Narrative, Grounded

Aevum can credibly be framed as a high-upside platform only if its story is told in the right order:

It is building a sovereign personal intelligence layer, not just another notes product.
Its stack spans capture, memory, inference, graph, invocation, and privacy ownership.
Its codebase already contains many of the primitives required for a category-defining operating layer.
Its immediate execution challenge is stabilization, truth alignment, and release discipline.

That is the right bridge between current code reality and a future billion-dollar valuation narrative: not “everything already works,” but “the architecture already encodes a platform-scale thesis that can become economically meaningful if stabilized, simplified, and brought to market with discipline.”

10. Final Statement

Aevum’s current strength is not that it is fully complete. Its strength is that the codebase already reflects an ambitious and unusual architecture: a local-first memory operating system with native capture, behavioural routing, graph semantics, model runtime control, and OS-level invocation surfaces.

For PM, product, and investor communication, the correct message is: Aevum already has platform DNA in code. The next value unlock is disciplined stabilization and truthful release control.