Skip to content

The Knowledge Base, from source to answer

The mental model

Your website is not automatically the assistant’s memory.

The Knowledge Base is a curated library. You choose WordPress pages, add approved documents, synchronize them, and let the assistant retrieve small relevant passages when a visitor asks a question. That separation is useful: editing the website and publishing knowledge to the assistant are related, but they are not the same event.

Think of the system as a six-stop journey:

1ChooseSelect pages or upload files.
2PrepareClean page text and attach saved metadata.
3SyncSend approved material to the site’s vector store.
4IndexOpenAI prepares it for retrieval.
5RetrieveA relevant question searches for useful passages.
6AnswerThe assistant writes a response using the retrieved context.

The visitor does not browse the vector store and the assistant does not receive every document in every conversation. Retrieval looks for relevant pieces. This is why clear source writing, distinctive titles, and focused metadata usually outperform a huge collection of repetitive material.

There are two source paths. They end in the same site vector store, but their editorial life is different.

Choose a source by how the information is owned and maintained
SourceBest fitWhat happens when it changesCommon mistake
WordPress page or post Public website information already maintained by an editor: services, policies, locations, FAQs, product explanations. Its processed content and saved metadata receive a new hash. The source becomes Pending until the next sync. Selecting every page, including thin archives, campaign duplicates, legal boilerplate, or expired announcements.
Uploaded PDF, DOCX, PPTX, or TXT Approved material that does not belong as a public page: a sanitized manual, service handbook, or controlled reference document. Upload the replacement and remove the obsolete file deliberately. File indexing has its own processing state. Treating an uploaded file as a private vault. Its content is sent to OpenAI and may be used in visitor answers.

Use one authoritative source for each fact whenever possible. If three pages describe cancellation differently, retrieval can find any of them. Metadata can improve findability; it cannot decide which contradiction is legally or operationally correct.

What WordPress keeps and what OpenAI receives

Section titled “What WordPress keeps and what OpenAI receives”

SmartSite keeps the editorial controls in WordPress: selected page IDs, page metadata, local upload records, synchronization records, source hashes, and the vector-store identifier. During synchronization, the plugin sends processed source material to OpenAI.

The boundary between your WordPress site and the retrieval service
MaterialStored or controlled in WordPressSent to OpenAI for knowledge retrieval
Selected page/post Selection, current post content, metadata form, current/previous hash and sync state. Title, URL, processed content, Category, Summary, Topics, FAQs, Key Facts, and Related Pages in a structured JSON document.
Uploaded document A local upload plus its filename, type, status, and OpenAI identifiers. The file itself, uploaded for assistant retrieval and attached to the same vector store.
Exclude Content entries Saved as editor instructions for the selected page. Not sent as instructions. Matching text is removed from the processed page before the remaining content is uploaded.
Visitor question Handled through normal chat and analytics storage rules. Sent during a response so relevant stored knowledge can be searched.

Only put material in the Knowledge Base that is approved for this processing and appropriate to surface in a public chat. Selection is not an access policy. A sentence such as “only show this to partners” does not authenticate the visitor.

Selection is local intent; Sync is publication

Section titled “Selection is local intent; Sync is publication”

Ticking a page says, “include this in the next synchronization.” It does not instantly replace the remote copy. Saving metadata behaves similarly: the new version becomes Pending. Sync compares the current source hash with the last successful one and creates, updates, leaves alone, or removes remote page files as needed.

The hash covers processed content, title, saved metadata, and the content-processor version. A meaningful source edit can therefore become Pending even if you never opened the metadata panel. Conversely, a source marked Current means its present processed version matches the version last synchronized; it does not certify that the writing is accurate.

Uploaded files follow a separate route: each file is uploaded and attached to the vector store, then OpenAI indexes it asynchronously. A file still processing is present but not ready to trust in a live test.

What Basic and Advanced runtime do with knowledge

Section titled “What Basic and Advanced runtime do with knowledge”

The Knowledge Base is shared infrastructure; the runtime decides how it may be used.

  • In Basic runtime, the active Assistant can search the connected vector store while composing its response. If Agent Tools also exist, the model can decide whether it needs knowledge, a tool, or neither.
  • In Advanced Agents runtime, the Base Assistant and specialist agents operate under the published workflow. A specialist’s Knowledge Base setting determines whether that specialist receives knowledge-search capability. This lets an appointments agent use your policies while a tightly scoped escalation agent may operate without them.

Turning Advanced Agents off does not create a second copy of the library and does not erase it. The default Assistant returns to the Basic response path and uses the same synchronized site knowledge. Turning Advanced Agents on adds routing and specialist boundaries around that capability.

Before adding a page, imagine a new colleague answering from that page alone:

  1. Can they tell what the page is about from its title and opening paragraph?
  2. Is the important answer written explicitly, or only implied by layout and imagery?
  3. Are dates, locations, currencies, conditions, and exceptions unambiguous?
  4. Does another source say something different?
  5. Would it be acceptable for a public visitor to hear every included fact?

If the answer fails this reading test, improve the source first. A useful FAQ or Topic can bridge vocabulary—“returns window” versus “withdrawal period”—but it should not invent a clearer policy than the organization has actually approved.

  1. Curate. Select a small set of authoritative pages and approved files.
  2. Clarify. Improve weak source text and add metadata only where it helps a visitor’s wording reach the right source.
  3. Synchronize. Keep the tab open, review the item-level result, and resolve partial failures.
  4. Wait for readiness. Pages should be Current; uploaded files should be completed.
  5. Test fresh. Start a new chat and ask real questions in more than one natural phrasing.
  6. Inspect evidence. Use Chat History and Knowledge Gaps to see whether search ran and which sources were found.
  7. Maintain. When policy changes, edit the authoritative source, sync again, and remove obsolete copies.

The summary cards answer four different questions: how many pages have been selected, how many documents were uploaded, whether a vector store is connected, and whether synchronization work remains. Do not collapse these into one “green means perfect” judgment. A connected vector store can still contain stale content; a zero Pending count can still describe poor or contradictory sources.

How the Knowledge Base Works
Capture
Open Knowledge Base after a completed sync with summary cards, one synchronized page, and one completed file visible.
Show
Selected-page count, uploaded-file count, vector-store status, sync health, source states
Viewport
Desktop, 1440 × 900
Annotate
Use numbered callouts only for controls referenced in the procedure.
Redact
OpenAI keys, tokens, secrets, personal information, private URLs, IP addresses, and conversation text