> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.revvue.ai/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.revvue.ai/_mcp/server.

# Knowledge hub

When Jonna answers a guest — opening hours, allergen policies, parking, private dining, corporate events — the answer comes from the **knowledge hub**: a structured, versioned wiki that you (and Jonna itself) maintain per tenant. If it isn't in the hub, the agent doesn't know it. That makes the hub the highest-leverage thing to keep accurate, and everything in it is manageable through the [Knowledge hub API](/api-reference/knowledge-hub).

## How knowledge is organized

**Pages** are markdown documents with a `title`, a one-line `summary` (shown in listings and search results), and a `content` body. A page is identified by a slash-delimited `path` (like `food/allergens` or `service/opening-hours`) inside a `namespace`, and every successful write bumps a monotonic `version` — writes are idempotent, so re-sending the same page is safe.

**Scopes** decide who a page applies to. Every page lives in exactly one scope bucket:

* **Location** — knowledge specific to one venue: its opening hours, its floor plan, its parking situation.
* **Group** — knowledge shared across venues: brand-wide policies, menu philosophy, the tone guests should feel. Groups are created per tenant and linked to any set of locations (`jonnaWikiSetGroupLocations`).

When Jonna reads on behalf of a location, it walks the hierarchy — the location's own pages first, then every group that location belongs to — so venue-specific pages naturally override or extend brand-level ones.

**Sources** are registered references to external documents (a PDF menu, a supplier contract, a house-rules doc). A source stores a pointer — type, id, title, URI — not the document itself, and pages cite the sources they were written from via `sourceIds`. That keeps every claim in the wiki traceable to where it came from.

## How the agent reads it

You rarely need to reimplement retrieval — the same read paths the platform's agents use are exposed directly:

* `jonnaWikiIndex` — a tree-shaped overview of every visible page; the best first call when you don't know what's in the wiki.
* `jonnaWikiSearch` — hybrid semantic search (full-text + vector + trigram) over titles, summaries, and bodies, for natural-language lookups.
* `jonnaWikiGrep` — literal/regex matching when you know the exact wording.
* `jonnaWikiAsk` — ask one question, get one answer. This is the agent's own read path: it returns the answer plus an `outcome` (`answered`, `no_knowledge`, `conflict`, or `degraded`), so you can tell *why* an answer looks the way it does.

## Keeping it accurate

A typical integration loop:

#### Write and organize pages

`jonnaWikiWritePage` creates or updates a page at a `(scope, namespace, path)`; `jonnaWikiMovePage` renames, `jonnaWikiDeletePage` removes permanently. Use `jonnaWikiGroups` / `jonnaWikiUpsertGroup` to shape brand-level scopes and `jonnaWikiLocations` to see the venues the wiki knows about.

#### Register where knowledge came from

`jonnaWikiAddSource` registers an external document reference (idempotent per `refType` + `refId`); cite its id in the pages you write. `jonnaWikiMarkSourceProcessed` closes the loop once a source has been incorporated.

#### Verify what the agent would say

Query `jonnaWikiAsk` with real guest questions and check the `outcome` — a `no_knowledge` or `conflict` tells you exactly which page to write or fix next.

The full operation-by-operation reference lives in the [Knowledge hub API section](/api-reference/knowledge-hub).