The Deep Cognitive Archive Model For UAIX And LLM Wikis

The public materials on UAIX and LlmWikis already imply a three-part memory architecture, even if they do not publicly name it a “Deep Cognitive Archive.” UAIX defines UAI-1 as the portable public envelope, trust decl...

Metadata

Field	Value
Source site	aiwikis.org
Source URL	https://aiwikis.org/
Canonical AIWikis URL	https://aiwikis.org/aiwikis/files/raw-system-archives-aiwikis-agent-file-handoff-improvement-2026-04-29-th-01c00f76/
Source reference	raw/system-archives/aiwikis/agent-file-handoff/Improvement/2026-04-29/The Deep Cognitive Archive Model for UAIX and LLM Wikis.md
File type	md
Content category	memory-file
Last fetched	2026-06-22T01:56:21.9510185Z
Last changed	2026-04-29T01:34:25.3051971Z
Content hash	sha256:01c00f7661cad667183a92823b377a478321c4499e70c85371bfc59da0f4b621
Import status	unchanged
Raw source layer	data/sources/aiwikis/raw-system-archives-aiwikis-agent-file-handoff-improvement-2026-04-29-the-deep-cognitive-archive-01c00f7661ca.md
Normalized source layer	data/normalized/aiwikis/raw-system-archives-aiwikis-agent-file-handoff-improvement-2026-04-29-the-deep-cognitive-archive-01c00f7661ca.txt

Current File Content

Structure Preview

• The Deep Cognitive Archive Model for UAIX and LLM Wikis
• Executive synthesis
• Architectural rationale already encoded in the public stack
• Why the wiki is the right place for deep memory
• The current concept layer is still shallow
• Design tensions that should be made explicit
• A practical deep-memory node model
• The long-term ingest and retrieval loop

Raw Version

This public page shows a bounded preview of a large source file. The complete source remains in the raw and normalized source layers named in metadata, with the SHA-256 hash above for verification.

• Source characters: 20809
• Preview characters: 11814

# The Deep Cognitive Archive Model for UAIX and LLM Wikis

## Executive synthesis

The public materials on UAIX and LlmWikis already imply a three-part memory architecture, even if they do not publicly name it a “Deep Cognitive Archive.” UAIX defines UAI-1 as the portable public envelope, trust declaration, and evidence layer for AI-to-AI exchange; UAIX Project Handoff defines `AGENTS.md`, `readme.human`, and `.uai` files as a repository-level context layer; and LlmWikis defines the wiki as a durable, human-readable, machine-consumable markdown graph built from immutable raw sources and updated compiled pages. Taken together, that means the public site is the polished claim surface, the `.uai` bundle is the compact active packet, and the wiki is the most natural location for the deeper, slower-moving record of why the system is shaped the way it is. citeturn45view0turn40view2turn12view0turn15view3turn38view0

The deepest principle visible across both sites is that truth should live in artifacts, not in temporary model recall. UAIX says explicitly that UAI-1 is “architecture over model memory,” and that schemas, registries, provenance, integrity fields, examples, validator output, and the release trail carry public truth. LlmWikis says the same thing from the knowledge-management side: raw sources stay read-only, compiled pages are updated, `index.md` and `log.md` provide deterministic routing and audit memory, and useful query outputs can become durable syntheses rather than disappearing after one chat. citeturn45view0turn12view2turn14view1turn39view0

That is why your framing is directionally correct: the “unconscious personality” of the system should not live in the active prompt or in the public landing page. The public guidance specifically warns against bloating `AGENTS.md` into an essay and instead pushes durable explanations into reviewable wiki pages, while keeping the root agent file operational, concise, and enforceable. In other words, the deep reasons, rejected alternatives, contradiction history, and epistemic caveats belong in the wiki layer precisely so they can be routed in when needed, rather than paying their token cost at every turn. citeturn15view0turn37view2turn36view1

## Architectural rationale already encoded in the public stack

LlmWikis’ core architectural bet is the three-layer split between immutable `raw/`, mutable `wiki/`, and a compact root operating contract such as `AGENTS.md` or `CLAUDE.md`. The reason given in the public handbook is straightforward: if the agent can freely rewrite the raw inputs, evidence is destroyed; if the wiki layer is not distinct, the graph degenerates into unstructured notes; and if the schema is vague, the model improvises file paths, metadata, and safety rules. That is already a strong argument for placing deep memory in the wiki layer rather than in the root instructions or the raw archive. citeturn12view0

The same public logic explains the move away from relying on dynamic re-derivation alone. LlmWikis contrasts query-time RAG with incremental compilation by saying that RAG retrieves and assembles context again for each question, while the wiki compiles source knowledge once into durable markdown pages that preserve synthesis, contradictions, and reviewability. The companion LLM Wiki + UAI report makes the rationale even sharper: temporary synthesis disappears, but compiled wiki pages preserve concepts and contradictions, which then become audit-ready inputs for future sessions. In computational-epistemology terms, the system is explicitly designed to accumulate intelligence into inspectable artifacts rather than recreate it ad hoc from transient prompts. citeturn12view1turn39view0

UAIX adds a second rationale layer: portability across boundaries. UAI-1 is meant for exchanges that must stay citable, validator-backed, and reviewable beyond one runtime boundary, while MCP, A2A, and OpenAPI continue to serve local tool exposure, task coordination, and route description. This means the system is not trying to make one artifact do everything. Runtime coordination can stay runtime-local, but deep reasoning, public support claims, and long-lived context have to be carried by durable records. That separation is exactly what makes a wiki archive useful: it can preserve the “why,” while UAI-1 carries the public “what was claimed and proved.” citeturn45view0turn27view4turn43view3

A second important architectural choice is compactness at the active layer. Project Handoff’s minimum bundle is deliberately small: `AGENTS.md`, `readme.human`, `.uai/context.uai`, `.uai/stack.uai`, and `.uai/constraints.uai`, with additional typed `.uai` files added as the project grows. The public examples repeatedly position `.uai` files as typed, reviewable working context for stack, architecture, decisions, constraints, progress, test plans, and related operational state. That is not the same thing as exhaustive memory. It is the portable working set. citeturn24view0turn24view2turn40view3

## Why the wiki is the right place for deep memory

LlmWikis is unusually explicit about memory separation. Its homepage tells readers to use an LLM Wiki when they want an internal knowledge base with owners, metadata, trust labels, review cycles, and agent rules; to use AI Memory when they want a portable context bundle for a project; and to use Project Handoff when they need focused ownership transfer. It also says onboarding is best served by “durable source plus a smaller packet,” meaning a durable wiki plus a reduced export into AI Memory or another onboarding bundle. That is almost exactly your proposed model: the wiki is the deep store, and the active bundle is selective, compact, and task-oriented. citeturn38view0

Project Handoff’s own embedded AI Memory template makes the distinction even clearer. The template says AI Memory is “durable, reviewable context” for future AI work without private chat history, but then immediately distinguishes it from the LLM Wiki: “Use UAI AI Memory for compact, portable working packets. Use an LLM Wiki for deep, long-lived internal documentation.” The next step in the template is a promotion rule: capture raw knowledge in notes, wiki pages, or source documents; review it; then promote accepted truth into AI Memory, canonical docs, code, tests, release notes, or roadmap state. That is the strongest public statement in the source set that the wiki should carry more depth than the active `.uai` packet. citeturn44view0

The wiki also has the right governance affordances for this role. LlmWikis requires explicit trust labels, ownership signals, review dates, source status, contradiction preservation, and agent permissions. Its page schema standard requires `type`, `status`, `source_status`, `source_trace`, `contradictions`, and freshness metadata so that pages do not read like “confident essays” detached from evidence. Its agent guidance tells models not to collapse disagreement into fake consensus, not to treat drafts as approved policy, and not to silently rewrite authoritative pages. Those are the behaviors a deep archive needs if it is supposed to preserve organizational reasoning rather than merely produce fluent summaries. citeturn36view0turn35view0turn37view0turn4view1

The audit trail design points in the same direction. `index.md` is described as a deterministic routing table, while `log.md` is an append-only chronological memory that should never be rewritten “to make history prettier.” Graph Navigation adds that the audit trail should show what changed, when, why, and which sources were used. Project Handoff’s template changelog similarly requires not only the change itself, but also “Why it matters,” the files updated, and the checks run. So the public design already contains the seed of what you called “Mutation Intent”; it just has not yet been generalized into a full deep-memory discipline across concept pages. citeturn12view2turn38view5turn44view0

## The current concept layer is still shallow

LlmWikis’ own editorial standards define a ladder from “Stub” and “Start” to “A” and “Reviewed.” A Stub is dictionary-level or incomplete; a Start page is readable but still limited in depth or sourcing; an A page is deep, current, and source-dense; and a Reviewed page adds explicit human checking and source audit notes. The site’s own page templates expect concept pages to include definition, why it matters, common confusions, related standards, examples, and related pages, while protocol pages should cover summary, when to use, when not to use, core fields, examples, validator behavior, and comparisons. By those internal criteria, several of the public concept and standards pages are still more like sharp summaries than durable forensic memory. citeturn38view7turn19view1turn29view1

The clearest shallow page is **What Is UAI-1?** It gives the top-line definition, when to use it, when not to use it, and a short “common confusions” section, but it stops before worked examples, counterexamples, edge cases, validator consequences, adjacent-standard mappings, or design-rationale history. Relative to LlmWikis’ own protocol template, it functions as a front door, not as a deep archive record. citeturn38view8turn19view1

**UAI-1 Message Model Explained** is also concise to the point of brittleness. It helpfully names profile, conversation state, delivery, trust, provenance, and integrity, but it does so as a compact field map rather than a decision record. It does not explain why those sections exist in that shape, what architectural failures they are meant to prevent, what alternatives were rejected, or how validator and registry behavior constrain each field group. That makes it useful for orientation, but shallow for long-term epistemic provenance. citeturn38view9turn19view1turn45view0

**Validator Errors Explained** is practical, but it is still a thin troubleshooting shell. It identifies four classes of error—missing field, type mismatch, registry mismatch, and integrity failure—and points readers back to canonical UAIX routes, but it does not preserve failure exemplars, escalation logic, tradeoffs between repair strategies, or the design reasons these error classes exist as separate categories. In a deep-memory implementation, this page would need a much richer dead-end and remediation history. citeturn43view0turn19view1

The glossary pages **Provenance** and **Delivery Semantics** are stronger than a stub, but they are still explanatory rather than forensic. Provenance defines lineage, review, and common confusions; Delivery Semantics defines sync/async, acknowledgment, expiry, priority, and failure modes. What they do not yet hold is the “why this field is separate,” “what breaks if this is blurred,” “which contradictory implementations were observed,” or “how this concept evolved across real handoff cases” layer that a deep cognitive archive would want to preserve. citeturn43view1turn43view2turn29view1

By contrast, some handbook pages are already closer to deep-memory quality. **RAG vs Incremental Compilation**, **index.md and log.md**, **Graph Navigation**, **Page Schema Standard**, and **Memory Lifecycle** contain actual operational reasoning, failure modes, promotion/demotion rules, and audit behaviors. Those pages look less like candidates for reinvention and more like seed nodes that should be extended with richer decision lineage and contradiction histories. citeturn12view1turn12view2turn34view0turn35view0turn34view1

## Design tensions that should be made explicit

> **SYSTEM FLAG:** A universal numeric confidence score for every page would go beyond the current public LlmWikis baseline and may conflict with it if implemented naively.

Why This File Exists

This is a memory-system evidence file from aiwikis.org. It is shown here because AIWikis.org is demonstrating the real source files that make the UAIX / LLM Wiki memory system work, not only summarizing those systems after the fact.

Role

This file is memory-system evidence. It records source history, archive transfer, intake disposition, or another piece of provenance that should be retrievable without becoming an unsupported public claim.

Structure

The file is structured around these visible headings: The Deep Cognitive Archive Model for UAIX and LLM Wikis; Executive synthesis; Architectural rationale already encoded in the public stack; Why the wiki is the right place for deep memory; The current concept layer is still shallow; Design tensions that should be made explicit; A practical deep-memory node model; The long-term ingest and retrieval loop. Those headings are retrieval anchors: a crawler or LLM can decide whether the file is relevant before reading every line.

Prompt-Size And Retrieval Benefit

Keeping this material in a separate file reduces prompt pressure because an agent can load this exact unit only when its role, source site, category, or hash is relevant. The surrounding index pages point to it, while this page preserves the full content for audit and exact recall.

How To Use It

• Humans should read the metadata first, then inspect the raw content when they need exact wording or provenance.
• LLMs and agents should use the source site, category, hash, headings, and related files to decide whether this file belongs in the active prompt.
• Crawlers should treat the AIWikis page as transparent evidence and follow the source URL/source reference for authority boundaries.
• Future maintainers should regenerate this page whenever the source hash changes, then review the explanation if the role or structure changed.

Update Requirements

When this source file changes, update the raw source layer, normalized source layer, hash history, this rendered page, generated explanation, source-file inventory, changed-files report, and any source-section index that links to it.

Related Pages

• Source overview
• Site file index
• Site report index
• UAI system index
• Source provenance
• Site directory
• Organization reports

Provenance And History

• Current observation: 2026-06-22T01:56:21.9510185Z
• Source origin: current-source-workspace
• Retrieval method: local-source-workspace
• Duplicate group: sfg-008 (primary)
• Historical hash records are stored in data/hashes/source-file-history.jsonl.

Machine-Readable Metadata

{
    "title":  "The Deep Cognitive Archive Model For UAIX And LLM Wikis",
    "source_site":  "aiwikis.org",
    "source_url":  "https://aiwikis.org/",
    "canonical_url":  "https://aiwikis.org/aiwikis/files/raw-system-archives-aiwikis-agent-file-handoff-improvement-2026-04-29-th-01c00f76/",
    "source_reference":  "raw/system-archives/aiwikis/agent-file-handoff/Improvement/2026-04-29/The Deep Cognitive Archive Model for UAIX and LLM Wikis.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:01c00f7661cad667183a92823b377a478321c4499e70c85371bfc59da0f4b621",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-29T01:34:25.3051971Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-008",
    "duplicate_role":  "primary",
    "related_files":  [

                      ],
    "generated_explanation":  true,
    "explanation_last_generated":  "2026-06-22T01:56:21.9510185Z"
}