Skip to main content
MITHUNAI

Your Knowledge.Your AI Expert.

It answers from your documents, or it tells you it can’t.

MITHUNAI turns the content you already have — documentation sites, GitHub repositories, PDFs and uploaded files — into an assistant that answers questions about it and cites the passages it used.

See how answers are groundedRead the architecture
Grounded
Checked against your content, not just prompted
Cited
Every answer shows the passages behind it
Honest
Abstains when your content does not answer

An assistant your customers can act on

The problem with putting a model in front of customers is not that it cannot answer. It is that it answers anyway when it should not. MITHUNAI is built around the opposite behaviour: an answer is checked against your own content before it is given, and withheld when that content does not support one.

  • Grounded in your content

    Retrieval assembles evidence from your corpus, and the answer engine is required to build its response from that evidence rather than from what the model happens to recall.

  • Citations a reader can follow

    Each answer carries the passages it was built from, so the person reading it can check the source instead of trusting the system.

  • An honest "I don’t know"

    When the evidence does not support an answer, the engine abstains and says so. That is the product working — an assistant that answers everything is one you cannot trust on anything.

  • Isolated per organisation

    Tenant scope is a parameter that has to be passed, not a convention to remember. Code that omits it does not compile into a working query — it fails closed.

Connect what you have already written

Point MITHUNAI at the content your organisation already maintains. It is fetched, extracted, split for retrieval and kept in step with the source — with the progress and the failures both visible rather than only the successes.

  • Documentation sites, repositories and files

    GitHub repositories, websites, sitemaps and uploaded files, behind one connector interface — so adding a kind of source does not change how the rest of the product works.

  • The formats technical content actually comes in

    Markdown, plain text, reStructuredText, source code, HTML, PDF and Word are extracted and chunked for retrieval, so a handbook and a header file both become answerable.

  • Crawling stays where you put it

    Website ingestion is same-origin and sitemap-driven, so connecting one documentation site does not become a crawl of the internet.

  • Ingestion you can watch and re-run

    Each sync reports what was discovered, what was indexed and what failed, and runs on a worker rather than blocking the request that started it.

Answers that show their work

A question goes to retrieval, retrieval assembles the evidence, and the answer is built from that evidence and checked against it. What arrives is an answer with its sources, or a clear statement that your content does not cover the question.

  • Grounded, and streamed as it is written

    The response is required to rest on the retrieved passages, and it arrives token by token so a reader is not left waiting on a blank screen.

  • Citations on every claim

    Each answer carries the passages it was built from, anchored back to the document and the source they came from.

  • Abstention is a distinct outcome

    When the evidence does not support an answer, the engine says so — and the API reports that as its own result, never dressed up as an answer with no citations.

  • Assistants you configure

    Name, description, model, corpus and system instruction, per assistant, read fresh on every turn. Operator guidance shapes tone and audience and cannot weaken the grounding rules.

  • Conversations that persist

    History is stored durably and survives a restart, so a conversation is a record rather than a session that vanishes.

Put it where the question gets asked

The same assistant, the same corpus, the same grounding and the same citations, through whichever surface fits — a widget on your own site, a server-to-server API, or an MCP server the tools your engineers already use can connect to.

  • A widget for your own domain

    An embeddable assistant that answers anonymous visitors on your site. A visitor is put through the same authorization pipeline as every other caller, and an embed answers only on the origins you list.

  • A versioned HTTP API

    Every delivered capability is reachable over /arukz/api/v1 by any client that speaks HTTP. Versioned from the first route, so the contract can outlive its first consumer.

  • A read-only MCP server

    Connect an MCP-capable client to your knowledge through three tools that search, list and ask — and none that write. Read-only by construction, scoped to one organisation per call, and authenticated with the same key as every other caller.

  • White-label without a fork

    Each organisation sets its own name, logos, colours and typography, and the widget it serves picks them up. Branding is configuration a customer administrator edits, not a build you maintain a branch of.

Organisations, people and keys

Underneath the assistant is the part that makes it operable by a company rather than by one person: organisations, the people and services in them, what each may do, and what it has been used for.

  • One organisation, many members

    A deployment carries many organisations. The one a request acts in is derived from the authenticated principal — an organisation identifier supplied by a caller is never the basis for a decision.

  • Signing in grants nothing on its own

    Knowing who someone is and deciding what they may do are separate steps, and the second one happens where the action does — never in the interface alone.

  • Roles carry permissions, requests carry scope

    Permissions come from the role held in an organisation, and ownership of the specific resource is checked alongside them — not instead of them.

  • API keys are principals, not bypasses

    A key authenticates as a service principal with its own membership and role. Only a hash is stored, the secret is shown once, and revoking a key takes effect on its next request.

  • Every caller is a principal, human or not

    A person, a service key and a widget visitor are all principals with a type, and whether the actor was human is recorded rather than guessed from a missing user id.

  • See what it is being used for

    Volume and answer-quality counts for your own organisation, broken down by model and by channel, and filterable to a single assistant. Counts only — no shape in the package can carry message content.

Built to survive a security review

An assistant over your internal documentation is only as safe as the boundary around it. Everything you connect is treated as attacker-controlled input, every decision is recorded, and no organisation can read another one’s corpus.

  • Retrieval cannot cross an organisation

    The corpus an assistant reads is bound to its organisation. Evidence from another tenant’s documents is not something the engine can be asked for.

  • Ingested content is fenced, not trusted

    Retrieved evidence, the question and operator guidance each sit inside a separate fence carrying a per-request nonce. Control characters, bidirectional overrides and invisible Unicode tag characters are stripped before a model ever sees them.

  • Fetching is bounded by policy, and fails closed

    Every outbound fetch to a URL you supply goes through one policy: HTTP and HTTPS only, no embedded credentials, a fixed port set, and a refusal for any host resolving to a private, loopback or link-local address — cloud metadata endpoints included. A host that does not resolve is refused rather than attempted.

  • Credentials are stripped before indexing

    A key committed to a repository or pasted into a document is redacted on the way into the corpus, so it cannot be retrieved back out of an answer.

  • Denials are recorded as denials

    A refused request emits a denial event, kept distinct from an operational failure, and the actor is read from the authorization decision itself — so a request that never gained an organisation context is still audited with a complete actor.

  • A failed audit fails the request

    If the record cannot be written, the operation does not quietly proceed. The guarantee is either kept or the request fails.

Boundaries that are enforced, not documented

The platform is built as layered modules with a dependency rule that a linter checks on every change. The foundation layer imports nothing from the layers above it, so the platform core cannot come to depend on the features built on top of it.

The module dependency rule

Each layer may depend only on those listed beside it. The foundation depends on nothing.

  1. experiencedepends onplatform, knowledge, ai, agents, workflow
  2. workflowdepends onplatform, ai, knowledge, agents
  3. agentsdepends onplatform, ai, knowledge
  4. knowledgedepends onplatform, ai
  5. aidepends onplatform
  6. platformdepends onnothing

  • Checked by a linter

    The import rule is machine-enforced in continuous integration, not left to review.

  • Every capability has an API

    Each capability is reachable by a client other than our own interface, so the platform is integrable rather than a closed application.

  • The transport holds no logic

    The HTTP layer parses, calls the module that owns the capability, and serialises. There is no behaviour in it that a reviewer would have to find twice.

  • Deployable where your data has to live

    The platform runs as a containerised deployment, so it can be operated in an environment you control rather than only as a hosted service.

Where a grounded assistant earns its place

These are the workloads the delivered platform supports today: grounded question answering over knowledge you connect, inside an organisation boundary.

  • Technical documentation assistance

    Answer product and API questions from your own documentation, with citations a reader can follow back to the page — and an abstention when the docs genuinely do not say.

  • Engineering knowledge retrieval

    Connect repositories and internal documentation so engineers can ask questions across them without the answer inventing an API that does not exist.

  • Support enablement

    Give a support team a grounded assistant over the same documentation the product ships, where every answer shows its evidence.

  • Regulated and multi-tenant environments

    Operate one platform across organisations where isolation, authorization and an audit record are conditions of running at all.

What to check before you trust an AI platform

Security review questions, answered as they stand today. Where something is not built yet, this page says so — the roadmap is below, and it is kept separate from what is delivered.

  • No outbound calls you did not configure

    The default posture makes no telemetry or analytics call. Any host the platform talks to is configured and documented.

  • Secrets are encrypted at rest and never logged

    Credentials do not appear in source, tests, fixtures or logs, and log-bound text is sanitised on the way out.

  • Parameterised queries, enforced by tooling

    Query construction is checked by repository tooling rather than left to reviewer attention.

  • Per-request ceilings and rate limiting

    Request volume and per-request cost both have bounds, so one caller cannot consume the deployment.

Not built yet

These are being built and are not part of the platform today. They are listed so an evaluation can plan around what exists now.

  • Validation against a live provider

    No model provider is bundled, and the platform has not yet been run end to end against a live one. Every claim on this page rests on the source and its tests, not on a production deployment.

  • Agent actions and workflows

    Assistants answer today. Agents that plan over several steps, call tools and act in external systems are a later direction, and are not built.

  • MCP client

    The MCP server half is delivered as three read-only tools. Consuming external MCP servers from inside MITHUNAI is deferred.

  • Per-tenant quota and spend caps

    Rate limiting bounds request volume today. Measuring a tenant against a usage or spending budget is not built.

  • SSO, SCIM and fine-grained RBAC

    Enterprise identity integration and finer permission granularity are later milestones.

Connect your documentation. Give your customers and teams answers they can check.

MITHUNAI is in active development toward its first release. If you are evaluating how your organisation will answer questions from its own knowledge, we would like to hear what you need.

Talk to usRead the documentation