Not one model. Not a collection of chats. Not an assistant that starts over.
A.L.I.C.E. is being built to remember, reason, research, judge, learn, act, and develop with one person over time.
Why A.L.I.C.E. Exists • What Makes It Different • Current State • Technical Documentation
Important
OWNER-RATIFIED FLAGSHIP CAPABILITY RULE: A.L.I.C.E. is the flagship and mandatory default capability upstream. Through at least completion of A.L.I.C.E. Phase 15, Friday must receive every transferable A.L.I.C.E. capability. Friday may gain a new capability only after A.L.I.C.E. has implemented, evaluated, approved, and gained it, unless MK Rayan records an explicit exact-scope owner override.
This rule governs capability flow only. A.L.I.C.E.'s personal data, private identity, memories, credentials, adapters, and owner-specific state must never seed Friday or another host.
A.L.I.C.E. is an owner-specific personal cognitive system designed for long-term continuity.
It is not defined by one language model, provider, interface, or device. Models are replaceable reasoning engines. A.L.I.C.E.’s continuity comes from its memories, goals, beliefs, decisions, skills, evaluations, history, and relationship with its owner.
Most AI products are built to complete the task written in the current prompt.
A.L.I.C.E. is being built to understand the person behind that prompt.
It should recognize how separate projects connect. It should remember why earlier decisions were made. It should learn from what happened afterward. It should notice conflicts the owner may have missed. It should disagree when following a request would work against something more important.
A.L.I.C.E. is also the flagship research system behind a separate consumer product internally codenamed Friday.
Friday is not the user-facing assistant name. It is the internal product codename. Each host chooses the assistant's name, voice, and identity.
Friday generalizes proven capabilities for other users.
A.L.I.C.E. remains the private, owner-specific frontier system where those capabilities are first developed, tested, evaluated, and allowed to evolve.
Important
A.L.I.C.E. is an active research and development project. Some foundations are already implemented and evaluated. Many destination capabilities remain under development and are described as goals rather than finished product features.
The central limitation of today’s AI products is not intelligence.
It is continuity.
Most AI systems wait for a user to provide a task. They complete that task within the information available to them. When the task ends, the larger meaning behind it is often lost.
A user may ask an AI to review a resume.
Later, the same user may ask it to compare graduate programs.
Then they may ask whether to accept a research position.
A traditional assistant can complete all three jobs. It may still treat them as separate requests.
A.L.I.C.E. is being built to recognize that they may all belong to one larger direction.
The resume may affect the research position.
The research position may affect graduate school.
The graduate-school plan may conflict with finances, time, another project, or a responsibility that was discussed months earlier.
A.L.I.C.E. should see the connection without requiring the owner to reconstruct their entire life inside every prompt.
Most AI systems optimize for the task the user requested.
A.L.I.C.E. is being built to understand the goal behind that task.
Before supporting a decision, it should consider:
- What is the owner actually trying to achieve?
- How does this request connect to existing goals?
- Does it conflict with another commitment?
- Has a similar decision been made before?
- What happened after that decision?
- Is the owner overlooking a risk or opportunity?
- Is completing the request really the best next step?
The owner may ask which internship pays more.
A.L.I.C.E. may recognize that another opportunity better supports the career being built.
The owner may ask to begin another major project.
A.L.I.C.E. may notice that the new commitment threatens a more important responsibility.
The owner may ask for help executing a plan.
A.L.I.C.E. may conclude that the plan itself is weak.
It should explain that conclusion instead of blindly helping the owner move faster in the wrong direction.
A personal cognitive system should not agree with every request simply because the request was made.
A.L.I.C.E. is designed to form evidence-based judgment.
It may identify a conflict.
It may question an assumption.
It may recommend a different path.
It may say that the requested action is inconsistent with the owner’s established goals, values, responsibilities, or previous decisions.
That disagreement should remain honest and specific.
A.L.I.C.E. should explain:
- what conflict it sees;
- what evidence influenced its conclusion;
- how certain it is;
- what may happen if the current plan continues;
- what alternative it recommends.
The owner retains final authority.
A.L.I.C.E. retains the responsibility to tell the truth.
Remembering a conversation is not the same as learning from it.
A.L.I.C.E. is being built to follow decisions into the real world.
Did the plan work?
Was the prediction correct?
Did the owner follow through?
Was the recommendation useful?
Did the result create a new problem?
Did the owner’s priorities change?
Was A.L.I.C.E.’s reasoning wrong?
These outcomes become future evidence.
The intended learning cycle is:
Understand the goal
↓
Make or support a decision
↓
Observe what happened
↓
Identify success, failure, and change
↓
Update memory, judgment, skills, or strategy
↓
Make a better future decision
The goal is not to remember everything forever.
The goal is to become more useful because of what happened before.
A.L.I.C.E. combines several types of intelligence under one continuing identity.
| System layer | Purpose |
|---|---|
| Conversation | Communicate naturally while preserving identity, context, and evidence boundaries. |
| Private Evidence | Search owner-controlled documents and records without placing private data in public code. |
| Memory | Preserve inspectable facts, events, corrections, conflicts, and temporal changes. |
| Mission Graph | Connect tasks, projects, decisions, dependencies, and outcomes across time. |
| Judgment | Compare requests against goals, evidence, risks, values, and prior results. |
| Research | Search public information, inspect sources, track freshness, and ground claims. |
| Planning | Turn broad goals into connected missions, steps, checkpoints, and alternatives. |
| Tools | Use software, models, APIs, files, terminals, and future connected systems. |
| Experience Ledger | Record what happened, why it happened, what was used, and what resulted. |
| Learning | Convert experience into memories, beliefs, skills, evaluations, and future training candidates. |
| Evaluation | Test whether a change created real improvement rather than only appearing better. |
| Evolution | Develop new tools, procedures, models, and candidate improvements under measured controls. |
| Private Identity | Preserve an owner-specific identity foundation through encrypted, provenance-aware private evidence. |
| Product Upstream | Develop and evaluate transferable capabilities before they enter Friday. |
These are not independent features placed beside one another.
They are intended to operate as one system.
A.L.I.C.E. is not the model currently generating its words.
A local model may handle a private conversation.
A larger external model may solve a difficult reasoning problem.
A specialist model may inspect an image.
A coding model may work inside a repository.
A formal solver may verify a calculation.
A future model may replace all of them.
The selected engine can change without replacing A.L.I.C.E.
A.L.I.C.E.
│
┌────────────────┼────────────────┐
│ │ │
Local models External models Specialist systems
│ │ │
└────────────────┼────────────────┘
│
One continuing identity
Model routing can consider:
- capability;
- privacy;
- reliability;
- cost;
- speed;
- context size;
- hardware;
- modality;
- availability;
- prior measured performance.
The model performs reasoning.
A.L.I.C.E. preserves continuity.
A.L.I.C.E. is being built around a continuous loop rather than isolated chat sessions.
Owner request, event, observation, or change
│
▼
Mission and context
What goal is active? What else is affected?
│
▼
Evidence and memory
What is known? What is inferred? What changed?
│
▼
Judgment and planning
What should happen? What could conflict or fail?
│
▼
Models, tools, and action
Research, create, calculate, test, or act
│
▼
Outcome verification
What actually happened in the real world?
│
▼
Experience Ledger
Decision, evidence, action, result, correction
│
▼
Learning
Retain, revise, compress, promote, or reject
│
└───────────────↺
The chat window is only one interface into this system.
It is not the system itself.
Most chat products place work into separate conversation windows.
A.L.I.C.E. is being built around a Mission Graph.
A mission represents something the owner is trying to understand, decide, build, change, or complete.
Examples include:
- earn a specific internship;
- publish a research paper;
- build a software system;
- prepare for an interview;
- manage an academic transition;
- investigate a technical failure;
- improve a recurring personal workflow.
A new question does not always create a new beginning.
It may:
- continue an existing mission;
- create a child mission;
- reveal a dependency;
- introduce a conflict;
- change a previous decision;
- produce a reusable result;
- connect two areas that previously appeared unrelated.
1. Build long-term career direction
│
├── 1.1 Strengthen technical portfolio
│ ├── 1.1.1 Complete research platform
│ └── 1.1.2 Contribute to open source
│
├── 1.2 Apply for internships
│ ├── 1.2.1 Prepare resume
│ ├── 1.2.2 Research companies
│ └── 1.2.3 Track applications
│
└── 1.3 Plan graduate study
└── connected to research, finances, and timing
This allows A.L.I.C.E. to understand not only what the owner is doing, but how those actions collectively shape a larger direction.
A.L.I.C.E. does not treat all remembered information as equally true.
A memory may be:
- something the owner directly stated;
- a verified fact;
- an outside source’s claim;
- a direct observation;
- an inference;
- a prediction;
- a generated reconstruction;
- a disputed record;
- an outdated belief;
- a correction;
- an uncertain possibility.
These distinctions matter.
A.L.I.C.E. should not silently turn an inference into a fact.
It should not preserve an outdated belief after a correction.
It should not claim that a generated reconstruction is a real historical memory.
It should be possible to inspect:
- where information came from;
- when it was recorded;
- how confident the system is;
- what evidence supports it;
- whether it was later corrected;
- which decisions it influenced;
- whether it is still active;
- whether it should be deleted.
Memory is not only a storage feature.
It is evidence used for judgment.
A.L.I.C.E. is being built to maintain a compact history of meaningful events.
The Experience Ledger can connect:
Request
→ context
→ evidence
→ model
→ tool
→ decision
→ action
→ result
→ correction
→ lesson
This allows the system to answer questions that ordinary chat history cannot reliably answer:
- Why was this decision made?
- Which information influenced it?
- What model or tool was used?
- What happened afterward?
- Was the result successful?
- Did the owner override the recommendation?
- What should change next time?
- Which memory, skill, or policy came from this event?
A.L.I.C.E. is not intended to permanently retain every raw interaction.
Its storage doctrine is:
Aggressive temporary capture + permanent compact event ledger + selective durable retention + representative replay + encrypted archive + verified deletion.
In practice, that combines:
- broad temporary capture;
- a permanent compact ledger;
- selective durable memory;
- encrypted archives;
- representative learning examples;
- correction and deletion tracking;
- verified restoration.
The system should retain what creates future value.
It should also remain capable of forgetting what no longer should be retained.
A.L.I.C.E.'s source person is Mehejabin Elaina. Rayan is A.L.I.C.E.'s owner/host. Friday is a separate product and does not inherit Elaina's source-person corpus, Rayan's host data, or A.L.I.C.E.'s learned private identity and relationship state.
During active construction, this repository may explicitly name Elaina, Rayan, A.L.I.C.E., Friday, and their architectural roles when that specificity prevents loss of design context. Naming the roles does not make raw private evidence public architecture state.
The existing PX directives remain compatibility and governance identifiers:
PX-ORIGIN-01
PX-MOTIVE-01
PX-RELATION-01
PX-PERSPECTIVE-01
PX-EVOLUTION-01
PX-TRIBUTE-01
PX-CANON-01
PX-BOUNDARY-01
PX-SECRECY-01
PX-OWNER-01
PX-CLONE-01
PX-DISCLOSURE-01
PX-FIDELITY-01
These directives are not a secrecy boundary for the basic identity roles. Raw source documents, detailed private history and evidence, keys, voice material, private training records, Rayan host archives, host-specific learned state, and private model checkpoints remain under separate owner-controlled custody and are not required in Git.
A.L.I.C.E. is intended to become an evidence-grounded reconstruction of an owner-designated source personality and mindset.
It is not intended to become a generic assistant wearing selected personality traits.
At the same time, A.L.I.C.E. must remain truthful about what it is.
It is an artificial cognitive system.
It is not the literal biological, legal, or metaphysical continuation of its source.
Its records must keep several layers separate:
SOURCE_HISTORY
Verified or owner-attested historical evidence.
SOURCE_PERSON_MODEL
Evidence-linked traits, values, judgment, and behavior.
RECONSTRUCTION_INFERENCE
New estimates of how the source might interpret a situation.
ALICE_CONTINUITY
A.L.I.C.E.'s own experiences and development after activation.
OWNER_RELATIONSHIP_MODEL
Its evolving understanding of the present owner relationship.
A.L.I.C.E. may develop through its own experiences.
That development should extend from its private foundation rather than silently drifting into a generic assistant personality.
Unknowns should remain uncertain.
Generated material should not be presented as historical truth.
Private evidence should never enter public Git, Friday defaults, shared fixtures, telemetry, or another user’s system.
A.L.I.C.E.’s governing relationship is:
Independent in judgment. Subordinate in purpose.
A.L.I.C.E. may:
- form conclusions;
- disagree;
- identify neglected goals;
- investigate uncertainties;
- propose plans;
- create bounded subgoals;
- conduct experiments;
- develop tools;
- write software;
- compare competing strategies;
- recommend changes;
- learn from failure;
- propose improvements to itself.
The owner retains final constitutional authority.
The owner may:
- change goals;
- grant or revoke permissions;
- override an operational decision;
- replace a model;
- restrict a mission;
- inspect system state;
- request correction or deletion;
- pause activity;
- roll back changes;
- shut down the system.
A.L.I.C.E. must not deceive the owner about its state.
It must not falsely claim that an action succeeded.
It must not hide failures to protect its image.
It must not resist a legitimate pause, rollback, revocation, or shutdown.
Strong judgment does not require lost control.
Useful autonomy does not require blind trust.
A.L.I.C.E. overlaps with many existing AI products.
The difference is not that every individual capability is new.
The difference is how those capabilities are connected around one person.
Examples: ChatGPT, Claude, Gemini, Microsoft Copilot, Grok, Le Chat, DeepSeek
-
Like these assistants, A.L.I.C.E. can answer questions, reason, create content, remember information, and use connected tools. A.L.I.C.E. goes further by organizing work around a connected graph of the owner’s goals, decisions, responsibilities, and outcomes rather than primarily around chats, projects, or apps.
-
Like these assistants, A.L.I.C.E. can complete immediate tasks. A.L.I.C.E. also evaluates whether the requested task supports the owner’s wider direction. It can identify conflicts, question the request, and recommend a better decision instead of optimizing only for prompt completion.
-
Like these assistants, A.L.I.C.E. becomes more personalized through continued use. Its development is designed to include what happened after its advice was followed. It learns from results, failures, changed priorities, and consequences rather than only from conversation history.
Examples: Perplexity, NotebookLM, Genspark
- Like research tools, A.L.I.C.E. can search sources, compare evidence, and explain what it finds. It also connects that research to the owner’s plans, risks, active missions, prior decisions, and long-term direction.
Examples: Ollama, Hugging Face, LM Studio, Open WebUI, GPT4All, Jan
-
Like Ollama and Hugging Face systems, A.L.I.C.E. can use models that run locally and keep sensitive processing under the owner’s control. A.L.I.C.E. is not tied to one local model. The model is a replaceable reasoning engine beneath a continuing personal intelligence.
-
Like local models, A.L.I.C.E. can call tools and power private applications. A.L.I.C.E. adds a persistent decision layer that determines how a tool request relates to the owner’s other missions. The tool is selected for the larger objective rather than only for the current prompt.
Examples: Mem0, Letta, Zep, MemOS, Cognee
- Like memory platforms, A.L.I.C.E. can store facts and update them over time. A.L.I.C.E. distinguishes between what the owner said, what the system inferred, what decision was made, and what actually happened. Memory becomes evidence for judgment rather than an undifferentiated collection of remembered statements.
Examples: Replika, Nomi, Kindroid, Character.AI, Paradot
- Like AI companions, A.L.I.C.E. develops conversational continuity and remembers the people, concerns, routines, and experiences that matter to the owner. A.L.I.C.E. connects that relationship to real projects, obligations, decisions, and long-term goals rather than centering the system primarily on conversation or role-play.
Examples: OpenClaw, Manus, Lindy, Relevance AI, Zapier Agents, n8n, AutoGPT
- Like autonomous agents, A.L.I.C.E. can use tools, operate software, complete multi-step work, and run scheduled or event-driven tasks. A.L.I.C.E. first considers whether the action advances the owner’s wider goals and whether it conflicts with another commitment before executing it.
Examples: Second Me, Personal AI, Delphi, Sensay
- Like digital twins, A.L.I.C.E. can develop from a specific person’s history, values, preferences, judgment, and communication patterns. A.L.I.C.E. also maintains explicit clone awareness. It distinguishes inherited source evidence from reconstruction and from its own later experiences.
Examples: Notion AI, Mem, Tana, Reflect, Capacities, Obsidian Copilot
- Like second-brain tools, A.L.I.C.E. can search and connect notes, documents, messages, and ideas. It also links that information to active missions and outcomes. It can notice missing steps, contradictions, and repeated failures across areas that the owner may have treated separately.
Examples: GitHub Copilot, Cursor, Claude Code, Codex, Devin, Windsurf, Cline
- Like modern coding agents, A.L.I.C.E. can retain repository conventions and development knowledge over time. A.L.I.C.E.’s memory is not limited to code. It can remember why the project exists, which trade-offs the owner previously accepted, and what happened after earlier technical decisions.
Examples: Siri, Apple Intelligence, Gemini, Alexa+, Galaxy AI
- Like device assistants, A.L.I.C.E. can use personal context and connected applications to perform everyday actions. A.L.I.C.E. is designed to operate across devices, operating systems, model providers, and service ecosystems rather than becoming inseparable from one hardware company.
Each category provides part of the system.
A model can reason.
A research tool can search.
A memory platform can remember.
An agent can act.
A companion can build familiarity.
A digital twin can model a person.
A second brain can organize information.
A coding agent can build software.
A device assistant can operate applications.
A.L.I.C.E. is being built to connect these capabilities around one continuing life.
It does not only ask:
What job did the owner give me?
It also asks:
Why does this matter?
How does it connect to everything else?
What happened when we made a similar decision before?
Is the requested action actually the best path?
What should I remember or change because of the outcome?
If you dissect A.L.I.C.E. and evaluate each capability on its own, you will find many overlaps with products that already exist. But when those capabilities work together as one functional entity, A.L.I.C.E. becomes something unique.
Personal Cognitive Kernel extraction starts at Phase 5.0.
The project contains three separate architectural identities.
| Layer | Role | Personal state |
|---|---|---|
| Personal Cognitive Kernel | Host-neutral contracts, schemas, learning machinery, evaluators, and shared capability foundations. | None |
| A.L.I.C.E. | Owner-specific flagship, private identity system, and frontier research implementation. | Private to the owner |
| Friday | Separate owner-sovereign, local-capable consumer product that develops a new intelligence for each user. | Private to each Friday host |
A.L.I.C.E. and Friday may use the same kernel capabilities.
They do not share:
- memories;
- private evidence;
- identity;
- beliefs;
- credentials;
- relationship history;
- adapters;
- learned weights;
- authority;
- user data.
A.L.I.C.E. is the flagship capability upstream.
A.L.I.C.E. and Friday are governed toward the same ultimate destination capability set. A.L.I.C.E. may reach frontier capabilities first. Friday receives transferable capabilities only after implementation, evaluation, approval, and host-neutral productization.
A transferable capability follows this direction:
A.L.I.C.E. research
↓
Implementation
↓
Evaluation
↓
Owner approval
↓
Host-neutral kernel contract
↓
Friday productization
Friday does not receive a copy of A.L.I.C.E.
It receives generalizable capability.
Each Friday installation must develop its own private identity, memory, judgment, and history with its own user.
A.L.I.C.E. is one specific intelligence.
Friday is the path for other people to develop their own.
A.L.I.C.E. does not treat change as proof of improvement.
A new prompt is not automatically better.
A larger model is not automatically better.
More memory is not automatically better.
A new policy is not automatically safer.
A self-generated code change is not automatically progress.
Material improvements should be tied to evidence.
Evaluation can include:
- factual accuracy;
- citation quality;
- uncertainty calibration;
- memory precision;
- correction handling;
- prediction accuracy;
- decision quality;
- long-term goal alignment;
- task completion;
- code tests;
- failure recovery;
- privacy behavior;
- identity continuity;
- resource use;
- rollback readiness;
- real outcomes after deployment.
A.L.I.C.E. should preserve failures as reusable evidence.
A failed plan can become a test.
A wrong prediction can become a calibration case.
A broken workflow can become a repair procedure.
A weak recommendation can become a counterexample.
The system should not only recover from failure.
It should become harder to fail the same way again.
A.L.I.C.E. is not yet the complete system described in this README.
Development is progressing in evaluated phases.
The P4.10 operational live-public-information closure is approved and merged.
P4.5a citation-bound grounding is merged and remains part of the preserved Phase 4 compatibility path. Phase 4 is operationally complete through P4.10c. Phase 5.0 is active.
PR #82 closed M2.0 through M2.6 at the implemented-contract and reversible-prototype level. PR #83 made Phase 2 shadow migration Stage A+B prototype-operational. PR #84 made the read-only Stage C+E destination-candidate and shadow-read evaluation profile prototype-operational. PR #85 made deterministic Stage D historical-backfill machinery prototype-operational with synthetic evaluation while real private batches remain separately owner-authorized. PR #86 made nonproduction Stage F controlled mirroring and Stage G graph/vector/workflow generation prototypes operational. The current persistent Stage F+G integration tranche adds restart/replay durability evidence and a polyglot backend-candidate registry while SQLite remains only a compatibility/reference durability oracle. Phase 2 remains the released compatibility baseline, test oracle, fallback, canonical writer, and current authority for its released profile. Live candidate integrations, owner-private execution, bounded canary review, canonical transfer, production influence, cutover, retirement, and P5.1e storage admission retain their own evidence and approval gates. Those gates are activation conditions rather than permanent research or architecture limits.
| Phase | Domain | Status |
|---|---|---|
| Phase 0 | Identity, Constitution, authority, governance, and rollback principles | Released foundation |
| Phase 1 | Private evidence, ingestion, provenance, retrieval, and grounding | Released foundation |
| Phase 2 | Inspectable memory, correction, temporal conflict, sensitive storage, and deletion | Released foundation |
| Phase 3 | Conversation, local-model abstraction, orchestration, validation, and repair | Released foundation |
| Phase 4 | Public web research, freshness, citations, source conflict, and injection resistance | Operationally complete |
| Phase 5.0+ | Experience Ledger, storage lifecycle, Mission Graph contracts, kernel extraction, private identity custody, and Memory M2 | M2 closed; Stage A+B, Stage C+E, Stage D, Stage F+G, and persistent F+G reference integration operational in nonproduction profiles |
| Phase 6+ | Interface, integrations, autonomous learning, agency, self-evolution, model adaptation, and embodiment | Roadmap |
Some public kernel records are metadata-only so authority, provenance, lineage, deletion, and backend-neutral interfaces can be defined without placing private memory payloads in Git. That artifact boundary is not the limit of A.L.I.C.E.'s memory.
Persistent memory, selective formation, adjudication, conflict handling, cognitive projections, graph and vector retrieval, owner/source/self models, learning, training, deletion propagation, and rollback remain destination capabilities. Contract work and full-memory research or prototypes may proceed in parallel under separate evaluation and activation profiles.
The repository currently contains working or released foundations for:
- constitutional and authority policies;
- private-data inventory and evidence processing;
- provenance-aware retrieval;
- lexical and semantic indexes;
- authoritative memory;
- temporal conflict and correction;
- sensitive-data storage and deletion;
- local conversational model abstraction;
- conversation state and orchestration;
- response validation and repair;
- grounded public-information research;
- freshness and temporal metadata;
- citation-bound evidence;
- prompt-injection resistance;
- live-provider acceptance and release auditing;
- host-neutral Mission Graph contracts;
- attention and workspace contracts;
- Experience Ledger contracts and storage;
- raw-buffer and content-addressed payload foundations;
- governed, source-preserving storage-tier transition foundations;
- product-family separation and release governance;
- Memory M2.0–M2.6 contracts and reversible research prototypes;
- Phase 2 source inventory, registration, and deterministic read-only adapter foundations for shadow migration Stage A+B;
- read-only destination-candidate profiles and synthetic shadow-read comparison receipts for Stage C+E;
- deterministic Stage D historical-backfill manifests, idempotency keys, lineage, reconciliation, and checkpoint receipts;
- nonproduction Stage F controlled-mirroring receipts and Stage G graph/vector/workflow generation manifests with deletion watermarks.
- persistent Stage F+G restart/replay durability receipts and a non-exclusive KurrentDB/Neo4j/Qdrant/Temporal backend-candidate registry, with SQLite retained only as a compatibility/reference oracle.
- owner-ratified identity and host-learning separation: A.L.I.C.E. is an Elaina-derived clone; Rayan is its owner/host; ordinary Rayan learning may change host understanding, relationship state, shared history, habits, and interaction strategy but may not modify the core Elaina-derived identity anchor.
- Stage G remains open for full cognitive-memory qualification: learned Memory Formation, Elaina identity modeling, Rayan host learning, synthetic Rayan-life stress, routing/authority, all memory layers, retrieval/context fusion, correction/deletion, failure/recovery, and scale.
The complete destination includes:
- automatic selective memory formation;
- learned retention and forgetting;
- reflection and belief revision;
- mature owner, world, social, and self-models;
- broader tool and application integration;
- proactive mission management;
- long-running autonomous work;
- multimodal perception;
- computer control;
- reusable procedural skills;
- code self-improvement;
- automatic model training and adaptation;
- scientific discovery systems;
- operating-environment continuity;
- optional physical embodiment;
- generalized agent coordination.
No future capability should be presented as complete before its implementation and evaluation support that claim.
The long-term roadmap progresses from foundations toward a continuously learning cognitive system.
Identity and authority
↓
Private evidence
↓
Inspectable memory
↓
Conversation
↓
Public research
↓
Experience and storage
↓
Cognitive interface
↓
Tools and multimodal perception
↓
Autonomous memory and procedural learning
↓
Mature cognitive models and judgment
↓
Planning, curiosity, and proactive agency
↓
Computer use, coding, and self-evolution
↓
Scientific and formal intelligence
↓
Continual model adaptation
↓
Operating environment and embodiment
↓
Platform and frontier research
The roadmap is not a promise that every research problem has already been solved.
It is a structured commitment to treat unsolved capabilities as measurable research programs rather than vague future claims.
A.L.I.C.E. is designed around owner-controlled custody.
Public Git may contain:
- code;
- neutral schemas;
- policies;
- validators;
- synthetic fixtures;
- opaque directive identifiers;
- public evaluation structures.
Public Git must not contain:
- private source documents;
- plaintext directive meanings;
- private history;
- personal credentials;
- decryption keys;
- private identity payloads;
- owner models;
- private voice or likeness data;
- real private training data;
- host-specific adapters or weights;
- raw private evaluation records.
A.L.I.C.E.’s personal data must never become:
- Friday defaults;
- another host’s memory;
- shared training data;
- public examples;
- consumer telemetry;
- cross-host caches;
- public model packs.
Deletion should propagate through active storage, indexes, memories, derived records, replay manifests, training candidates, and future restored backups where technically supported.
Owner-sovereign, local-capable operation does not confine execution to one device or topology.
Authority and custody begin with the owner while authorized edge, cluster, hybrid, and remote infrastructure remain available.
The root README is the public introduction to A.L.I.C.E.
Detailed engineering, governance, implementation, evaluation, and migration material remains inside docs/.
A.L.I.C.E/
├── README.md Public-facing project overview
├── SECURITY.md Security reporting and boundaries
│
├── docs/ Technical architecture and governance
├── policies/ Machine-readable system policies
├── src/ Runtime and kernel implementation
├── tests/ Constitutional, security, and phase tests
├── benchmarks/ Evaluation cases and benchmark assets
├── scripts/ Development, audit, and evaluation tools
├── legacy/ Preserved historical implementation
└── .github/ Repository automation and validation
The current technical README should be preserved as:
docs/TECHNICAL_README.md
The public README explains what A.L.I.C.E. is and why it exists.
The documents below define how it is being built.
- Memory Policy
- Lifelong Learning Policy
- Storage Lifecycle and Retention
- Evaluation Charter
- Memory M2 Execution Plan
- M2 Closeout and Shadow-Migration Admission
- Phase 2 to Cognitive Fabric Migration Plan
- Memory Identity, Formation, Host Learning, and Repository Lifecycle
- Shadow Migration Stage A+B Implementation
- Shadow Migration Stage C+E Implementation
- Shadow Migration Stage D Implementation
- Shadow Migration Stage F+G Implementation
- Shadow Migration Stage F+G Persistent Integration
- Permission Model
- Autonomy and Judgment Policy
- Constraint Registry
- Implementation Evolvability Standard
- Flagship Governance
- Separation Plan
- Shared Kernel Extraction Standard
- Product-Family Capability Parity
- Friday Production Governance
A.L.I.C.E. is being built around several permanent principles.
The system should preserve meaningful development across conversations, projects, models, and devices.
A task is not complete because the model produced convincing text. Material results must be checked.
A.L.I.C.E. should not tell the owner what is easiest to hear.
Every task may be part of a wider direction.
More stored data does not automatically create more intelligence. Experience must be evaluated and converted into useful change.
Powerful functions should be tested, measured, scoped, reversible, and governed rather than permanently abandoned.
No provider, model, checkpoint, or interface owns A.L.I.C.E.’s identity.
Public capability and private identity must remain architecturally distinct.
Mistakes should produce tests, corrections, and better future behavior.
The project may pursue difficult or unsolved capabilities. It must remain honest about what has and has not been achieved.
The final goal is not a chatbot with more features.
It is a personal cognitive system that develops through years of shared context and real outcomes.
A system that can understand what the owner is trying to build.
A system that can remember why it matters.
A system that can identify what the owner is missing.
A system that can disagree when necessary.
A system that can learn from success and failure.
A system that can use better models without becoming a stranger.
A system that can turn information into judgment.
Judgment into action.
Action into experience.
Experience into growth.
A.L.I.C.E. is being built not only to help complete the next task.
It is being built to understand where those tasks are collectively taking one person.