Guided Design for AI Dreaming Memory Management on LLMWikis.org

Full report

On this page

Executive summary

The strongest fit for LLMWikis.org is a governed hybrid memory architecture: keep a small working-memory layer for live prompts, an append-only episodic project log for sessions and wizard actions, a reviewed semantic wiki layer for durable project knowledge, and a wizard export layer for handoff artifacts such as system profiles, receiver briefs, startup packets, and related manifests. In this design, AI “dreaming” should be implemented as an offline consolidation pipeline that clusters, deduplicates, scores, summarizes, and proposes promotions from episodic traces into reviewed semantic pages, but does not silently rewrite approved project memory without provenance and human review. That recommendation matches both the LLMWikis emphasis on durable, reviewed, trust-labeled, citable knowledge with raw-vs-curated separation and the UAIX/AIWikis evidence that wizard flows already revolve around generated profiles, briefs, startup packets, memory plans, evidence ledgers, conflict resolution, risk, and rollback rules.

This is also the architecture most consistent with current memory research. Recent surveys describe agent memory as a lifecycle of consolidation, updating, indexing, forgetting, retrieval, and compression, and emphasize that production systems need explicit handling for latency, benchmark validity, contradiction management, privacy, and governance. Recent systems show that offline consolidation and structured compression can sharply cut online token and API costs, while graph- or hierarchy-based retrieval improves reuse and multi-hop recall when compared with flatter memory stores or repeated raw RAG.

For LLMWikis specifically, the most practical implementation pattern is:

1. Treat the starter bundle as the source-tree skeleton, not as a plugin or theme.
2. Store raw project material separately from curated wiki memory.
3. Write every wizard interaction as an episodic event with provenance.
4. Run dreaming on a schedule or on-demand preview.
5. Promote only reviewed candidates into files analogous to SYSTEM_OVERVIEW, DECISION_LOG, OPEN_QUESTIONS, RUNBOOKS, GOVERNANCE, and related wiki artifacts.
6. Generate handoff packets from the reviewed layer plus explicitly scoped episodic context, not straight from chat history.

If LLMWikis adopts only one core principle, it should be this: dreaming is a governed compiler pass over project memory, not a license for unsupervised memory mutation. That principle best preserves provenance, reversibility, trust labels, and wizard operability.

Core concepts and working definitions

In current agent-memory literature, working memory is the bounded, inside-task context the agent can actively reason over; episodic memory records task-specific experiences and time-bound events; semantic memory stores generalized world or project knowledge; procedural memory stores the “how” layer of rules or procedures; and long-term memory is best treated as the persistent umbrella containing one or more of those durable forms rather than as a single homogeneous store. A useful engineering translation is: working memory lives in the prompt/context engine, episodic memory lives in append-only logs and session summaries, semantic memory lives in reviewed wiki claims/pages, and procedural memory lives in policies, runbooks, schemas, and agent instructions.

For this report, AI dreaming means an offline or background memory-consolidation process that moves selected high-signal short-term traces into durable memory after scoring, deduplication, reflection, and review. That definition is not just metaphorical: official OpenClaw documentation uses “Dreaming” for a background consolidation system whose phases stage short-term material, reflect on themes, and promote durable candidates into long-term memory, while keeping the process inspectable and reviewable. LightMem describes a similar “sleep-time update” idea in research form by decoupling long-term consolidation from online inference.

The LLMWikis framing makes these distinctions especially important. AIWikis’ summary of the LLMWikis handbook model describes an LLM Wiki as a durable, reviewed, trust-labeled, citable knowledge system where raw sources remain distinct from curated wiki pages, important claims carry citation paths, and agents should route through an index and trust model before editing. That means LLMWikis-style project memory should not collapse chats, notes, handoffs, wiki pages, and “dreamed” abstractions into one undifferentiated blob.

A productive LLMWikis mapping is therefore:

• Working memory: active wizard pane state, current task context, recent retrieval pack.
• Episodic memory: wizard runs, user edits, approvals, agent tool calls, source ingests, decision episodes, unresolved incidents.
• Semantic memory: reviewed project facts, entities, architecture summaries, glossary entries, accepted decisions, stable constraints.
• Procedural memory: wizard rules, promotion policies, runbooks, safety boundaries, review criteria, export rules.
• Long-term memory: the governed union of reviewed semantic pages plus selected episodic histories and procedural guides.

Architectures and algorithms that matter most

The broadest recent survey frame is useful here: agent memory can be understood through representations and operations. A major 2025 survey divides memory into parametric and contextual forms and identifies six core operations: consolidation, updating, indexing, forgetting, retrieval, and condensation/compression. A 2026 survey similarly describes memory as a write–manage–read loop and groups mechanisms into families such as context-resident compression, retrieval-augmented stores, reflective self-improvement, hierarchical virtual context, and policy-learned management.

For LLMWikis, consolidation is the most important dreaming operation. Generative Agents showed an early, influential form of memory consolidation by storing experiences, synthesizing them into higher-level reflections, and retrieving them dynamically for planning. LightMem formalizes a more production-oriented version: sensory filtering, topic-aware short-term consolidation, and long-term memory with a sleep-time update. OpenClaw’s dreaming adds a highly operational version of the same idea: a light phase for staging, a REM phase for reflective themes, and a deep phase for promotion into durable memory.

For rehearsal, the design fork is important. If LLMWikis wants to preserve durable performance without modifying model weights, use contextual replay and example reuse: retrieve past successful project traces, summaries, or decisions as demonstrations in wizard previews and project workflows. If LLMWikis ever fine-tunes models, rehearsal becomes a separate parametric concern, and recent work such as Self-Synthesized Rehearsal exists to mitigate catastrophic forgetting when original past data are unavailable. For a file-centric wiki system, however, the default should be non-parametric replay, because it is more auditable, reversible, and aligned with provenance.

For compression, the key issue is whether the system compresses once at write time, repeatedly at read time, or both. SimpleMem argues for semantic structured compression, recursive consolidation, and adaptive retrieval, reporting large token savings on its evaluations. LightMem similarly pushes compute into offline consolidation. In contrast, full-history approaches preserve maximal fidelity but push token and latency costs into the online path. For LLMWikis wizard flows, write-time compression is usually preferable because wizard outputs are formal artifacts that benefit from stable intermediate representations.

For retrieval, four patterns dominate:

First, hybrid lexical plus vector retrieval is the best baseline. OpenClaw’s default memory engine uses BM25/FTS5 keyword search plus embedding-based vector search and hybrid ranking in a single local SQLite-backed system. This is easy to adopt, cheap to operate, and generally enough for project memory where names, IDs, pages, and exact phrases matter.

Second, graph or associative retrieval is valuable when wizard questions are multi-hop and relationship-heavy. HippoRAG combines LLMs, knowledge graphs, and Personalized PageRank to support deeper knowledge integration and reports better results than several RAG baselines on multi-hop QA, with lower cost than iterative retrieval on its benchmarks. A-MEM and Synapse-style systems take this further by structuring memory as linked notes or episodic-semantic graphs.

Third, hierarchical virtual-context systems like MemGPT and LongMem treat the context window as a scarce cache and external memory as slower storage. This is powerful for long tasks and very large source collections, but weaker as a complete governance model because paging alone does not tell you which promoted knowledge is reviewed policy and which is merely retrieved context.

Fourth, policy-learned memory management is an emerging direction. Systems such as AgeMem and Memory-R1 push memory decisions into the agent’s learned policy, letting the agent decide when to add, update, summarize, delete, or retrieve. This is promising, but it also increases training and observability burden. For LLMWikis, it is better treated as a future optimization layer than as the first production design.

For forgetting, recent work matters because external memory does not eliminate continual-learning trade-offs; it relocates them. MemoryBank uses a forgetting-curve-inspired update rule with reinforcement and decay. A 2026 experience-reuse study shows that continual-learning bottlenecks reappear at retrieval time: old and new experiences compete within a limited context budget, and poor representation choices can produce forgetting or negative transfer. Another empirical study finds that selective addition and strategic deletion improve long-horizon performance and reduce propagation of bad experiences. In other words, forgetting is not merely cleanup. It is part of correct memory management.

The practical conclusion is straightforward: for LLMWikis project memory, the best default is hybrid retrieval + offline dreaming + governed promotion + selective forgetting. That design is more aligned with LLMWikis’ handbook and trust-model ethos than either naïve full-context prompting or unconstrained vector-only memory.

The following comparison table synthesizes the research and official implementation patterns above. The cost bands are relative architecture bands, not vendor price quotes.

A tailored architecture for LLMWikis project memory and wizard workflows

The public materials around LLMWikis and AIWikis strongly imply a source-governed, file-centric knowledge architecture rather than a monolithic chat memory application. AIWikis explicitly describes LLMWikis as the handbook source for practical LLM Wiki structure, governance, starter templates, metadata, trust labels, source policy, agent rules, and handbook patterns. It also shows that the source-side system separates public content information, real system files, demonstrations, and provenance, and that the imported memory layer preserves source URLs, retrieval times, content hashes, and update histories.

That matters architecturally. It means LLMWikis-style project memory should be arranged as layers with different trust and mutability rules, not as a single database table called “memory.” The most compatible layering is:

• Raw sources: uploads, notes, transcripts, external docs, tool outputs.
• Episodic project memory: append-only normalized events from project work and wizard actions.
• Reviewed semantic wiki: stable project pages and governed records such as system overviews, decisions, open questions, glossaries, policies, and runbooks.
• Wizard export layer: generated system profiles, receiver briefs, startup packets, optional LLM Wiki memory plans, and manifest-backed handoff outputs.

The starter-bundle evidence supports this direction. The imported LLMWikis bundle contains files such as SYSTEM_OVERVIEW.md, AGENT_INSTRUCTIONS.md, DECISION_LOG.md, OPEN_QUESTIONS.md, GOVERNANCE.md, RUNBOOKS.md, TRUST_MODEL.md, MANIFEST.json, README.md, and INDEX.md. That is exactly the kind of file surface a memory compiler should target. Dreaming therefore should not generate an opaque database blob; it should generate or update candidate content for these specific governed artifacts.

A strong LLMWikis-specific pattern is to let dreaming propose content by destination. For example, if repeated episodic traces establish an architectural fact, route the candidate to SYSTEM_OVERVIEW; if they establish a policy decision, route to DECISION_LOG; if conflict persists, route to OPEN_QUESTIONS; if they reveal procedure, route to RUNBOOKS; if they change escalation rules or approval boundaries, route to GOVERNANCE or agent instructions. This matches the bundle’s explicit file roles and preserves page ownership.

The wizard layer should then sit above that governed memory. AIWikis’ public description of current wizard evidence mentions generated system profiles, receiver briefs, startup packets, optional LLM Wiki memory plans, and source-authority, evidence-ledger, conflict-resolution, risk, and rollback rules. The implication is that wizard outputs are not the same thing as underlying project memory; they are structured views and exports derived from it. That is exactly how LLMWikis should treat wizard flows.

flowchart LR
    A[Raw sources<br/>docs, chats, tool logs, imports] --> B[Ingest and normalize]
    B --> C[Episodic event store<br/>append-only project memory]
    B --> D[Security and PII classification]
    C --> E[Working set builder<br/>active wizard/runtime context]
    C --> F[Dreaming pipeline<br/>cluster, dedupe, summarize, score]
    F --> G[Review queue]
    G --> H[Reviewed semantic wiki<br/>SYSTEM_OVERVIEW, DECISION_LOG,<br/>OPEN_QUESTIONS, RUNBOOKS, GLOSSARY]
    H --> I[Wizard outputs<br/>system profile, receiver brief,<br/>startup packet, handoff manifest]
    H --> J[Retrieval API]
    C --> J
    K[Trust model, governance,<br/>authority boundaries] --> F
    K --> G
    K --> H
    J --> L[Agent runtime and wizard UI]

This architecture is not locked to any specific stack. It can be implemented with plain files plus indexing, Git plus sidecar services, a relational core with markdown exports, or a CMS-backed source tree. The important point is behavioral separation: reviewed wiki pages are the authoritative semantic layer, wizard packets are derivative packaged views, and episodic traces remain available for audit and rollback.

Data contracts, APIs, storage, privacy, provenance, and cost

A good data model for LLMWikis project memory should distinguish events, claims, pages, reviews, and exports. The following templates are recommended syntheses of the file-centric starter-bundle model, the reviewed wiki paradigm, and the wizard/handoff packet concepts exposed in the AIWikis/UAIX materials.

{
  "memory_event": {
    "event_id": "evt_01",
    "project_id": "proj_alpha",
    "wizard_run_id": "wiz_2026_05_09_01",
    "timestamp": "2026-05-09T14:20:00Z",
    "actor": "user|agent|system",
    "memory_type": "episodic",
    "event_kind": "source_ingest|decision|edit|approval|retrieval|tool_call",
    "content": "Normalized event summary",
    "source_refs": [
      {
        "source_id": "src_88",
        "source_url": "stored-outside-response",
        "content_hash": "sha256:...",
        "retrieved_at": "2026-05-09T14:18:00Z"
      }
    ],
    "trust_label": "draft|reviewed|approved",
    "security_class": "public|internal|restricted",
    "pii_flags": ["none"],
    "supersedes": [],
    "contradicts": [],
    "tags": ["wizard", "architecture"],
    "embedding_ref": "emb_001"
  },
  "memory_claim": {
    "claim_id": "clm_01",
    "project_id": "proj_alpha",
    "page_target": "SYSTEM_OVERVIEW",
    "claim_text": "Project uses queue-backed offline consolidation",
    "memory_type": "semantic",
    "evidence_event_ids": ["evt_01", "evt_09", "evt_11"],
    "source_refs": ["src_88"],
    "status": "proposed|reviewed|approved|rejected",
    "review_owner": "pm_or_engineer",
    "review_notes": "Needs confirmation from runtime owner",
    "open_question_ids": ["oq_03"],
    "version": 3
  }
}

Recommended API surfaces should also preserve those distinctions. A minimal stack-agnostic set is:

POST /memory/events
POST /memory/retrieve
POST /memory/dream/preview
POST /memory/dream/promote
POST /memory/claims/review
POST /wiki/pages/apply
POST /wizard/system-profile/generate
POST /wizard/receiver-brief/generate
POST /wizard/startup-packet/generate
POST /wizard/handoff/export
GET  /memory/provenance/{id}
GET  /memory/contradictions
GET  /memory/open-questions

The most robust storage pattern is a hybrid one. Use an object store or immutable blob layer for raw uploads and transcripts; a relational store for events, claims, review states, and provenance metadata; a vector index for semantic lookup; and a file or Git-like source tree for approved wiki pages and exported packet artifacts. For smaller or local deployments, OpenClaw’s built-in memory engine is a useful proof point that a simple setup can combine per-agent SQLite, FTS5/BM25, vector search, and hybrid ranking without much infrastructure. For richer wiki behavior, OpenClaw’s memory-wiki plugin shows the companion pattern: a maintained knowledge vault with deterministic pages, structured claims, provenance, contradictions, dashboards, and machine-readable digests beside the active memory layer.

For LLMWikis, the right baseline recommendation is therefore file-first source of truth with database sidecars, not database-only memory. That matches the starter-bundle orientation, supports source control and review, and makes wizard outputs easy to diff, audit, and package. This is a design recommendation rather than a statement that LLMWikis currently implements it internally. It follows from the documented bundle structure and source-governed page model.

Privacy and security should be enforced at the write path, not bolted on after the fact. AIWikis agent rules explicitly prohibit adding secrets, credentials, private keys, raw customer data, regulated data, or private chat logs, and they require human approval before changing policy, security, privacy, legal, production, architecture, or sensitive content. OWASP’s official LLM guidance highlights indirect prompt injection from external sources, and its agentic-security materials identify memory and context poisoning as a live attack surface. NIST’s AI RMF and Privacy Framework remain the best high-level control frameworks for mapping governance, measurement, and privacy risk management into the lifecycle.

Concretely, that means the LLMWikis write path should perform PII and secret scanning, source trust labeling, prompt-injection screening, quarantine of suspicious memory writes, role-based approval gates, and artifact-level access scopes before any dreamed content becomes approved semantic memory. It also means that wizard exports should default to the minimum disclosure needed for their receiver. A startup packet for an internal engineer should not automatically expose the same episodic traces as a broader project brief.

For versioning and provenance, the AIWikis/LLMWikis materials are especially strong. AIWikis shows stable URLs, source references, retrieval times, content hashes, update histories, and file-level provenance; the imported file index exposes hashes for key starter-bundle records; and agent rules explicitly require preserving source attribution, keeping layers separate, checking manifests when exporting packet state, updating changelogs when recommendations change, and marking unresolved conflicts as open questions. LLMWikis dreaming should preserve all of that. Every promoted claim should carry source refs, evidence event IDs, reviewer identity, supersession links, and rollback targets.

On cost, the main trade-off is where to spend compute. Full-context designs pay continuously in token cost and latency. Offline-dreaming systems pay more at write time but much less at read time. On their respective evaluations, LightMem reports substantial reductions in token/API costs while improving accuracy, SimpleMem reports major token reductions relative to full-context baselines, and HippoRAG reports better performance than some iterative retrieval pipelines while being markedly cheaper and faster on its benchmark setup. Those exact numbers are benchmark-specific and should not be transplanted directly into budgeting models, but the directional lesson is stable: move consolidation off the hot path, and retrieve compact reviewed memory whenever possible.

Best practices, failure modes, monitoring, and governance

The highest-value LLMWikis best practices are mostly governance rules disguised as memory rules. Agents should read the README, INDEX, source map, trust model, and safety boundaries before editing; use the smallest useful page set; preserve uncertainty, open questions, and contradictions; avoid treating drafts or external references as approved policy; and stop for human approval on sensitive changes. These should not be documentation niceties. They should be enforced in the wizard and dreaming pipeline as runtime policy.

A second best practice is to keep three memory layers distinct: public or reviewed wiki memory, compact handoff state, and deep/archive memory. AIWikis explicitly says public pages, compact .uai handoff state, and source-side deep archive memory should remain in their own layers. That is exactly the right design for project memory too. Approved wiki pages should stay small and reviewable; handoff packets should stay portable; archival episodic traces should stay queryable but not automatically loaded into the agent.

The main failure modes are now well enough documented to plan around them. Research and official guidance point to: memory bloat, stale or contradictory memory, semantic drift, error propagation from bad memories, misaligned experience replay, prompt injection and memory poisoning, privacy over-retention, and evaluation regimes that reward surface recall while missing deeper constraint failures. Recent empirical work specifically shows that indiscriminate memory addition can degrade long-term performance, and that strategic deletion helps. LoCoMo and LoCoMo-Plus show that very long-term conversational memory remains challenging, especially when the task depends on latent user state, goals, or values rather than simple factual recall.

Because of that, the right monitoring stack should go beyond “memory hit rate.” At minimum, track:

• retrieval precision by memory type,
• answer grounding / citation coverage,
• contradiction count and contradiction age,
• open-question backlog and time-to-resolution,
• promotion acceptance rate,
• duplicate compression ratio,
• false memory rate / unsupported claim rate,
• token cost per successful wizard flow,
• p95 retrieval and dreaming latency,
• rollback frequency, and
• handoff packet completeness.

OpenClaw’s dreaming UI suggests a useful operational pattern: expose current enabled state, phase-level status, short-term counts, grounded counts, signal counts, promoted-today counts, and next scheduled run timing. LLMWikis wizards should expose analogous observability for project maintainers: how many episodic events were ingested, how many claims were proposed, how many were promoted, how many are blocked for missing provenance, and which wizard exports depend on stale reviewed pages.

A good governance model for LLMWikis dreaming should therefore include the following policy defaults, expressed here as a recommended synthesis of the sources rather than as a statement of existing implementation:

• No silent promotion into approved semantic pages.
• Every promotion requires provenance completeness.
• Conflicts become open questions, not hidden overwrites.
• Sensitive memory classes require scoped access and explicit approval.
• Every export is manifest-backed and rollbackable.
• Every page has an owner and review cadence.

Implementation templates and wizard flows

The following pipeline is the most practical concrete implementation for LLMWikis’ project memory and wizard model. It is a proposed template grounded in the LLMWikis starter-bundle surface, the AIWikis-governed wiki approach, and the official/research dreaming patterns already discussed.

def ingest_event(project_id, wizard_run_id, raw_item):
    norm = normalize(raw_item)
    security = classify_security(norm)
    if security.block_write:
        return quarantine(norm, reason=security.reason)

    event = write_event(
        project_id=project_id,
        wizard_run_id=wizard_run_id,
        memory_type="episodic",
        content=norm.summary,
        source_refs=norm.source_refs,
        trust_label="draft",
        tags=norm.tags,
    )

    route = infer_page_target(event)
    enqueue_for_dreaming(event_id=event.id, route_hint=route)
    return event


def dream_cycle(project_id):
    recent = load_recent_events(project_id)
    clusters = cluster_by_topic_entity_time(recent)
    candidates = []

    for cluster in clusters:
        candidate = summarize_cluster(cluster)
        candidate.score = weighted_score(
            relevance=candidate.relevance,
            frequency=candidate.frequency,
            query_diversity=candidate.query_diversity,
            recency=candidate.recency,
            recurrence=candidate.recurrence,
            conceptual_richness=candidate.conceptual_richness,
            source_trust=candidate.source_trust,
        )
        candidate.page_target = infer_page_target(candidate)
        candidate.requires_review = True
        candidates.append(candidate)

    candidates = dedupe_against_reviewed_pages(candidates)
    candidates = split_conflicts_to_open_questions(candidates)
    return write_review_queue(project_id, candidates)


def approve_candidate(candidate_id, reviewer):
    candidate = load_candidate(candidate_id)
    assert candidate.provenance_complete
    patch_page(candidate.page_target, candidate.patch)
    record_claim(candidate, status="approved", reviewer=reviewer)
    update_manifest_and_changelog(candidate.project_id)
    return export_if_requested(candidate.project_id)


def retrieve_for_wizard(project_id, query, flow_type):
    active = load_recent_events(project_id, days=2)
    semantic = retrieve_reviewed_claims(project_id, query)
    if flow_type == "handoff":
        episodic = retrieve_recent_decisions_and_open_questions(project_id, query)
    else:
        episodic = retrieve_supporting_events(project_id, query)

    return build_context_pack(active=active, semantic=semantic, episodic=episodic)

A useful default dreaming policy can be expressed compactly like this:

dreaming:
  enabled: true
  cadence: "nightly-or-manual-preview"
  signals:
    relevance: 0.30
    frequency: 0.20
    query_diversity: 0.15
    recency: 0.10
    recurrence: 0.10
    source_trust: 0.10
    conceptual_richness: 0.05
  promotion_rules:
    require_provenance: true
    require_human_review: true
    route_conflicts_to_open_questions: true
    never_write_sensitive_content_to_public_pages: true
  targets:
    architecture: SYSTEM_OVERVIEW
    decision: DECISION_LOG
    uncertainty: OPEN_QUESTIONS
    procedure: RUNBOOKS
    policy: GOVERNANCE

Those weights are a recommended adaptation of official dreaming signals rather than a claim that LLMWikis already uses them. OpenClaw’s documented deep-ranking features—relevance, frequency, query diversity, recency, consolidation, and conceptual richness—provide a credible starting point for such a policy.

A practical step-by-step wizard flow for LLMWikis should be:

1. Choose project and authority boundary. The wizard asks whether the output is for reviewed project memory, experimental memory, or handoff/export. It reminds the user that LLMWikis remains the handbook source for wiki patterns while UAIX remains canonical for UAI-1/public handoff claims.
2. Import raw sources. Sources are ingested into the raw layer with source refs, retrieval times, and content hashes. The wizard explicitly separates raw sources from curated wiki memory.
3. Auto-classify memory type. Each item is labeled as working, episodic, semantic-candidate, procedural-candidate, or handoff-only. This follows the memory-type distinctions used in current agent-memory literature.
4. Generate destination-aware proposals. The wizard produces candidate updates for SYSTEM_OVERVIEW, DECISION_LOG, OPEN_QUESTIONS, RUNBOOKS, and related files instead of writing to a generic store.
5. Run dream preview. The user sees what offline consolidation would promote, what stays episodic, what is compressed, and what is blocked for review, trust, or security reasons. This mirrors the explainable/reviewable dreaming model described in official docs.
6. Review conflicts and uncertainties. Contradictions are surfaced, not hidden; unresolved items go to OPEN_QUESTIONS. Sensitive or ambiguous items require explicit human approval.
7. Commit reviewed memory. Approved candidates update the reviewed wiki layer, the manifest, and the changelog, while preserving source attribution and supersession history.
8. Generate wizard exports. The wizard creates the system profile, receiver brief, startup packet, and optional handoff export from the reviewed layer plus scoped episodic support, with evidence ledgers and rollback info attached.

flowchart TD
    A[Select project] --> B[Set authority boundary<br/>reviewed wiki vs handoff export]
    B --> C[Import raw sources]
    C --> D[Normalize and classify<br/>working, episodic, semantic, procedural]
    D --> E[Generate page-targeted proposals]
    E --> F[Dream preview<br/>score, dedupe, summarize]
    F --> G{Approved?}
    G -- Yes --> H[Apply reviewed updates<br/>pages, manifest, changelog]
    G -- No --> I[Route to open questions<br/>or quarantine]
    H --> J[Generate system profile,<br/>receiver brief, startup packet]
    I --> J

If LLMWikis wants one especially high-leverage implementation detail, it should add a “why is this here?” panel to every dreamed candidate and every exported wizard artifact. That panel should show source refs, evidence event IDs, route target, trust label, review status, and rollback path. Doing so would operationalize the site’s trust-model goals better than any retrieval tweak.

Open questions and limitations

Some of the most relevant LLMWikis material was available in this crawl through AIWikis recovered summaries, file indexes, and source-provenance pages rather than through directly indexed full-text pages on LLMWikis itself. That means the tailoring here is strongest on architecture, file surfaces, source-governance boundaries, and wizard artifact roles, and somewhat weaker on page-by-page details of LLMWikis prose where only recovered structures were exposed publicly. The file-level provenance, hashes, and bundle paths do provide strong evidence for the intended architecture, but they do not substitute for every raw page body.

Many of the academic memory references used here are recent arXiv papers or recent surveys. They are appropriate primary sources for an engineering design review, but several are still pre-publication or early-cycle results. Their directional lessons are useful; their benchmark numbers should be treated as comparative evidence, not guaranteed production outcomes.

Because no specific runtime, database, or hosting stack was provided, the schemas, API contracts, and storage designs in this report are implementation templates, not vendor-locked prescriptions. The high-confidence part of the recommendation is the layering and governance model: raw vs episodic vs reviewed semantic vs wizard export, with dreaming as an offline compiler pass and review queue. That conclusion is well supported by the LLMWikis/AIWikis/UAIX materials and by the current primary-source memory literature.