Data flow map: what leaves your environment, per product

1. 1Sources → Engine: records copied one way, on a schedule
2. 2Engine → Insights and your applications: inside the boundary
3. 3AI Assistant ↔ your LLM provider: the information required for the request, under your account and key
4. 4MCP Server ↔ AI clients: the requested results, under keys you can revoke

Why one map

A platform with four products has four answers to "does my data leave?", and they should differ, because the products do different things. An index that serves your own applications has no reason to send anything anywhere. An assistant that uses a language model has to send that model something, or it cannot answer. A single line promising that nothing ever leaves would be true of two products and false of two, and would not survive the first security review that asked about the model. So this page draws one boundary and describes each flow across it separately, with the exact wording each product's own page uses.

The boundary

Your infrastructure: your servers or your private cloud, with the LipiCore deployment inside it. Engine holds the indexed collections. Insights, the AI Assistant and the MCP Server run beside it and read from it. Everything in the lead diagram inside the blue line is yours and runs where you put it; the two things outside it on the right - your LLM provider and the AI clients your team uses - are the only parties anything is sent to, and both are chosen and keyed by you.

Flow 1: sources → Engine

One way, on a schedule. Your ERP, CRM, accounting system and custom applications send records into Engine, or Engine pulls them from your database, collection by collection: orders hourly, customers every four hours, products daily, invoices weekly, whatever each one needs. What is copied is the fields you configured for each collection, into an index that lives inside the boundary. Nothing goes back. Engine never writes to your systems, and the sources do not know the index exists. Incremental indexing covers the mechanics.

Flow 2: Engine → your applications and Insights

Inside the boundary. Your web, mobile and internal applications call Engine's REST APIs; Insights dashboards and grids read the same collections. The requests and the responses travel inside your infrastructure and nothing about this flow involves a third party. For a deployment that runs Engine and Insights only, this is the whole picture: your data stays within your environment, and nothing is hosted on LipiCore servers.

Flow 3: AI Assistant → your LLM provider

The assistant runs inside your infrastructure, but the language model it uses runs at the provider you chose - OpenAI and Amazon Bedrock work today - under your own account and your own key. When a question is asked, only the information required for the request is shared with the external LLM; the assistant can send relevant metadata rather than exposing the full dataset. The provider's own terms govern what happens to what it receives, which is why the account is yours and not LipiCore's: there is no LipiCore account in the path, and no usage flows through one. How can AI answer questions about business data? shows what the model does with what it is sent.

Flow 4: MCP Server → AI client

The MCP (Model Context Protocol) server runs inside your infrastructure and reads the collections indexed in Engine. An AI client - ChatGPT, Claude, Cursor or your own - connects with your endpoint and an access key issued from your deployment. When the client requests information, only the requested results are sent to that client and handled according to your agreement with its AI provider. Keys can be rotated or revoked at any time; no key, no connection. The production database is not exposed to the client, and the client carries no additional load onto it. MCP server explained walks through one call.

What never flows

Writes back to your systems: no product writes to the sources. Anything to LipiCore or Techgrains servers: the deployment is yours, the keys are yours, and LipiCore does not send data anywhere on its own. The production database, to any model or any client: the assistant and the MCP Server work from the indexed copy, never from the database that runs the business.

Per product

Questions to ask any vendor

The map above is LipiCore's. The questions behind it apply to any platform that promises AI over your data, and they are worth asking in exactly this form.

1. Where does each component run - in our infrastructure, in yours, or at a third party?
2. For each component, what leaves our environment, and to whom?
3. Whose account does the language model run under, and whose terms apply to what it receives?
4. Can any component write to our systems of record, and if so, which, and under whose control?
5. Does any model or external client ever reach the production database, or only a copy?
6. Who issues the keys, and how quickly can one be revoked?

A vendor who can answer these per product, in a table, has thought about the boundary. A vendor who answers them with one sentence for the whole platform has not.

Related

PILLAR How can AI answer questions about business data? The model does not read your database. It turns your question into a structured query, runs it against indexed data, and writes up the result. The numbers come from the index; the words come from the model. EXPLAINER MCP server explained A small service that publishes a list of tools and answers calls to them with structured results. For business data, the right tools are search, filter and aggregate over indexed collections - not raw SQL. EXPLAINER Incremental indexing: keeping an index fresh An index is a copy, so it has to be refreshed. The question is how, how often, and what to tell users.