ABL / Repository roadmap

Documentation

ABL Repository Roadmap

Evidence reviewed

ABL’s original roadmap was a plain document: project overview, current state, version roadmap, hardware, model assignment, principles and upstream systems. This public edition keeps that order and the corrected version history, with dated evidence and acceptance limits.

Format: the April 3 owner-supplied replacement specification. Status and exit-check wording reflect the November 5 evidence review; they are not backdated completion claims. The original source establishes a Markdown document, not a prior website design.

Read Markdown

Project Overview

ABL (Aurora, Borea, Lis) is a three-role AI system intended to carry useful work through research, coordination and memory. The ambition is an everyday partner with shared goals, durable context and useful action within clear boundaries. This roadmap preserves its original document structure while keeping historical implementation, retained execution proof, unfinished integration and planned capability distinct.

Where ABL stands → Sanitized execution evidence → Planning-lineage summary →

Current State

The retained product sequence runs from v0.1 Foundation through v0.15 Nerves. A later corrected history says v0.16 was never sealed and had no finalized codename. v0.17 Cognition remained an idea/unscoped proposal.

Later work outgrew the old release strings. November 5 receipts establish specific admission, native-task, component-test and cold-feedback results. Workflow V17/V18 labels are receipt iterations, not new ABL product versions.

The next verification gates below are a current synthesis of the retained plans and project evidence. Their wording is new acceptance guidance, not a backdated promise or a claim that the stage is complete.

These historical scope summaries come from archived owner-supplied implementation reports and planning exchanges, reconciled with the later owner-supplied August history correction. This review did not rerun the original historical filesystem/runtime audit.

The post-v0.9 number was explicitly corrected by the owner to v0.10, not v1.0. Earlier Sovereignty planning became v0.5 Dream Mode. Earlier Persona scope must not be displayed as a delivered v0.16 release.

  • v0.1 “Foundation”. State: Historical record. Three-agent peer bus, governance and safety, memory, tools and a CLI. Historical implementation report. Safety scaffolding preceded broad capability. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.2 “Pulse”. State: Historical record. Streaming conversation, vitals, dashboard, approvals and history. Historical report. A browser-interface manifest did not establish a working browser. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.3 “Senses & Intelligence”. State: Historical record. Voice I/O, self-measurement, a knowledge vault and isolated code changes. Historical report. Later audits retained real-audio and wiring gaps. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.4 “The Forge”. State: Historical record. Specialist subagents, experiment lifecycle and training/forecast foundations. Frameworks and scaffolds were not proof of successful training or forecast outcomes. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.5 “Dream Mode”. State: Historical record. Idle-triggered internal maintenance and external research pipelines. Earlier Sovereignty scope was revised to Dream Mode. Later audit retained generator stubs and no recovered early end-to-end overnight receipt. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.6 “Ascension”. State: Historical record. Vaults, watchdog, model evaluation, AIP/OODA and integration/browser foundations. Historical seal/audit report, not current continuous operation. Broader earlier ambitions were narrowed. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.7 “First Light”. State: Historical record. Runtime boot, checkpoints and resilience, hardened consensus, guarded modes and adversarial tests. Historical report. The later audit could not recover the first live-task output. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.8 “Awakening”. State: Historical record. Provider adapters replacing inference stubs, ensemble confidence and forgetting. A historical wiring report, not present provider health. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.9 “Anamnesis”. State: Historical record. Source-backed wiki memory, transcript ingestion, personalization, divisions and per-agent models. Historical memory architecture; its stack is not automatically the current runtime stack. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.10 “Praxis”. State: Historical record. Ephemeral specialists, evaluations and model council, replay/feedback and operational integrations. The owner corrected v1.0 to v0.10. Later audit found some browser/large-provider dependencies unwired in this arc. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.11 “Aletheia”. State: Historical record. Correct capability claims, remove non-test mocks, wire real adapters/voices/consensus and freeze scope. A historical corrective release. It does not prove every current route uses the same deliberation configuration. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.12 “Bankai”. State: Historical record. Model deliberation, dissent and deadlock behavior, with review and quality pipelines. Separate the consensus architecture from the actual configured route. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.13 “Flow”. State: Historical record. CLI, memory, scheduled reports, secure peer bus and project integrations. Historical integration record. A remote-resource plan is not proof of current availability. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.14 “Hands”. State: Historical record. A file/command/git toolbelt behind consensus and guards, real-model checks and memory organization. Bounded guarded tools, not unrestricted autonomy. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.
  • v0.15 “Nerves”. State: Historical record. Voice loop, model and embedding upgrades, secure mesh/failover and consultation. Reported historical seal. Addenda and later history retained built-versus-wired and audible-loop gaps. Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.

Reviewed against retained November 5 evidence. “Verified” means the stated bounded receipt exists; it is not a live health badge. In-progress stages have a concrete acceptance gap. Planned stages retain their original goal without claiming it is already installed.

  • Dated proof · Nov 5 — Admission → native ledger → reviewed result. State: Verified receipt. A narrow admission repair and one real local 27B execution are documented. The execution completed; the incomplete answer was rejected and retained. Proof boundary: Retain the failure as evidence. A completed process is not an accepted answer or a general model-quality result.
  • Dated proof · Nov 5 — Saved feedback → cold resume → review stop. State: Verified bounded proof. Sixteen consumer tests pass. Two explicit cold resumes recognize the isolated integration proof and stop ready for review, with zero new model calls or source changes. Proof boundary: This closes only the explicit retrieval/recognition path. It does not close background scheduling or automatic next-task selection.
  • Current integration gate — Promote the reviewed component through its owner. State: In progress. A supervisor-authored one-file correction passes scalar and AVX2 synthetic tests inside an isolated source tree. The original model answer remains rejected. Keep the source manifest, attribution and review result bound to the exact candidate. Retain ordinary-output, absent-input, invalid-argument and deliberate-failure controls. Exit check: The legitimate owner accepts and promotes those exact reviewed bytes, with a rollback path and post-promotion readback.
  • Current integration gate — Validate the complete matching model and store. State: In progress. Twelve synthetic codec-plane gates are component proof. They do not establish the complete model/store build, matching assets, quality or throughput. Bind the build to the intended model/store assets. Run a complete acceptance task and preserve failed comparisons. Exit check: The full build loads matching assets and passes a predeclared quality/correctness acceptance; synthetic success alone cannot pass this gate.
  • Current integration gate — Mount the reviewed workflow in the active Hub. State: In progress. Reviewed installation preparation exists. The active client, serving root and integration ownership still need proof. Identify the currently loaded client and the integration owner. Use the existing canonical task ledger rather than a second queue. Demonstrate desktop and phone reading the same task, result and review state. Exit check: A bounded owner-visible task/result flow is accepted in the actual mounted interface, including refresh and interrupted-return behavior.

Version Roadmap

The forward version entries remain unsealed or proposed. The additional tracks below retain the wider plans without inventing a later release number. Exit checks are current editorial acceptance guidance.

v0.16 No finalized codename

  • State: Historical · unsealed.
  • Voice bring-up, capability truth and integration/debt repair.
  • Unsealed in the revised August history. Persona was earlier proposed scope, not its finalized delivered name.
  • Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.

v0.17 “Cognition” — proposed

  • State: Historical proposal.
  • Persistent cognition, specialist analysis, source-based book learning and Red Team evolution.
  • Recorded idea/unscoped future work. No verified formal release or completed planning directory is established here.
  • Record boundary: This register records the retained planning/implementation account. It does not establish current service health or completion of every intended capability.

Next controlled capabilities

Next controlled capability — Native continuation with accountable identity

  • State: Planned integration.
  • Windows containment, Promise observation and Host-boundary candidates have tests. Genuine authority, membership, result origin, accounting and launch binding remain separate requirements.
  • Keep one operation/session identity across admission, execution and reconciliation.
  • A lost reply or started effect must not enable unsafe replay.
  • Exit check: One authorized real continuation preserves the exact native session and effective launch settings, with a durable terminal receipt and failed-cleanup controls.

Next controlled capability — Persistent goals and scheduled work

  • State: Planned.
  • The original direction includes overnight work and carrying goals across channels. Explicit cold resumes are a useful substrate, but are not an unattended goal selector.
  • Admit one goal with a bounded acceptance check and resource budget.
  • Preserve queue identity, owner control, interruption and restart behavior.
  • Separate proposals from permitted external effects.
  • Exit check: A reviewed persistent loop selects only admitted work, survives restart without duplication and produces an independently checked result within its bounds.

Next controlled capability — Useful memory with source and correction

  • State: Planned acceptance.
  • The plans ask for durable context, preference learning and continuity. Existing stores and a bounded feedback consumer do not prove everyday memory usefulness.
  • Retain source identity, permission and correction history.
  • Test exact retrieval, contradictions, forgetting and restart persistence.
  • Keep private evidence separate from the public record.
  • Exit check: An owner-approved memory task retrieves the intended source, explains the match and survives correction/restart without leaking or inventing context.

Wider capability tracks

These tracks connect the named history to intended capability. Existing components and scoped proofs are substrate; each wider result still needs its own acceptance evidence.

Nerves lineage — A complete usable voice loop

  • State: Planned acceptance.
  • The original plans call for a natural conversational loop. Built voice components and a transcript alone do not establish a complete audible interaction.
  • Capture a complete permitted utterance without fixed-window word loss.
  • Produce a correct transcript, a real agent response and audible playback.
  • Check interruption/stop, latency, absent-device and degraded behavior.
  • Exit check: A reviewed utterance-to-response-to-playback task works on the intended interface, with source, timing and failure evidence.

Hands lineage — Useful tools through the intended guard chain

  • State: Planned wider proof.
  • The historical toolbelt direction is bounded project work, not unrestricted command authority. A real model task through the ledger is one narrower proof.
  • Complete one admitted read/write/command/change task.
  • Exercise refusal, timeout and rollback controls on that same route.
  • Exit check: The configured provider, actual guards and real storage produce an independently checked task result, with exact apply/rollback and no hidden fallback.

First Light lineage — Recovery that preserves task identity

  • State: Planned acceptance.
  • Recovery receipts and cold restarts are useful scoped evidence. Wider degraded operation still needs a declared dependency-loss test.
  • Observe checkpoint recovery and dependency loss.
  • Distinguish disabled, idle, degraded and failed states.
  • Do not infer service health from a process name.
  • Exit check: An admitted interrupted task resumes or refuses coherently without duplicate effects, lost acknowledgements or a falsely healthy status.

v0.17 recorded proposal — Source-grounded cognition and analysis

  • State: Proposed; not a release.
  • Retained Cognition scope includes persistent knowledge, a dedicated analysis role, book/document ingestion and learning from adversarial findings. It was not a sealed v0.17 release.
  • Evaluate source-linked ingestion and answers on held-out tasks.
  • Make a Red Team finding produce a specific tested behavior change.
  • Grade a lesson before treating it as improved capability.
  • Exit check: The analyzer retrieves the correct permitted source and improves a predeclared task evaluation without erasing counterevidence.

Earlier Persona proposal — Personal interaction with a separate work mode

  • State: Proposed interaction.
  • Persona was proposed conversation/personality/voice scope. The later history does not establish a delivered release under that name.
  • Test task/casual routing and consistent agent voices.
  • Retain owner feedback, correction and interruption controls.
  • Do not turn private behavior into a public profile by inference.
  • Exit check: Explicit owner feedback confirms the intended interaction, while task mode and permission boundaries remain correct.

Governed improvement direction — Work → verify → lesson → next work

  • State: Planned wider loop.
  • The cold feedback consumer recognizes a completed isolated integration and stops for review. The wider direction includes grounded next work and safely improving the project.
  • Bind each patch to its source, acceptance checks and independent review.
  • Apply only through the legitimate owner and applicable approval tier.
  • Retain rollback and a post-change outcome.
  • Exit check: A reviewed improvement survives the full work/claim/verify/lesson cycle and produces the intended post-change result without expanding its own authority.

The original capture and memory phases

The February owner-supplied AURORA brief used its own Phase 0–6 sequence. It is a capture/memory/governance track, not a second product release register. The acceptance wording below makes those goals testable while omitting private topology.

Phase 0 — Hardware topology

  • Map resource roles and limits. The public Nodes view reveals responsibilities rather than private topology.

Phase 1 — Minimal viable capture

  • One permitted capture reaches durable storage and can be retrieved with its source identity.

Phase 2 — Structured memory schema

  • Records retain type, time, provenance and explicit boundaries; retrieval does not flatten every source into one trust level.

Phase 3 — Shutdown protocol

  • Close a capture session without losing acknowledged work; restart without duplicate intake.

Phase 4 — Overnight worker

  • Process an admitted queue within resource and action limits, then leave an inspectable result.

Phase 5 — Preference model learning

  • Separate owner statements, observed behavior and inference; evaluate corrections before promotion.

Phase 6 — Scaling and storage lifecycle

  • Declare resource tiers, retention and migration checks; storage capacity is not active compute.

The lettered perception track

The April assistant-authored blueprint proposed 2A–2D and 3+ as interaction tracks responding to owner goals. They do not establish installed continuous capture. Each needs explicit capture scope, pause/stop/delete behavior and a complete source-to-result check.

Phase 2A — Ears First

  • Permissioned audio intake and transcription with provenance; capture, retention and use remain explicit.

Phase 2B — Eyes

  • Visual context with separate image/OCR observations and source coverage; no invented scene facts.

Phase 2C — Voice Identity

  • A consistent voice/interface with reproducible behavior and deliberate activation.

Phase 2D — Screen Awareness

  • Relevant screen context linked to the task and permission boundary, rather than uncontrolled capture.

Phase 3+ — Deep Perception

  • Richer cross-modal context only after the simpler source, reliability and privacy checks hold.

Bootstrap, improvement and backlog labels

Bootstrap blueprint

  • Phase 1: Claude Code Builds ABL → Phase 2: ABL Comes Online → Phase 3: ABL Becomes Asif’s Claude Code
  • An assistant-authored implementation ladder following owner goals; not the v0.x release register.

Self-modification track

  • Foundation → Deployment Pipeline → Improvement Loop → Tool Dispatch
  • A separate proposed build order. A safe change requires acceptance, review, exact apply/rollback and an observed outcome.

Later trust backlog

  • A/B/C/D workstreams
  • Queue lanes, not 2A–2D perception or a chronological product-version sequence.

Architecture-document draft

  • Version 0.1.0
  • The February draft document identifier; not the April ABL v0.1 product release.

Long-term partner and campus direction → Compute and service roles →

Hardware Roadmap

  • Current, documented: primary Linux services provide the backend, durable task records, local model services, retrieval and search. Desktop controls retain the native client, guarded transports and compatibility helpers. These are dated role descriptions, not a fresh private-service health measurement.
  • Current, separate responsibilities: SQLite records, markdown memory and the Chroma vector index need different persistence and retrieval checks. Specialist compute and witness roles are historical documentation; their present availability has not been remeasured here.
  • Next: establish active client, serving-root and integration ownership; demonstrate the reviewed workflow in the owner-visible Hub. Full model/store validation remains a separate acceptance gate.
  • Future: add resource capacity through role-specific admission, useful-result and recovery checks. A role is not a physical-machine count; private topology and operational destinations are withheld.

Compute and service roles → Current stack and evidence →

Model Assignment

  • Aurora: the public architecture illustrates a research role; a current provider assignment is not established by that illustration.
  • Borea: the public architecture illustrates a coordination role; a current provider assignment is not established by that illustration.
  • Lis: the public architecture illustrates a memory role; these role labels do not establish three independently running models.
  • Documented execution path: Ollama, llama.cpp-based routing and a durable native ledger. One local 27B task completed on November 5; its incomplete answer was rejected and preserved.
  • Next: accept a complete scoped result through the intended configured path. Validate the matching full model/store separately; neither admission nor a synthetic component pass establishes general quality or full AETHER runtime behavior.
  • Future: model changes need an explicit assignment and an evaluation on the actual route. Source inventory, historical configuration and model names alone do not establish current availability.

Illustrated persona roles → Sanitized dated execution evidence →

Design Principles

  • Keep source and authorship attached; distinguish historical scope, implemented components, useful complete paths and current runtime measurements; require bounded authority, explicit acceptance checks and inspectable outcomes; preserve privacy and corrections; advance a stage only when its stated exit check passes.

Upstream Systems

The original roadmap used one bullet per related system. This public update lists only relationships already described in the dated public evidence; a planning reference is not an installed or currently healthy integration.

  • AETHER research: a supervisor-authored correction was reviewed and tested in an isolated source candidate. Authoritative source promotion and complete model/store acceptance remain open.
  • Ollama and llama.cpp: documented components of the bounded local-model execution path. The dated one-task receipt does not establish present availability or broad coding quality.
  • Hub and desktop integration: reviewed installation preparation exists. Active client/root ownership and mounted owner-visible acceptance remain open.

Current evidence → Long-term direction → Public lab record →