System Requirements Document for blenai-conversation-intelligence

1. Introduction

blenai-conversation-intelligence is the BlenAI platform: a multi-tenant, API-first conversation intelligence service. It ingests recorded sales and customer conversations, transcribes them in multiple languages, and produces structured analysis — summaries, customer intent, buyer requirements and budget, objections, buying signals, lead scores, and automated follow-up recommendations — all returned as structured JSON through secure, authenticated REST APIs documented with Swagger/OpenAPI.

The product is delivered as a Python/FastAPI backend with a modular AI engine that integrates OpenAI and other LLM providers, persists tenant-scoped configuration and conversation data in PostgreSQL, stores audio recordings in Amazon S3, and is containerized with Docker and deployed on AWS behind HTTPS. A configurable knowledge and intelligence engine supplies industry-specific knowledge, business rules, prompt management, and knowledge retrieval, and is designed to accept future AI model integrations and additional AI intelligence modules.

The audience is threefold: platform administrators who configure tenants, prompts, business rules, knowledge bases, and monitor API usage; AI engineers and integrators who consume the REST APIs and extend the AI engine; and sales/revenue analysts who upload recorded conversations and act on the resulting lead intelligence.

2. System Overview

blenai-conversation-intelligence is delivered as a headless, API-first platform. There is no custom end-user web UI in the current scope: all product behavior is exposed through secure REST APIs, and the human-facing interaction surface is the API documentation and the authenticated API itself. The platform is multi-tenant: every tenant's configuration, knowledge, prompts, business rules, conversations, and analysis results are isolated from other tenants.

Current delivery comprises:

• BlenAI Core Platform — Python/FastAPI backend, modular AI engine architecture, OpenAI and other LLM provider integration, PostgreSQL persistence, secure authenticated REST APIs, multi-tenant architecture, configurable prompts/business rules/knowledge bases, structured JSON responses, and API usage tracking and logging.
• AI Conversation Intelligence — upload and processing of recorded conversations, multilingual speech-to-text transcription, summarization, customer intent identification, buyer requirements and budget extraction, objection and buying-signal detection, lead scoring, automated follow-up recommendations, and structured conversation analysis exposed through APIs.
• Knowledge and Intelligence Engine — configurable industry-specific knowledge, business rules and prompt management, knowledge retrieval, support for future AI model integrations, and an extensible architecture for additional AI intelligence modules.
• AWS Hosting and Deployment — Docker containerization, AWS deployment, PostgreSQL integration, Amazon S3 audio storage, HTTPS and secure API access, Swagger/OpenAPI documentation, and automated testing and deployment documentation.

Actors. The active human personas are the Platform Administrator, the AI Engineer / Integrator, and the Sales / Revenue Analyst. Non-human actors include the LLM providers (OpenAI and others) reached through the LiteLLM gateway, the speech-to-text transcription service, Amazon S3, and the PostgreSQL database.

Provisioned infrastructure. The runnable service inventory is: a shared FastAPI backend process hosting all application APIs and domain modules; a database service (MariaDB) for application-owned persistent data; a litellm gateway service through which the backend makes model-provider calls; and a postgres service supporting LiteLLM, separate from application-owned storage. The backend reuses its single process and port for all feature APIs.

Narrow exclusions. No custom end-user web application, no real-time/live call capture, no outbound CRM or email delivery of follow-ups (recommendations are produced as structured output only), and no account-management features beyond the identity establishment and verification needed to reach protected tenant-scoped work.

Removed from scope

• None.

2a. Product Interpretation and Delivery Boundary

blenai-conversation-intelligence is a backend intelligence service, not a consumer application. Its value is delivered to integrators and analysts through authenticated HTTPS REST endpoints that accept audio and configuration and return structured JSON analysis. The Swagger/OpenAPI documentation is the discoverable contract for that surface.

Access is application-owned. Because tenant-scoped configuration, conversation history, and analysis results must remain bound to the correct tenant and be resumable by the correct human, the platform establishes identity on first use (self-service enrollment or provisioned account) and verifies returning users before granting access to protected tenant-scoped work. Establishing that identity is an anonymous entry boundary; all tenant-scoped configuration, upload, and analysis retrieval remain protected until identity is established and tenant context is resolved.

Provider responsibilities stay with their owners: LLM inference is performed by OpenAI and other providers via the LiteLLM gateway; speech-to-text transcription is performed by the configured transcription service; audio object storage is owned by Amazon S3. The platform orchestrates these and owns the structured analysis, tenant configuration, usage tracking, and logging.

Future-facing boundaries — additional AI model integrations and additional AI intelligence modules — are architectural extension points, not current features.

2c. Page Content and Component Coverage

The current delivery is headless and API-first; the human-facing surfaces are the identity entry boundary, the authenticated API surface with its Swagger/OpenAPI documentation, and the tenant configuration and analysis resources exposed through it. Coverage below describes each surface's information, actions, entities, and states without adding product scope.

Account Access

• Information/state: enrollment form (organization/tenant name, administrator identity, credentials); returning verification form (identity + credential); post-verification tenant context.
• Primary actions: self-service enroll or accept a provisioned account; verify returning identity; establish tenant context.
• Supporting actions: recover from failed verification; request re-entry after session expiry.
• Domain entities: Tenant, User identity, Tenant membership.
• States: loading (submission in progress); empty (first use, no account yet); success (identity established, tenant context resolved, access to protected APIs granted); error (invalid credentials, duplicate enrollment, expired session) with recovery by re-verification.

API Documentation (Swagger/OpenAPI)

• Information/state: OpenAPI specification of all endpoints, schemas, authentication requirements, and structured JSON response shapes.
• Primary actions: authenticate to the documented API; discover endpoints for upload, analysis retrieval, configuration, and usage.
• Supporting actions: inspect request/response schemas; obtain authenticated API credentials.
• Domain entities: API credential, endpoint, schema.
• States: loading (spec fetch); success (interactive documentation rendered); error (unauthenticated access to protected operations) with recovery by authenticating.

Conversation Intake and Analysis API

• Information/state: uploaded audio reference (S3 object), processing status, transcription, and the full structured analysis record (summary, intent, requirements, budget, objections, buying signals, lead score, follow-up recommendations).
• Primary actions: upload a recorded conversation; request processing; retrieve structured analysis as JSON.
• Supporting actions: poll or query processing status; re-request analysis retrieval.
• Domain entities: Conversation, Audio recording, Transcript, Analysis result, Lead score, Follow-up recommendation.
• States: loading (upload/processing in progress); empty (no conversations yet for tenant); success (structured JSON analysis returned); error (unsupported audio, transcription failure, provider failure, unauthorized tenant access) with recovery by re-submission or retry.

Tenant Configuration API (Prompts, Business Rules, Knowledge Bases)

• Information/state: tenant-scoped prompts, business rules, industry-specific knowledge bases, and retrieval configuration.
• Primary actions: create/update prompts, business rules, and knowledge base entries; configure industry knowledge; invoke knowledge retrieval.
• Supporting actions: list and inspect current configuration; validate configuration.
• Domain entities: Prompt, Business rule, Knowledge base, Knowledge entry, Industry profile.
• States: loading; empty (no configuration yet); success (configuration saved and effective); error (validation failure, unauthorized tenant access) with recovery by correction and resubmission.

API Usage and Logging

• Information/state: per-tenant API usage records and logs of API activity and model-provider calls.
• Primary actions: query usage and logs for the tenant.
• Supporting actions: filter by time range and endpoint.
• Domain entities: Usage record, Log entry.
• States: loading; empty (no usage recorded yet); success (usage/log records returned); error (unauthorized access) with recovery by re-authentication.

3. Functional Requirements

FR-1 — FastAPI backend with modular AI engine. As a Platform Administrator, I should have the platform run on a Python/FastAPI backend whose AI engine is modular, so that intelligence capabilities are organized as discrete, replaceable modules. (explicit) Lifecycle: administrator relies on the deployed backend; modules are invoked per request; observable result is that each intelligence capability executes as its own module; failure in one module surfaces as a structured error without corrupting others; continuation is retry of the affected request.

FR-2 — LLM provider integration. As an AI Engineer / Integrator, I should have the platform integrate with OpenAI and other LLM providers, so that analysis can use the appropriate model per task. (explicit) Lifecycle: provider calls are routed through the LiteLLM gateway; observable result is model-backed analysis returned; provider failure returns a structured error and the request can be retried.

FR-3 — PostgreSQL database. As a Platform Administrator, I should have application data persisted in PostgreSQL, so that tenant configuration and conversation data are durable. (explicit) Lifecycle: writes on configuration and analysis; observable result is durable retrieval on subsequent requests; failure returns a structured error and the operation can be retried.

FR-4 — Secure authenticated REST APIs. As an AI Engineer / Integrator, I should access REST APIs that require authentication, so that only authorized callers reach tenant data. (explicit) Lifecycle: caller presents authenticated API credentials; unauthenticated requests are rejected; authenticated requests proceed; failure returns an authentication error with recovery by supplying valid credentials.

FR-5 — Multi-tenant architecture. As a Platform Administrator, I should have every tenant's configuration, knowledge, conversations, and analysis isolated, so that tenants never see each other's data. (explicit) Lifecycle: each request carries tenant context; observable result is that responses contain only the caller's tenant data; cross-tenant access attempts are rejected with a structured error.

FR-6 — Configurable prompts, business rules, and knowledge bases. As a Platform Administrator, I should configure prompts, business rules, and knowledge bases per tenant, so that analysis reflects each tenant's business. (explicit) Lifecycle: administrator submits configuration; it is validated and persisted; observable result is that subsequent analysis uses the updated configuration; invalid configuration returns a validation error with recovery by correction.

FR-7 — Structured JSON responses. As an AI Engineer / Integrator, I should receive all API responses as structured JSON, so that integrations can parse results reliably. (explicit) Lifecycle: every response is JSON with a defined schema; errors are also structured JSON; malformed requests return structured validation errors.

FR-8 — API usage tracking and logging. As a Platform Administrator, I should have API usage tracked and logged, so that consumption is observable. (explicit) Lifecycle: each API call and model-provider call is recorded; observable result is queryable usage and log records; logging failure does not block the primary response but is surfaced.

FR-9 — Upload and process recorded conversations. As a Sales / Revenue Analyst, I should upload a recorded conversation and have it processed, so that I obtain analysis without manual review. (explicit) Lifecycle: analyst uploads audio; it is stored in S3; processing is triggered; observable result is a processed conversation with analysis; unsupported or failed audio returns a structured error with recovery by re-upload.

FR-10 — Multilingual speech-to-text transcription. As a Sales / Revenue Analyst, I should have recordings transcribed in multiple languages, so that non-English conversations are analyzed. (explicit) Lifecycle: processing invokes transcription; observable result is a transcript in the source language; transcription failure returns a structured error and can be retried.

FR-11 — Conversation summarization. As a Sales / Revenue Analyst, I should receive a summary of each conversation, so that I grasp it quickly. (explicit) Observable result is a summary field in the structured analysis.

FR-12 — Customer intent identification. As a Sales / Revenue Analyst, I should see the identified customer intent, so that I understand what the buyer wants. (explicit) Observable result is an intent field in the structured analysis.

FR-13 — Buyer requirements and budget extraction. As a Sales / Revenue Analyst, I should see extracted buyer requirements and budget, so that I can qualify the opportunity. (explicit) Observable result is requirements and budget fields in the structured analysis.

FR-14 — Objection and buying-signal detection. As a Sales / Revenue Analyst, I should see detected objections and buying signals, so that I can address concerns and pursue momentum. (explicit) Observable result is objections and buying-signal fields in the structured analysis.

FR-15 — Lead scoring. As a Sales / Revenue Analyst, I should receive a lead score for each conversation, so that I can prioritize. (explicit) Observable result is a lead score field in the structured analysis.

FR-16 — Automated follow-up recommendations. As a Sales / Revenue Analyst, I should receive automated follow-up recommendations, so that I have a clear next step. (explicit) Observable result is a follow-up recommendation field in the structured analysis.

FR-17 — Structured conversation analysis through APIs. As an AI Engineer / Integrator, I should retrieve the full structured conversation analysis through APIs, so that I can integrate it into downstream systems. (explicit) Observable result is a JSON analysis document containing all analysis fields; retrieval failure returns a structured error with recovery by retry.

FR-18 — Configurable industry-specific knowledge. As a Platform Administrator, I should configure industry-specific knowledge, so that analysis is grounded in the tenant's domain. (explicit) Observable result is that analysis uses the configured industry knowledge; invalid knowledge returns a validation error.

FR-19 — Business rules and prompt management. As a Platform Administrator, I should manage business rules and prompts, so that analysis behavior is governed. (explicit) Observable result is that updated rules and prompts take effect on subsequent analysis.

FR-20 — Knowledge retrieval capabilities. As an AI Engineer / Integrator, I should invoke knowledge retrieval, so that relevant knowledge is surfaced for analysis. (explicit) Observable result is retrieved knowledge returned as structured JSON; retrieval failure returns a structured error with recovery by retry.

FR-21 — Support for future AI model integrations. As an AI Engineer / Integrator, I should have an architecture that accepts future AI model integrations, so that new models can be added without redesign. (explicit) Observable result is that model providers are pluggable through the modular engine and gateway.

FR-22 — Extensible architecture for additional AI intelligence modules. As an AI Engineer / Integrator, I should have an extensible architecture for additional intelligence modules, so that new analysis capabilities can be added. (explicit) Observable result is that new modules can be registered without altering existing modules.

FR-23 — Docker containerization. As a Platform Administrator, I should have the platform containerized with Docker, so that it deploys consistently. (explicit) Observable result is reproducible container builds.

FR-24 — AWS deployment. As a Platform Administrator, I should have the platform deployed on AWS, so that it runs in the target environment. (explicit) Observable result is a running deployment on AWS.

FR-25 — PostgreSQL database integration. As a Platform Administrator, I should have PostgreSQL integrated into the deployment, so that persistence is available in production. (explicit) Observable result is a connected PostgreSQL instance serving application data.

FR-26 — Amazon S3 for audio storage. As a Sales / Revenue Analyst, I should have uploaded audio stored in Amazon S3, so that recordings are durably retained. (explicit) Observable result is the audio object stored in S3 and referenced by the conversation record; storage failure returns a structured error with recovery by re-upload.

FR-27 — HTTPS and secure API access. As an AI Engineer / Integrator, I should access APIs over HTTPS, so that traffic is encrypted. (explicit) Observable result is that all API access is served over HTTPS.

FR-28 — Swagger/OpenAPI documentation. As an AI Engineer / Integrator, I should have API documentation via Swagger/OpenAPI, so that I can integrate correctly. (explicit) Observable result is an interactive OpenAPI specification covering all endpoints and schemas.

FR-29 — Automated testing and deployment documentation. As a Platform Administrator, I should have automated tests and deployment documentation, so that changes are verified and deployments repeatable. (explicit) Observable result is a test suite and deployment documentation.

FR-30 — Identity establishment and returning verification. As a Platform Administrator, I should establish identity on first use (self-service enrollment or provisioned account) and verify on return, so that protected tenant-scoped work is bound to the correct tenant and user. (required_inference) Lifecycle: anonymous entry at the Account Access boundary; enrollment or provisioning creates identity and tenant membership; returning verification grants access; invalid credentials return an error with recovery by re-verification; session expiry requires re-verification.

FR-31 — Tenant context resolution. As a Platform Administrator, I should have tenant context established after verification, so that all tenant-scoped configuration and conversation data are correctly scoped. (required_inference) Observable result is that every protected request is scoped to the resolved tenant; missing or mismatched tenant context is rejected with a structured error.

FR-32 — Authenticated API credentials over HTTPS. As an AI Engineer / Integrator, I should obtain authenticated API credentials for secure REST access over HTTPS, so that programmatic integrations are authorized. (required_inference) Observable result is a credential usable on HTTPS requests; invalid or expired credentials return an authentication error with recovery by re-issuance.

4. User Personas

Platform Administrator

The Platform Administrator owns the multi-tenant platform's configuration and observability. Their product context is the tenant-scoped configuration surface and the usage/logging surface. Their primary goal is that every tenant operates with correct prompts, business rules, industry knowledge, and knowledge bases, and that API usage is observable. Distinct responsibilities: establishing and verifying identity and tenant context; managing tenants; configuring prompts, business rules, and industry-specific knowledge bases; monitoring API usage tracking and logging; ensuring secure authenticated API access and HTTPS. Relevant inputs/decisions: tenant definitions, prompt and rule content, industry knowledge, and usage thresholds. Interactions: with the AI Engineer / Integrator (whose integrations depend on configuration) and with the Sales / Revenue Analyst (whose analysis quality depends on configuration). Observable success: tenants operate with correct configuration and usage is observable.

AI Engineer / Integrator

The AI Engineer / Integrator builds against the platform's APIs. Their product context is the Swagger/OpenAPI documentation and the authenticated REST API. Their primary goal is reliable, structured JSON results from conversation analysis and knowledge retrieval. Distinct responsibilities: obtaining authenticated API credentials; submitting recorded conversations; retrieving structured conversation analysis; invoking knowledge retrieval; extending the modular AI engine with additional intelligence modules and future model integrations. Relevant inputs/decisions: endpoint selection, request schemas, and model/provider choices. Interactions: with the Platform Administrator (configuration and credentials) and, indirectly, with the Sales / Revenue Analyst (whose analysis is delivered through their integrations). Observable success: integrations return reliable structured results.

Sales / Revenue Analyst

The Sales / Revenue Analyst is the consumer of conversation intelligence. Their product context is the conversation intake and analysis surface. Their primary goal is actionable lead intelligence and a clear next step from each recorded conversation. Distinct responsibilities: uploading recorded conversations; reviewing transcription, summary, customer intent, buyer requirements and budget, objections, buying signals, lead score, and follow-up recommendations. Relevant inputs/decisions: which recordings to submit and how to act on the resulting recommendations. Interactions: with the AI Engineer / Integrator (who may deliver the analysis through integrations) and with the Platform Administrator (whose configuration shapes the analysis). Observable success: each conversation yields actionable lead intelligence and a clear next step.

5. Core User Flows

Flow A — Platform Administrator establishes identity and tenant context

1. The Platform Administrator reaches the Account Access boundary anonymously.
2. They self-enroll (organization/tenant name, administrator identity, credentials) or accept a provisioned account.
3. The platform creates the identity and tenant membership and resolves tenant context.
4. On return, the administrator verifies identity; invalid credentials return an error and they re-verify.
5. On success, tenant context is established and protected tenant-scoped work is available.

Flow B — Platform Administrator configures prompts, business rules, and knowledge

1. From the authenticated configuration surface, the administrator selects the tenant.
2. They create or update prompts, business rules, and industry-specific knowledge base entries.
3. The platform validates and persists the configuration; invalid configuration returns a validation error and they correct and resubmit.
4. On success, subsequent analysis uses the updated configuration.

Flow C — Platform Administrator monitors API usage and logs

1. From the authenticated usage surface, the administrator queries usage and logs for the tenant.
2. The platform returns usage records and log entries as structured JSON; an empty result indicates no usage yet.
3. Unauthorized access returns an error and they re-authenticate.

Flow D — AI Engineer / Integrator obtains credentials and integrates

1. The AI Engineer / Integrator authenticates and obtains API credentials over HTTPS.
2. They consult the Swagger/OpenAPI documentation to select endpoints and schemas.
3. They submit requests; unauthenticated or invalid-credential requests return structured authentication errors and they re-issue credentials.
4. On success, they receive structured JSON responses.

Flow E — Sales / Revenue Analyst uploads and reviews a conversation

1. The analyst uploads a recorded conversation through the authenticated API.
2. The platform stores the audio in Amazon S3 and triggers processing; storage failure returns a structured error and they re-upload.
3. The platform transcribes the audio multilingually; transcription failure returns a structured error and they retry.
4. The platform produces the structured analysis: summary, customer intent, buyer requirements and budget, objections, buying signals, lead score, and follow-up recommendations.
5. The analyst retrieves the structured analysis as JSON; retrieval failure returns an error and they retry.
6. On success, the analyst has actionable lead intelligence and a clear next step.

Flow F — AI Engineer / Integrator retrieves structured analysis and knowledge

1. The integrator requests the structured conversation analysis for a conversation.
2. The platform returns the JSON analysis document; failure returns a structured error and they retry.
3. The integrator invokes knowledge retrieval; the platform returns retrieved knowledge as structured JSON; failure returns an error and they retry.

Flow G — AI Engineer / Integrator extends the engine

1. The integrator registers a new intelligence module or model provider through the modular engine and gateway.
2. The platform makes it available without altering existing modules; existing analysis continues to function.

6. Visuals Colors and Theme

No user-specified palette, fonts, or brand were provided. The following are coherent, accessible defaults labeled as such.

• Mode: light default with dark-mode parity.
• Primary: #0F3D3E (deep teal) — headers, primary actions.
• Accent: #E07A5F (terracotta) — highlights, active states.
• Surface: #F7F5F0 (warm off-white) — page background.
• Card surface: #FFFFFF — content cards.
• Text primary: #1B1B1B; text secondary: #5A5A5A.
• Success: #2E7D32; warning: #B26A00; error: #B3261E.
• Headings font: "Inter", system-ui, sans-serif; body font: "Source Sans 3", system-ui, sans-serif; mono (API/JSON): "JetBrains Mono", monospace.
• Type scale: 12 / 14 / 16 / 20 / 24 / 32 / 40 px.
• Radius: 6 px controls, 10 px cards.
• Spacing rhythm: 4 / 8 / 12 / 16 / 24 / 32 px.
• Imagery: minimal, data-forward; JSON and schema motifs rather than photography.

[Default — not specified by user]

7. Signature Design Concept

The public entry is the Account Access boundary and the Swagger/OpenAPI documentation surface. The signature concept is a "structured intelligence" motif: the access page presents a calm warm off-white canvas with a deep-teal header band, and the OpenAPI documentation renders each endpoint as a card whose response schema is shown as a syntax-highlighted JSON block in JetBrains Mono. The visual idea recomposes only accepted content — enrollment/verification controls and the documented endpoints — into a single coherent, data-forward identity that signals an API-first intelligence service.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the Account Access boundary with the OpenAPI documentation as the adjacent surface.
• Input→transformation→outcome thesis: a visitor enters identity details → the platform verifies and resolves tenant context → protected API access and documented endpoints become available.
• Motion vocabulary: none beyond standard focus and state transitions; no scroll-linked or ambient motion.
• Composed first frame: warm off-white canvas, deep-teal header, centered enrollment/verification card, with a syntax-highlighted JSON schema block as a static accent.
• Reduced-motion state: identical to the default; no motion to reduce.

9. Non-Functional Requirements

• NFR-1 (explicit): Backend must be built with Python and FastAPI.
• NFR-2 (explicit): Database must be PostgreSQL for application data.
• NFR-3 (explicit): Audio recordings must be stored in Amazon S3.
• NFR-4 (explicit): Deployment must be on AWS using Docker containerization.
• NFR-5 (explicit): APIs must be secure, authenticated, and served over HTTPS.
• NFR-6 (explicit): API responses must be structured JSON.
• NFR-7 (explicit): Architecture must be multi-tenant with tenant isolation.
• NFR-8 (explicit): Architecture must be modular and extensible for future AI model integrations and additional AI intelligence modules.
• NFR-9 (explicit): API documentation must be provided via Swagger/OpenAPI.
• NFR-10 (explicit): Automated testing and deployment documentation must be provided.
• NFR-11 (required_inference): Identity establishment and returning verification must precede access to protected tenant-scoped work; sessions must expire and require re-verification.

10. Tech Stack

• Backend: Python, FastAPI (shared backend process hosting all feature APIs and domain modules).
• AI engine: modular architecture integrating OpenAI and other LLM providers via the litellm gateway.
• Application database: PostgreSQL (per explicit constraint), integrated into the deployment.
• Provisioned infrastructure: backend (FastAPI), database (MariaDB for application-owned persistent data), litellm (model-provider gateway), postgres (supporting LiteLLM, separate from application-owned storage).
• Audio storage: Amazon S3.
• Containerization: Docker.
• Deployment: AWS, HTTPS.
• API documentation: Swagger/OpenAPI.
• Testing: automated test suite with deployment documentation.

11. Assumptions and Constraints

• A-1: The platform is API-first and headless; no custom end-user web UI is in current scope.
• A-2: Identity is application-owned; enrollment is self-service or provisioned, and returning users verify before protected access.
• A-3: Tenant context is resolved after verification and scopes all protected requests.
• A-4: LLM inference is performed by external providers via the LiteLLM gateway; transcription is performed by a configured speech-to-text service.
• A-5: Follow-up recommendations are produced as structured output only; no outbound delivery is in scope.
• A-6: Future AI model integrations and additional intelligence modules are extension points, not current features.
• A-7: Visual tokens in Section 6 are defaults, not user-specified.

12. Glossary

• Tenant: An isolated organizational account whose configuration, knowledge, conversations, and analysis are separated from other tenants.
• AI engine: The modular subsystem that executes intelligence capabilities and routes model calls.
• LiteLLM gateway: The provisioned service through which the backend calls OpenAI and other LLM providers.
• Structured analysis: The JSON document containing summary, intent, requirements, budget, objections, buying signals, lead score, and follow-up recommendations.
• Knowledge retrieval: The capability that surfaces relevant configured knowledge for analysis.
• Intelligence module: A discrete, registerable analysis capability within the modular AI engine.
• OpenAPI/Swagger: The specification and interactive documentation of the platform's REST APIs.