public_documentation-catalogs

Catalogs in Evie’s Library are structured containers for organizing related documents, enabling granular access control and retrieval optimization through configurable metadata, chunking settings, and type-specific behaviors. They serve as the primary mechanism for segmenting business information (e.g., HR, product, or client-specific data) while tailoring AI Specialist interactions to context-specific needs.

Catalogs in Evie’s Library are structured containers for organizing related documents, enabling granular access control and retrieval optimization through configurable metadata, chunking settings, and type-specific behaviors. They serve as the primary mechanism for segmenting business information (e.g., HR, product, or client-specific data) while tailoring AI Specialist interactions to context-specific needs.

Core Features

Every catalog includes four foundational attributes: a name and description for identification, a type determining organizational logic, chunk size settings for document processing, and custom metadata fields (e.g., internal IDs). These features ensure documents are stored, retrieved, and accessed according to business requirements, with chunking settings directly influencing how AI Specialists parse and utilize the content.

Standard Catalogs

Standard catalogs function as general-purpose repositories where all documents are equally accessible to querying Specialists. Common use cases include:

• Public Information Catalogs: Centralizing company-wide public documents (e.g., press releases, marketing materials).
• HR Information Catalogs: Restricting access to internal policies or employee data.
• Product Information Catalogs: Isolating sales-related documentation for Specialist use in customer interactions. This segmentation allows businesses to enforce access rules and streamline Specialist behavior without manual oversight.

Specialised Catalogs

Specialised catalogs extend functionality by introducing tags and search vectors to filter retrievals dynamically. Unlike standard catalogs, they require tag specification during document ingestion (e.g., client_id, client_name) and use retrievers to limit searches to tagged subsets. For example, a Customer Support Specialist might only access documents tagged with the current client’s ID, preventing cross-client data leakage.

Practical Example: Customer Support

In a support scenario, a Client-Specific Catalog could expose tags like client_id and client_name. When a Specialist queries this catalog, it must provide the client’s context (via a retriever) to surface only relevant documents. This ensures confidential information remains isolated while enabling context-aware responses—critical for compliance and personalized service delivery.

License-Dependent Flexibility

Available catalog types vary by license tier, with advanced options (e.g., additional tag labels) requiring consultation. The system’s modularity allows businesses to start with standard catalogs and scale to specialised configurations as needs evolve, balancing simplicity with precision control over information flow.