05 System Architecture

Aevum System Architecture

Authoritative runtime, module, ingestion, inference, and device-architecture specification for the current enterprise baseline.

Document Version
v1.0
Date
2026-04-19
Status
Working Baseline
Owner
PM / Architecture

1. Purpose

This document defines how Aevum is architected at system level today and what the target enterprise runtime model is intended to be. It captures the real module topology, canonical ingestion boundary, local storage model, local inference path, and the release-critical differences between package stability and actual application readiness.

This architecture is written to support disciplined execution by engineering teams, QA, security, compliance, and future external delivery partners.

2. Architectural Principles

Core Principles

  • Local-first persistence for first-party user-authored thought capture.
  • Canonical ingestion boundary for all first-party input surfaces.
  • Deferred enrichment only after root write, never as a substitute for visible persistence.
  • Runtime truth over intention docs or legacy design claims.
  • Foreground/manual graph maintenance baseline unless explicitly re-approved.

Enterprise Principles

  • Clear module ownership and dependency boundaries.
  • Deterministic and testable ingestion behavior.
  • Accurate provenance across all inputs.
  • Compliance claims only where evidence and controls exist.
  • Operational readiness separated from package-level engineering success.

3. Topology Overview

flowchart TD
  A["UI Layer\nApp / Widgets / Sheets / Views"] --> B["UnifiedIngestionService\nCanonical Ingestion Boundary"]
  A --> C["BehaviourIntelligenceLayer\nCompanion Orchestration"]
  B --> D["CoreMemory / SwiftData\nRoot MemoryEntry + Event Persistence"]
  B --> E["IntelligencePipeline\nDeferred Enrichment / Background Processing"]
  C --> F["ContextRetriever + PromptAssembler"]
  F --> G["PhiEngine / Local Inference"]
  G --> C
  E --> D
  D --> H["Memory Graph / Relationships / Session / Persona State"]
  I["Cloudflare R2\nModel Artifact Delivery"] --> G
      

4. Runtime Layers

LayerResponsibilityCurrent State
UI Layer User input, onboarding, dashboards, capture sheets, import surfaces, settings, legal/privacy views, widgets. Real and active. Multiple surfaces now route more consistently, but release truth still depends on app-level build and metadata cleanup.
Canonical Ingestion Layer Single gateway for first-party input to become visible root memory/log entries. Implemented via UnifiedIngestionService. Core architectural improvement over prior fragmented paths.
Companion Orchestration Layer Turn user input into contextual response behavior using persona, session, and retrieved memory context. Implemented in BehaviourIntelligenceLayer and supporting helpers, but response quality and release truthfulness remain separate concerns.
Deferred Processing Layer Post-save enrichment, event handling, deduplication, and system processing after root persistence. Implemented via IntelligencePipeline and EventQueueActor. Must never replace direct root write for user-driven actions.
Persistence Layer SwiftData / local store for memory entries, events, session state, persona state, logs, and graph-related entities. Real and central. Strongest current architectural truth of the system.
Inference Layer Local model orchestration, prompt assembly, context retrieval, and response generation. Real, but still operationally constrained by app packaging, entitlements, and model-delivery strategy.

5. Module Map

Module / PackageRoleArchitectural Notes
CoreMemoryCanonical local data models and store foundation.Contains primary persistence entities and store setup. Must remain storage/domain focused, not orchestration-heavy.
IntelligenceEngineIngestion, orchestration, event processing, companion logic, runtime intelligence coordination.Owns the canonical ingestion service and most behavior control logic.
PhiInferenceEngineLocal model and inference-related runtime components.Also contains external model artifact download logic, which is a release/compliance disclosure concern.
UIComponentsShared UI surfaces and product-facing flows.Should remain thin in business logic; major control logic belongs in ingestion/orchestration layers.
MemoryGraphEngineGraph and relationship-oriented engine logic.Supports higher-order relation and graph behavior.
SecurityLayerSecurity-related helpers and device-local protections.Not yet sufficient alone to claim enterprise security readiness.
ShortcutsIntegrationApp Intents / Shortcuts entry surfaces.Must respect the same ingestion contract as first-party app surfaces.
CloudSyncEngineIntegration-facing logic.Current enterprise truth requires strict scrutiny of what is real versus placeholder or local-only behavior.

6. Canonical Ingestion Architecture

Required Contract

  • Any first-party user-triggered input must create a visible root MemoryEntry immediately.
  • No user-triggered import may disappear into queue-only behavior.
  • Deferred enrichment may happen after root creation only.
  • Provenance must reflect the true source.

Current Baseline

  • UnifiedIngestionService is now the intended single ingress boundary.
  • Dashboard, capture, import, habit, and legacy-triggered flows have been progressively brought under this boundary.
  • This is one of the strongest architectural improvements in the current repo.

7. Input Surface Routing Model

SurfaceExpected BehaviorArchitectural Rule
Dashboard text / voiceImmediate visible root entry, then contextual response and optional enrichment.Must not create duplicate root nodes.
CaptureSheet text / voiceImmediate visible root entry with correct provenance.Voice remains .voice, text remains .text.
Import routeMust open true import surface and create visible imported logs immediately.Import must not route to unrelated legacy UI.
Habit actionsImmediate visible system/habit log entry.No queue-only behavior for user-triggered habit actions.
Legacy initializationImmediate visible root event followed by optional enrichment.Must remain auditable and not hidden inside pipeline-only work.
Shortcuts / App IntentsRespect same local persistence truth where the action is user-originated.No hidden alternate persistence rules.

8. Companion Intelligence Architecture

Target Logic

  • Fetch active persona state.
  • Fetch current session state.
  • Retrieve relevant recent/local memory context.
  • Assemble bounded local prompt.
  • Invoke local inference.
  • Compose a direct answer before optional hook/follow-up.

Current Reality

  • The architecture has moved beyond dummy persona/session placeholders.
  • ContextRetriever and PromptAssembler are present and improve grounding.
  • However, release readiness depends not just on companion logic quality, but also on packaging, privacy truth, and operational controls.

9. Data and Event Flow

sequenceDiagram
  participant U as User
  participant UI as UI Surface
  participant UIS as UnifiedIngestionService
  participant DB as SwiftData Store
  participant BIL as BehaviourIntelligenceLayer
  participant RET as ContextRetriever
  participant INF as PhiEngine
  participant PIPE as IntelligencePipeline

  U->>UI: Type / Speak / Import / Act
  UI->>UIS: captureImmediate / ingestImportedItem / ingestImportedBatch
  UIS->>DB: Create root MemoryEntry
  UIS->>PIPE: Append deferred enrichment event
  UI->>BIL: Request companion response
  BIL->>RET: Fetch persona / session / recent context
  RET->>DB: Retrieve local state
  BIL->>INF: Invoke grounded local inference
  INF-->>BIL: Structured output
  BIL-->>UI: Companion response
  PIPE->>DB: Post-save enrichment / graph updates
      

10. Device Architecture

SurfaceCurrent StateArchitectural Implication
iPhonePrimary product surface.All baseline release decisions should be anchored here first.
iPadShared iOS app surface, not a deeply separate runtime architecture.Needs validation, but not a distinct architectural stack.
WidgetsPresent and integrated into project topology.Need the same product-truth and metadata discipline as the main app.
macOS / cross-platform package supportPackage compilation is increasingly portable, but release truth remains iOS-first.Do not confuse package portability with product-platform readiness.

11. Security and External Boundary Architecture

Local Boundary

  • Primary memory persistence is local SwiftData.
  • User-authored thought processing is designed to remain on-device.
  • Local store and device-native capture paths are central to the product identity.

External Boundary

  • Model artifact delivery currently uses Cloudflare R2.
  • This means Aevum is not strictly “no external infrastructure” in absolute terms.
  • Architecture, privacy, and compliance docs must distinguish local thought processing from external model delivery.

12. Release-Critical Architectural Risks

RiskDescriptionImpact
Package success misread as app readinessPackage builds/tests are green, but app-level build still fails.False release confidence.
Identity driftMindTwin and Aevum coexist in active release metadata.Brand, legal, App Review, and UX inconsistency.
Entitlement riskHigh-risk memory entitlements remain unresolved.App Store rejection or review escalation risk.
Privacy truth gapRuntime/legal copy overstates what is proven today.Compliance and trust risk.
Manifest/disclosure gapMissing app-owned privacy manifest and incomplete external-boundary disclosure.Submission and policy risk.

13. Architecture Decisions Locked for 1.0 Baseline

14. Open Architectural Work Before Enterprise Release

Release Architecture

  • App build and archive pipeline stabilization
  • Entitlement decision
  • Privacy manifest integration

Product Architecture

  • Product identity normalization
  • Permission and metadata cleanup
  • Model-delivery disclosure accuracy

Control Architecture

  • Compliance evidence pack
  • Release gate automation
  • Documentation truthfulness governance

15. Acceptance Criteria

CriterionSuccess Condition
Architecture clarityTeams can identify ingestion, persistence, deferred enrichment, inference, and external boundaries without ambiguity.
Input disciplineAll first-party inputs use the canonical ingestion model.
Release truthArchitecture docs no longer imply package stability equals deployment readiness.
Compliance alignmentArchitecture docs clearly distinguish local processing, external model delivery, and evidence gaps.