Feature Catalogue¶

Product capability reference

This catalogue describes capabilities represented in the WhiteLotusAI repository¹. It separates evidence of implementation from proof of successful runtime behavior.

1. Purpose and interpretation¶

This document is the working catalogue of product capabilities represented in the current WhiteLotusAI source code. It is intended to help product, engineering, QA, security, and operations teams understand what is present and what remains to be demonstrated.

Four evidence states must be kept distinct:

2. Capability summary¶

3. Conversational AI and orchestration¶

The repository contains a chat service, agent workflow code, model-provider configuration, and plugin tool-dispatch functionality. The inspected implementation includes the following feature areas:

• Chat request processing and response generation.
• Streaming-related response paths.
• Agent nodes for intent handling and tool execution.
• Plugin discovery and dispatch.
• Permission checks and confirmation handling for write-capable operations.
• Plugin connectivity checks and tool-call metrics.

The diagram below is a conceptual view of the feature path, not a deployment diagram or guarantee that every branch currently passes acceptance tests.

flowchart TD
    A(["User Request"])
    B["Chat Processing"]
    C["Agent Workflow"]
    D["Intent and Context Handling"]
    E{"Need a Provider Tool?"}
    F["Model Response"]
    G["Tool Discovery and Dispatch"]
    H["Permission and Policy Checks"]
    I["Provider Operation"]
    J["Result Formatting"]
    K(["Response Delivery"])

    A --> B
    B --> C
    C --> D
    D --> E
    E -->|No| F
    E -->|Yes| G
    G --> H
    H --> I
    I --> J
    F --> K
    J --> K

    %% Pastel fills and colored outlines.
    classDef request fill:#E8F0FE,stroke:#4F83CC,stroke-width:1.5px,color:#23345B
    classDef orchestration fill:#EDE9FE,stroke:#7C3AED,stroke-width:1.5px,color:#3B267A
    classDef processing fill:#E0F7FA,stroke:#0891B2,stroke-width:1.5px,color:#164E63
    classDef authorization fill:#FFF2CC,stroke:#D97706,stroke-width:1.5px,color:#7C3E00
    classDef response fill:#DDF5E5,stroke:#25804B,stroke-width:1.5px,color:#16452B
    classDef decision fill:#FCE8E6,stroke:#C2410C,stroke-width:2px,color:#7F2718

    class A request
    class B,C,D orchestration
    class F,G,I processing
    class H authorization
    class J,K response
    class E decision

    %% Theme-independent connector styling.
    linkStyle default stroke:#9CA3AF,stroke-width:1.3px

What must be verified¶

• Intent classification and tool selection for clear, ambiguous, and multi-part requests.
• Whether streaming starts, continues, and terminates correctly under normal and error conditions.
• Provider timeouts, invalid credentials, unavailable dependencies, and malformed tool responses.
• Retry behavior and whether a failed operation can be executed more than once.
• Permission checks across all registered tools and dispatch paths.
• Whether monitoring and tool-call metrics capture success and failure accurately.

4. External integration catalogue¶

4.1 Registered plugins and frontend catalogue flags¶

The inspected chat-service startup code registers six plugin implementations:

4.2 Operation inventory¶

The lists below reflect tool definitions recorded during source inspection. They are an inventory of declared operations, not an endorsement that they should be available in the initial read-only release.

5. Read-only scope and permission policy¶

The initial product requirement is read-only access to the six integrations. However, the inspected source defines tools beyond read-only operations, so the presence of permission categories and confirmation flows must not be described as proof of strict read-only enforcement.

The plugin framework defines four operation categories:

The default policy described in the inspected source allows READ and UTILITY, requires confirmation for WRITE, and denies DESTRUCTIVE. The registry also checks permissions during dispatch and requires confirmation for write-capable and destructive tools. This is a confirmation/permission mechanism; it is not, by itself, a strict read-only policy.

Required controls before claiming read-only compliance¶

1. Define an explicit release policy that denies all write and destructive integration operations.
2. Enforce that policy in trusted backend dispatch code—not only in the frontend, tool descriptions, or model instructions.
3. Apply the policy consistently to every registered tool and every route or dispatch path.
4. Prove that each write-capable tool is denied even when a caller attempts to confirm the operation.
5. Test direct and alternate execution paths, including MCP-related paths where applicable.
6. Verify that read operations cannot bypass authorization or access another user's data.
7. Record automated and manual evidence in the Security and Testing documentation.

def is_allowed_in_read_only_release(operation_category: str) -> bool:
    """Conceptual rule; adapt it to the repository's trusted policy layer."""
    return operation_category == "READ"

The snippet illustrates the intended rule only. It does not represent a verified implementation or replace the repository's actual authorization and dispatch code. If a utility is required, allowlist it explicitly after review rather than automatically treating all utility tools as safe.

6. Identity, sessions, and user data¶

The repository contains authentication-related routes, profile operations, session-related processing, and database models or migrations supporting application state. The following behaviors need functional and security verification:

• Registration and login.
• Authentication token handling and refresh.
• Logout and session invalidation.
• Profile retrieval and updates.
• Password-change flows.
• Session creation, listing, switching, and deletion.
• Authorization boundaries for user-specific data.
• Failure handling when backing services are unavailable.

7. Knowledge base and retrieval¶

The repository includes a retrieval-augmented generation (RAG) service and document-processing functionality. The intended feature area includes document ingestion, retrieval, and interaction with stored knowledge.

Before publishing specific guarantees, verify the following:

• Supported document formats and file-size limits.
• Ingestion success, partial failure, and retry behavior.
• Retrieval relevance and grounding of generated answers.
• Document deletion, retention, and data lifecycle behavior.
• User-level access controls and tenant/data isolation.
• Behavior when the retrieval service or embedding provider is unavailable.
• Treatment of malformed, empty, duplicated, or unsupported documents.

Do not publish unsupported claims about retrieval accuracy, throughput, ingestion capacity, or supported file formats. Record tested limits and the environment used for each measurement.

8. Deployment and operations¶

The repository contains Docker Compose configurations for local and production use. The inspected production configuration also defines frontend delivery through Nginx and a Certbot renewal process.

Deployment documentation and release tests should establish:

• Exact services, ports, and service dependencies in each environment.
• Required environment variables and secret-management practices.
• Health-check behavior and startup ordering.
• Database and message-broker initialization and migrations.
• TLS certificate issuance, renewal, and HTTPS routing.
• Backup and restore procedures.
• Monitoring, alerting, and incident-response procedures.

A Compose file is evidence of intended configuration; it is not proof of a successful or secure production deployment.

9. Feature lifecycle and evidence standard¶

Use the following lifecycle statuses consistently. Assign status to an individual feature or operation instead of applying one label to an entire integration when operations have different evidence levels.

10. Acceptance and release checklist¶

Use this checklist when promoting a feature from Implemented to Verified. Mark items only when evidence exists.

• Expected user behavior and explicit exclusions are documented.
• Source implementation and configuration have been inspected.
• Authentication, authorization, and user-data boundaries have been tested.
• Read-only restrictions are enforced in trusted backend code.
• Write and destructive operations are denied in the read-only release.
• Denial remains effective when confirmation is supplied or alternate dispatch paths are used.
• Success, failure, timeout, malformed-response, and provider-unavailable scenarios are tested.
• Automated results and required manual test evidence are recorded.
• Known limitations and release dependencies are documented.
• Published statements match the tested behavior and actual release configuration.

11. Review and maintenance¶

Review this catalogue whenever plugin tools, authorization policies, API behavior, product scope, model-provider configuration, document processing, or deployment configuration changes.

For every update:

1. Inspect the relevant source and configuration.
2. Identify which statements changed and whether operation classifications changed.
3. Run the applicable unit, integration, security, and end-to-end tests.
4. Update the relevant integration, Security, Testing, and release documentation.
5. Change a feature to Verified only when its acceptance evidence is available.

Related documentation¶