Skip to main content
MITHUNAI is built in four layers. The platform core holds organisations, people, API keys and authorisation. Knowledge sources ingest and index your content. The answer engine retrieves evidence, answers from it and cites it, or abstains. Channels deliver those answers through the console, the HTTP API, the website widget and the MCP server. Each layer depends only on the ones beneath it. Every channel goes through the same answer engine, so an answer is the same whichever channel it arrives through.

​
Design decisions

  • Grounding is enforced, not prompted. Evidence is assessed before the model is called, and every answer is checked against the passages it cites afterwards. An assistant’s guidance cannot turn either check off. See How answers work.
  • The organisation comes from the credential. Every request acts in the organisation of the verified session or key, never one named in the request, and a resource in another organisation is reported as not found. See Security.
  • The MCP server is read-only. Its three tools can search and ask, and none can change anything. See MCP server.
  • A website visitor is a narrow, public principal. A widget key can only start and continue conversations with one assistant, from origins you allow, within its own rate limit. See Website widget.
  • API keys are principals with roles. A key is checked on every request like a person, holds one role, cannot grant a role above its creator’s, and cannot manage keys. See API keys.
  • Support access is consented and read-only. MITHUNAI staff see nothing until an Owner or Administrator allows it, and every request they make is recorded in your audit history. See Support access.
  • Ingested content is untrusted. Fetching cannot reach private networks, credentials are redacted before indexing, and retrieved text is kept apart from the model’s instructions. See Retrieval pipeline and Model gateway.

​
Where the data lives

Knowledge, conversations, settings, invitations, usage counts and saved connections (their tokens encrypted) are stored in PostgreSQL, with passages indexed by pgvector for semantic search and by PostgreSQL full-text search for keywords. Ingestion runs in background workers. Model calls go to the providers your deployment is configured with. See Deployment.
Last modified on November 7, 2026