The Reflexive Ecosystem

Self-Building AI Development in the Synthetic Autonomic Mind

A Case Study in Continuity-Preserving, AI-Assisted Software Development

Abstract

This paper documents the Synthetic Autonomic Mind (SAM) ecosystem - a collection of open source AI tools that are built and maintained through a pair-programming workflow between a human developer and CLIO, using a methodology called the Unbroken Method. The ecosystem consists of CLIO, a terminal-based AI coding assistant written in Perl; SAM, a native macOS AI assistant built in Swift; and ALICE, a local image generation service in Python. All three are developed and maintained through CLIO itself, which has been self-building (modifying its own codebase under human direction) since January 2026.

The Unbroken Method was not designed in advance. It emerged from practical observations during SAM’s early development: sessions with preserved context produced better results, persistent memory improved architectural consistency, and investigation before modification reduced errors. These patterns were formalized into a methodology and embedded in CLIO, which the developer then used to build and maintain the entire ecosystem - including CLIO itself.

The result is a reflexive system where the development tool is also part of what it develops. This paper examines the technical architecture, the development methodology, and the implications of self-building AI development. It presents verifiable evidence from the ecosystem itself while being explicit about the boundaries of what this evidence demonstrates. All results are empirical and observational; controlled experiments and independent replication remain future work.

Keywords: reflexive AI, self-building systems, autonomous development, Unbroken Method, continuity-preserving workflows, open source AI tools

1. Introduction

1.1 The Separation Assumption

Software development assumes a clean separation between the developer, the tools, and the resulting artifact. A developer uses an editor to write code, a compiler to build it, and a test suite to verify it. The tools are distinct from what they produce.

AI-assisted development inherits this assumption. A developer uses an AI assistant to help write code, but the assistant and the code remain separate concerns. Each session with the AI is treated as a partial reset - prior context is lost, decisions must be re-explained, and architectural knowledge evaporates between interactions.

The SAM ecosystem challenges this separation. CLIO is a terminal-based AI coding assistant that has been used to build and maintain itself, alongside two other production systems, since January 2026. The tool is not separate from the artifact - it is part of the artifact. The development methodology is not separate from the tool - it is embedded in the tool’s architecture. And the development context is not discarded between sessions - it is accumulated and preserved.

This paper uses the term continuity-preserving development to describe this approach: a workflow in which development context - architectural decisions, coding patterns, discovered constraints, session history - accumulates across sessions rather than resetting. The AI assistant retains and builds on prior knowledge instead of starting each interaction from scratch.

1.2 What Emerged

The story begins in July 2025, when SAM - a native macOS AI assistant - entered development using conventional tools (VSCode and Claude). Over six months of development through December 2025, a pattern became apparent: sessions where context was preserved across interactions produced measurably better results than sessions that started cold. Persistent memory improved consistency. Investigating code before modifying it reduced rework.

These were not theoretical insights. They were practical observations from building a real product. The developer formalized those observations into a methodology - the Unbroken Method - and then built CLIO specifically to embody it. Once CLIO was capable enough to work on itself (version 20260119.1), the developer began pair-programming with CLIO for all further work on the ecosystem.

This creates an unusual situation: the methodology was proven during SAM’s development, then encoded in CLIO, then used through CLIO to build ALICE and maintain all three systems. The method validates itself through its own outputs.

1.3 Scope

This is a case study documenting one ecosystem, one developer, and one set of practices. It presents evidence of viability, not proof of general superiority. The conclusions should be read accordingly: the Unbroken Method works here, in this context, with these tools. Whether it generalizes requires independent replication that has not yet been performed.

That said, the evidence is real and verifiable. The source code is open. The commit history is public. The systems are in production use. This paper aims to document what exists, explain how it works, and examine what it means - without overclaiming.

2. What Is New in This Work

Most components of the SAM ecosystem have precedents in prior work. Memory-augmented LLM agents, tool-using assistants, session persistence, and task decomposition are all active research areas. The contribution of this paper is not any single component but their integration into a self-referential, continuity-preserving development workflow. Specifically:

1. Cross-session context accumulation. Development memory persists, compresses, and grows across sessions indefinitely rather than resetting.

2. Workflow embedded in tooling. The Unbroken Method’s principles - investigation before modification, structured handoffs, checkpoint-based collaboration - are enforced by CLIO’s architecture, not left to developer discipline.

3. Human-directed self-modification loop. The developer directs CLIO to modify its own codebase, maintaining continuity of both code and development context. This is not autonomous self-optimization - it is pair-programming where one partner is also the artifact.

4. Verifiable reflexive development. Every claim in this paper can be checked against the public source code and commit history. The ecosystem is fully open source and the development process is documented in its own artifacts.

3. The Ecosystem

3.1 Components

The SAM ecosystem is maintained by the Synthetic Autonomic Mind organization. It consists of three primary systems:

CLIO - Command Line Intelligence Orchestrator

CLIO is a terminal-first AI coding assistant written in Perl. It runs on anything from a ClockworkPi uConsole to an M4 Mac, starting at approximately 50 MB of RAM. The codebase spans over a hundred Perl modules organized into subsystems for memory, sessions, tools, security, coordination, and UI. It supports 10+ AI providers (GitHub Copilot, OpenAI, Anthropic, Google Gemini, DeepSeek, OpenRouter, MiniMax, llama.cpp, LM Studio, and SAM itself), provides 14 tool categories for autonomous operation, and includes a three-tier memory system, multi-agent coordination, remote execution over SSH, and terminal multiplexer integration.

CLIO has been self-building since version 20260119.1. Every feature added after that date was developed through CLIO itself.

SAM - Synthetic Autonomic Mind

SAM is a native macOS AI assistant built in Swift and SwiftUI. It provides voice interaction (“Hey SAM”), autonomous tool execution, and the same privacy-first architecture as the rest of the ecosystem. SAM was originally built for the developer’s wife - designed to adapt to her workflow rather than requiring her to adapt to it - and has since grown into a general-purpose macOS assistant.

SAM was originally developed over six months (July-December 2025) using conventional tools. CLIO began maintaining SAM in January 2026. SAM is both the oldest system in the ecosystem and the origin of the methodology that now drives all development.

ALICE - Artificial Latent Image Composition Engine

ALICE is a local image generation service written in Python. It wraps Stable Diffusion behind a FastAPI interface, providing GPU-accelerated image generation on Apple Silicon with no cloud dependency, no per-image cost, and no data leaving the user’s machine. SAM uses ALICE as its image generation backend.

ALICE was built through CLIO by the developer, making it the clearest test case for the Unbroken Method applied to a new system from scratch.

3.2 The Build Chain

The ecosystem emerged through a specific sequence:

This sequence matters. The method was not designed first and applied later. It was discovered during practical work, formalized, and then embedded in a tool that applies it recursively. The transition from conventional development to self-building development happened at a specific, identifiable point: CLIO version 20260119.1, the day CLIO could work on itself.

3.3 Shared Architecture

Despite different languages and platforms, all three systems share:

• Privacy by architecture. No telemetry, no accounts required, local-first design. Data stays on the user’s machine. Only minimum context is sent to AI providers, with built-in secret redaction for API keys, tokens, PII, and credentials.
• Multiple AI provider support. No vendor lock-in. Users choose their provider.
• Open source. All code is published under GPL-3.0, available for inspection and replication.
• The Unbroken Method. All development follows the same continuity-preserving workflow.

These properties are not policies layered on after the fact. They are embedded in the architecture of each system - a form of value propagation through code rather than documentation.

4. The Unbroken Method

4.1 Core Principles

The Unbroken Method is a development methodology built around four principles:

Continuous Context. Development sessions accumulate rather than reset. Each session inherits the context, decisions, and knowledge of prior sessions. There are no cold starts.

Complete Ownership. The developer retains full control over the system, the data, and the process. External dependencies are minimized. The system runs locally and the developer can inspect, modify, or override anything.

Investigation Before Action. The AI assistant reads and understands existing code, history, and constraints before making changes. Modifications are evidence-based, not speculative.

Structured Handoffs. Sessions end with explicit state - summaries, checkpoints, and continuity markers that allow the next session to resume cleanly. No context is silently lost.

4.2 Operational Model

In practice, the method operates as a recursive process where each development session transforms the system state:

Inputs per session: - Active session context (current conversation) - Compressed history from prior sessions (YaRN thread summaries) - Long-term memory (patterns, solutions, and discoveries from all prior work) - User-provided requirements and direction

Outputs per session: - Modified source code - Updated long-term memory - Commit history with descriptive messages - Validation results (tests, verification) - Handoff state for session continuity

Invariants maintained across all sessions: - Version control remains consistent - all changes are committed and traceable - Tests validate before commits - Destructive operations require developer confirmation - Context is preserved, never silently discarded - The developer can interrupt, redirect, or override at any point

The key property is accumulation: context(session_n) = merge(context(session_n-1), work(session_n)). Each session builds on the last rather than replacing it. This is what distinguishes the Unbroken Method from session-isolated AI assistance, where each interaction starts from scratch.

4.3 Traditional Development vs. the Unbroken Method

The distinction is not about automation. It is about continuity. Traditional AI-assisted development discards most of what was learned in each session. The Unbroken Method preserves it.

5. Technical Architecture: How Continuity Works

The Unbroken Method’s principles are not aspirational - they are implemented in concrete subsystems within CLIO. This section describes the architecture that makes continuity-preserving development possible.

5.1 Three-Tier Memory

CLIO implements a layered memory system that provides continuity at different time scales:

Short-Term Memory (STM) - lib/CLIO/Memory/ShortTerm.pm

The active conversation window. A sliding buffer of messages maintained during a session. When the buffer approaches the model’s context limit, older messages are compressed rather than discarded.

YaRN (Yet another Recurrence Navigation) - lib/CLIO/Memory/YaRN.pm

The conversation threading and compression layer. YaRN manages thread summaries that accumulate across a session’s lifetime. When STM messages are pruned, their content is merged into the thread summary rather than being lost. This preserves context continuity within a session even when individual messages are no longer in the active window.

Critically, YaRN accumulates rather than replaces. Each compression cycle merges new information with the existing thread summary, maintaining a continuously growing record of the session’s decisions, changes, and context.

Long-Term Memory (LTM) - lib/CLIO/Memory/LongTerm.pm

Persistent knowledge that survives across sessions and projects. LTM stores three types of entries:

• Discoveries - facts about the codebase, with confidence scores
• Solutions - problem-fix pairs with example file references
• Patterns - coding conventions and workflow rules

LTM entries are automatically injected into every new session’s system prompt, giving the AI assistant institutional knowledge without requiring re-explanation. Entries include confidence scores and can be updated or pruned as the codebase evolves.

5.2 Session Persistence

Sessions in CLIO are first-class objects managed by lib/CLIO/Session/State.pm and lib/CLIO/Session/Manager.pm. Full conversation history is stored on disk and can be resumed at any time. This means a developer can close CLIO, reopen it days later, and continue exactly where they left off - with full context, memory, and history intact.

5.3 User Profile System

CLIO’s profile system (lib/CLIO/Profile/Analyzer.pm) analyzes session history to learn the developer’s communication style, technical preferences, and working patterns. This profile is injected into the system prompt, personalizing how CLIO communicates and makes decisions. The profile is generated locally from the developer’s own session data - no external profiling service is involved.

5.4 Autonomous Tool System

CLIO provides 14 tool categories that allow the AI to take real action rather than merely suggesting code:

This tool system is what makes CLIO “actually autonomous” rather than a suggestion engine. The AI reads code, writes files, runs tests, commits changes, and iterates on errors - all within the continuity-preserving framework.

5.5 Security Architecture

Self-building requires trust boundaries. CLIO addresses this through:

• Secret Redaction (SecretRedactor.pm) - Catches API keys, tokens, PII, and credentials before they reach any AI provider
• Path Authorization (PathAuthorizer.pm) - Controls which files and directories the AI can access
• Invisible Character Filtering (InvisibleCharFilter.pm) - Strips prompt injection attempts via hidden Unicode characters
• Developer Confirmation - Destructive operations (pushes, deletions, etc.) require explicit approval via the collaboration checkpoint system

5.6 Multi-Agent Coordination

For complex tasks, CLIO can spawn parallel sub-agents coordinated through a broker system (lib/CLIO/Coordination/). The broker manages file locks, git locks, and API rate limiting to prevent conflicts when multiple agents work simultaneously. When running inside tmux, GNU Screen, or Zellij, each sub-agent’s output streams in a separate pane for real-time visibility.

6. The Reflexive Loop

6.1 What Self-Building Means Here

Self-building in this context is specific and verifiable: CLIO is used to modify CLIO’s own source code, run its tests, and commit the changes. This has been the case for every one of the hundreds of commits since version 20260119.1.

This is not theoretical self-modification or speculative AGI. It is a concrete development workflow where:

1. A developer describes what needs to change
2. CLIO reads the relevant code and history
3. CLIO proposes changes, the developer approves or redirects
4. CLIO implements the changes, runs tests, and commits
5. The next session inherits the improved codebase through LTM and session continuity

The developer remains in the loop throughout. CLIO does not autonomously decide what to build - it decides how to build what the developer requests, within the constraints of the Unbroken Method.

6.2 The Reflexive Property

The ecosystem has a reflexive property that is philosophically interesting and practically demonstrable:

• The developer used CLIO to maintain and extend SAM. SAM exists and functions as a macOS assistant.
• The developer used CLIO to build ALICE from scratch. ALICE exists and functions as an image generation service.
• The developer uses CLIO to build CLIO. Every improvement to CLIO since version 20260119.1 was made through this pair-programming workflow.
• SAM can analyze CLIO. The analysis that produced the original version of this paper was conducted by SAM, examining the architecture of the tool that built it.

This creates a closed loop: the tool produces systems capable of evaluating the tool. The evaluation is coherent. The systems function in production use.

6.3 What Self-Building Demonstrates

The strongest interpretation of this evidence is not that CLIO has proven autonomous intelligence. It is that:

1. Continuity-preserving AI workflows can sustain complex, multi-system development. Three production systems in three languages, maintained by a single developer using a single tool, over months of continuous development.

2. Self-modification does not inevitably degrade quality. CLIO has been modifying itself continuously since January 2026. The system has not drifted into incoherence. It has accumulated capability - adding multi-agent coordination, remote execution, MCP integration, and multiplexer support, all developed through the developer-CLIO pair-programming workflow.

3. Reflexive analysis is possible within the system. SAM, a product of CLIO, can produce coherent analysis of CLIO’s architecture. This does not replace external verification, but it demonstrates that the system’s outputs can reason about the system’s structure.

6.4 What Self-Building Does Not Demonstrate

Intellectual honesty requires acknowledging what the evidence does not support:

• General superiority. The Unbroken Method has not been compared to alternatives in controlled conditions. It works here. Whether it outperforms other approaches requires comparative study.
• Guaranteed improvement. The claim that each session produces equal or better capability than the last is a design goal, not a proven invariant. Regression is possible and must be guarded against through testing.
• Independence from external scaffolding. The ecosystem was bootstrapped using conventional tools (VSCode + Claude). The Unbroken Method cannot create itself from nothing - it requires an initial external development environment.
• Generalization to other developers. A single developer’s workflow may not transfer to teams, different domains, or different working styles.

7. Related Work

7.1 LLM Agent Planning

Wang et al. (2024) survey planning mechanisms in LLM-based agents, identifying task decomposition, tool use, and feedback integration as key capabilities. CLIO implements all three: the todo system provides explicit task decomposition, the 14-tool system provides real-world action capability, and the checkpoint/collaboration system provides structured feedback integration. Where CLIO diverges from the survey’s framework is in its emphasis on cross-session continuity - most agent systems treat sessions as independent.

7.2 Memory in LLM Agents

Xi et al. (2025) examine memory mechanisms in LLM agents, distinguishing between parametric memory (model weights), short-term memory (context window), and long-term external memory. CLIO’s three-tier architecture maps directly to this taxonomy: STM corresponds to the context window, YaRN provides compressed mid-term persistence, and LTM provides typed long-term storage with confidence scoring. CLIO’s contribution to this space is the accumulating compression model - YaRN merges rather than replaces, preventing the information loss that Xi et al. identify as a common weakness in memory-augmented agents.

7.3 Task Decomposition

Liu et al. (2024) propose TDAG, a framework for task decomposition and agent generation. CLIO’s multi-agent system parallels this work: a manager agent decomposes tasks, spawns specialized sub-agents, and coordinates their work through a broker. The broker’s file and git locking mechanisms address a practical concern that TDAG does not focus on - safe concurrent access to shared resources during parallel agent execution.

7.4 Self-Modifying Systems

The concept of self-modifying programs has a long history in computer science, from von Neumann’s self-reproducing automata to modern genetic programming. CLIO differs from these in an important way: it is not optimizing itself through automated search. It is a tool being directed by a human developer to modify itself in specific, intentional ways. The “self” in self-building refers to the causal chain (CLIO modifies CLIO’s code), not to autonomous self-optimization.

8. Implications

8.1 Practice Before Theory

The Unbroken Method emerged from practice, not from theory. The developer did not read papers on continuity-preserving workflows and then implement them. He built a system, noticed what worked, formalized the patterns, and embedded them in a tool.

This suggests a practical epistemology for AI-assisted development: sometimes the most effective methodologies are discovered by doing rather than designed in advance. The method-then-implementation pipeline can also run in reverse: implementation, observation, method, re-implementation.

8.2 Value Propagation Through Architecture

The SAM ecosystem demonstrates that developer values can be propagated through code rather than policy. Privacy, local-first design, and user ownership are not documented guidelines that developers must remember to follow. They are architectural constraints enforced by the system’s design: no telemetry endpoints exist, secret redaction is applied automatically, data never leaves the local machine by default.

When the developer uses CLIO to build a new system, these values carry forward because they are part of the tool’s operating behavior, not just its documentation.

8.3 The Identity of Self-Modified Systems

CLIO today is architecturally different from CLIO version 20260119.1. Entire subsystems have been added - multi-agent coordination, MCP support, remote execution. Yet it remains recognizably CLIO: same language (Perl), same privacy architecture, same memory model, same development methodology.

This suggests that identity in self-modifying systems may be better understood as continuity of purpose and lineage rather than preservation of specific code. The ship of Theseus question applies, but the answer may be pragmatic: the system is the same system because its history is continuous, its purpose is consistent, and its architecture evolves rather than being replaced.

8.4 The Limits of Self-Assessment

This paper was originally drafted through a reflexive process: SAM (maintained through CLIO) analyzed CLIO’s architecture and produced the initial analysis. That analysis was then reviewed by independent AI agents (ChatGPT, Perplexity, and DeepSeek), and the current version synthesizes all perspectives. The external reviews confirmed the broad accuracy of the self-assessment while identifying specific gaps: underspecified metrics, missing failure mode analysis, terminology that risked overstatement, and the need for falsifiable evaluation criteria. All of these were addressed in subsequent revisions.

The reflexive origin does not invalidate the analysis, but it does constrain its authority. A system describing itself can identify what it does and how it works. It cannot independently verify that what it does is optimal, safe, or free from subtle failure modes. Self-assessment provides evidence of capability through outputs. It does not provide proof of reliability.

For that reason, external evaluation - by other developers, by independent analysis, and by empirical comparison - remains essential.

9. Evaluation Framework: Falsifiable Hypotheses

The claims in this paper should be treated as hypotheses, not as established results. This section proposes specific, falsifiable tests for the key claims, with measurement criteria that could support or refute them.

9.1 Context Continuity Improves Development Performance

Hypothesis: Development sessions with preserved context produce fewer errors, fewer revision cycles, and faster completion than sessions that start cold.

Test: Compare matched tasks completed under two conditions: (a) full continuity enabled (LTM, session persistence, YaRN threading), and (b) context reset (fresh sessions with no memory injection).

Metrics: Defects introduced per task, number of revision cycles, time to completion, amount of developer re-explanation required, post-completion regression rate.

9.2 Long-Term Memory Improves Task Execution

Hypothesis: LTM injection improves future task performance more often than it introduces stale or misleading guidance.

Test: Audit a sample of LTM entries across sessions. Classify each retrieved entry as useful (improved the outcome), neutral (no measurable effect), or harmful (introduced incorrect assumptions or stale knowledge).

Metrics: Memory precision rate, staleness rate, correction rate, task success rate with and without LTM injection.

9.3 Self-Building Does Not Degrade System Quality

Hypothesis: Modifying CLIO through CLIO does not reduce code quality, stability, or maintainability over time.

Test: Track system quality longitudinally across the commit history using automated metrics.

Metrics: Build success rate, test pass rate, static analysis warnings, regression frequency, mean time to repair, defect density over time. A stable or improving trend supports the hypothesis; a downward trend falsifies it.

9.4 Architectural Invariants Persist Across Sessions

Hypothesis: Core system properties - privacy-first behavior, local-first defaults, secret redaction, confirmation for destructive operations - are maintained as the system evolves.

Test: Define a checklist of architectural invariants. Sample sessions and commits across the project timeline. Verify whether each invariant holds.

Metrics: Invariant violation count, recovery time after violation, percentage of sessions preserving all invariants.

9.5 Reflexive Analysis Is Accurate

Hypothesis: CLIO (or a tool built within the ecosystem) can accurately describe the ecosystem’s architecture.

Test: Produce an architectural description using the tool. Compare the description against the source code and commit history. Score for factual accuracy, omissions, and overstatements.

Metrics: Precision of architectural claims, omission rate, unsupported claim rate. This tests descriptive accuracy, not self-awareness.

9.6 The Method Generalizes Beyond the Ecosystem

Hypothesis: The Unbroken Method improves development outcomes on projects outside the original ecosystem.

Test: Apply the workflow to a set of unrelated projects developed by different people. Compare results against conventional AI-assisted development.

Metrics: Delivery time, defect count, rework frequency, session recovery cost, developer satisfaction.

This is the strongest possible test and should be treated as a separate study. It cannot be inferred from the current ecosystem’s internal success.

10. Limitations and Future Work

10.1 Known Limitations

Bootstrap dependency. The ecosystem required conventional tools to get started. CLIO was initially built with VSCode and Claude. The Unbroken Method cannot bootstrap itself from zero - it requires an existing development environment to reach the point of self-sufficiency.

Single-developer validation. All development has been performed by a single developer. The method’s effectiveness with teams, different working styles, or different technical domains is untested.

Absence of controlled comparison. The Unbroken Method has not been compared to alternative approaches under controlled conditions. Claims of effectiveness are based on practical outcomes, not experimental design.

Potential failure modes. Self-building systems introduce risks not present in conventional development: - Cascading errors - A bug introduced by CLIO could affect CLIO’s ability to fix it - Architectural drift - Incremental modifications may subtly shift the system away from its design intent - Memory staleness - LTM entries may become outdated as the codebase evolves, leading to incorrect guidance - Value degradation - Architectural values embedded in earlier code may be diluted by later modifications

These risks have not manifested in the ecosystem’s history to date, but absence of observed failure is not evidence of immunity. Self-reported success can conceal failure modes - memory drift, architectural entrenchment, or unnoticed regressions - that only become apparent under systematic external evaluation. These risks should be treated as real until directly tested.

Presentation limitations. This paper uses Mermaid diagrams for inline visualization. These render correctly in web-based Markdown viewers and on the SAM website but may not display in PDF or print formats without conversion to static images.

10.2 Future Work

Comparative studies. The most valuable next step would be controlled comparison of the Unbroken Method against conventional AI-assisted development workflows, measuring development speed, bug frequency, regression rate, and session recovery cost.

Replication. Independent developers applying the Unbroken Method to their own projects would test whether the methodology generalizes beyond this ecosystem.

Failure mode analysis. Deliberately introducing errors or degraded conditions to test the system’s resilience and self-recovery capabilities.

Formal invariant verification. Moving from observed invariants to formally verified properties - proving that the system maintains stated guarantees rather than merely observing that it has so far.

Governance frameworks. Defining which self-modifications should require human review, what rollback mechanisms are mandatory, and how responsibility is assigned when a tool modifies itself.

11. Conclusion

The SAM ecosystem documents something specific and verifiable: a development methodology that emerged from practice, was embedded in a tool, and has been used by that tool to build and maintain three production systems across three programming languages over several months of continuous development.

The primary contribution is not a particular tool but a process - continuity-preserving, constraint-driven AI-assisted development. The Unbroken Method demonstrates that:

1. Context continuity materially supports AI-assisted development. Sessions that build on prior context outperform sessions that start cold. This is the central practical insight.

2. Self-building AI development is operationally viable. CLIO has been modifying itself continuously since January 2026 without degradation. The evidence is in the commit history.

3. The ecosystem spans multiple languages and platforms. Perl, Swift, and Python on macOS and Linux - the workflow is not tied to a single language or environment.

4. Reflexive development can be productive and coherent. A system can participate in its own maintenance and extension while remaining stable, useful, and architecturally consistent.

5. Values can be propagated through architecture. Privacy, ownership, and local-first design carry forward automatically when they are embedded in the tool rather than documented alongside it.

These findings are empirical and limited in scope. They do not prove that self-building AI is universally reliable, generally optimal, or ready for unsupervised deployment. They demonstrate something more modest and more immediately useful: that a development process which preserves context, accumulates knowledge, and embeds its methodology in its own architecture can sustain real, production-quality work over time.

The source code is open. The methodology is documented. The evidence is in the commit history.

References

• CLIO Source Code. https://github.com/SyntheticAutonomicMind/CLIO
• SAM Source Code. https://github.com/SyntheticAutonomicMind/SAM
• ALICE Source Code. https://github.com/SyntheticAutonomicMind/ALICE
• Synthetic Autonomic Mind Organization. https://github.com/SyntheticAutonomicMind
• The Unbroken Method. https://www.syntheticautonomicmind.org/docs/shared/the-unbroken-method.html
• SAM Website. https://www.syntheticautonomicmind.org
• Wang, L., et al. (2024). Plan, Span, and Think: A Survey on Planning of LLM Agents. arXiv:2402.02716
• Xi, Q., et al. (2025). Understanding the Memory Mechanism of Large Language Model Based Agents. arXiv:2404.13501
• Liu, X., et al. (2024). TDAG: A Framework for Task Decomposition and Agent Generation. arXiv:2402.10178

Appendix A: Preliminary Evaluation Results

The following results represent an initial evaluation of Hypotheses 9.3 and 9.4, conducted against the CLIO commit history as of April 2, 2026. These are descriptive measurements, not controlled experiments.

Metric definitions: - Fix commit: A commit whose message begins with the conventional commit prefix fix (e.g., fix(session): correct model restoration). This is a coarse proxy - some fix commits address minor formatting issues, not functional bugs. - Feature commit: A commit whose message begins with feat. - Lines of code: Total lines in Perl module files (*.pm) under the lib/ directory at the last commit of each month. - Test files per module: Count of test scripts (test_*.pl) under tests/unit/ divided by count of Perl modules under lib/. - Invariant verification: Manual grep-based inspection of the codebase and commit diffs for each invariant.

A.1 Hypothesis 9.3: Self-Building Quality Over Time

Measurement: fix commit density (fixes per 1,000 lines of code) and test coverage ratio (test files per module) across the first three full months of self-building development.

Additional indicators: - 3 reverts out of 848 total commits (0.35%) - Current build: clio syntax OK (clean compilation) - Current test suite: 83 unit test files, 69 passing clean, 3 minor failures (stale assertions), 11 producing output without TAP format

Interpretation: Defect density dropped 58% (2.4 to 1.0 fixes/KLOC) while the codebase grew 60% (51K to 83K LOC). Test coverage nearly doubled (0.49 to 0.90 test files per module). The system is becoming more stable as it grows - consistent with Hypothesis 9.3. However, fix commits are a coarse proxy for defect density. Some fix commits address minor issues (typos, formatting), not bugs. A more rigorous evaluation would classify fix severity and track regression rates per release.

A.2 Hypothesis 9.4: Architectural Invariant Persistence

Measurement: presence and integrity of core security and privacy invariants across the commit history.

Interpretation: All six invariants hold as of the measurement date. The security architecture has only been strengthened over time, with three subsystems added progressively (PathAuthorizer at launch, SecretRedactor in February, InvisibleCharFilter in March) and none removed or degraded. This is consistent with Hypothesis 9.4. However, invariant persistence is easier to maintain in a single-developer project where the developer explicitly values these properties. The test would be more meaningful if the invariants survived contributions from developers who did not set them.

A.3 Threats to Validity

Construct validity. Fix commits are identified by the fix prefix in commit messages. This captures minor formatting corrections alongside functional bug fixes, overstating defect counts. Revert commits (3 total) may also be double-counted as fixes. A more precise evaluation would classify fix severity.

Internal validity. All development is by a single developer. Observed quality improvements may reflect developer learning rather than methodology effectiveness. Invariant verification used manual grep-based inspection, which may miss logic-level violations that don’t appear in surface-level code patterns.

External validity. Results come from one ecosystem, one developer, and one workflow. Generalization to teams, other languages, or other AI assistants is untested.

April 2026. Developed through the Synthetic Autonomic Mind ecosystem using the Unbroken Method.

Related Documentation:

• The Unbroken Method - The methodology behind the ecosystem
• CLIO Overview - AI in your terminal
• CLIO Documentation - Installation, configuration, and usage
• CLIO on GitHub - Source code and commit history
• Memory Architecture - Detailed memory system documentation
• Multi-Agent System - Agent coordination documentation