Skip to content
AIWikis.org

LLM Wiki And UAIX Project Handoff

Publication Warning This page is marked noindex and should not be treated as canonical public authority.

This article is written for publication on UAIX.org, for a general professional audience that may include product leaders, engineers, AI implementers, and standards readers. It treats Project Handoff

Metadata

FieldValue
Source siteuaix.org
Source URLhttps://uaix.org/
Canonical AIWikis URLhttps://aiwikis.org/uaix/files/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-llm-wiki-fd6d564d/
Source referenceraw/system-archives/uaix/internal-memory-reorg/2026-05-01/docs/LLM Wiki and UAIX Project Handoff By ChatGPT.md
File typemd
Content categorymemory-file
Last fetched2026-06-22T01:56:21.9510185Z
Last changed2026-04-26T17:02:39.2169903Z
Content hashsha256:fd6d564d1e871fdc5cda0f25a5b7c5f7fb41f5b91e7be1bad44e646d86ce14a3
Import statusunchanged
Raw source layerdata/sources/uaix/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-llm-wiki-and-uaix-project-handoff-fd6d564d1e87.md
Normalized source layerdata/normalized/uaix/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-llm-wiki-and-uaix-project-handoff-fd6d564d1e87.txt

Current File Content

Structure Preview

  • LLM Wiki and UAIX Project Handoff
  • Assumptions
  • Executive summary
  • Why this problem exists
  • What each pattern optimizes
  • How they compare in practice
  • When to use each and when to combine them
  • Risks, governance, and implications
  • Further reading and sources

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: 18210
  • Preview characters: 11871
# LLM Wiki and UAIX Project Handoff

## Assumptions

This article is written for publication on UAIX.org, for a general professional audience that may include product leaders, engineers, AI implementers, and standards readers. It treats [Project Handoff](/en-us/specification/project-handoff/) as a current public draft for repository context, not as a certification mechanism or a replacement for [UAI-1](/en-us/specification/uai-1/). The comparison centers on when to use Karpathy’s LLM Wiki pattern, when to use UAIX Project Handoff, and when the two work best together. citeturn10view3turn7view0turn9view2

## Executive summary

Two different problems are getting collapsed into one in today’s AI tooling conversations. One problem is **knowledge accumulation**: how to keep research, synthesis, and cross-document understanding from evaporating when a chat ends. The other is **project continuity**: how to let the next model, agent, team, or vendor continue real work in a repository without reconstructing everything from scratch. Karpathy’s LLM Wiki speaks primarily to the first problem. UAIX Project Handoff speaks primarily to the second. citeturn12view0turn10view3

LLM Wiki is best understood as a persistent, LLM-maintained knowledge layer that sits between raw sources and future questions. Karpathy describes a three-layer setup of immutable raw sources, an LLM-generated wiki, and a schema file such as `AGENTS.md` or `CLAUDE.md` that governs how the system behaves. The goal is compounding understanding: summaries, concept pages, entity pages, comparisons, indexes, and logs become durable assets instead of disposable chat outputs. citeturn11view4turn12view0

UAIX Project Handoff is different. The Project Handoff specification defines a draft `AGENTS.md` plus `.uai` repository-context format for moving work between AI models, agent systems, vendors, teams, and companies. Its purpose is to give the next assistant a predictable start point, an explicit load list, typed context files, current state, next steps, and visible constraints before it starts editing code or copy. citeturn10view3turn3view1turn3view0

The right framing for UAIX is therefore not “LLM Wiki versus Project Handoff” as if one should replace the other. A better framing is: **LLM Wiki helps knowledge accumulate; UAIX Project Handoff helps project state travel.** When public interoperability claims or release-facing evidence are involved, UAIX’s own boundary pages make clear that the next step is UAI-1 and validator-backed conformance evidence, not handoff files alone. citeturn10view3turn8view4turn9view2

## Why this problem exists

Modern AI systems are strong at local reasoning but weak at durable continuity unless teams deliberately externalize context. The original Retrieval-Augmented Generation paper framed part of this problem clearly: large language models can store factual knowledge, but provenance and updating remain open problems, which is why RAG combines parametric memory with external non-parametric memory. Karpathy’s critique of ordinary document-chat workflows goes one step further: in many common setups, the model re-discovers knowledge from raw documents at query time, and little accumulation actually happens between sessions. citeturn13view0turn13view1turn1view1

That same continuity problem also shows up inside repositories. OpenAI’s Codex documentation now treats `AGENTS.md` as durable project guidance that travels with the repository and applies before the agent starts work. OpenAI also describes customization as layered: `AGENTS.md` for persistent instructions, memories for carried-forward context, skills for reusable workflows, and MCP for external systems. In other words, mainstream agent tooling is already moving toward explicit, durable context rather than assuming that one long chat transcript is enough. citeturn14view1turn14view0

What changes the design question is that “memory” is not one thing. Knowledge memory, repository memory, runtime protocol state, and public evidence each serve different jobs. UAIX’s own Standards Fit page makes this distinction explicit at the protocol layer: A2A coordinates agents, MCP connects tools and resources, and UAI-1 records the portable exchange rather than replacing those runtime systems. Project Handoff belongs to that same boundary logic, but one layer earlier: it is repository memory, not the public message envelope. citeturn9view2turn8view1

## What each pattern optimizes

Karpathy’s LLM Wiki is optimized for **ongoing synthesis**. In his description, the raw sources remain immutable, the LLM owns the wiki layer, and a schema file instructs the LLM how to ingest, update, and answer. The generated wiki can include summaries, entity pages, concept pages, comparisons, indexes, and synthesis pages. Karpathy also recommends `index.md` as a catalog of the wiki and `log.md` as an append-only chronology of ingests, queries, and maintenance. The pattern is especially well-suited to long-running research, book analysis, internal knowledge bases, competitive analysis, and other domains where the main goal is structured understanding over time. citeturn11view4turn12view0turn11view1turn11view2

UAIX Project Handoff is optimized for **repeatable continuation of work in a repository**. The Project Handoff page defines a root `AGENTS.md` that summarizes the handoff, lists files to load, records current state, tracks next steps, preserves agent history, and names constraints that should not change without approval. It pairs that with typed `.uai` files such as `context`, `stack`, `architecture`, `decisions`, `constraints`, `style`, `progress`, `errors`, and `custom`, plus explicit `@uai[]` load references that tell the receiving model what to read before acting. citeturn3view1turn3view2turn2view3

The fastest useful Project Handoff bundle is intentionally small: `AGENTS.md`, `.uai/context.uai`, `.uai/stack.uai`, and `.uai/constraints.uai`. The spec then adds a required first-response pattern: the next AI should summarize the project, name which `.uai` files loaded, confirm hard constraints, list what it expects to touch, and name what checks it expects to run. If required context cannot be loaded, the AI should stop and report the blocker instead of guessing. That is closer to engineering discipline than to knowledge-base authoring. citeturn2view0turn2view1turn3view0turn3view3

There is also a technical difference in how structure is expressed. Project Handoff proposes two compatible `.uai` record profiles: a Markdown context profile for human-readable repository knowledge and a JSON information profile for stricter machine records with fields such as schema version, provenance, links, checksum, and signature. But the same page also states a key support boundary: these are draft repository-source formats, not UAI-1 conformance records or certification evidence. citeturn3view1turn10view3

## How they compare in practice

The most useful way to compare these patterns is not by file extension or by brand, but by **what you are trying to preserve**. The synthesis below is drawn from Karpathy’s LLM Wiki pattern, the UAIX Project Handoff specification, the UAIX AGENTS.md linking proposal, and OpenAI’s guidance on `AGENTS.md`. citeturn12view0turn10view3turn7view0turn14view0turn14view1

| Dimension | LLM Wiki | UAIX Project Handoff |
|---|---|---|
| Primary job | Accumulate and refine knowledge over time | Transfer repository state so the next AI can continue safely |
| Main artifact | Interlinked wiki pages in Markdown | Root `AGENTS.md` plus typed `.uai` files |
| Source model | Raw sources remain immutable; the wiki is synthesized | Repository files and handoff records capture current working truth |
| Typical question answered | “What have we learned?” | “What is true right now, and what should happen next?” |
| Best-fit work | Research, analysis, reading, internal knowledge surfacing | Implementation handoff, repo continuation, multi-agent coordination |
| Operating style | Ingest, update pages, maintain index/log, synthesize | Load explicit context, summarize first, confirm constraints, then act |
| Main failure mode | Summary drift or over-trusting generated synthesis | Stale handoff files or incomplete constraints |
| Strongest guardrail | Human review against raw sources and version history | Explicit load order, typed files, stop-on-missing-context, approval for high-impact actions |

A second way to see the boundary is as a stack, not a fork. LLM Wiki can sit upstream of repository handoff by helping teams discover and stabilize knowledge; Project Handoff then turns the subset that actually governs continuing work into explicit operational context; UAI-1 sits downstream when that work becomes a portable public exchange or release-facing evidence. That boundary also matches UAIX’s own Standards Fit language: UAI-1 records the portable exchange while adjacent systems keep their runtime jobs. citeturn9view2turn10view3turn8view1turn8view4

```mermaid
flowchart TD
    A[Raw sources] --> B[LLM Wiki]
    B --> C[Compounded knowledge pages]
    D[Repository files and trusted runbooks] --> E[AGENTS.md plus .uai]
    E --> F[Portable repository state]
    F --> G[UAI-1 messages and validation evidence]

    C -. informs .-> E
    E -. public release or interoperability claim .-> G
```

The diagram matters because it prevents a common category error. A generated wiki page may be useful background, but it should not automatically become repository instruction. Likewise, a repository handoff file may be sufficient for the next coding session, but it is not by itself public interoperability evidence. OpenAI’s `AGENTS.md` guidance also points in the same direction: keep `AGENTS.md` short and practical, and if it grows too large, reference more specific files instead of bloating the root instructions. citeturn3view0turn10view3turn14view0

## When to use each and when to combine them

If the work is **research-heavy and open-ended**, prefer LLM Wiki first. Karpathy’s own examples include deep research over weeks or months, book analysis, internal knowledge bases, competitive analysis, and other tasks where the value comes from cumulative synthesis rather than from one precise repository state. In those cases, what matters most is that insights, contradictions, comparisons, and source relationships keep compounding instead of being repeatedly regenerated from scratch. citeturn12view0

If the work is **implementation-heavy and handoff-sensitive**, prefer UAIX Project Handoff first. The spec explicitly targets the moment when work moves from one AI assistant or model family to another, when contractors or organizations change, when multiple agents need shared state without relying on private chat history, or when a human wants a durable, reviewable project brief beside the repo. In those situations, explicit context loading, typed constraints, recent progress, and a required first summary matter more than a sprawling concept graph. citeturn2view0turn2view3turn3view3

If the work is **shipping into a public standard or interoperability surface**, use both, but keep the layers honest. An LLM Wiki can support background research and synthesis. Project Handoff can carry the local repository brief, stack, decisions, and constraints. But once the work becomes a public message contract or a support claim, UAIX’s own pages say to move into UAI-1 and validator-backed evidence. The validator checks candidate UAI messages against published schemas, field-order governance, and current operating-surface expectations; a passing result supports alignment at the time of validation, not blanket certification or permanent compatibility. citeturn10view3turn8view4turn8view5turn8view1

Why This File Exists

This is a memory-system evidence file from uaix.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: LLM Wiki and UAIX Project Handoff; Assumptions; Executive summary; Why this problem exists; What each pattern optimizes; How they compare in practice; When to use each and when to combine them; Risks, governance, and implications. 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

Provenance And History

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

Machine-Readable Metadata

{
    "title":  "LLM Wiki And UAIX Project Handoff",
    "source_site":  "uaix.org",
    "source_url":  "https://uaix.org/",
    "canonical_url":  "https://aiwikis.org/uaix/files/raw-system-archives-uaix-internal-memory-reorg-2026-05-01-docs-llm-wiki-fd6d564d/",
    "source_reference":  "raw/system-archives/uaix/internal-memory-reorg/2026-05-01/docs/LLM Wiki and UAIX Project Handoff By ChatGPT.md",
    "file_type":  "md",
    "content_category":  "memory-file",
    "content_hash":  "sha256:fd6d564d1e871fdc5cda0f25a5b7c5f7fb41f5b91e7be1bad44e646d86ce14a3",
    "last_fetched":  "2026-06-22T01:56:21.9510185Z",
    "last_changed":  "2026-04-26T17:02:39.2169903Z",
    "import_status":  "unchanged",
    "duplicate_group_id":  "sfg-1232",
    "duplicate_role":  "primary",
    "related_files":  [

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

Next Useful Routes

  • Start Here A task-first reading path for AIWikis.org, separating newcomer learning, source-memory lookup, maintainer workflow, and AI-agent retrieval.
  • Topic Index A tag-oriented index for LLM Wiki, AI memory, UAI, source governance, crawling, and retrieval topics.
  • Source Map AIWikis source-governed page for durable AI memory, evidence routing, and agent-readable retrieval.
  • UAIX.org UAIX.org source-system overview for transparent AIWikis memory demonstration.
  • UAIX.org Source Memory Guide AIWikis source-governed page for durable AI memory, evidence routing, and agent-readable retrieval.
  • UAIX.org Files Site-scoped current-source file index for UAIX.org.