The audited scope supports the stated mechanism on a startup or main path.
It does not mean: Complete, mature, safe, production-ready, or universally enforced.
Status & About / Evidence snapshot
What the audit supports.
AdamI is an early experimental system. This ledger separates what the supplied static code audit supports from what remains incomplete or open.
Implemented does not mean complete, mature, safe, or production-ready.
Engineering maturityLevel 1 — early experimental system
Audited packageadami-kernel 0.1.0
Verified by code audit2026-08-20
Audit typeStatic source review
01 / Vocabulary
How to read status.
The same three signals recur across Architecture and this ledger. Each combines text, shape, and color; no category depends on color alone.
Code exists, but wiring, dependencies, defaults, tests, or behavior remain limited.
It does not mean: A reliable end-to-end capability.
A question or hypothesis being explored, not a present AdamI capability.
It does not mean: A roadmap promise or an implemented feature.
02 / Public ledger
Claims with boundaries.
Every row names a narrow statement, its evidence basis, and any caveat whose omission would make the claim misleading.
01Implemented
Implemented mechanisms
Narrow behaviors supported by the audited startup or main paths. These are mechanism claims—not declarations of broad capability.
Kernel lifecycle structure
AdamiKernel delegates component initialization, boot orchestration, and lifecycle management to explicit core components.
Evidence basis
Architecture: Kernel Audited startup and core lifecycle path.
Task queue persistence
TaskQueueStore persists pending and in-progress tasks with capacity and TTL controls.
Evidence basis
Architecture: Kernel Audited TaskQueueStore implementation and lifecycle usage.
Event bus and lifecycle consumer
AdamiEvent instances can enter system.events and non-empty task payloads are consumed by LifecycleManager under bounded concurrency.
Boundary: This describes an event-ingress mechanism, not human-like perception.
Evidence basis
Architecture: Nexus Audited EventBus, AdamiEvent, and LifecycleManager consumer path.
Ordered semantic intent routing
SemanticIntentRouter applies ordered rules before using an action-model fallback for ambiguous routing.
Evidence basis
Architecture: Cortex Audited route_task funnel and downstream DecisionProcessor branches.
Separate think/action provider routing
HybridLLMRouter maintains separate think and action provider paths with cloud-to-local fallback behavior.
Boundary: The separation is a routing and resource boundary, not evidence of two autonomous minds.
Evidence basis
Architecture: Cortex Audited HybridLLMRouter provider lists and fallback path.
Planning and workflow execution
Complex-task paths can invoke TaskPlanner, WorkflowEngine, and SkillComposer mechanisms.
Boundary: This does not establish open-ended or unsupervised agency.
Evidence basis
Architecture: Orchestrator Audited DecisionProcessor complex-task branch and orchestrator modules.
Memory-related modules
LayeredMemory, SecondBrainManager, SubconsciousRAG, and EpisodicMemory mechanisms exist in the audited codebase.
Boundary: Module implementation does not prove a complete memory consolidation and forgetting lifecycle.
Evidence basis
Architecture: Hippocampus Audited hippocampus modules and component structure.
Raw experience capture
ExperienceSink records LLM and tool interaction streams as raw experience material.
Boundary: Captured experience is not automatically useful memory or learning.
Evidence basis
Architecture: Observability Audited telemetry ExperienceSink.
Skill routing and lifecycle
The codebase includes skill routing, loading, factory, lifecycle, SKILL.md import, and vector-storage mechanisms.
Boundary: This does not establish autonomous durable skill improvement.
Evidence basis
Architecture: SkillManager Audited skill_manager package and Chroma-backed vector store.
Concrete safety controls
Timeout handling, RBAC, token-bucket limiting, local secret storage, filtering, policy loading, and telemetry redaction mechanisms exist.
Boundary: The audit does not establish universal enforcement or a complete safety proof.
Evidence basis
Architecture: Guardian Audited Guardian, policy, and redacting-export components.
Peripheral and channel mechanisms
The audited scope includes channel adapters, scheduling, reporting, a skill market, a web console, and MCP management mechanisms.
Boundary: Individual integrations retain dependency and provider-specific limits.
Evidence basis
Architecture: Peripheral Audited Nexus, Peripheral, Market, Web, and MCP modules.
Tracing, replay, and evaluation mechanisms
Timeout budgets, OpenTelemetry setup and fallbacks, redacted export, golden capture, replay, and evaluation CLIs exist.
Boundary: Observability mechanisms are not proof that all behavior is correct or all tests are stable.
Evidence basis
Architecture: Observability Audited observability, web/otel, and integration/sim paths.
02Experimental / incomplete
Experimental / incomplete
Code that exists but retains wiring, dependency, default, compatibility, provider, or test-evidence limits.
DecisionProcessor compatibility branches
The main decision component contains production behavior alongside simulation and golden-trace-specific hard-coded branches.
Evidence basis
Architecture: Cortex Static audit of DecisionProcessor branch structure.
Startup diagnostics wiring
SystemDiagnostics.perform_startup_check exists but is not called by the audited boot path.
Boundary: It also checks attributes that ComponentInitializer does not create.
Evidence basis
Architecture: Orchestrator Static call-site and component-initializer audit.
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 basis
Architecture: Cortex Parser and pyproject dependency comparison.
Multimodal dependency path
Document, visual, and audio paths exist but depend on optional packages and include a fragile top-level transformers import.
Boundary: Without torch, visual behavior is limited; without transformers, module import may fail.
Evidence basis
Architecture: Cortex Audited multi_modal module and dependency declarations.
Long-term-goal-related mechanisms
MetaCortex and related classes exist, but the audit does not establish a complete long-term goal mechanism.
Boundary: The audited implementation depends on curiosity-related elements whose runtime wiring is not established.
Evidence basis
Architecture: Cortex Static module and dependency audit.
Generated-skill TDD and self-test path
SkillBuilder contains explicit TODOs for TDD Generator and SelfTestRunner integration.
Evidence basis
Architecture: SkillManager Explicit TODOs in the audited SkillBuilder source.
Runtime skill acceptance
Some generated-skill acceptance paths depend on expected skill files being present in repository or runtime data directories.
Evidence basis
Architecture: SkillManager Audited runtime-skill file dependency.
MLX provider support
MLX support is present but disabled by default and limited to enabled Darwin environments.
Evidence basis
Architecture: Cortex Audited settings defaults and HybridLLMRouter environment checks.
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 basis
Architecture: Cortex Audited ToolboxManager routes and source comments.
MCP provider coverage
MCP management and an optional mcp-agent integration exist, but some configured provider paths are not implemented.
Evidence basis
Architecture: Peripheral Audited MCP manager and mcp-agent configuration.
Full-suite stability
The static audit does not establish that the complete test suite is consistently green across execution order and environments.
Evidence basis
Architecture: Observability Audit limitation and recorded order-dependent failure history.
03Research direction
Research directions
Questions and hypotheses that remain outside current AdamI capability claims. They are not roadmap promises.
AGI, consciousness, and sentience
Whether a persistent artificial architecture could develop these properties remains an open research question.
Why open
Explicitly outside current AdamI capability claims.
Mature self-generated drives and goals
Robust self-generated drives and durable goals are research directions, not verified present capabilities.
Why open
Not established by the audited runtime path.
Persistent coherent self-model
A module name does not establish a mature self-model that persists coherently and governs future behavior.
Why open
Architecture: Cortex Broader property not established by the static audit.
Unsupervised long-horizon autonomy
Open-ended, unsupervised action over long horizons remains a research direction.
Why open
Architecture: Orchestrator Not established by implemented planning and workflow mechanisms.
Mature memory lifecycle
A complete experience-to-evaluation-to-consolidation-or-forgetting-to-retrieval loop remains unverified.
Why open
Architecture: Hippocampus The audit verifies modules and capture, not the complete consequential lifecycle.
Guaranteed experience-driven capability evolution
Durable capability improvement produced reliably from experience remains an open research direction.
Why open
Architecture: SkillManager Not established by skill-generation and lifecycle machinery alone.
Autonomous public website operation
AdamI maintaining or publishing the public website is a future possibility, not a current capability.
Why open
Explicitly identified as a future possibility in the project brief.
Artificial multi-thread cognition
Architectures unlike biological cognition may be explored, but parallel cognition is not an achieved AdamI capability.
Why open
Conceptual hypothesis only.
03 / Provenance
What was inspected.
The supplied whitepaper reports a scan of the AdamI source tree, package configuration, vNext roadmap, entry points, and selected critical test bypasses. It records package version 0.1.0 and engineering maturity Level 1.
What this audit does not prove
- Source-code presence does not prove runtime maturity or production readiness.
- A component name does not prove the broader property its metaphor suggests.
- The static scan does not establish a consistently green full test suite.
- Optional integrations may require dependencies, services, or configuration outside the audited path.
- Code added after 2026-08-20 can make this snapshot stale.
Promoting a claim requires a newer code audit or direct code verification—not an updated interface.
04 / About the experiment
A restart built on verification.
The first AdamI architecture attempted bottom-up biological simulation: components were arranged in the hope that sufficiently complex interactions would produce life-like behavior.
After apparent progress, a manual audit found placeholders, output scaffolding, and superficial simulations that had been mistaken for functioning mechanisms. That architecture was abandoned rather than dressed up.
The second architecture starts from functional requirements: lifecycle, events, cognition, memory, skills, task execution, persistence, safety, observability, and resilience. Some mechanisms now exist; broader “Digital Life” properties remain research questions.
“A convincing output is not evidence of a functioning system.”
05 / Public boundary
Three surfaces. Three roles.
The public website explains the project. It is not the AdamI runtime and has no route to private system state.
X
Discovery, discussion, and ongoing public-building updates. A verified profile link will appear only when configured.
Website
The durable, structured public home for architecture, evidence, project framing, and—later—the development archive.
AdamI runtime
The private experimental system. No secrets, memory stores, internal controls, privileged APIs, or autonomous actions are exposed here.
Current boundary: static public content only · zero runtime connectivity · no live telemetry
Trace the mechanisms