EN中文
Digital LifeArchitectureDevelopment LogStatus & About

Architecture / Audited codebase

Mechanisms, not metaphors.

This page describes relationships supported by the current code audit. It is a map of implemented machinery and explicit limits—not a diagram of a future artificial life.

An implemented component does not imply that every broader capability associated with its name is mature.

Packageadami-kernel 0.1.0
Engineering maturityLevel 1 — early experimental system
Evidence date2026-08-20
Review Status & About

01 / System map

Responsibility before flow.

The first map groups the nine public subsystem areas by responsibility. It avoids arrows where the audit establishes components but not a universal relationship.

Responsibility mapGrouped by audited responsibility—not presented as a universal data-flow graph.

Continuity

KernelLifecycle · boot · task continuity

Event / sensory ingress

NexusEvents · channels · sensory inputs

Cognition and planning

CortexRouting · decisions · providers · toolsOrchestratorPlanning · workflows · composition

Memory and capability

HippocampusStorage · retrieval · episodic modulesSkillManagerRouting · loading · lifecycle

Peripheral / integration

PeripheralChannels · schedules · reports · protocols

Text equivalent

The audited architecture groups Kernel under continuity; Nexus under event and sensory ingress; Cortex and Orchestrator under cognition and planning; Hippocampus and SkillManager under memory and capability; and Peripheral under channels and integration. Guardian and Observability provide specific supporting mechanisms. The map intentionally makes no claim that those supporting systems wrap or govern every component.

02 / Verified path

Event to decision.

This is the narrow main path supported by the audit: event publication, lifecycle admission, decision routing, and the three documented branch types.

Audited main pathSolid connectors show relationships described by the supplied code audit.
  1. 01
    External or internal sourceChannel, shell, schedule, or internal publisher
  2. 02
    AdamiEventPublished to system.events on EventBus
    DLQ behavior exists at the event-bus boundary.
  3. 03
    LifecycleManager consumerRequires a non-empty payload.task
    Bounded concurrency · per-chat locking · task persistence · cancellation · timeout/budget controls
  4. 04
    DecisionProcessorInvokes SemanticIntentRouter after internal and queue handling
  5. 05
    Supported decision branches
    • DIRECT_ANSWERDirect response path
    • SYSTEM_ACTIONSupported system-action dispatcher
    • COMPLEX_TASKTaskPlanner / WorkflowEngine → selected implemented tools or skills

Text equivalent

An external or internal source publishes an AdamiEvent to EventBus topic system.events. LifecycleManager ignores events without a task payload and processes eligible events with concurrency, per-chat, queue, cancellation, and timeout controls. DecisionProcessor uses SemanticIntentRouter and dispatches direct-answer, system-action, or complex-task behavior. The complex branch can invoke TaskPlanner and WorkflowEngine, then selected implemented tool or skill paths. No completed experience-to-learning loop is asserted.

03 / Routing architecture

Separate paths, not separate minds.

“Dual-Brain” is a public shorthand for two technical separations: ordered fast intent routing and distinct think/action provider lists.

“Dual-Brain” means routing separationA public metaphor for intent and provider paths—not two minds.

A · Fast semantic routing

  1. 1Sensitive / realtime / forced / system / length rules
  2. 2Fast patterns
  3. 3Complex patterns
  4. 4Action-model fallback for ambiguity
Direct answerSystem actionComplex task → planning

B · Provider separation

Think providersComplex reasoning and planning requests where selected
Action providersAction-oriented and ambiguity-routing requests where selected
Fallback behavior

Cloud provider failure can fall back toward local Ollama. MLX support is present, disabled by default, and limited to enabled Darwin environments.

Text equivalent

SemanticIntentRouter evaluates ordered rule groups, then uses an action-model call only for otherwise ambiguous routing. The result is a direct answer, a system action, or a complex task routed to planning. Separately, HybridLLMRouter maintains think-provider and action-provider lists with cloud-to-local fallback. This architecture separates routing and compute roles; it is not evidence of two autonomous minds.

04 / Subsystems

Nine areas, mixed maturity.

A subsystem is not assigned one blanket status. Each chapter separates verified mechanisms, incomplete aspects, and open questions.

01Kernel02Nexus03Cortex04Orchestrator05Hippocampus06SkillManager07Guardian08Peripheral09Observability
01

Continuity

Kernel

Provides system lifecycle and continuity; cognition remains outside the kernel.

ImplementedImplemented core lifecycle mechanisms.

Verified mechanisms

  • AdamiKernel
  • ComponentInitializer
  • BootManager
  • LifecycleManager
  • TaskQueueStore
  • KernelContext
  • restart control

Connection to the audited path

Initializes components, coordinates boot, and hands non-empty task events to the lifecycle and decision path.

Research
  • How should continuity behave across longer periods and more failure modes?
02

Event / sensory ingress

Nexus

Provides event publication, channel ingress, and system-sensory mechanisms.

ImplementedExperimentalImplemented event infrastructure and adapters.

Verified mechanisms

  • EventBus
  • AdamiEvent and EventPriority
  • DLQ behavior
  • CLI
  • Telegram and Discord adapters
  • nerve registry
  • proprioception and sensory modules
  • health server
  • pulse/autonomic system

Connection to the audited path

Publishes AdamiEvent objects to system.events; LifecycleManager consumes task-bearing events from that topic.

Experimental
  • Adapter availability still depends on configured services and optional environments.
Research
  • How should richer event sources be evaluated without implying subjective perception?
Verified as of2026-08-20
Audit source pathssrc/adami_kernel/nexus/
03

Cognition / routing

Cortex

Routes intent, selects model-provider paths, and coordinates decision and tool-related mechanisms.

ImplementedExperimentalImplemented routing core with incomplete and compatibility-heavy extensions.

Verified mechanisms

  • DecisionProcessor
  • SemanticIntentRouter
  • HybridLLMRouter
  • ToolboxManager
  • JSON extraction
  • prompt and adaptive-intent mechanisms

Connection to the audited path

DecisionProcessor receives lifecycle events, invokes SemanticIntentRouter, and dispatches direct, system-action, or complex-task branches.

Experimental
  • DecisionProcessor includes simulation/golden-trace branches.
  • JSON repair is not a required dependency.
  • Multimodal imports and optional dependencies are fragile.
  • MLX is disabled by default.
  • Built-in and registered tool schemas are not unified.
Research
  • A mature persistent self-model and broad general intelligence are not established.
04

Planning / execution

Orchestrator

Turns supported complex-task branches into plans and workflow execution.

ImplementedExperimentalImplemented planning core with an unwired diagnostics path.

Verified mechanisms

  • TaskPlanner
  • WorkflowEngine
  • SkillComposer
  • multi-agent orchestration modules
  • reflexion-loop module

Connection to the audited path

The COMPLEX_TASK branch can call TaskPlanner and WorkflowEngine, which may select implemented tools or skills.

Experimental
  • SystemDiagnostics is not called by boot and checks attributes not created by ComponentInitializer.
Research
  • Open-ended, unsupervised long-horizon agency remains unverified.
05

Memory

Hippocampus

Provides storage, retrieval, and episodic-memory-related mechanisms.

ImplementedExperimentalImplemented memory-related modules; mature memory lifecycle remains open.

Verified mechanisms

  • LayeredMemory
  • SecondBrainManager
  • SubconsciousRAG
  • EpisodicMemory

Connection to the audited path

Memory components are initialized in the system, but the audit does not establish a complete experience-consolidation loop on the main path.

Experimental
  • Complete evaluation, consolidation, active forgetting, and future-behavior influence are not established end to end.
Research
  • What makes retained experience consequential rather than merely stored?
Verified as of2026-08-20
Audit source pathssrc/adami_kernel/hippocampus/src/adami_kernel/telemetry/experience_sink.py
Related status evidence
06

Capability

SkillManager

Loads, routes, creates, and manages lifecycle metadata for skill artifacts.

ImplementedExperimentalImplemented core mechanisms with incomplete self-test extensions.

Verified mechanisms

  • SkillManager and SkillRouter
  • loader, factory, and lifecycle
  • SKILL.md importer
  • Chroma vector store
  • SkillBuilder
  • runtime-generated skill file convention

Connection to the audited path

Planner and skill-creation paths can use the skill system; acceptance may depend on runtime skill files.

Experimental
  • TDD Generator and SelfTestRunner integration remain TODOs.
  • Some acceptance paths depend on expected runtime files.
Research
  • Reliable experience-driven capability improvement is not established.
07

Supporting controls

Guardian

Provides specific permission, timeout, limiting, filtering, secret-storage, and redaction mechanisms.

ImplementedExperimentalImplemented controls without a universal safety guarantee.

Verified mechanisms

  • ImmunitySystem timeout handling
  • RBACMatrix
  • TokenBucketLimiter
  • LocalSecretVault
  • sensitive filtering
  • PolicyLoader
  • RedactingSpanExporter

Connection to the audited path

Individual controls are used at documented boundaries; the audit does not prove blanket enforcement across every action.

Experimental
  • No complete safety proof or universal policy-enforcement claim is supported.
Research
  • How should permission, supervision, and stopping policies scale with greater autonomy?
Verified as of2026-08-20
Audit source pathssrc/adami_kernel/guardian/src/adami_kernel/policy/src/adami_kernel/observability/otel_export_policy.py
Related status evidence
08

Channels / integration

Peripheral

Hosts scheduling, reporting, external-channel, market, console, and protocol-integration mechanisms.

ImplementedExperimentalImplemented integration surface with partial provider coverage.

Verified mechanisms

  • CircadianNerve
  • Report Studio
  • last30days bridge
  • Skill Market
  • web console
  • McpManager
  • channel adapters

Connection to the audited path

Adapters and scheduled mechanisms can publish events or support tool and skill workflows where configured.

Experimental
  • Some mcp-agent provider paths are not implemented.
  • Integrations depend on their external services and optional packages.
Research
  • Future public integration requires a separate, permissioned read-only boundary.
Verified as of2026-08-20
Audit source pathssrc/adami_kernel/peripheral/src/adami_kernel/integration/src/adami_kernel/market/src/adami_kernel/web/src/adami_kernel/mcp/
Related status evidence
09

Supporting evidence

Observability

Provides timeout context, tracing, redaction, capture, replay, and evaluation mechanisms.

ImplementedExperimentalImplemented mechanisms with unresolved full-suite evidence.

Verified mechanisms

  • ContextVar timeout budget
  • OpenTelemetry initialization and fallbacks
  • telemetry redaction
  • ExperienceSink
  • golden capture
  • replay and evaluation CLIs
  • AGL compatibility boundary

Connection to the audited path

Supports selected runtime and evaluation paths; it does not establish correctness by itself.

Experimental
  • The audit does not establish a consistently green full test suite.
Research
  • How should evidence stay current as the codebase changes?
Verified as of2026-08-20
Audit source pathssrc/adami_kernel/observability/src/adami_kernel/telemetry/src/adami_kernel/integration/sim/src/adami_kernel/web/otel.py
Related status evidence

05 / Audit limits

Known gaps and wiring limits.

These are source-supported constraints, not hidden footnotes. A transparent gap is more useful than an implied capability.

Experimental

DecisionProcessor compatibility branches

The main decision component contains production behavior alongside simulation and golden-trace-specific hard-coded branches.

Evidence
Experimental

Startup diagnostics wiring

SystemDiagnostics.perform_startup_check exists but is not called by the audited boot path.

It also checks attributes that ComponentInitializer does not create.

Evidence
Experimental

Optional JSON repair fallback

A fourth-stage json_repair fallback is probed by the parser, but the package is not declared as a required project dependency.

Evidence
Experimental

Multimodal dependency path

Document, visual, and audio paths exist but depend on optional packages and include a fragile top-level transformers import.

Without torch, visual behavior is limited; without transformers, module import may fail.

Evidence
Experimental

Long-term-goal-related mechanisms

MetaCortex and related classes exist, but the audit does not establish a complete long-term goal mechanism.

The audited implementation depends on curiosity-related elements whose runtime wiring is not established.

Evidence
Experimental

Generated-skill TDD and self-test path

SkillBuilder contains explicit TODOs for TDD Generator and SelfTestRunner integration.

Evidence
Experimental

Runtime skill acceptance

Some generated-skill acceptance paths depend on expected skill files being present in repository or runtime data directories.

Evidence
Experimental

MLX provider support

MLX support is present but disabled by default and limited to enabled Darwin environments.

Evidence
Experimental

Tool schema unification

Registered external tools use a generic execution route while built-in tools use separate methods and schemas are not fully unified.

Evidence
Experimental

MCP provider coverage

MCP management and an optional mcp-agent integration exist, but some configured provider paths are not implemented.

Evidence
Experimental

Full-suite stability

The static audit does not establish that the complete test suite is consistently green across execution order and environments.

Evidence

Trust layer

Read the claims as a ledger.

The Status & About page separates implemented mechanisms, incomplete work, and research directions—and explains what the audit cannot prove.

Review Status & About