An LLM Wiki gives an agent durable memory. A UAI-style assertion and handoff boundary gives that memory a way to reject claims that violate hard constraints. Used together, they form a practical pattern for project handoffs where context must compound without letting mistakes become permanent truth.
Non-normative report
This article is an explanatory LlmWikis report. UAIX.org remains canonical for UAI-1, Project Handoff, Agent File Handoff, schemas, validator behavior, roadmap, and governance. This page does not claim certification, endorsement, hosted upload validation, or official .uai generation support.
The core problem
Traditional retrieval-augmented generation is useful for search, but its synthesis is usually temporary. A model retrieves chunks, answers a question, and then the structure of that answer disappears. An LLM Wiki moves synthesis into a persistent artifact: raw sources remain read-only, the compiled wiki records concepts and contradictions, and a compact schema file tells the agent how to maintain the graph.
That persistence is powerful, but it creates a new risk. If an agent misreads a source during ingestion, the error can be written into the wiki and reused by later sessions. For engineering, compliance, safety, or project-handoff work, a fluent summary is not enough. Some claims must be checked against deterministic rules before they are allowed to become memory.
Where UAI fits
A UAI-style boundary sits between probabilistic language generation and the harder world of project constraints, schemas, external validators, and approval workflows. The language model can propose an update. The assertion layer decides whether the update is allowed, blocked, or escalated into a structured handoff.
| Layer | Job | Failure it reduces |
|---|---|---|
| Raw sources | Keep original PDFs, transcripts, specs, tickets, datasets, and decisions unchanged. | Loss of evidence and accidental source rewriting. |
| LLM Wiki | Compile source material into linked concepts, entities, summaries, contradictions, and logs. | Repeated re-reading and context loss across sessions. |
| UAI-style assertion boundary | Validate candidate claims, artifacts, or handoff records against structured rules before persistence. | Hallucinated or constraint-breaking claims becoming durable facts. |
| Project handoff | When rules conflict, stop autonomous progress and return a structured choice to a human. | Silent relaxation of constraints or invented workarounds. |
Validated ingestion pipeline
The agent reads a new source and extracts atomic claims, decisions, constraints, and open questions.
Candidate updates are tested against schema rules, validator outputs, source requirements, or project handoff constraints.
Passing claims update the wiki. Failing claims become warnings, contradiction records, or handoff items instead of silent facts.
The wiki records source, claim, result, reviewer state, and any human decision that changed the operating boundary.
Project handoff under deadlock
The most important behavior is not automatic success. It is a disciplined stop. If a project has incompatible requirements, the agent should not invent a compromise or quietly relax a rule. It should preserve the conflict and hand it back as a decision package.
| Report field | Purpose | Example content |
|---|---|---|
| System status | Names the halt condition. | Blocked: constraints are irreconcilable under current rules. |
| Conflicting rules | Shows exactly which requirements collide. | Rule A requires one bound; Rule B requires an incompatible bound. |
| Evidence trail | Links source documents, validator traces, and wiki pages. | Raw source path, compiled concept page, log entry, validator output. |
| Resolution menu | Returns explicit human choices with tradeoffs. | Preserve all constraints, relax one requirement, change scope, or add a new resource. |
| Decision record | Stores who approved the change and why. | Approved option, date, rationale, follow-up tasks, affected pages. |
Human briefing before the handoff
A root readme.human gives people a plain-language view of what the AI needs from them before it acts: authority boundaries, unsafe assumptions, approval lines, and done checks. It complements AGENTS.md without replacing project constraints or human decisions.
Active file intake before the wiki writes
The weak spot is the file boundary. Humans and other AI systems often drop a memo, export, screenshot, PDF, CSV, or ZIP into the project and expect the next agent to notice. The UAIX Agent File Handoff pattern turns that into an AGENTS.md load step: create or verify agent-file-handoff/Content/, agent-file-handoff/Improvement/, and agent-file-handoff/Archive/; check Content for candidate public or editorial material and Improvement for audits, QA findings, SEO reports, bug notes, and site-fix work; treat files sitting directly under agent-file-handoff/ as misplaced until classified into Content or Improvement; refresh .uai/intake-index.uai; then inspect and disposition every needs-agent-review file before unrelated broad work. After complete intake outcome, move the source file to Archive; routine AI intake ignores archived files unless a human explicitly names one or moves it back into an active bucket.
For an LLM Wiki, this means dropped files are not silently promoted into memory. They become reviewable local inputs first, with source path, hash, route hint, a named work result, hot-memory update or no-change reason, and long-memory/archive evidence when configured. Wiki memory is not a substitute for doing the accepted work: memory distribution without site or system work is a failed handoff, and copying a report into memory does not count as the project work by itself.
Current UAIX developer evidence trail
When the handoff becomes a UAI-1 implementation, release, or support claim, the public UAIX route set gets wider than the specification page. A reviewer should also inspect the API Reference, Adoption Kit, Conformance Pack, implementation tracks, Roadmap, and Changelog so the handoff stays aligned with current public evidence instead of only local project context.
| UAIX surface | Why it matters to an LLM Wiki handoff |
|---|---|
| API Reference | Shows the live REST contract behind public pages and machine routes. |
| Adoption Kit | Bundles starter payloads, validator-ready requests, mock-exchange examples, and implementation next steps. |
| Conformance Pack | Gives positive and negative fixtures, canonical-hash evidence, and reusable validation proof material. |
| Implementation tracks | Separates current WordPress Publication Track and .NET Bridge Track evidence from broader future support ideas. |
| Roadmap and Changelog | Prevent future work from being described as current support. |
How the wiki compounds after handoff
Once the human decision is made, the LLM Wiki becomes more useful than a ticket comment or chat transcript. It can create a durable page for the deadlock, update related concept pages, add the decision to the log, and link the approved rule change to future work. The next agent does not need to re-discover why the compromise exists. It can read the evidence trail, follow the links, and respect the current boundary.
This is the practical value of combining the two patterns: the wiki remembers, and the assertion boundary prevents memory from drifting away from reviewed constraints.
Recommended operating pattern
- Separate source and synthesis. Keep raw sources immutable and compiled pages editable.
- Require claim status. Mark claims as source-backed, draft, contradicted, stale, or human-approved.
- Validate before persistence. Do not let constraint-sensitive claims become wiki facts until the relevant check has passed or a warning is attached.
- Escalate real conflicts. Use a structured handoff record when the agent cannot satisfy all rules at once.
- Record the resolution. Link the decision, affected pages, source evidence, and reviewer state so future sessions inherit the right context.
Related sources
- UAIX UAI-1 specificationCanonical UAI-1 source
- UAIX Project HandoffCanonical public handoff pattern
- UAIX Agent File HandoffCanonical active file-intake guidance
- UAIX API ReferenceMachine route reference for discovery, validation, adoption, and conformance routes
- UAIX Adoption KitStarter payloads and first reusable proof packet
- UAIX Conformance PackReusable fixtures and validation evidence bundle
- UAIX Implementation TracksCurrent public implementation evidence boundaries
- UAIX RoadmapCurrent versus planned support boundary
- UAIX ChangelogDated public release trail
- RAG vs Incremental CompilationLlmWikis architecture comparison
- index.md and log.mdDeterministic navigation and audit memory
- Page Schema StandardClaim status, review metadata, and source traces