---
title: "How Memory.Wiki keeps your docs, bundles, and hub fresh"
url: https://memory.wiki/RUMdz2fQ
updated: 2026-05-24T15:23:53.207Z
hub: https://memory.wiki/hub/raymindai
concept_count: 12
source: "mcp"
---
# How Memory.Wiki keeps your docs, bundles, and hub fresh

Every Memory.Wiki URL is built to be **what the AI reads when you paste it**. That promise breaks the moment your URL is showing stale content, so freshness isn't an afterthought, it's part of the deal.

This is the full picture: what's guaranteed up-to-date, what isn't, and when to click **Re-analyze**.

## TL;DR

| Layer | What | How fresh | Anything to click? |
| --- | --- | --- | --- |
| **Document body** | The markdown you wrote | Always, within ~60 seconds of save | Nothing. Just save. |
| **Bundle graph** | AI-generated themes / insights | Up-to-date until a member doc's content changes | "Re-analyze with AI" in the bundle header when stale |
| **Hub concept index** | Cross-doc "related concepts" map | Auto-extracted within seconds of each save, but 30-min cooldown per doc | "Re-analyze (N)" banner appears when stale |

Body markdown is always fresh. The AI-derived layers (bundle graph, hub concept index) sometimes need a nudge.

## Three layers, three different stories

### 1. Document body, always fresh

When you save a doc (autosave or explicit), the new markdown is in Postgres immediately. The next AI fetch sees it within ~60 seconds:

- `/raw/{id}` and `/d/{id}` always read straight from the database.
- The edge cache (`stale-while-revalidate=300`) keeps repeat requests cheap, but the moment your content changes any subsequent fetch revalidates in the background.
- Net effect: **your last save propagates to AI URLs within roughly a minute.** No action needed.

### 2. Bundle graph, Re-analyze when content drifts

A bundle's "AI graph" (themes, insights, the spatial layout of the canvas) is **generated once, then reused**. Specifically:

- The graph is computed by an LLM pass over the member docs at one moment in time.
- That moment is stamped on the bundle as `graph_generated_at`.
- Memory.Wiki compares this against the latest `embedding_updated_at` across the member docs (which only bumps when a doc's actual content hash changes).

If a member doc's content has changed since the graph was generated, the bundle is **stale**. You'll see:

- A subtle "Re-analyze with AI" refresh icon in the bundle header. Click it any time.
- The graph view itself indicates the stale state.

Why not auto-rebuild? Bundle graphs cost a real LLM call and the user is usually in the middle of editing. Auto-triggering wastes tokens and disrupts focus. **You decide when the analysis is worth re-running.**

### 3. Hub concept index, automatic plus manual top-up

The hub's `concept_index` (what AIs see as "the user's knowledge graph") is the most complex. Every doc you save fires this pipeline:

1. **Enqueue** an ontology refresh job (deduplicated at the database level, so bursts of saves don't pile up).
2. **Fast-path run** inside Vercel's `after()` closure. The LLM extraction usually finishes within a few seconds.
3. **Backstop**: if the serverless instance dies mid-flight, a cron worker picks up the pending row and retries.

So normal usage: concept changes appear in the hub URL **within seconds** of saving.

#### Two automatic guardrails that can make a doc look stale

1. **30-minute per-doc cooldown.** Back-to-back edits on the same doc don't re-run the LLM extractor. Without this, an active editing session would burn tokens on every keystroke.
2. **200-character minimum delta.** Trivial edits (a typo fix) don't trigger re-extraction.

These keep cost predictable, but they mean that within a heavy editing session your doc's concept attribution may lag the actual content for a while.

#### The Re-analyze banner

When the hub view opens, Memory.Wiki checks:

- `concepts_built_at` is the most recent successful ontology job's finish time
- `docs_touched_at` is the latest `embedding_updated_at` across your docs

If `docs_touched_at > concepts_built_at`, you see:

> Concepts out of date. N docs have changed since the last build.
> [Re-analyze (N)]

Clicking **Re-analyze**:

- **Only re-extracts the N docs that actually changed.** Unchanged docs are skipped entirely.
- **Caps at 50 docs per click.** If you have more stale docs, the extras stay queued and the cron worker processes them in the background over the next few minutes.
- **Bypasses the 30-minute cooldown.** That's the whole point of an explicit click.
- Fires asynchronously. The button label flips to "Re-analyzing..." while the queue drains, but you can keep working.

So a Re-analyze click is cheap: at most 50 short LLM calls for the docs that genuinely changed. Not "rebuild the whole hub from scratch."

## Doc-level Re-analyze

You can also force a single doc's concepts to refresh. Right-click any doc in the sidebar and choose **Re-analyze concepts**. Same machinery as the hub-wide button, scoped to one doc, bypasses the cooldown. Useful when:

- You're polishing a doc in tight cycles and want the hub's concept attribution to keep up.
- A doc's concept tags look obviously off and you want to force a re-extraction.

## When you DON'T need to click anything

- You edited a doc and shared its URL. The receiving AI will see your edits within ~60 seconds. Concept attribution catches up in seconds to minutes automatically.
- You haven't touched the hub layer (just reading existing docs). Nothing to refresh.
- You're an anonymous (non-signed-in) user. No concept index applies.

## When clicking Re-analyze is worth it

- You bulk-imported or edited multiple docs and want the hub's concept map to reflect the new shape **immediately**.
- The yellow banner appears and you're about to share your hub URL with an AI.
- You added a doc on a new topic and want it surfaced as "related" to existing docs right away.

## Why we don't auto-rebuild more aggressively

Two reasons:

1. **Cost discipline.** Concept extraction is a Haiku call per doc. Auto-rebuilding on every save would burn tokens during noisy editing sessions where the user doesn't care yet.
2. **Predictability.** When something changes in your hub, you're the one who chose for it to change. Implicit background rebuilds make "why does my AI see X?" much harder to debug.

The trade is: body markdown gets aggressive freshness guarantees (always-fresh, no click needed). AI-derived metadata gets fast-but-not-instant defaults with explicit override available.

---

*Last updated 2026-05-25. Part of [memory.wiki](https://memory.wiki) public documentation. See also [MWBench](/mwbench) for the open eval that proves these freshness layers actually deliver across Claude, OpenAI, and Gemini.*

## Facts

- Document body markdown propagates to AI URLs within roughly 60 seconds of save
- Bundle graph requires manual Re-analyze click when member doc content changes
- Hub concept index updates automatically within seconds but enforces 30-minute per-doc cooldown during editing
- Re-analyze button only re-extracts changed docs, capped at 50 per click
- Concept extraction uses LLM calls and is not auto-triggered to preserve token cost and editing focus


---

## Summary
Memory.Wiki maintains three layers of content freshness: document body markdown updates automatically within 60 seconds, bundle graphs require manual Re-analyze clicks when member docs change, and hub concept indices update automatically within seconds but include a 30-minute cooldown per doc to control LLM token costs during active editing sessions.

## Themes
- freshness as product promise
- layered consistency guarantees
- cost-driven automation trade-offs

## Key takeaways
- Document body markdown propagates to AI URLs within roughly 60 seconds of save with no user action required.
- Bundle graph must be manually refreshed via Re-analyze button when member doc content changes, as it is generated once then reused.
- Hub concept index auto-updates within seconds but enforces a 30-minute per-doc cooldown during active editing to control LLM token costs.
- Re-analyze button only re-extracts the N docs that actually changed, capped at 50 docs per click, bypassing the normal 30-minute cooldown.
- Concept extraction is not auto-triggered on every save to preserve token cost predictability and avoid disrupting user editing focus.

## Insights
- The system treats raw content freshness (60 seconds) differently from derived metadata freshness (seconds to minutes plus manual override), creating a tiered trust model for AI consumers.
- Cooldowns and minimum deltas during editing sessions are explicitly cost-control mechanisms, not technical limitations, making the staleness predictable and debuggable.
- Re-analyze is designed to be cheap (only changed docs, 50 doc cap) rather than comprehensive, which shapes when users will actually click it.

## Open questions / gaps
- What happens if a user's hub has more than 200 stale docs and they hit Re-analyze, given the 50 doc per-click cap and background cron processing?

## Concepts in this document
- **memory.wiki** _(entity)_
  The primary product platform being developed and documented.
- **Knowledge Management** _(tag)_
  Overarching domain of personal and organizational information systems
- **mdfy** _(entity)_
  A memory infrastructure layer that provides a URL-based knowledge hub for AI tools.
- **Claude** _(entity)_
  Specified AI tool for prototyping and validation before moving to high-fidelity design.
- **MCP server** _(concept)_
  A standard protocol allowing diverse AI tools to query and interact with the memory.wiki hub.
- **Hybrid Retrieval** _(concept)_
  Technical approach combining chunked indexing with semantic search for precise question-targeted recall.
- **URL as API** _(concept)_
  Core architectural principle where every Memory.Wiki URL serves as a fetchable API endpoint for AI consumption
- **ChatGPT** _(entity)_
  One of the AI platforms currently suffering from isolated memory silos.
- **Cursor** _(entity)_
  One of the AI platforms currently suffering from isolated memory silos.
- **AI memory** _(tag)_
  Conceptual topic describing how memory is used by AI agents.
- **Cross-AI Compatibility** _(concept)_
  The ability for Memory.Wiki URLs to work across any AI tool without vendor lock-in
- **Markdown** _(tag)_
  Lightweight markup format used as the universal content format across Memory.Wiki.

## Concept relations (within this doc's concepts)
- **Markdown** transport format **URL as API**
- **MCP server** integrates with **mdfy**
- **mdfy** provides platform **Knowledge Management**
- **AI memory** disrupts category **Knowledge Management**
- **mdfy** evolved into **memory.wiki**
- **mdfy** rebranded to **memory.wiki**
- **memory.wiki** targets platform **Claude**
- **memory.wiki** targets platform **ChatGPT**
- **URL as API** content format **Markdown**
- **memory.wiki** targets platform **Cursor**
- **URL as API** integrates with **ChatGPT**
- **memory.wiki** exposes through **MCP server**
- **URL as API** integrates with **Claude**
- **Cross-AI Compatibility** enables through **URL as API**
- **memory.wiki** implements **URL as API**
- **Hybrid Retrieval** serves domain **Knowledge Management**
- **URL as API** implements pattern **Cross-AI Compatibility**
- **URL as API** enables compatibility **Cross-AI Compatibility**
- **Cursor** saves decisions to **memory.wiki**
- **Claude** loads context from **memory.wiki**

_Hub canonical:_ https://memory.wiki/hub/raymindai
_Concept digest:_ https://memory.wiki/raw/hub/raymindai?digest=1&compact=1