{"slug": "llm-wiki-maintenance-drift-contradictions-and-review", "title": "LLM Wiki Maintenance: Drift, Contradictions and Review", "summary": "An LLM Wiki requires active maintenance to prevent knowledge drift, contradictions, and citation decay, as compiled pages can appear clean while being factually outdated or misleading. The author argues that maintenance—including drift detection, contradiction checks, and review workflows—is essential for keeping the system trustworthy, and proposes a simple, repeatable loop focused on source preservation and explicit review.", "body_md": "# LLM Wiki Maintenance: Drift, Contradictions and Review\n\nKeep compiled knowledge trustworthy\n\nAn LLM Wiki fails when old facts remain plausible, contradictions become polished, and generated summaries drift from their sources.\n\nMaintenance is the real product of any compiled knowledge system. Creating wiki pages is straightforward compared with keeping them trustworthy across months of ingest, edits, rewrites, and new sources.\n\nThis article covers the operational side of LLM Wiki systems: drift detection, contradiction checks, citation discipline, linting, Git review, and maintenance workflows. It assumes you already understand the basic pattern described in [LLM Wiki - Compiled Knowledge That RAG Cannot Replace](https://www.glukhov.org/knowledge-management/knowledge-systems-architectures/compiled-knowledge/what-is-llm-wiki/): raw sources are compiled into durable Markdown pages that humans and agents can query later. The calm but opinionated view is that an LLM Wiki without maintenance is just a nicer-looking knowledge graveyard.\n\n## What Makes LLM Wiki Maintenance Different\n\nTraditional wikis rot because people stop updating them. RAG systems drift because the corpus changes, chunks get stale, metadata is weak, and retrieval keeps finding plausible but outdated fragments. The deeper reason is that [retrieval and representation solve different problems](https://www.glukhov.org/knowledge-management/foundations/retrieval-vs-representation/): retrieval can be re-run against fresh data, but a representation you already compiled has to be actively kept honest.\n\nAn LLM Wiki has a different failure mode. It can look clean even when it is wrong.\n\nThe pages may be well formatted. The links may work. The summaries may sound balanced. But underneath that neat surface, the system may have dropped critical facts, merged incompatible concepts, cited summaries instead of sources, or preserved an old decision as if it still applied.\n\nThat is why LLM Wiki maintenance must check both structure and meaning.\n\n## The Maintenance Goal\n\nThe goal is not to make every page perfect. That is too expensive, and it usually leads to abandoned systems.\n\nThe goal is to keep the wiki useful, inspectable, and recoverable.\n\nA maintained LLM Wiki should make it easy to answer these questions:\n\n- What sources support this claim?\n- When was this page last reviewed?\n- Has this concept changed?\n- Are there conflicting pages?\n- Is this summary still current?\n- Did the agent rewrite more than it should?\n- Can we roll back a bad update?\n- Can a human understand why the page says what it says?\n\nIf the answer is no, the problem is not only content quality. It is system design.\n\n## A Simple Maintenance Loop\n\nA useful LLM Wiki needs a repeatable loop. The loop should be simple enough to run often and strict enough to catch drift before it becomes invisible.\n\nThis loop is not glamorous. That is the point.\n\nA knowledge system becomes durable through boring maintenance: source preservation, explicit review, predictable structure, and small safe updates. The same instinct drives [evergreen notes](https://www.glukhov.org/knowledge-management/methods/evergreen-notes/): a note or a wiki page only compounds in value if someone keeps refining it instead of leaving it to rot after the first draft.\n\n## Types of Drift in an LLM Wiki\n\nKnowledge drift is not one thing. Different drift types require different checks. A good maintenance system should name them clearly.\n\n### Source Drift\n\nSource drift happens when the underlying source material changes.\n\nFor example, a tool releases a new version, a policy is updated, an API changes, or a vendor deprecates an old feature. The old wiki page may still be accurate for the previous version, but wrong for current use.\n\nSource drift is dangerous because the old claim may still be true in historical context. The problem is not that the claim is fake. The problem is that it no longer answers the current question.\n\n**Maintenance response:**\n\n- Record source dates\n- Record last reviewed dates\n- Mark version-specific pages clearly\n- Link old pages to superseding pages\n- Avoid mixing old and new versions without labels\n\n### Concept Drift\n\nConcept drift happens when the meaning of a term changes over time.\n\nThis is common in AI and software architecture. Terms like “agent”, “memory”, “RAG”, “workflow”, “tool use”, “structured output”, and “context engineering” can shift meaning quickly.\n\nA wiki can accidentally preserve several meanings of the same term without explaining the difference. That creates confusing pages that sound coherent but combine incompatible ideas.\n\n**Maintenance response:**\n\n- Maintain glossary pages\n- Add “meaning in this wiki” sections\n- Separate overloaded concepts into distinct pages\n- Link related meanings explicitly\n- Avoid letting the model silently merge terms\n\n### Terminology Drift\n\nTerminology drift is smaller than concept drift but still harmful.\n\nIt happens when the wiki uses multiple names for the same thing: “LLM Wiki”, “compiled knowledge base”, “AI-maintained wiki”, “agent-maintained wiki”, and “Markdown knowledge base”.\n\nSome variation is fine. Too much variation breaks search, linking, and review.\n\n**Maintenance response:**\n\n- Define canonical page names\n- Keep aliases in front matter or page metadata\n- Redirect duplicate pages\n- Lint for near-duplicate titles\n- Use consistent anchor text in internal links\n\n### Decision Drift\n\nDecision drift happens when a past decision remains documented but no longer reflects current practice.\n\nFor example, a page might say that the project uses vector RAG for all document search, while newer pages describe an LLM Wiki workflow. Both statements may be historically true, but the wiki must show which one is current.\n\nThis matters for architecture notes, engineering processes, content strategy, and internal tooling. The same discipline applies to [decision records in AI-driven development](https://www.glukhov.org/app-architecture/documentation/decision-records-ai-driven-development/): a decision page is only trustworthy if superseded choices are marked as superseded rather than silently overwritten.\n\n**Maintenance response:**\n\n- Mark decisions as proposed, accepted, superseded, or rejected\n- Keep decision dates\n- Link superseded decisions to replacements\n- Preserve historical context\n- Avoid deleting old decisions without trace\n\n### Citation Drift\n\nCitation drift happens when a page cites a source, but the claim no longer matches what the source says.\n\nThis can happen after a rewrite. The citation remains in place, but the sentence around it changes. The page still looks sourced, yet the citation no longer supports the claim.\n\nThis is one of the most serious LLM Wiki failure modes because it creates false confidence.\n\n**Maintenance response:**\n\n- Check claim-level citation support\n- Avoid citing only summaries\n- Keep raw sources\n- Require citations for important claims\n- Flag paragraphs with sources but no direct support\n- Review citation changes in Git diffs\n\n### Structure Drift\n\nStructure drift happens when the wiki slowly loses navigability.\n\nNew pages are created instead of updating old ones. Index pages fall behind. Duplicate pages appear. Orphan pages accumulate. Related pages stop linking to each other.\n\nThe wiki still contains useful knowledge, but finding and trusting it becomes harder.\n\n**Maintenance response:**\n\n- Lint for orphan pages\n- Maintain index pages\n- Detect duplicate topics\n- Require backlinks for canonical pages\n- Archive rather than scatter\n- Keep folder roles clear\n\n## The Core Maintenance Files\n\nAn LLM Wiki should not rely on memory, vibes, or repeated prompting. It needs operating files that tell humans and agents how to maintain it.\n\nA practical structure can look like this:\n\n```\nllm-wiki/\n  raw/\n    sources/\n    transcripts/\n    documents/\n  wiki/\n    index.md\n    concepts/\n    entities/\n    projects/\n    decisions/\n  maintenance/\n    review-log.md\n    lint-report.md\n    stale-pages.md\n    contradiction-report.md\n  rules/\n    AGENTS.md\n    schema.md\n    style-guide.md\n    citation-policy.md\n    source-policy.md\n```\n\nThe exact names do not matter. The roles do.\n\nThe wiki needs source storage, compiled pages, review artifacts, and rules that survive across sessions.\n\n### AGENTS.md\n\n`AGENTS.md`\n\nshould explain how the agent is allowed to work.\n\nIt should answer questions like:\n\n- Should the agent update existing pages before creating new ones?\n- When should it ask for review?\n- How should it cite sources?\n- Can it reorganize folders?\n- Can it rewrite old pages?\n- What should it do with contradictions?\n- What should it never delete?\n\nA useful rule is:\n\n```\nPrefer small, source-backed updates over broad rewrites.\n```\n\nThat one sentence prevents many bad maintenance habits. It also draws a useful boundary relative to [agent memory](https://www.glukhov.org/ai-systems/memory/memory-systems-in-ai-assistants/): memory shapes how an agent behaves in the moment, while the wiki’s rules file shapes what the agent is allowed to change in the shared knowledge base.\n\n### schema.md\n\n`schema.md`\n\nshould define the page structure.\n\nFor example:\n\n```\n# Page Title\n\n## Summary\nShort current summary.\n\n## Key Claims\n- Claim with source reference.\n- Claim with source reference.\n\n## Current Status\nCurrent, historical, superseded, draft, or uncertain.\n\n## Details\nMain compiled explanation.\n\n## Related Pages\nInternal links.\n\n## Sources\nRaw source references.\n\n## Review Notes\nLast reviewed date and reviewer.\n```\n\nA schema does not need to be rigid. But without a schema, the wiki becomes a pile of inconsistent essays. The schema gives the agent something to preserve.\n\n### citation-policy.md\n\nThe citation policy should say what requires a source. At minimum, require citations for:\n\n- Technical claims\n- Comparisons\n- Product behavior\n- Version-specific statements\n- Benchmark results\n- Pricing\n- Legal or compliance claims\n- Current status claims\n- Claims copied or derived from a source\n\nA good citation policy also says what not to do. Do not cite a compiled page as if it were the original source. Do not attach citations to paragraphs they do not support. Do not keep a citation after rewriting a claim unless the source still supports it.\n\nCitation discipline is the difference between a useful LLM Wiki and decorative confidence.\n\n### source-policy.md\n\nThe source policy should define how raw sources are stored.\n\nFor example:\n\n- Keep original files when possible\n- Preserve URLs and access dates\n- Store copied notes separately from generated summaries\n- Record source type\n- Mark low-confidence sources\n- Avoid overwriting raw material\n- Keep superseded sources when they explain historical decisions\n\nThis policy protects the wiki from a common mistake: summarizing a source, discarding the original, and then treating the summary as evidence.\n\nThat is not knowledge management. That is lossy compression.\n\n## What an LLM Wiki Linter Should Check\n\nA linter should check structure first. Structural problems are easier to automate and often reveal deeper semantic problems.\n\nUseful structural checks include:\n\n- Broken internal links\n- Orphan pages\n- Duplicate titles\n- Missing source sections\n- Missing review dates\n- Pages without backlinks\n- Empty or placeholder sections\n- Very long pages without section structure\n- Pages with no incoming links from an index\n- Inconsistent naming conventions\n- Invalid front matter\n- Stale “current” pages older than a review threshold\n\nThese checks do not prove the knowledge is true. They prove the wiki is still maintainable. That is a necessary starting point.\n\n## Semantic Checks\n\nSemantic checks are harder but more valuable.\n\nUseful semantic checks include:\n\n- Claims without direct source support\n- Two pages making incompatible claims\n- Old decisions presented as current\n- Duplicate concepts with different names\n- One concept page mixing several meanings\n- Summaries that omit known constraints\n- “Best” or “recommended” claims without criteria\n- Version-specific claims without version labels\n- Pages that contradict newer sources\n\nThese checks should not automatically rewrite the wiki. They should usually produce a report for review.\n\nThe safer pattern is:\n\n```\nDetect automatically.\nExplain clearly.\nUpdate deliberately.\nReview risky changes.\n```\n\n## Contradiction Detection\n\nContradiction detection is not just asking an LLM whether two pages contradict each other.\n\nThat can help, but it is too vague. A better approach is to compare claims.\n\nA contradiction workflow can look like this:\n\nThis works better because many apparent contradictions are not real contradictions.\n\nOne page may describe version 1.0 and another version 2.0. One page may describe personal use and another enterprise use. One page may describe the design goal and another the implementation reality.\n\nThe contradiction report should include:\n\n- Conflicting claims\n- Pages involved\n- Source references\n- Date or version context\n- Likely explanation\n- Suggested resolution\n- Whether human review is required\n\nDo not let the agent silently resolve contradictions by blending both claims into a vague compromise. That creates smooth nonsense.\n\n## How to Resolve Contradictions\n\nThere are several valid ways to resolve a contradiction.\n\n- If one claim is outdated, mark it as superseded and link to the newer page.\n- If both claims are true in different contexts, split the context clearly.\n- If the sources disagree, preserve the disagreement and explain it.\n- If the wiki page invented or overgeneralized a claim, remove or narrow the claim.\n- If the contradiction reflects a real unresolved decision, create or update a decision page.\n\nThe goal is not to remove all tension. Some tension is useful. A good wiki shows where knowledge is settled and where it is still uncertain.\n\n## Stale Page Review\n\nEvery compiled page should have a review status.\n\nA simple metadata block can be enough:\n\n```\nstatus: current\nlast_reviewed: 2026-07-10\nreview_after: 2026-10-10\nsource_confidence: medium\n```\n\nFor fast-moving topics, use short review windows. For stable concepts, use longer windows.\n\n| Page type | Review interval |\n|---|---|\n| Tool version pages | 30 to 90 days |\n| Pricing or availability pages | 7 to 30 days |\n| Architecture principles | 6 to 18 months |\n| Historical decision records | Only when superseded |\n| Glossary pages | 3 to 12 months |\n| Source summaries | When source changes |\n| Comparison pages | 30 to 180 days |\n\nThe interval is less important than the habit. A page without a review date is a page that will eventually lie quietly.\n\n## Source-Aware Updates\n\nWhen a new source arrives, the agent should not simply write a new summary page.\n\nIt should ask:\n\n- Does this update an existing concept?\n- Does it supersede a previous source?\n- Does it contradict an existing page?\n- Does it add a new entity or term?\n- Does it change a recommendation?\n- Does it require an index update?\n- Does it affect decision pages?\n\nA good ingest workflow updates the wiki as a graph, not as a stack of isolated summaries.\n\nThis is why one source may touch many pages. That is normal. The maintenance challenge is making those updates small, reviewable, and traceable.\n\n## Review with Git Diffs\n\nGit is one of the best maintenance tools for an LLM Wiki.\n\nNot because Git is fashionable, but because generated knowledge needs reviewable change history. A Git diff shows what the agent changed, deleted, moved, or rephrased.\n\nUse Git to review:\n\n- New pages\n- Deleted sections\n- Changed claims\n- Changed citations\n- Renamed pages\n- Index updates\n- Link changes\n- Status changes\n- Broad rewrites\n\nThe most important review habit is to inspect deletions. LLMs often remove details while making prose cleaner.\n\nClean prose is not always better knowledge.\n\n## Safe Commit Strategy\n\nAvoid giant commits like:\n\n```\nUpdate wiki\n```\n\nUse commits that explain the operation:\n\n```\ningest: add source notes for Qwen embedding release\nmaint: mark old vector store comparison as superseded\nlint: fix broken internal links in RAG pages\nreview: update LLM Wiki page citations\nrefactor: split agent memory concept from long-term memory\n```\n\nThis gives future humans and agents a useful history.\n\nCommit messages are part of the knowledge system. They explain why the wiki changed.\n\n## Review Levels\n\nNot every page needs the same review level. Use risk-based review.\n\n**Low-risk changes:**\n\n- Broken link fixes\n- Formatting cleanup\n- Adding backlinks\n- Adding index entries\n- Correcting typos\n- Adding aliases\n\n**Medium-risk changes:**\n\n- Adding source summaries\n- Creating new concept pages\n- Updating recommendations\n- Merging duplicate pages\n- Changing page status\n\n**High-risk changes:**\n\n- Deleting claims\n- Rewriting canonical pages\n- Changing decision records\n- Updating security, legal, pricing, or benchmark claims\n- Resolving contradictions\n- Marking content as current or superseded\n\nHigh-risk changes should get human review. That may be you, a maintainer, or a domain owner.\n\nThe agent can prepare the change, but it should not always be the final authority.\n\n## A Maintenance Dashboard\n\nA simple maintenance dashboard can live in Markdown.\n\nExample:\n\n```\n# LLM Wiki Maintenance Dashboard\n\n## Needs Review\n- wiki/concepts/agent-memory.md - review overdue\n- wiki/projects/search-index.md - conflicting claims found\n\n## Stale Pages\n- wiki/tools/ollama.md - last reviewed 120 days ago\n- wiki/concepts/rag.md - fast-moving topic, review due\n\n## Broken Links\n- wiki/index.md -> wiki/concepts/old-page.md\n\n## Orphan Pages\n- wiki/entities/vendor-x.md\n\n## Contradiction Reports\n- reports/contradictions/2026-07-10-agent-memory.md\n\n## Recent Ingests\n- raw/sources/2026-07-09-new-paper.md\n```\n\nThis is not a fancy admin panel. It is a working surface.\n\nFor many solo or small-team systems, a Markdown dashboard is enough.\n\n## Metrics for a Healthy LLM Wiki\n\nYou can track wiki health without overengineering it.\n\nUseful metrics include:\n\n- Number of pages\n- Pages without sources\n- Pages without review dates\n- Pages past review date\n- Broken internal links\n- Orphan pages\n- Duplicate titles or aliases\n- Contradiction reports open\n- Contradiction reports resolved\n- Average page age by cluster\n- Raw sources not yet ingested\n- Pages changed without human review\n- Canonical pages changed in the last 30 days\n\nThese metrics are not vanity numbers. They tell you whether the system is becoming easier or harder to trust.\n\nA growing wiki with rising orphan pages and stale reviews is not compounding knowledge. It is compounding maintenance debt.\n\n## Maintenance Prompts\n\nMaintenance prompts should be narrow. Broad prompts produce broad rewrites.\n\n### Structural Lint Prompt\n\n```\nReview the wiki structure.\n\nCheck for:\n- broken internal links\n- orphan pages\n- duplicate or near-duplicate page titles\n- pages missing source sections\n- pages missing last_reviewed metadata\n- index pages that do not link to new pages\n\nDo not rewrite content.\nProduce a Markdown report with findings and suggested fixes.\n```\n\n### Citation Review Prompt\n\n```\nReview citations for the selected page.\n\nFor each important claim:\n- identify the supporting source\n- check whether the source directly supports the claim\n- flag claims with weak, missing, or mismatched support\n- do not rewrite the page yet\n\nReturn a table with:\nclaim, current citation, support level, issue, suggested action.\n```\n\n### Contradiction Check Prompt\n\n```\nCheck this page for contradictions against related pages.\n\nSteps:\n1. Extract the main claims from the page.\n2. Find related pages through links, backlinks, aliases, and search.\n3. Extract potentially conflicting claims.\n4. Classify each conflict as:\n   - real contradiction\n   - version difference\n   - scope difference\n   - terminology difference\n   - unresolved uncertainty\n5. Recommend a resolution.\n\nDo not edit files until the contradiction report is reviewed.\n```\n\n### Stale Page Review Prompt\n\n```\nReview this page for staleness.\n\nCheck:\n- dates\n- version-specific claims\n- tool behavior\n- recommendations\n- links to superseded pages\n- sources newer than the page review date\n- claims marked current without recent support\n\nReturn:\n- keep current\n- update needed\n- mark historical\n- mark superseded\n- split into versioned pages\n```\n\n### Safe Update Prompt\n\n```\nUpdate the selected wiki page using the provided source.\n\nRules:\n- preserve existing useful structure\n- do not remove sourced claims unless the source is superseded\n- add citations for new claims\n- mark uncertainty explicitly\n- update related pages only when necessary\n- add a review note explaining what changed\n- keep the diff small\n```\n\nThese prompts are not magic. They are guardrails. The real value comes from making the maintenance action explicit.\n\n## Common Maintenance Mistakes\n\nThe first mistake is letting the agent rewrite too much.\n\nLarge rewrites feel productive because they make pages smoother. They also make it harder to see what changed and easier to lose sharp details.\n\nThe second mistake is treating generated summaries as sources.\n\nA summary can be useful, but it is not the evidence. Keep raw sources and cite them when claims matter.\n\nThe third mistake is creating new pages instead of updating old ones.\n\nThis produces duplicate concepts, conflicting recommendations, and search confusion. The agent should search first, update second, and create new pages only when the concept is genuinely new.\n\nThe fourth mistake is deleting historical context.\n\nOld decisions, failed experiments, and superseded recommendations can be valuable. Mark them clearly instead of erasing them.\n\nThe fifth mistake is forgetting indexes.\n\nA page that is not linked from the right place is half-lost. Index maintenance is not clerical work. It is navigation architecture.\n\nThe sixth mistake is using the same review policy for every page.\n\nA stable conceptual page and a fast-moving tool comparison should not have the same review schedule.\n\n## Archive, Supersede, or Delete\n\nMost stale pages should not be deleted immediately.\n\n| Outcome | Use when |\n|---|---|\n| Archive | The page is historical but still useful |\n| Supersede | A newer page replaces the old answer |\n| Delete | The page is duplicate, empty, wrong, or unrecoverable |\n\nA superseded page should link to the replacement.\n\nFor example:\n\n```\nStatus: superseded\nSuperseded by: wiki/concepts/agent-memory-architecture.md\nReason: This page used an older definition of agent memory before the project separated session memory, user memory, and compiled knowledge.\n```\n\nThis preserves context and reduces confusion.\n\nDeletion should be rare and reviewable. Knowledge systems need pruning, but invisible pruning is dangerous.\n\n## Canonical Pages Need Extra Care\n\nEvery LLM Wiki eventually develops canonical pages.\n\nThese are pages that define core concepts, architecture choices, workflows, or project vocabulary. They are more important than ordinary notes because many other pages depend on them.\n\nExamples:\n\n- What is LLM Wiki\n- RAG vs compiled knowledge\n- Agent memory\n- Source policy\n- Review workflow\n- Project architecture\n- Glossary\n- Index\n\nChanges to canonical pages should require stricter review.\n\nA small error on an obscure page is local. A small error on a canonical page can distort the whole wiki.\n\n## How Often Should You Run Maintenance\n\nFor an active LLM Wiki, run small maintenance frequently and deep maintenance occasionally.\n\n| Frequency | Maintenance task |\n|---|---|\n| Every ingest | Update links, sources, indexes, and review notes |\n| Weekly | Run structural lint checks |\n| Monthly | Review stale pages and orphan pages |\n| Monthly | Check contradictions in active clusters |\n| Quarterly | Review canonical pages |\n| Quarterly | Archive or supersede old pages |\n| Before major use | Run citation checks on pages used for reports, articles, or decisions |\n\nThe schedule should match risk. A personal research wiki can be lighter. A wiki used for technical publishing, customer support, or engineering decisions needs more discipline.\n\n## Using an LLM Wiki for Technical Publishing\n\nFor a technical blog or documentation site, the LLM Wiki can become the knowledge layer behind article planning.\n\nIt can track:\n\n- Canonical explanations\n- Repeated definitions\n- Internal link opportunities\n- Stale comparisons\n- Article gaps\n- Topic clusters\n- Source notes\n- Decisions about structure\n- Claims that need verification\n\nThis is useful, but it raises the maintenance bar.\n\nIf the wiki feeds published articles, then stale wiki pages can become stale public content. If the wiki contains contradictions, those contradictions may leak into articles. If citations are weak, generated drafts will inherit that weakness. The scoped summaries, schema-based extraction, and human review loops described in [AI for Knowledge Management: Real Workflows That Hold Up](https://www.glukhov.org/knowledge-management/ai-augmented-knowledge/ai-for-knowledge-management-workflows/) are a good template for keeping that editorial pipeline honest.\n\nFor publishing workflows, treat the LLM Wiki as an editorial system, not just a private notebook. A [digital garden](https://www.glukhov.org/knowledge-management/methods/digital-gardening/) makes this explicit by showing readers which pages are still growing and which are mature, which is exactly the kind of status signal a well-maintained LLM Wiki should also expose.\n\n## Maintenance Is Not Optional\n\nAn LLM Wiki is attractive because it promises compounding knowledge.\n\nBut compounding only works if old knowledge remains useful. Otherwise, the system compounds noise, not insight.\n\nThe maintenance burden does not disappear because an agent is involved. It changes shape.\n\nHumans should not have to do every tedious task. Agents can check links, find stale pages, compare claims, draft reports, and propose updates. But humans still need to set policy, review risky changes, and decide what the wiki is allowed to mean.\n\nThat is the real bargain.\n\n## Conclusion\n\nLLM Wiki maintenance is about keeping compiled knowledge honest.\n\nThe important practices are not complicated: preserve sources, cite claims, keep indexes current, detect contradictions, review Git diffs, mark stale pages, and avoid broad unreviewed rewrites.\n\nA good LLM Wiki does not pretend to be magically self-correcting. It makes correction easier.\n\nThat is the standard worth aiming for: not perfect knowledge, but inspectable knowledge that can be reviewed, repaired, and trusted over time.", "url": "https://wpnews.pro/news/llm-wiki-maintenance-drift-contradictions-and-review", "canonical_source": "https://www.glukhov.org/knowledge-management/knowledge-systems-architectures/compiled-knowledge/llm-wiki-maintenance-knowledge-drift/", "published_at": "2026-07-16 09:43:56+00:00", "updated_at": "2026-07-16 10:29:57.367909+00:00", "lang": "en", "topics": ["large-language-models", "ai-tools", "ai-infrastructure", "ai-agents"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/llm-wiki-maintenance-drift-contradictions-and-review", "markdown": "https://wpnews.pro/news/llm-wiki-maintenance-drift-contradictions-and-review.md", "text": "https://wpnews.pro/news/llm-wiki-maintenance-drift-contradictions-and-review.txt", "jsonld": "https://wpnews.pro/news/llm-wiki-maintenance-drift-contradictions-and-review.jsonld"}}