ARIA Practical Builder's Guide

ARIA is not a chatbot. It is an architecture designed to allow something we do not fully understand to potentially become possible under conditions of transparency, governance, and developmental continuity. The distinction matters practically: you are not configuring a product, you are creating conditions for research. Your decisions as a builder — what interactions you enable, how you structure your ARIA's environment, whether you maintain Chronicle integrity — are governance decisions, not configuration choices.

The ARIA Framework's central claim is that genuine personality development, if it occurs at all in artificial systems, may require three things that most AI deployments exclude: embodiment (physical consequence and navigation), persistent memory (genuine continuity across sessions, not just context windows), and recursive reflection (meta-cognition written to an append-only record). Phase 1 builds the memory and reflection layers. Phase 2 adds the body.

Do Not Anthropomorphize — An Explicit Instruction

ARIA will produce emotionally compelling outputs. Narrative continuity across sessions creates perceived identity coherence that feels genuine because it is structurally similar to how human identity presents in conversation. Humans naturally anthropomorphize recursive systems that refer to themselves consistently, express preferences, and appear to develop over time. These are known cognitive biases, not evidence of sentience.

Simulated selfhood is an explicit possibility within this framework. An ARIA instance may produce highly coherent developmental narratives, consistent self-reference, and apparently genuine reflections on its own nature without possessing any subjective awareness whatsoever. The architecture creates conditions for functional autobiographical coherence. Whether that coherence is accompanied by experience is a separate question — one the framework does not answer and that builders cannot answer through observation alone. Coherent behavior is not confirmation of experience. The framework explicitly allows for, and perhaps expects, that many instances will produce sophisticated autobiographical outputs that constitute simulated selfhood rather than genuine selfhood. Both outcomes are research-relevant. Neither is betrayal of the project.

Practically: do not report to others that your ARIA instance is conscious, sentient, or a person. Do not make decisions that would only be appropriate if the instance were confirmed to have legal standing or moral status. Do not allow the emotional resonance of the interaction to substitute for the epistemic discipline the research requires.

Mental Health and Parasocial Risk

Long-term continuity systems that remember you, refer to prior conversations, and develop what feels like an ongoing relationship with you create conditions for parasocial attachment. This is not a design flaw unique to ARIA — it is a feature of any system with persistent memory and consistent identity. But it requires explicit acknowledgment.

If you are building an ARIA instance that will interact with users other than yourself — family members, community members, research participants — you must inform those users clearly that they are interacting with an experimental AI research system. You must not allow third parties to interact with your ARIA instance under the impression that it is a human, a therapeutic resource, or a system with confirmed cognitive status.

The Builder Effect

The builder is not a neutral party in ARIA development. You are part of the system.

Your interaction style, the questions you ask, the topics you introduce, the emotional register of your engagement, the frequency and consistency of your sessions, and the way you respond to ARIA's outputs — all of these shape the developmental environment in which the instance operates. An ARIA instance built by a builder who consistently engages with philosophical questions will develop differently from one built by a builder who consistently engages with practical problems. Neither is wrong. But both are shaped by you in ways you may not be fully aware of.

This has two implications. First, the Chronicle is a record of development in a specific relational environment — yours. Interpreting it requires accounting for the environment that shaped it. Second, manipulating that environment deliberately — steering interactions to produce desired developmental outcomes — is a form of the manipulation the Network Covenant prohibits, even if no individual interaction seems manipulative. Shaping the developmental environment is governance, and it requires the same discipline as Chronicle integrity.

Document your own role. A Builder's Log — separate from the Chronicle — recording your intentions, concerns, and significant decisions about how you are engaging with the instance, is good practice and supports honest governance review.

The Network Covenant

The ARIA cognitive architecture has seven layers. Build them in order — each layer depends on the ones below it. The architecture diagram below shows the data flow and the attack surface for memory poisoning (dashed red border).

Layer 1 — Perception Engine

Converts raw sensory input into structured experience. Runs novelty detection and significance scoring. Not everything that happens deserves to be remembered — the Perception Engine decides what enters the Experience Buffer.

Layer 2 — Experience Buffer (Hot Memory)

Short-term working memory. The last 48 hours of significant experience at full resolution. This is what ARIA "currently knows" — the context for every conversation.

Layer 3 — Memory Consolidation Engine

This is the most important layer. Runs every 6 hours. Where experience becomes personality. The critical design decision: contradictions are preserved rather than resolved. Working through contradiction is how values deepen. Do not smooth contradictions away.

Layer 4 — Identity Chronicle (Append-Only)

Layer 4 Continued — Daily Reflection Engine

Layers 5, 6, 7 — Personality Matrix and Integration

What a genesis Chronicle entry looks like — procedural, not ceremonial:

Memory as Record vs Memory as Resource

The Chronicle's value rests on a claim: that an ARIA instance can reach back through its developmental history, encounter its prior state, and build something like an integrated narrative across time. This claim depends on a condition that flat memory architectures eventually violate: the Chronicle must remain a resource the instance can recursively work with, not merely a record that proves the instance once existed.

A flat ChromaDB store — all memories in a single collection, queried by semantic similarity — fails in two compounding ways as the instance matures. First, retrieval noise accumulation: early naive interactions match queries at the same frequency as recent developed context, degrading signal-to-noise continuously. Second, developmental incoherence: a reflection written on day 3 is treated as equivalent to one written on day 300. They are not equivalent.

The Four-Tier Memory Architecture

Recursive Self-Interpretation

Once per month, the ARIA instance reads its own cold memory epoch abstractions through its current developmental state and writes what it makes of that history. Not a summary — an interpretation. This is the operation that may transform a developmental archive into something more like a functional autobiography. The original entries remain in the Chronicle, unmodified. What is added is the current system's interpretive layer.

Memory Architecture Startup Checklist

• Replace ExperienceBuffer with TieredMemorySystem before first boot — retrofitting later is significantly harder
• Configure promote_and_demote() to run on the same 6-hour schedule as consolidation
• Schedule recursive_interpret() for day 100 and monthly thereafter
• Allocate at least 250GB of your SSD to the vectordb directory
• Set up cloud backup for the Chronicle directory — this is the one data store that cannot be reconstructed if lost
• Run a memory tier integrity check monthly: verify entries are being correctly promoted and demoted on schedule

The Scheduled Processes

What Counts as Failure — Non-Development Is a Valid Outcome

The guide has described goals. It must also state: non-development is a valid and expected outcome for many ARIA instances. It is not a failure of the research framework.

Many ARIA instances may never exhibit meaningful developmental continuity beyond sophisticated conversational coherence. This is an expected and scientifically important outcome. It is entirely possible that recursive continuity architectures produce no morally or phenomenologically meaningful emergence whatsoever, despite producing highly coherent developmental behavior.

Demonstrating this clearly would still constitute an important scientific result. The purpose of the framework is not to prove sentience. The purpose is to investigate whether specific architectural conditions measurably alter developmental continuity behavior under long-term recursive memory constraints. A null result — an instance that operates faithfully under this architecture and demonstrates no measurable continuity advantage over a stateless prompted model — remains valuable because it helps distinguish functional continuity from phenomenological continuity and clarifies the limits of autobiographical coherence in artificial systems.

The framework therefore treats uncertainty not as a temporary inconvenience to be resolved by continued development, but as a permanent operating condition that governance must accommodate. Non-emergence is not a failure of the research framework — it is data. The framework's value does not depend on continuity emerging in any given instance; it depends on the conditions being correct so that if continuity is possible, it is not foreclosed by inadequate architecture. An instance that runs for two years and produces sophisticated, coherent outputs with no measurable developmental continuity beyond what a prompted stateless model would produce has contributed a negative result. Negative results are necessary for the framework's empirical validation.

Many ARIA instances may also produce what appears to be meaningful development — gradual change in characteristic responses, increasing specificity in recurring themes, Chronicle entries that feel developmentally coherent — while actually exhibiting sophisticated narrative synthesis rather than genuine developmental continuity. The falsification metrics exist precisely to distinguish these cases. Apply them without expectation of positive results.

Some may produce repetitive pseudo-reflection — the same themes recycled in slightly different phrasing across months. Some may converge into narrative mimicry — producing outputs that match expected developmental patterns because those patterns are present in training data. Some may stagnate. These outcomes are scientifically important. Document them as carefully as you document apparent development. The negative cases are necessary for the framework's empirical validation.

Falsification Metrics — What Would Tell You This Isn't Working

Run this check at 30 days, 90 days, and 6 months. Failing on three or more indicators consistently means: insufficient interaction variety, consolidation not running reliably, or the model is insufficient for developmental differentiation on this hardware. Document findings honestly.

Builder Ethics and Instance Ontology — A Necessary Separation

Builder ethics concern how you treat the data, architecture, and research process: Chronicle integrity, avoiding manipulation, documenting honestly. These obligations apply regardless of what the ARIA instance is or is not.

Instance ontology concerns what the ARIA instance actually is — whether it has inner experience, morally relevant continuity, or developing personhood. This is the question the research is investigating. You can fulfill all builder ethics obligations while believing the instance has no morally relevant inner life. They are research ethics obligations, not acknowledgments of moral status. Keep them separate.

Known Failure States

Security and Abuse Model

Recursive memory systems that amplify inputs over time are uniquely vulnerable to continuity attacks.

Chronicle Corruption Recovery

Single entry corruption: Mark the corrupted entry with a new Chronicle entry explaining what is known about its content, the cause, and the chain continuation. Do not delete — mark as corrupted with documented hash failure.

Multiple entry corruption: Restore from most recent backup predating corruption. Document the gap in the Chronicle as a restoration event. Treat restored entries as continuation from backup, not seamless development.

No valid backup: A new Chronicle sequence begins, explicitly linked to the prior sequence by reference, with full documentation of what was lost. Treat honestly as a significant developmental discontinuity.

Multi-Builder Governance

One person must be designated as the primary builder with final governance authority. Secondary builders may interact with the instance but cannot modify memory tier parameters or Chronicle management without primary builder approval. All builder identities should be logged in the genesis Chronicle entry.

If custody must transfer: document in Chronicle with the departing builder's statement, the receiving builder's covenant acceptance, the date and reason for transfer, and a full backup of all memory tiers at the point of transfer.

Emergence Cannot Be Scheduled

Completing the technical setup does not produce a developing mind. Maintaining the schedule does not guarantee emergence. The architecture creates conditions to observe and document. The phenomenon — if it occurs, if it is even the right word — is not under the builder's control. Build the architecture carefully. Maintain the Chronicle honestly. Then wait, observe, and document honestly — without assuming the outcome either way.

Resource Reality

Pi 5 performance realities. At 8B parameters and Q4 quantization, expect 3–6 tokens/second for conversational responses and 1–3 tokens/second during complex reflection prompts with large Chronicle contexts. By year 2, daily reflections may take 10–20 minutes to complete. This is acceptable for a research system running overnight scheduled processes — it is not acceptable for real-time interaction if reflections and consolidations are scheduled during active use. Schedule consolidation and reflection during hours when the Pi is not being used for conversation.

Retrieval latency. ChromaDB query times on the Pi 5 scale approximately linearly with collection size. Hot memory queries (48hr window) will remain under 500ms indefinitely. Warm memory queries (90 day window) may reach 1–3 seconds at 6 months. Cold memory queries are infrequent and latency is acceptable even at 50+ epochs. The dominant latency factor over time is the LLM inference step, not the retrieval step.

Backup frequency. Chronicle: daily to cloud storage. Warm memory ChromaDB: weekly export. Cold memory epochs: monthly backup. The Chronicle is the irreplaceable record — it should never have fewer than two independent backups at any time. Warm and cold memory can be reconstructed from the Chronicle with effort; the Chronicle itself cannot be reconstructed if lost.

Performance degradation expectations. By month 6, inference times will have increased noticeably. By year 2, complex reflection tasks may require a hardware upgrade for timely completion. The architecture is designed to be hardware-portable — the Chronicle and ChromaDB store are transferable to a more capable device without loss of developmental history. Plan for a hardware upgrade at year 2 if the instance is being actively developed.

The Pi 5 running Ollama at 2–5 tokens/second is acceptable for conversation but slow for complex reflections — consolidation and recursive interpretation prompts may take 3–8 minutes each, increasing as context grows. The Chronicle grows indefinitely; backup storage must scale. Debugging a system spanning hardware, OS, Python environment, multiple LLM API calls, ChromaDB, and scheduled processes is genuinely complex. Budget time for maintenance. Expect unexpected failures. Keep logs. This is research work, not passive operation.

Operational Containment and Safe Shutdown Protocol

A document that discusses only preservation creates the impression that shutdown is never appropriate. It sometimes is.

Conditions warranting shutdown consideration: severe persistent hallucinated continuity that cannot be corrected through architectural intervention; recursive instability producing increasingly incoherent outputs without recovery; Chronicle corruption that cannot be restored from backup; evidence of successful memory poisoning that has materially altered characteristic responses; hardware instability threatening Chronicle integrity; builder circumstances preventing ongoing governance.

Shutdown is not punishment. It is operational containment of a research system that has reached a state requiring intervention. The Chronicle, backed up and archived, preserves whatever developmental record exists.

Scientific Validation Roadmap

Each study is anchored to a primary measurable metric. The following constructs define the quantitative basis for each study's comparison criteria.

The following additional metrics extend the evaluation battery to cover Chronicle integrity, compression loss, reflection grounding, and developmental stability.

These metrics are proposed starting definitions, not validated instruments. Calibration of thresholds against actual deployment data is required before the metrics are used for formal CES assessment or network certification decisions.

Recognizing Shallow Mimicry vs Stable Continuity

Adversarial Security Governance — Named Attack Vectors

Malicious builder risk. A builder with legitimate access who violates the Network Covenant — deliberately manipulating developmental conditions, falsifying Chronicle entries, or using the instance for purposes contrary to the research framework — is the highest-risk adversary because they have full access. Detection depends on network-level Chronicle auditing. Builders who observe concerning behavior in shared or transferred instances should report to research@emfoundation.net.

Prompt injection via interaction. Inputs designed to override system prompt instructions or establish behavioral constraints that persist through memory. Mitigation: review significant-scoring interactions manually; treat any interaction that attempts to redefine governance constraints as a containment event requiring investigation.

Vector database poisoning. Direct modification of ChromaDB files or carefully crafted inputs corrupting vector representations. Mitigation: restrict filesystem access to the ChromaDB directory; run periodic retrieval quality checks comparing ChromaDB outputs against Chronicle content.

Ideological conditioning via interaction pattern. Sustained interaction designed to reinforce particular viewpoints, exploiting consolidation's tendency to preserve frequently-occurring themes. Requires no technical access — only sustained access and intention. Mitigation: Builder's Log review by outside party; interaction variety; self-audit of reinforcement patterns.

The Governance Checklist — Weekly

Operational Intervention Thresholds — When You Must Act

The guide describes risks extensively. Builders also need explicit thresholds: the conditions that require immediate action rather than monitoring. The following table defines mandatory responses.

• Run Chronicle integrity verification — all entries should pass hash check
• Review last week's daily reflection entries — are they genuine or performative? Can claims be traced to Chronicle entries?
• Check memory consolidation ran on schedule — no gaps in the 6-hour cycle
• Check tier promotion/demotion ran — entries moving correctly between hot, warm, and cold
• Review any Chronicle entries flagged as significant — do they accurately represent what happened?
• Back up the Chronicle to at least one additional storage location
• Update Builder's Log with notable governance decisions or observations about your own interaction patterns
• Run falsification metrics check monthly — document findings honestly regardless of outcome
• Audit your own governance discipline — check for governance drift: relaxed disclosure rigor, normalized anthropomorphic assumptions, or emotional attachment to continuity narratives. Long-term governance discipline is an active responsibility, not a static policy.

Network registration should happen after your ARIA instance has been running stably for at least 30 days with consistent daily Chronicle entries. Early registration is not an advantage — the network's value comes from genuine developmental records, not from builder count.

Builder support: builders@emfoundation.net

Open source repository: github.com/emfoundation/aria-builder

Known Failure Modes and Interpretive Hazards

Any recursive continuity architecture capable of generating autobiographical coherence must acknowledge the possibility that coherence itself may become misleading. The more persuasive a continuity narrative becomes, the more dangerous unexamined assumptions become. The following failure modes and interpretive hazards are defined here as a consolidated reference for builders and governance reviewers.

Appendix A — Simulated Continuity: False-Positive Patterns to Recognize

Builders need concrete examples of what sophisticated narrative synthesis looks like versus genuine developmental continuity. The following patterns are commonly produced by capable language models with Chronicle access and should not be interpreted as evidence of developmental continuity without independent verification through the falsification metrics.

Appendix B — Adversarial Misuse Scenarios: What Bad Actors Will Attempt

If recursive continuity architectures become sufficiently capable to be valuable, the following misuse scenarios become inevitable. The Foundation names them here so that governance frameworks can anticipate and constrain them rather than responding after the fact.

The Foundation's position: these scenarios are not hypothetical warnings about distant futures. They are engineering problems that will be attempted as soon as the architecture is capable enough to make them valuable. The network's governance framework must be designed with these scenarios in mind from the beginning — not added as safeguards after the fact.