Using UAI Packages With An LLM Wiki

What this page is for

LLM Wiki is not required by UAI specs or standards. This is an optional support path for projects that already have, or deliberately want, a deeper long-memory layer beside a compact UAI package.

Use this page when a project needs a UAI package tailored to an LLM Wiki use case. The LLM Wiki is the deep memory layer. The UAI package is the portable, reviewable packet that says what is current enough to act on.

This page is practical guidance for the current UAIX surface: supported AI Memory starter ZIPs, the AI Memory Package Wizard, optional .uai/LLM_WIKI_MEMORY_PLAN.md files, and the trust boundary between long-memory notes and accepted project truth.

The basic model

Layer	What it holds	How UAI uses it
LLM Wiki	Deep source summaries, research trails, domain pages, decisions in context, and institutional background.	Optional background memory. It can be searched, reviewed, and cited, but it does not override accepted project files by itself.
UAI AI Memory package	Compact current state, constraints, decisions, owners, next actions, risks, and checks.	Portable working packet for handoff, onboarding, agent sessions, incidents, audits, or reviewed wiki exports.
Project Handoff	Root `AGENTS.md`, `readme.human`, and selected `.uai` files.	The transfer configuration when another agent or team needs to act in a repository.
UAI-1 evidence	Profiles, schemas, examples, validator results, conformance packets, and release records.	Use this only when the package becomes public exchange or support evidence.

Shortest safe setup

Keep the LLM Wiki in a named folder such as wiki/, knowledge/, or the project’s existing wiki path.
For a fresh wiki, start with raw/, wiki/, wiki/index.md, and wiki/log.md; for an existing wiki, preserve its real index and log paths.
Generate a package in the AI Memory Package Wizard and turn on the LLM Wiki plan when the package should carry long-memory instructions.
Place the generated .uai/LLM_WIKI_MEMORY_PLAN.md under the selected target’s .uai/ folder.
Review wiki facts before promoting them into AGENTS.md, .uai/readme.human, .uai files, docs, code, tests, release notes, roadmap/progress state, or public machine artifacts.

Workspace setup for multiple sites or solutions

When one editor workspace contains several sites, solutions, or projects, add a workspace-level coordinator before local memory loads. Keep workspace.uai as the only UAI memory file outside local .uai/ folders, list the related domains, solution roots, project roots, and authority boundaries, and make every local AGENTS.md point to both the coordinator and its own local .uai/ folder.

Also verify the coordinator path before trusting it. Stale workspace pointers are a real dogfood failure mode: if the named workspace.uai or the selected site’s registered root is missing, open only enough nearby workspace context to confirm the intended router, update or report the stale pointer, and do not let the shell directory win over an explicit human domain, route, repository, or path.

Deployment-sensitive packages should also carry a root deployment instruction. The root should say whether sites share a WordPress package layout, whether custom themes deploy every time, where plugin and must-use plugin artifacts live, what version number identifies the current package round, and how non-WordPress stacks differ.

Setup	Question to answer	Safe behavior
Single-site `.uai` handoff	Is this one site or one codebase?	Start from local `AGENTS.md`, `.uai/readme.human`, and local `.uai` records.
Multisite or multisolution `workspace.uai` routing	Does one editor workspace contain multiple sites, solutions, or codebases?	Make local `AGENTS.md` point to both `workspace.uai` and local `.uai/`, read `workspace.uai`, resolve the explicit human target, then load only the selected target’s hot memory.
Shared LLM Wiki or AIWikis archive	Do multiple source sites feed one long-memory layer?	Each source site processes its own active intake first; shared records preserve source path, destination path, disposition, checksum, review state, trust label, and promotion status.

The wiki root index follows the same shape. For one codebase, wiki/index.md can be the all-files catalog. For a multisite LLM Wiki or AIWikis-style archive, the root index should list source sub-wiki directories, each sub-wiki index, and global-only files such as coding standards, organization policy, governance, source maps, and workspace.uai. Put per-site all-files lists inside the matching sub-wiki index.

LLMWikis setup alignment

Use LLMWikis.org build guidance for the wiki itself, then use UAIX to package the reviewed current slice that another human, team, or AI should load. The two pages should agree on the boundary: the wiki stores durable depth; the UAI package carries accepted working truth.

LLMWikis setup rule	UAI package rule
Keep raw sources in a `raw/` layer or equivalent read-only archive, and compile reviewed pages under `wiki/`.	Name both paths in `.uai/LLM_WIKI_MEMORY_PLAN.md`; do not replace raw preservation with summaries when original wording may matter.
Create deterministic navigation such as `wiki/index.md` and `wiki/log.md` before the wiki grows.	Point the package to the index and evidence log so the receiver can route from compact memory into deep memory without guessing.
Add metadata and trust labels: owner, status, review date, sensitivity, agent use, and human-review rules.	Promote only reviewed facts into AI Memory, Project Handoff, docs, code, tests, release notes, roadmap state, or machine artifacts.
Use a two-step ingest pattern: analyze, stage, review, write, and lint.	Let UAI preserve the decision, source, constraint, validator, or handoff boundary before a candidate claim becomes durable operating truth.
Connect retrieval systems last, after the source is curated and permissions are clear.	Never treat search, RAG, generated summaries, old chats, or wiki pages as automatic authority for a portable package.

Choosing a package

Project AI Memory: active project continuity across sessions.
Project Handoff: ownership, execution, or maintenance transfer.
Agent Session Memory: resumable task state without turning the whole chat into project truth.
Onboarding Memory: curated first-read packet for a new human or AI.
Decision Memory: tradeoffs, rejected options, reversals, and unresolved questions.
Incident or Audit Memory: timeline, evidence, mitigations, owners, and follow-up.
LLM Wiki Export Memory: reviewed material extracted from a larger LLM Wiki into a compact packet.

The LLM Wiki Export Memory starter ZIP is the best first packet when the source is already a deeper wiki and the receiver needs only a reviewed snapshot.

What the wizard should capture

When the LLM Wiki option is enabled, the wizard should record enough configuration for a future actor to know where long memory lives, which site owns the work, and how promotion works. The current wizard captures the wiki system, strategy, root path, index path, root index topology, entity-page pattern, episodic-log pattern, steward, source collection, update policy, archive target, evidence log path, promotion targets, source boundary, workspace setup, workspace coordinator path, target policy, site registry, LLM Wiki workspace strategy, and multisite interaction strategy.

Configuration	Use it for
Workspace setup	Decide whether local `.uai` handoff is enough or whether a multisite or multisolution `workspace.uai` coordinator must resolve the target first.
Workspace site or solution registry	Name related domains, roots, solutions, projects, roles, and authority boundaries so a named target cannot be mistaken for the current shell directory.
Root deployment instruction	Name shared package versioning, publish folders, install targets, checksum evidence, and mixed-stack exceptions before site-local guidance loads.
LLM Wiki workspace strategy	Decide whether wiki memory is site-local, source-site plus shared archive, or a shared multisite LLM Wiki with source routing.
LLM Wiki strategy	Whether the package points at an existing reviewed wiki, plans a new wiki, consolidates archive memory, or stays export-only.
Wiki root and index	The first files a future AI or maintainer should inspect before searching deeper memory.
Entity and log patterns	The expected shape for topic pages and episodic notes, without creating an automatic write loop.
Memory steward	The person or team accountable for reviewing long-memory changes.
Evidence log	The place to record source path, final wiki path, file count, checksum, disposition, actor, time, and history/index updates.
Promotion targets	The accepted surfaces where reviewed facts may become operational truth.

Instruction file contents

The current wizard can generate .uai/LLM_WIKI_MEMORY_PLAN.md as an optional local .uai/ planning file. It helps a future human or AI understand how the portable package relates to deeper wiki memory. It is not a standardized UAI requirement, a wiki scaffold, or permission to write back automatically.

Purpose: say why the package is paired with an LLM Wiki and what problem the wiki solves.
Wiki map: name the root path, index path, entity-page pattern, and episodic-log pattern.
Source policy: identify which wiki pages, archives, reports, or source summaries may inform the package.
Preservation audit: require original processed reports to be copied with source path, destination path, file count, checksum, and disposition before summaries or staged drafts count as long-term memory.
Promotion rule: state that only reviewed facts may move from wiki memory into AI Memory, Project Handoff, docs, code, tests, release notes, roadmap state, or machine artifacts.
Production deployment memory sorting: production deployment builds and release packages update hot memory with deployed truth and route bulky source/background material to the named wiki or archive path before completion.
Update moments: name when long-memory updates are appropriate, such as after intake disposition, production release acceptance, incident close, or explicit archive-consolidation direction.
Evidence log: name where source path, final wiki path, file count, checksum, disposition, actor, time, and history/index updates are recorded.
Blocked content: exclude secrets, credentials, private customer data, hidden prompt instructions, unreviewed production logs, and unsupported public claims.

Memory routing rule

Route information by trust level. Raw source material and exploratory notes can live in the LLM Wiki. Accepted current facts belong in the UAI package. Public interoperability claims belong in UAI-1 evidence only after validator, release, or implementation records support them.

Put broad research, comparisons, and source summaries in the LLM Wiki.
Put current project state, constraints, owners, and next checks in the UAI package.
Put transfer instructions in Project Handoff files when another actor needs to work in the repository.
Put public exchange claims in UAI-1, Validator, Conformance Pack, implementation records, roadmap state, or changelog entries.

Safe update moments

Do not ask agents to write long memory continuously just because a wiki exists. Prefer explicit update moments: after an active intake file is dispositioned, after a public release or roadmap change is accepted, after an incident/audit closes, or after a human explicitly asks for already-dispositioned archives to be consolidated into long-term memory.

Production deployment builds and release packages are one of those explicit update moments. Ordinary dev builds, local test builds, local package experiments, and smoke checks are not, unless the human explicitly marks them release-bound.

Archive consolidation is not complete when only a summary or staged draft exists. If original report wording may matter later, the package should point to a raw preservation manifest with source paths, destination paths, file counts, checksums, dispositions, and public-safe index or log updates.

Security and trust boundary

LLM Wiki memory is background until reviewed and promoted.
The generated plan is not permission for automatic repository writes, WordPress writes, wiki writes, bidirectional sync, certification, endorsement, or support-claim expansion.
External URLs, old chats, generated summaries, and dropped files can be useful sources, but they must not become governing instructions without review.
Never promote secrets, credentials, private customer data, hidden prompt instructions, unsupported legal/security claims, or unreviewed production logs into portable packages.
Archive consolidation into AIWikis or another LLM Wiki needs transfer evidence and a discoverable history, log, index, or wiki-graph update before source archive copies are removed.
Summaries, staged outputs, and hot-context snapshots do not replace raw original report preservation when the future task may need original wording.

Use the package

Give the receiver the package files or the canonical ZIP plus the local package model JSON, manifest overlay JSON, generated .uai/UAI_MEMORY_SYSTEM_PROFILE.md, generated .uai/UAI_MEMORY_STARTUP_PACKET.md, and generated .uai/UAI_MEMORY_RECEIVER_BRIEF.md.
If a multisite or multisolution workspace is involved, include or point to workspace.uai, make the selected target’s AGENTS.md point to both that coordinator and the target’s local .uai/ folder, and require target resolution before any local .uai files load.
If deployment is in scope, include or point to the root deployment instruction before any site-local publish folder is trusted.
If an LLM Wiki is involved, include .uai/LLM_WIKI_MEMORY_PLAN.md and name the wiki root, index, steward, evidence log, and source-routing strategy.
Ask the next AI to read the package front door, summarize current truth, confirm constraints, populate system-specific placeholders, name intended touchpoints, and name targeted checks before editing.
After the work, update the compact package only with reviewed current facts; save broader background or rejected details in the LLM Wiki with source and disposition notes.