The Pragatix / BusinessGPT architecture uses a staged pipeline to ingest source documents, extract and clean text, generate embeddings, store content in a vector database, retrieve relevant chunks for user questions, and send enriched prompts to an LLM for answer generation. This flow is described in the existing components overview and the Gateway module documentation.

Summary of the flow

1. Document ingestion begins in the Dashboard / Ingester layer

   • The Ingester Service connects to source systems, pulls documents and permissions, and submits them for processing.

   • The Dashboard manages synced content, permissions, collections, and chat interfaces. VA-Pragatix Components Overview…

2. Documents are queued for embedding

   • The ingested content, metadata, and permissions are written to the Gateway-side processing flow through an embedding queue / gateway database.

   • The Gateway then picks up queued items for processing.

3. Text extraction and cleanup

   • The Content Loader extracts text from each content item.

   • It removes unnecessary material such as email signatures, disclaimers, and other noise before downstream processing.

4. Chunking and embedding generation

   • The Embedding Service receives cleaned text from the loader.

   • It splits content into chunks while trying to preserve meaningful file, paragraph, and section boundaries, with neighboring context where needed.

   • Each chunk is transformed into a vector embedding using the configured embedding model.

5. Vector and metadata storage

   • The resulting chunk text, metadata, and embeddings are stored in the Vector DB.

   • The vector database stores:

     • chunked text

     • vector embeddings

     • metadata

     • embedded vector binary content

6. User query and retrieval

   • A user submits a question from the Dashboard.

   • The Dashboard sends the query to the Gateway API / Insights Engine.

   • The Insights Engine searches the Vector DB for relevant chunks using semantic retrieval and, in the Gateway implementation, may also combine keyword search and ranking logic.

7. Prompt augmentation and LLM call

   • The retrieved chunks are attached to the user query as context.

   • The Gateway sends the augmented prompt to the configured LLM, which may be:

     • an OpenAI-hosted model

     • Amazon Bedrock

     • a locally hosted LLM server/container

8. Response returned to the user

   • The LLM generates an answer.

   • The Gateway returns the answer, and optionally source references, back to the Dashboard for display.

Data Flow Diagram

Detailed Processing Stages

1. Ingestion stage

The ingestion process starts on the Windows-side Dashboard / Ingestor environment. The Ingestor Service connects to enterprise content sources and pulls both the content itself and its associated permissions. The existing overview explicitly states that the ingestor sends content and permissions onward for embedding.

2. Queueing and handoff

The Gateway documentation expands this by describing a queue-based handoff: ingested content, raw files, and metadata are stored in a gateway-side database/queue and marked for embedding. This queue acts as the control point for processing state such as new, processing, done, or failed.

3. Content loading

The Content Loader is responsible for format-specific parsing. Different loaders may be used for different file types. The output of this stage is normalized text suitable for chunking and embedding.

4. Chunking and embedding

The Embedding Service splits extracted text into chunks and converts those chunks to vectors. The components overview explicitly notes a preference for keeping paragraphs and sections together where possible, with surrounding context retained to improve retrieval quality.

5. Storage model

The Vector DB stores the embeddings together with the chunk text and metadata. The current architecture identifies Postgres Vector DB as the implementation. This makes the vector store the central retrieval layer for downstream Q&A.

6. Retrieval and orchestration

For question answering, the Gateway API receives a user query and passes it into the Insights Engine. The Insights Engine performs retrieval over the vector database and determines the best algorithm to generate the response.

Once relevant chunks are found, the Gateway constructs an augmented prompt that includes both the user’s question and retrieved enterprise context. That prompt is then sent to the configured LLM backend. The resulting answer is returned to the Dashboard, often with source-document mapping.

Component Responsibilities in This Flow