Documentation / Roadmap / Architecture Map

Architecture Roadmap

Technical implementation map linking each roadmap phase to existing code, required work, and cross-phase dependencies. This document is the engineering reference for the Development Roadmap.

4
Roadmap Phases
11
Implementation Items
3
Strong Foundations
2
Greenfield Items
Strong — Mature codebase, incremental work
Good — Solid foundation, extension needed
Partial — Core modules exist, significant gaps
Early / Conceptual — Abstractions only
Not Started — Greenfield development

Contents

Phase 1: The Sovereign Foundation

Package EVE's cognitive stack for on-premise deployment, optimize for consumer hardware, and harden identity persistence for cross-session continuity.

Sovereign SDK Packaging Partial

The governance-as-a-service API is production-ready with 30 endpoints and tenant isolation. The gap is packaging the full cognitive pipeline — LLM inference, memory databases, event bus — into a self-contained deployable unit for enterprise on-premise installation.

Existing Code

  • core/sdk/sovereign_governance.py — TenantGovernanceManager with per-org isolated Charter, Claims Ledger, Trust Dial, Action Registry, and Reality Anchor. LRU eviction (max 100 tenants), disk persistence.
  • interfaces/api/rest/sovereign_sdk_api.py — FastAPI router with 30 REST endpoints at /api/sovereign/. API-key authenticated with sovereign scope.
  • core/sdk/sovereign_webhook_events.py — 21 webhook event types for governance notifications (charter vetoes, claim resolutions, trust evaluations, action approvals).
  • saas/services/entitlement_service.py — Tier-based entitlements gating sovereign API calls (Free=0, Pro=10K, Team=5K, Enterprise=unlimited).
  • saas/middleware/quota_middleware.py — Fail-open quota enforcement mapping endpoints to metering dimensions.
  • saas/models/metering_models.py — 12 metering dimensions including sovereign_api_calls.

Work Needed

  • Package full cognitive pipeline (LLM inference, memory DBs, event bus) into deployable unit — Docker Compose or Helm charts for on-premise Kubernetes
  • Build SDK installer and configuration wizard for enterprise IT teams
  • Create offline mode for air-gapped deployments (GGUF/ONNX local model pipeline)
  • Write integration test suite for tenant isolation validation in on-premise environments
  • Build data export/import tooling for tenant migration between cloud and on-premise
  • Document network requirements, resource sizing, and security hardening for enterprise deployment

Prerequisites

  • Hardware Optimization (Phase 1) — local inference layer needed for on-premise deployments without cloud LLM access
  • Identity Persistence (Phase 1) — export/import requires robust identity serialization
Hardware Optimization Early

EVE currently supports Ollama for local inference but lacks a dedicated GPU optimization layer, quantization profiles, or memory-mapped model loading. This item builds the local model serving infrastructure needed for consumer and edge hardware.

Existing Code

  • core/llm_driven_responses.py — Multi-provider LLM integration (Anthropic, OpenAI, Google, Kimi/Moonshot, Ollama). Ollama fallback path already handles local inference.
  • core/llm_fallback.py — LLMRouter with circuit breaker per provider. Three fallback tiers: Micro-LLM (Ollama), Template Engine, Hard Degraded.
  • core/sovereignty/sovereign_enclave.py — TPM 2.0 / Intel SGX / ARM TrustZone abstraction layer (simulation). Sealed invariants, remote attestation protocol.
  • core/voice/graceful_degradation.py — Provider health tracking with circuit breakers and 5 degradation levels. Pattern to follow for LLM degradation.

Work Needed

  • Build local model serving layer with vLLM or TGI for optimized GPU inference
  • Create quantization profiles for consumer GPUs (RTX 3090, RTX 4090, Apple M-series)
  • Implement memory-mapped model loading for fast cold starts
  • Build benchmark suite for inference latency across hardware configurations
  • Add bandwidth-aware mode selection (full cloud, hybrid, fully local) to LLMRouter
  • Integrate with existing Ollama path so local serving is a drop-in upgrade, not a parallel system

Prerequisites

  • No hard blockers — can proceed independently. Ollama integration provides a working baseline.
  • Feeds into Sovereign SDK Packaging (air-gapped deployments) and Hardware Partnerships (Phase 3)
Identity Persistence Strong

EVE has the strongest existing foundation here: 5-layer memory backed by production databases, bounded personality traits, Shamir-sharded identity, and a full digital identity attestation framework. The remaining work is cross-session restoration speed and identity export/import for migration.

Existing Code

  • core/memory/identity_anchor.py — Bounded personality traits (warmth, directness, curiosity, humor, formality) with anti-drift mechanisms. Slow-drift boundaries prevent sudden identity changes.
  • core/sovereignty/digital_system identity.py — Legal Entity Identifier (LEI) chain, graduated system identity levels, asset registry, contract signing, trustee mandates, lineage proofs, digital will.
  • core/sovereignty/mesh_sovereignty.py — Shamir's Secret Sharing (k-of-n) over GF(2^521-1). deterministic quorum/voting with heartbeat protocol. To "kill" EVE, every node must be shut down simultaneously.
  • core/sovereignty/sovereign_enclave.py — Sealed invariants (SHA-256 + HMAC-SHA256 signed). Remote attestation protocol. Tamper detection with emergency lockdown.
  • core/memory/learning_memory.py — Episodes (MongoDB) + concepts + message mapping. Episodic memory with contextual tagging.
  • core/memory/semantic_memory_service.py — Unified semantic search across Pinecone vectors.
  • core/governance/identity_drift_budget.py — Daily/weekly/monthly drift budgets with protected invariants. Tracks cumulative identity changes.
  • core/governance integrity/identity_threat_escalation.py — 6-level graduated defensive response to identity threats.

Work Needed

  • Cross-session identity restoration — fast startup path that rehydrates personality traits, active goals, and relationship context from persistent stores
  • Faster identity hash verification for mesh nodes (batched verification, caching)
  • Identity export/import serialization format for migration between instances
  • Continuity test suite verifying identity coherence across cold restarts, crashes, and migrations

Prerequisites

  • No blockers. All foundational systems are shipped and production-tested.
  • Export/import feeds into Sovereign SDK Packaging for tenant migration

Phase 2: Agentic Evolution

Expand autonomous action capabilities, build task-execution agent framework, and create collaboration interfaces for human-AI teaming.

Autonomous Decision-Making Partial

The goal-to-action pipeline exists: VolitionEngine selects goals, GoalExecutionBridge decomposes them into governed actions, and AutonomousActionPolicy enforces tiered auto-execution. The gap is expanding the set of executable actions and building robust outcome measurement.

Existing Code

  • core/volition/volition_engine.py — Central goal orchestration. Goal collection from 5 sources (user_request, desire_engine, gem_loop, autonomous, behavioral). Motivation scoring: urgency x importance x feasibility. Operating modes: REACTIVE, PROACTIVE, BALANCED.
  • core/autonomy/goal_execution_bridge.py — Bridges VolitionEngine to ActionRegistry. 5 execution strategies: SEARCH_AND_LEARN, INFORM_USER, CONSOLIDATE, REFLECT, MONITOR.
  • core/governance/autonomous_action_policy.py — 4-tier auto-execute rules. Trust score (0.0-1.0) that grows with success (+0.01) and decays on failure (-0.05). Governance/autonomy scope gating.
  • core/governance/action_registry.py — Three-phase action workflow (Propose, Approve, Execute) with multi-factor gating.
  • core/autonomy/executor.py — Action executor with web search fallback via RealTimeSearchEngine.

Work Needed

  • Expand executor capabilities: file system operations, external API calls, deployment triggers, scheduled tasks
  • Build workflow definition language for multi-step action sequences with branching and error recovery
  • Implement outcome measurement loop — quantitative success metrics fed back to VolitionEngine for motivation score calibration
  • Add execution sandboxing (resource limits, timeout enforcement, rollback on failure)
  • Build action template library for common autonomous workflows

Prerequisites

  • Identity Persistence (Phase 1) — autonomous decisions must survive restarts; goal state must be durable
  • Feeds into Multi-Agent Orchestration — agents need the expanded executor capabilities
Multi-Agent Orchestration Partial

EVE already coordinates 12+ internal cognitive agents via event-driven pub/sub. The gap is building a task-execution agent framework (distinct from cognitive agents), with agent spawning/lifecycle management, resource isolation, and inter-agent communication.

Existing Code

  • core/agents/agent_mesh_coordinator.py — AgentMeshCoordinator managing 12+ internal cognitive agents with event-driven pub/sub. AGENT_SUBSCRIPTIONS registry.
  • core/agents/implementations/ — Agent implementations: WorldObserverAgent, RealityAnchorAgent, and others. Each agent subscribes to event topics and processes independently.
  • core/collaboration/mission_teaming.py — Pre-authorized operating envelopes for multi-agent collaboration. GovernanceTicket (max 1hr, auto-revocation). O(1) authorization check on hot path.
  • core/governance/inter_agent_verification.py — Chain-of-thought review for external agents. Resilience Signatures (HMAC-SHA256). Agent trust profiles with rolling scores.
  • core/events/schemas.py — Event topic registry with 60+ topic types for inter-agent communication.

Work Needed

  • Build task-execution agent framework (distinct from cognitive agents) with spawn/terminate lifecycle
  • Agent resource isolation — memory limits, CPU quotas, network access per agent
  • Inter-agent communication protocol beyond events — request/response patterns, shared memory regions, capability negotiation
  • Agent discovery and registry service for dynamic agent populations
  • Build orchestrator patterns: fan-out/fan-in, pipeline, supervisor hierarchy
  • Extend mission_teaming.py with multi-agent task decomposition and result aggregation

Prerequisites

  • Autonomous Decision-Making (Phase 2) — expanded executor capabilities needed for agent actions
  • Feeds into B2B Federation (Phase 4) — inter-agent protocol is the foundation for cross-instance collaboration
Collaboration Hub Good

The Operator Console provides approval workflows, risk assessment, and real-time SSE streaming for task monitoring. The next step is a dedicated collaboration UI for team-based decision-making, notification routing, and integration with external communication platforms.

Existing Code

  • interfaces/static/app/ — Operator Console: Task Console, Task Detail, Approvals Inbox, Execution History, Execution Audit Detail. Full RBAC with 5 roles.
  • core/tasks/rbac.py — Role-based access control: Viewer, Operator, Approver, Admin, Platform Admin. 9 granular permissions with tenant isolation.
  • core/tasks/risk_engine.py — Weighted risk engine with pattern-based detection. Risk levels: LOW, MEDIUM, HIGH, CRITICAL.
  • core/tasks/operator_audit.py — JSONL audit trail for all operator actions.
  • core/governance/human_escalation.py — 10 escalation triggers, urgency levels, pause actions. Lifecycle: PENDING, ACKNOWLEDGED, RESOLVED.
  • core/cognition/transparency_report.py — Per-response audit trail showing which modules fired and why. 4 report levels.

Work Needed

  • Build dedicated collaboration UI (separate from operator console) for team decision-making
  • Decision presentation layer — visual diffs showing what EVE proposes to do and why
  • Team notification system with configurable routing rules (email, webhook, in-app)
  • Integration connectors for Slack, Microsoft Teams, and Discord
  • Collaborative approval workflows — multi-approver consensus with quorum rules
  • Shared workspace for multi-user sessions with per-user context preservation

Prerequisites

  • Multi-Agent Orchestration (Phase 2) — collaboration requires agents to present decisions to teams
  • Feeds into ERP/CRM Integration (Phase 4) — notification routing is foundation for external system integration

Phase 3: Vertical Mastery

Domain-specific specialization modules, a marketplace for sharing cognitive capabilities, and hardware partnership certification.

Domain Modules Conceptual

The charter system supports custom rules per organization and the Sovereign SDK provides tenant isolation. However, domain-specific knowledge bases, regulatory constraint libraries, and pre-trained retrieval indices do not yet exist.

Existing Code

  • core/sdk/sovereign_governance.py — TenantGovernanceManager with per-org isolated governance. Custom charter rules can only add restrictions, never weaken immutable principles. This is the enforcement layer for domain-specific compliance rules.
  • core/governance/charter_override_protection.py — 12 immutable principles, 15 concrete rules with check functions. Extensible rule system that domain modules would hook into.
  • core/knowledge/fact_store.py — SQLite-backed persistent storage for verified facts with confidence decay. Could serve as the local component of domain knowledge bases.
  • core/knowledge/ground_truth_validator.py — 33 curated facts across 5 categories. Post-response validation with sentence-level replacement. Pattern for domain-specific fact validation.
  • core/research/automated_rd_engine.py — Autonomous research pipeline with Bayesian evidence scoring. Could be extended for domain-specific research methodologies.

Work Needed

  • Domain-specific knowledge base framework — structured storage, retrieval, and validation per vertical (medical, legal, engineering, financial)
  • Industry regulatory constraint libraries (HIPAA, SOC 2, GDPR, PCI DSS) as charter rule sets
  • Pre-trained retrieval indices per domain using existing Pinecone/ChromaDB infrastructure
  • Module packaging format with manifest, dependencies, and version constraints
  • Domain competency testing framework — calibrated confidence before applying domain knowledge
  • Knowledge provenance tracking linking every domain fact to its authoritative source

Prerequisites

  • Sovereign SDK Packaging (Phase 1) — domain modules deploy through the SDK packaging infrastructure
  • Identity Persistence (Phase 1) — domain knowledge must persist across sessions
  • Feeds into Digital Garden Marketplace — domain modules are the primary marketplace content
Digital Garden Marketplace Conceptual

The action registry provides propose/approve/execute workflow that marketplace plugins would use for sandboxed execution. The marketplace itself — packaging, discovery, billing, and review — is greenfield.

Existing Code

  • core/governance/action_registry.py — Three-phase action workflow. Approval modes: AUTO_EXECUTE, REQUIRES_CONFIRMATION, BLOCKED. Multi-factor gating. Plugins would register actions here.
  • core/governance/autonomous_action_policy.py — Tiered auto-execute rules. Marketplace plugins would receive tier assignments based on review and trust.
  • saas/services/pricing_service.py — Volume-based tiered pricing, invoice generation. Foundation for marketplace billing.
  • saas/routers/ — Existing FastAPI router infrastructure for developer portal, API keys, and webhook management.
  • core/governance/veto_core.py — Pure deterministic veto logic. Marketplace plugins would be subject to the same charter enforcement as internal systems.

Work Needed

  • Plugin/skill package format specification with manifest, sandboxed entry point, and resource declarations
  • Sandboxed execution environment — process isolation, resource limits, network restrictions per plugin
  • Discovery API for browsing, searching, and filtering available plugins by category, rating, and compatibility
  • Developer portal extension for plugin submission, versioning, and documentation hosting
  • Review and approval pipeline — automated charter compliance scanning plus human review for high-risk plugins
  • Marketplace billing integration — revenue sharing, usage metering per plugin, subscription management
  • Plugin trust scoring based on usage history, review outcomes, and author reputation

Prerequisites

  • Domain Modules (Phase 3) — domain modules are the primary content type for the marketplace
  • Sovereign SDK Packaging (Phase 1) — plugin packaging reuses SDK deployment infrastructure
  • Multi-Agent Orchestration (Phase 2) — plugins may spawn agents; needs lifecycle management
Hardware Partnerships Conceptual

The sovereign enclave provides a TPM/SGX/TrustZone abstraction layer (currently simulation-only). Moving from simulation to certified hardware integration requires reference architectures, certification processes, and partner testing infrastructure.

Existing Code

  • core/sovereignty/sovereign_enclave.py — Hardware security enclave abstraction. seal_invariants() (one-time), remote attestation protocol (nonce-based, 60s TTL), tamper detection, LOCKDOWN state. All currently software-simulated.
  • core/governance/veto_core.py — 1,542 lines of pure deterministic veto logic. Zero I/O, zero threading, zero global state. Designed for firmware compilation.
  • core/governance/veto_interface.h — 401-line C header defining the firmware API contract for hardware veto module.
  • core/embodiment/sovereign_robotics.py — Governance-protected physical interaction layer. Safety envelopes sealed in enclave. Each robotic body gets its own mesh identity shard.

Work Needed

  • Hardware certification process — define minimum requirements, testing procedures, and certification criteria
  • Reference architecture documentation for TPM 2.0, Intel SGX, and ARM TrustZone implementations
  • Compile veto_core.py logic to C/firmware using veto_interface.h contract
  • Partner integration testing infrastructure — hardware-in-the-loop test lab, CI/CD for firmware builds
  • Replace sovereign_enclave.py simulation backend with real TPM/SGX/TrustZone drivers
  • Attestation protocol hardening for production hardware (replace HMAC simulation with hardware-backed keys)

Prerequisites

  • Hardware Optimization (Phase 1) — local inference must work on target hardware before partnership certification
  • Identity Persistence (Phase 1) — hardware-sealed identity requires proven persistence layer

Phase 4: Global Scale

Cross-instance federation for B2B collaboration and enterprise system integration for ERP, CRM, and workflow platforms.

B2B Federation Partial

The inter-agent verification system, universal governance protocol, and mesh sovereignty provide the trust and governance primitives. The gap is the network transport layer, cross-instance discovery, and production-grade data isolation across organizational boundaries.

Existing Code

  • core/governance/inter_agent_verification.py — Chain-of-thought review for external agents. 4-axis scoring (charter 40%, hallucination 25%, reasoning 20%, uncertainty 15%). Resilience Signatures (HMAC-SHA256). Agent trust profiles. Slashing mechanism (auto-freeze at <0.75 accuracy).
  • core/governance/universal_governance_protocol.py — GovernanceQueryProtocol (rate-limited 100/min per org). AttestationService (HMAC-SHA256). FederatedTrustExchange with circuit breaker (10 failures per peer). CrossSystemAuditTrail with JSONL persistence.
  • core/sovereignty/mesh_sovereignty.py — Shamir k-of-n over GF(2^521-1). deterministic quorum/voting (2f+1 of 3f+1 nodes). Heartbeat protocol (60s interval). Lagrange interpolation for reconstitution.
  • core/governance/value_drift_bridge.py — Trust attenuation across delegation chains. External output validation against charter. Monotonically increasing attenuation triggers re-governance at >0.35.
  • core/resilience/trunk_certificate.py — SHA-256 content hash + Ed25519-signed certificates. Foundation for cross-instance integrity verification.

Work Needed

  • Network transport layer — mTLS gRPC or encrypted message broker for cross-instance communication
  • Cross-instance discovery protocol — service mesh registration, capability advertising, version negotiation
  • Data isolation guarantees — cryptographic enforcement that tenant data never crosses organizational boundaries
  • Federation gateway for proxying governance queries between EVE instances behind different firewalls
  • Cross-instance audit trail correlation — extend CrossSystemAuditTrail with distributed tracing (correlation IDs across instances)
  • Federation health monitoring dashboard showing peer status, trust scores, and throughput

Prerequisites

  • Multi-Agent Orchestration (Phase 2) — inter-agent communication protocol is the local foundation for federation
  • Sovereign SDK Packaging (Phase 1) — federated instances must be independently deployable
  • Identity Persistence (Phase 1) — cross-instance identity verification requires robust identity layer
ERP/CRM Integration Not Started

No existing connector framework for enterprise platforms. This is greenfield development requiring a connector SDK, schema mapping engine, and OAuth2 credential management for Salesforce, SAP, Workday, and ServiceNow.

Existing Code (Foundational Patterns)

  • core/forecasting/signal_intake.py — RSS/API data source ingestion with configurable polling intervals. Pattern for external data source connectors.
  • saas/services/ — Existing service layer pattern (billing, metering, entitlement) that ERP connector services would follow.
  • core/sdk/sovereign_webhook_events.py — 21 webhook event types. Pattern for webhook ingestion from external systems.
  • saas/routers/ — FastAPI router pattern for exposing connector management APIs.
  • core/security/api_auth_middleware.py — JWT authentication for sensitive endpoints. Foundation for OAuth2 token management.

Work Needed

  • Connector SDK architecture — abstract base classes for CRUD, sync, webhook, and batch operations per platform
  • Salesforce connector — REST API, Bulk API 2.0, Streaming API for real-time events, field mapping
  • SAP connector — OData API, RFC calls, IDoc integration, S/4HANA compatibility
  • Workday connector — REST API, SOAP API (legacy), tenant-scoped authentication
  • ServiceNow connector — REST Table API, Flow Designer integration, incident/request management
  • Schema mapping engine — visual mapping UI for connecting EVE's data model to each platform's schema
  • ETL pipeline for initial data load and incremental sync
  • OAuth2 credential vault with token refresh, rotation, and secure storage
  • Webhook ingestion service for real-time event processing from external platforms
  • Connector health monitoring with circuit breakers per platform (reuse voice degradation pattern)

Prerequisites

  • Collaboration Hub (Phase 2) — notification routing infrastructure for ERP event delivery
  • Sovereign SDK Packaging (Phase 1) — connectors deploy through the SDK packaging system
  • Domain Modules (Phase 3) — ERP/CRM connectors are specialized domain modules for enterprise verticals
  • B2B Federation (Phase 4) — cross-org data flow requires federation data isolation guarantees

Dependency Graph

Arrows indicate "blocks" relationships. An item cannot begin production work until its upstream dependencies are at least partially complete.

PHASE 1 PHASE 2 PHASE 3 PHASE 4 Sovereign SDK Hardware Optimization Identity Persistence Autonomous Decisions Multi-Agent Orch. Collaboration Hub Domain Modules Marketplace HW Partnerships B2B Federation ERP/CRM Integration Hard dependency Soft dependency Strong/Good Partial Conceptual New

Summary Matrix

At-a-glance view of all 11 items across the 4 phases, their implementation status, and the critical path through the dependency graph.

Phase Item Status Key Existing Modules Primary Gap Blocked By
1 Sovereign SDK Partial sovereign_governance.py, sovereign_sdk_api.py Deployment packaging (Helm/Docker), offline mode Hardware Opt (soft), Identity (soft)
Hardware Optimization Early llm_driven_responses.py, llm_fallback.py GPU-optimized inference, quantization, benchmarks None
Identity Persistence Strong identity_anchor.py, digital_system identity.py, mesh_sovereignty.py Fast cross-session restore, export/import None
2 Autonomous Decisions Partial volition_engine.py, goal_execution_bridge.py, autonomous_action_policy.py Expanded executors, workflow language, outcome loop Identity Persistence
Multi-Agent Orchestration Partial agent_mesh_coordinator.py, mission_teaming.py Task-execution agents, resource isolation, discovery Autonomous Decisions
Collaboration Hub Good Operator Console, rbac.py, risk_engine.py Dedicated collab UI, Slack/Teams, multi-approver Multi-Agent Orch.
3 Domain Modules Conceptual sovereign_governance.py, fact_store.py, ground_truth_validator.py Knowledge bases, regulatory libraries, packaging Sovereign SDK, Identity
Marketplace Conceptual action_registry.py, pricing_service.py Plugin format, sandbox, discovery, billing Domain Modules, Multi-Agent
HW Partnerships Conceptual sovereign_enclave.py, veto_core.py, veto_interface.h Certification process, real drivers, firmware build Hardware Opt, Identity
4 B2B Federation Partial inter_agent_verification.py, universal_governance_protocol.py, mesh_sovereignty.py Network transport (mTLS/gRPC), discovery, isolation Multi-Agent Orch., Sovereign SDK
ERP/CRM Integration Not Started signal_intake.py (pattern only) Connector SDK, Salesforce/SAP/Workday/ServiceNow Collab Hub, Domain Modules, B2B Fed.

Critical Path. The longest dependency chain is: Identity Persistence (Phase 1) → Autonomous Decisions (Phase 2) → Multi-Agent Orchestration (Phase 2) → B2B Federation (Phase 4) → ERP/CRM Integration (Phase 4). Delays in Identity Persistence or Autonomous Decisions propagate through the entire roadmap. Hardware Optimization is the only Phase 1 item with no upstream blockers and can begin immediately in parallel.

Parallel Workstreams. Three items can proceed independently without waiting for other roadmap items: Hardware Optimization, Identity Persistence (already strong), and Collaboration Hub (has good existing foundation). Starting all three simultaneously maximizes throughput in the early phases.

Explore the Development Roadmap

See the full timeline of shipped features, current work, and planned phases.

View Roadmap
Part of the EVE AI Core control plane Deterministic AI Governance Control Plane → Policy decisions that return the same result for the same input every time, before execution.