Knowledge

Knowledge gives Convosite the information it can use when answering a visitor.

Unlike Blocks and Endpoints, Knowledge is content, not developer configuration. It is managed in the Convosite console and is made available to conversations automatically.

A typical site might contain Knowledge such as:

Knowledge
├── Product information
│   ├── Blue Widget
│   ├── Red Widget
│   └── Product warranty
├── Delivery and returns
│   ├── Delivery
│   └── Returns
└── Company information
    ├── About us
    └── Contact details

Each Knowledge collection contains one or more Knowledge Items. An item has a title, content, and can have Media attached to it.

Knowledge collections

A Knowledge collection groups related information together. Each collection has:

• a name
• an optional description
• an ordered set of Knowledge Items

Use collections to keep related information together. For example, product information and delivery information can live in separate collections without changing how developers build the frontend.

Knowledge Items

A Knowledge Item is an individual piece of information inside a collection.

Each item contains:

• a title
• rich text content
• an optional set of attached Media

Keep each item focused on one useful subject. Smaller, clearly named items make it easier for Convosite to retrieve the information that is relevant to the current conversation.

TIP

Prefer an item named Returns policy containing the returns policy over one very large item containing every company policy.

How Knowledge is used

When a visitor sends a message, Convosite can retrieve Knowledge relevant to that message and provide it to the conversational runtime.

For example, if your Knowledge contains an item titled Blue Widget and the visitor asks:

Tell me about the blue widget.

Convosite can use that item when generating the response.

Developers do not need to fetch Knowledge manually or send it with each message.

Visitor message
      ↓
Relevant Knowledge
      ↓
Convosite conversation
      ↓
Selected Block + structured content
      ↓
Your UI

Knowledge and Blocks

Knowledge supplies information. Blocks define how a response can be presented.

These are deliberately separate concerns.

For example, Knowledge might describe a product and include a product image, while a Block defines fields such as:

{
  "key": "product",
  "name": "Product",
  "props": [
    {
      "key": "name",
      "label": "Name",
      "type": "text",
      "required": true
    },
    {
      "key": "description",
      "label": "Description",
      "type": "richtext",
      "required": true
    },
    {
      "key": "image",
      "label": "Image",
      "type": "media",
      "required": true
    }
  ]
}

Convosite can use the retrieved product information to populate the Block. If relevant Media is attached to the Knowledge Item, a compatible media or medias field can use that asset.

Your application remains responsible for rendering the resulting Block.

What developers manage

Knowledge itself is managed in the Convosite console. It is not part of the local CLI project.

Concern	Managed by
Blocks	Developer / CLI
Endpoints	Developer / CLI
Knowledge	Convosite console
Knowledge Items	Convosite console
Media	Convosite console
Variables	Convosite console

This means content teams can update the information available to conversations without requiring a code deployment.

Knowledge is not a public content API

@convosite/client does not expose methods for listing or querying Knowledge directly.

Knowledge is an internal source of context for conversations. If your application needs a conventional public content API for some other purpose, build that separately rather than treating Knowledge as one.

Updating Knowledge

When Knowledge Items are saved, Convosite updates the searchable representation used by the conversational runtime. Deleted items are removed as well.

This process is handled by the platform. Developers do not need to trigger indexing from the client.

Next steps

• Writing Knowledge Items
• Knowledge Media
• Blocks