Operator knowledge base module — JetSetGo MCP reference

The knowledge module is the delivery and write-back path for the operator-curated knowledge base: everything an operator wants the AI assistant to know about their business that is not live platform data. That covers tone of voice, business story, fleet character, seasons, target markets, competitors, policy and standard-operating-procedure documents, FAQs, and guardrails (explicit never-say / never-do rules). It works in two directions: retrieval, where the assistant searches what the operator curated; and propose-and-approve write-back, where the assistant can record a learned fact only into a holding queue a human must approve before it has any effect.

What the operator uses it for

Curating the standing narrative of their business and keeping it trustworthy. The operator writes or edits entries per category, uploads policy documents whose extracted text becomes searchable, sets self-expiry dates on high-churn facts, and archives anything stale. When the assistant learns something new in conversation — a fact the operator never entered — it lands as a proposal in a review queue; the operator approves, rejects, or ignores it. Nothing the assistant proposes can shape an answer until the operator flips it active.

Where it sits

This module complements the live-data modules rather than duplicating them. Bookings, availability, and pricing come from operational modules such as resources (a resource is a bookable product) and tickets; the knowledge base carries the qualitative layer those systems cannot express. When a knowledge entry conflicts with live platform data, live data wins by design — a fleet note claiming a larger capacity loses to the actual configured resource. Downstream consumers are the assistant runtime itself (per-turn injection of the standing block plus on-demand retrieval) and the email template studio, which shares the same brand voice definition so chat and email speak identically.

Key concepts

Standing block — a small, fixed digest assembled server-side each turn: the single company overview, all active guardrails, brand identity and voice, and a compact index of what exists. Everything else is retrieved on demand.
Category — one of a fixed key list (overview, our_business, fleet, seasons, markets, competitors, local_knowledge, policies, faqs, guardrails). Anything outside the list is rejected at validation.
Entry status — the safety spine: active (live), proposed (awaiting human approval, invisible to retrieval), archived (soft-deleted, recoverable), rejected (declined proposal).
Proposal — an assistant-authored entry written directly to proposed. Inert by status until a person approves it; it also self-expires after thirty days.
Placeholder — a flag marking seeded or unverified content so the assistant hedges when citing it.
Valid-until expiry — an optional date after which an entry drops out of the digest and search automatically.
Document — an uploaded file (PDF/docx/txt) with honest text extraction, folded under its parent entry's id so search hits resolve through the entry.

Tools

Tool	Class	Purpose
`knowledge_digest`	Read	Fetch the assembled standing block (primarily consumed deterministically by the assistant runtime).
`knowledge_search`	Read	Full-text search returning stubs (id, title, category, snippet); empty query lists a category.
`knowledge_get`	Read	Fetch one full entry body, including extracted document text when linked.
`knowledge_save_entry`	Guarded write	Create or update an entry at the operator's request; preview then confirm.
`knowledge_archive_entry`	Guarded write	Archive (soft-delete) or restore an entry; preview then confirm.
`knowledge_propose`	Provisional write	Record an assistant-learned fact directly as an inert proposed entry — the platform's single documented exception to preview-then-confirm.

Rules worth knowing

Delete is immediate: archived, expired, and proposed rows are excluded from the digest and search at the query level, and fetching a deleted or lapsed id returns not-found — a removed fact is never quoted afterwards.
Proposed entries cannot influence any answer until a human approves them in the review queue. The proposal itself carries no approval token and no permission; worst-case abuse is bounded queue spam, capped per turn and self-expiring in thirty days.
The fixed category list and the single-overview rule (one non-archived overview entry) are enforced server-side on every write path.
Search returns stubs only; full bodies come from knowledge_get. Document hits carry their parent entry's id, so both content kinds resolve through one id space.
Archiving is destructive but reversible via restore; only active entries can be archived and only archived ones restored — proposals are handled exclusively in the review queue.
The standing block stays inactive until at least one piece of operator-confirmed content exists; a seeded-but-never-curated tenant injects nothing.
Knowledge text can never escalate capability: it is plain read-tool output and cannot widen tool scope or alter permissions.

Tenantpermissions — governs who may administer the tenant, including curation rights over this content.
Settings — supplies the business identity facts the knowledge base builds on.
Resources — live bookable-product data that takes precedence over knowledge entries on conflict.