Your customers want search and AI answers over their own data, and none of them want to share an index. Ship the feature without building the platform.
A search box over one folder is a demo. Search for a thousand paying tenants is an infrastructure product, and most teams discover that after they have promised the feature.
LM-Kit One's search service is the retrieval platform, so your product only calls it.
01
Each customer gets a tenant; each workspace a collection, over REST.
02
API keys carry explicit cluster grants; a key sees its tenants and nothing else.
03
Documents are parsed, chunked, and embedded by the document engine; reindexing is a call, not a project.
The deployment model of your product decides the form of its search.
Serve it
Your application servers call the search service over REST; tenants, collections, grants, and reindexing are its job. It scales horizontally, any node serving any request, as your customer base grows.
Embed it
The desktop or customer-installed edition of your product embeds the built-in vector store and the same retrieval pipeline, one tenant per install, no server required.
The three answers your customers' security reviews will ask for.
Isolated
Access is grant-only per API key and the service scopes every query to that grant, on every storage engine. On PostgreSQL, row-level security adds a further layer inside the database itself.
Yours
Two choices per cluster: full text on PostgreSQL, built-in SQLite, MySQL, or SQL Server; vectors beside it or in Qdrant. From fully local to 100% PostgreSQL to your estate paired with Qdrant.
Grounded
Answer responses carry citations, a groundedness score, and any unsupported claims flagged, so your product can refuse to bluff.
Two calls your product makes: ranked results for the search box, grounded answers for the assistant.
Ranked, reranked results scoped to one tenant's collection.
curl http://your-server:5189/lmkit/v1/search/search \
-H "Authorization: Bearer sk-acme-***" \
-H "Content-Type: application/json" \
-d '{"clusterId":"production","tenantId":"<acme-tenant-id>",
"collectionId":"<workspace-id>",
"query":"termination clause in the vendor MSA",
"searchType":"Hybrid","topK":10,"rerank":true}'A cited answer over the same scoped collection, ready for your product's assistant.
curl http://your-server:5189/lmkit/v1/search/answer \
-H "Authorization: Bearer sk-acme-***" \
-H "Content-Type: application/json" \
-d '{"clusterId":"production","tenantId":"<acme-tenant-id>",
"collectionId":"<workspace-id>",
"question":"When can we terminate the vendor MSA?"}'
# Response: answer + citations[] + groundednessScore + unsupportedClaimsThe search service composes documented capabilities you can inspect on their own.
Store
Embedded storage for the SDK; database-backed collections for the service.
How storage worksEmbed
Dense vectors on-device, with reindexing handled by the service.
How embeddings workRank
Second-pass relevance over hybrid candidates before results reach users.
How reranking worksUnderstand
Short user queries become retrievable intent before they hit the index.
How expansion worksIngest
Parsing, OCR, and chunking turn customer uploads into indexable content.
How ingestion worksRelated
The same service pointed inward: one search backend for internal tools.
The internal-search use caseBelow your application code, on every storage engine. API keys carry explicit per-cluster grants, so a key can only see the tenants it was granted, and the service scopes every query to that grant. On PostgreSQL, row-level security adds a further enforcement layer inside the database itself. Isolation never depends on your queries remembering a filter.
Storage is composed per cluster on two independent axes. Full text runs on PostgreSQL, the built-in SQLite store, MySQL, or SQL Server; vectors live beside the full text (pgvector on PostgreSQL, the local index on SQLite) or in an external Qdrant. That spans fully local with zero external services, 100% PostgreSQL in one database, and MySQL or SQL Server paired with Qdrant.
Reindexing is a service operation per collection, not a data migration you script. The service owns chunking, embedding, and index maintenance, so a model upgrade is a call and a wait, and queries keep serving meanwhile.
No. Ingestion, embedding, retrieval, and answer generation all run on your deployment of LM-Kit One. There is no hosted index, no third-party vector database, and no new data processor in your customers' DPAs.
Search for builders