Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/tudoumono/Sherpa/llms.txt

Use this file to discover all available pages before exploring further.

Sherpa is an agentic RAG (Retrieval-Augmented Generation) platform for internal business documents. You register a local folder — containing design specs, source code, COBOL/JCL programs, Office files, incident reports, or any combination — and Sherpa builds a searchable knowledge base from it. From that point on, anyone with access can type a question in plain language and receive a grounded answer, with citations that link directly to the original source files for download. This page explains what Sherpa does, who it is for, and the key design ideas behind it.

What Sherpa does

Sherpa exposes everything through a single chat interface. You describe what you need to know and Sherpa selects the right investigation method — called a lens — automatically. There are three lenses:
LensExample questionWhat you get
Impact analysis”What is affected if we change the consumption tax rate?”Hit count + breakdown (fix now / needs review / not affected) + traversal path + citations. Excel export available.
Troubleshooting”The nightly batch job terminated abnormally — what is the cause?”Ranked cause-candidate cards ordered by confidence score, each with a reason, verification steps, and a source citation.
Spec Q&A”How is the invoice amount calculated?”The relevant excerpt from the spec document + citation link. If no evidence exists, Sherpa says “no evidence found” explicitly rather than guessing.
When the Knowledge retrieval toggle is on, every answer includes a citation at the bottom. If Sherpa cannot find supporting evidence it says so — it never asserts without a source.

Who Sherpa is for

End users

Developers, maintainers, and operations staff who need to investigate change impacts, diagnose incidents, or look up specifications — all through the chat interface, with no knowledge of the underlying search technology.

Admins

Team members responsible for registering document folders, triggering ingestion runs, confirming the knowledge graph, managing full-text search, and administering user accounts and audit logs.

Ops

Infrastructure staff who operate the server and the backing stores (PostgreSQL, Neo4j, Elasticsearch). The stores run in Docker; the application core runs directly on the host.

Local / unauthenticated

Anyone evaluating Sherpa on a local machine. Without authentication enabled, the app runs in compatibility mode as the admin user — no login required to try everything.

The directory-mirror model

Sherpa’s data model is deliberately simple: one registered folder equals one world. A world consists of one Neo4j graph and one Elasticsearch index, both derived entirely from that folder’s contents. The folder tree itself defines the scope — there is no separate configuration for what belongs to which project or phase. When you run an ingest:
  • Files that changed are replaced in the knowledge base.
  • Files that were deleted are removed from the knowledge base.
  • Files that are new are added.
There is no versioning, no draft/publish workflow, and no staging step. The knowledge base is a live mirror of the folder on disk.
Think of the registered directory as the single source of truth. Whatever is in the folder is the knowledge base. Re-run ingest after any change and the knowledge base reflects it immediately.
A subfolder prefix inside a world is called a scope path (e.g. 02_設計 or 03_開発). You can narrow any search, impact traversal, or citation to a specific scope without creating a separate world. Components that appear in multiple scopes — such as shared COBOL copybooks — are resolved automatically within the same generation (top-level folder segment).

Design principles

Evidence-first: Sherpa never makes an assertion without a citation. When Knowledge retrieval is on, every claim is backed by a link to the source document, which you can download in one click. When no supporting evidence exists, Sherpa explicitly says “no evidence found” rather than returning a fabricated answer.
Two further principles follow from this:
  1. Shared vs. personal separation. Shared knowledge (the registered folder) is visible to all users and serves as the common evidentiary base. Personal files uploaded to My Workspace are only searchable by the uploading user via grep; they are never indexed into the shared RAG or the knowledge graph.
  2. Text only sent to AI. Source file content is sent to the AI provider as plain text only. Files are not uploaded to or retained by any external service.

Technology stack

LayerComponent
ApplicationFastAPI (runs directly on the host, not in Docker)
Graph storeNeo4j (Docker)
Full-text searchElasticsearch (Docker)
Relational storePostgreSQL (Docker)
AI providersHeuristic/simple (default, no AI key required) · Codex (gpt-5.5) · OpenAI · Gemini · Ollama
RuntimeLinux / WSL2
The stores (PostgreSQL, Neo4j, Elasticsearch) run inside Docker containers for easy setup and teardown. The FastAPI application, ingestion pipeline, and AI execution all run directly on the host so that file-system access and local tooling (grep, static analysis) work without container overhead.

Next steps

  • Follow the Quickstart to clone the repo, start the stores, register a folder, and ask your first question in under five minutes.
  • Read Core concepts to understand worlds, scope paths, the knowledge graph schema, and the ingest pipeline in detail.

Build docs developers (and LLMs) love