ATOCore/docs/master-plan-status.md

AtoCore Master Plan Status

Current Position

AtoCore is currently between Phase 7 and Phase 8.

The platform is no longer just a proof of concept. The local engine exists, the core correctness pass is complete, Dalidou hosts the canonical runtime and machine database, and OpenClaw on the T420 can consume AtoCore safely in read-only additive mode.

Phase Status

Completed

• Phase 0 - Foundation
• Phase 0.5 - Proof of Concept
• Phase 1 - Ingestion

Baseline Complete

• Phase 2 - Memory Core
• Phase 3 - Retrieval
• Phase 5 - Project State
• Phase 7 - Context Builder

Baseline Complete

• Phase 4 - Identity / Preferences. As of 2026-04-12: 3 identity memories (role, projects, infrastructure) and 3 preference memories (no API keys, multi-model collab, action-over-discussion) seeded on live Dalidou. Identity/preference band surfaces in context packs at 5% budget ratio. Future identity/preference extraction happens organically via the nightly LLM extraction pipeline.

• Phase 8 - OpenClaw Integration (baseline only, not primary surface). As of 2026-04-15 the T420 OpenClaw helper (t420-openclaw/atocore.py) is verified end-to-end against live Dalidou: health check, auto-context with project detection, Trusted Project State surfacing, project-memory band, fail-open on unreachable host. Tested from both the development machine and the T420 via SSH. Scope is narrow: 14 request shapes against ~44 server routes, predominantly read-oriented plus POST/DELETE /project/state and POST /ingest/sources. Memory management, interactions capture (covered separately by the OpenClaw capture plugin), admin/backup, entities, triage, and extraction write paths remain out of this client's surface by design — they are scoped to the operator client (scripts/atocore_client.py) per the read-heavy additive integration model. "Primary integration" is therefore overclaim; "baseline read + project-state write helper" is the accurate framing.

Baseline Complete

• Phase 9 - Reflection (all three foundation commits landed: A capture, B reinforcement, C candidate extraction + review queue). As of 2026-04-11 the capture → reinforce half runs automatically on every Stop-hook capture (length-aware token-overlap matcher handles paragraph-length memories), and project-scoped memories now reach the context pack via a dedicated --- Project Memories --- band between identity/preference and retrieved chunks. The extract half is still a manual / batch flow by design (scripts/atocore_client.py batch-extract + triage). First live batch-extract run over 42 captured interactions produced 1 candidate (rule extractor is conservative and keys on structural cues like ## Decision: headings that rarely appear in conversational LLM responses) — extractor tuning is a known follow-up.

Not Yet Complete In The Intended Sense

• Phase 6 - AtoDrive
• Phase 10 - Write-back
• Phase 11 - Multi-model
• Phase 12 - Evaluation
• Phase 13 - Hardening

Engineering Layer Planning Sprint

Status: complete. All 8 architecture docs are drafted. The engineering layer is now ready for V1 implementation against the active project set.

• engineering-query-catalog.md — the 20 v1-required queries the engineering layer must answer
• memory-vs-entities.md — canonical home split between memory and entity tables
• promotion-rules.md — Layer 0 → Layer 2 pipeline, triggers, review queue mechanics
• conflict-model.md — detection, representation, and resolution of contradictory facts
• tool-handoff-boundaries.md — KB-CAD / KB-FEM one-way mirror stance, ingest endpoints, drift handling
• representation-authority.md — canonical home matrix across PKM / KB / repos / AtoCore for 22 fact kinds
• human-mirror-rules.md — templates, regeneration triggers, edit flow, "do not edit" enforcement
• engineering-v1-acceptance.md — measurable done definition with 23 acceptance criteria
• engineering-knowledge-hybrid-architecture.md — the 5-layer model (from the previous planning wave)
• engineering-ontology-v1.md — the initial V1 object and relationship inventory (previous wave)
• project-identity-canonicalization.md — the helper-at-every-service-boundary contract that keeps the trust hierarchy dependable across alias and canonical-id callers; required reading before adding new project-keyed entity surfaces in the V1 implementation sprint

The next concrete next step is the V1 implementation sprint, which should follow engineering-v1-acceptance.md as its checklist, and must apply the project-identity-canonicalization contract at every new service-layer entry point.

LLM Client Integration

A separate but related architectural concern: how AtoCore is reachable from many different LLM client contexts (OpenClaw, Claude Code, future Codex skills, future MCP server). The layering rule is documented in:

• llm-client-integration.md — three-layer shape: HTTP API → shared operator client (scripts/atocore_client.py) → per-agent thin frontends; the shared client is the canonical backbone every new client should shell out to instead of reimplementing HTTP calls

This sits implicitly between Phase 8 (OpenClaw) and Phase 11 (multi-model). Memory-review and engineering-entity commands are deferred from the shared client until their workflows are exercised.

What Is Real Today (updated 2026-04-12)

• canonical AtoCore runtime on Dalidou (build_sha tracked, deploy.sh verified)
• 33,253 vectors across 5 registered projects
• project registry with template, proposal, register, update, refresh
• 5 registered projects:
  • p04-gigabit (483 docs, 5 state entries)
  • p05-interferometer (109 docs, 9 state entries)
  • p06-polisher (564 docs, 9 state entries)
  • atomizer-v2 (568 docs, newly ingested 2026-04-12)
  • atocore (drive source, 38 state entries)
• 47 active memories (16 project, 16 knowledge, 6 adaptation, 3 identity, 3 preference, 3 episodic)
• context pack assembly with 4 tiers: Trusted Project State > identity/preference > project memories > retrieved chunks
• query-relevance memory ranking with overlap-density scoring
• retrieval eval harness: 18 fixtures, 17/18 passing
• 290 tests passing
• nightly pipeline: backup → cleanup → rsync → LLM extraction (sonnet) → auto-triage
• off-host backup to clawdbot (T420) via rsync
• both Claude Code and OpenClaw capture interactions to AtoCore
• DEV-LEDGER.md as shared operating memory between Claude and Codex
• observability dashboard at GET /admin/dashboard

Now

These are the current practical priorities.

1. Observe and stabilize — let the nightly pipeline run for a week, check the dashboard daily, verify memories accumulate correctly from organic Claude Code and OpenClaw use
2. Multi-model triage (Phase 11 entry) — switch auto-triage to a different model than the extractor for independent validation
3. Automated eval in cron (Phase 12 entry) — add retrieval harness to the nightly cron so regressions are caught automatically
4. Atomizer-v2 state entries — curate Trusted Project State for the newly ingested Atomizer knowledge base

Next

These are the next major layers after the current stabilization pass.

1. Phase 10 Write-back — confidence-based auto-promotion from reinforcement signal (a memory reinforced N times auto-promotes)
2. Phase 6 AtoDrive — clarify Google Drive as a trusted operational source and ingest from it
3. Phase 13 Hardening — Chroma backup policy, monitoring, alerting, failure visibility beyond log files

Later

These are the deliberate future expansions already supported by the architecture direction, but not yet ready for immediate implementation.

1. Minimal engineering knowledge layer
   • driven by docs/architecture/engineering-knowledge-hybrid-architecture.md
   • guided by docs/architecture/engineering-ontology-v1.md
2. Minimal typed objects and relationships
3. Evidence-linking and provenance-rich structured records
4. Human mirror generation from structured state

Not Yet

These remain intentionally deferred.

• automatic write-back from OpenClaw into AtoCore — OpenClaw capture plugin now exists (openclaw-plugins/atocore-capture/), interactions flow. Write-back of promoted memories back to OpenClaw's own memory system is still deferred.
• automatic memory promotion — auto-triage now handles promote/reject for extraction candidates. Reinforcement-based auto-promotion (Phase 10) is the remaining piece.
• reflection loop integration — fully operational: capture (both clients) → reinforce (automatic) → extract (nightly cron, sonnet) → auto-triage (nightly, sonnet) → only needs_human reaches the user.
• replacing OpenClaw's own memory system
• live machine-DB sync between machines
• full ontology / graph expansion before the current baseline is stable

Working Rule

The next sensible implementation threshold for the engineering ontology work is:

• after the current ingestion, retrieval, registry, OpenClaw helper, organic routing, and backup baseline feels boring and dependable

Until then, the architecture docs should shape decisions, not force premature schema work.