FoJin aggregates 10,500+ Buddhist texts into a searchable corpus with cited AI answers, a trilingual cross-canon alignment layer, and an open quote-verification endpoint. The architecture is the interesting part; the corpus licensing is the part to check before you build on it.

Can I use xr843/fojin commercially?

Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is xr843/fojin still maintained?

Yes. The repository last received commits 3 days ago.

What programming language is xr843/fojin written in?

Mainly Python, according to GitHub's language statistics.

FoJin Review: Buddhist Digital Text Platform with Cited RAG Answers

At a glance

What is it?: FoJin aggregates 10,500+ Buddhist texts into a searchable corpus with cited AI answers, a trilingual cross-canon alignment layer, and an open quote-verification endpoint. The architecture is the interesting part; the corpus licensing is the part to check before you build on it.
Who is it for?: Adopt FoJin if you are building a Buddhist-studies tool, a citation checker, or an MCP client that needs URN-addressable canon passages, and you can live with a hosted-first design where the deployment path is the Docker and FastAPI stack in the repository. Do not adopt it if you need a fully offline, self-contained corpus with per-source licence metadata, or if your users need guaranteed uptime from a service you control rather than mcp.fojin.ai.
Can I use it commercially?: Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 3 days ago.
What is it written in?: Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 10, 2026 · xr843/fojin

The Scatter Problem FoJin Is Trying to Collapse

Buddhist primary texts live in a set of databases that do not talk to each other: CBETA for Chinese, SuttaCentral for Pali, BDRC for Tibetan, 84000 for translations, GRETIL for Sanskrit. The README states the consequence directly: a reader with a question spends more time locating the right passage than understanding it. FoJin's answer is aggregation plus retrieval. The stated corpus is 612 data sources, 10,500+ texts, and 19,000+ volumes of full content in Classical Chinese, Pali, Tibetan, and Sanskrit, with 8,900+ texts readable online. The intended user is not a casual reader. It is someone who needs to move between canons, compare a Chinese passage against its Pali or Tibetan counterpart, and cite the result. The README frames the project as "open, cross-canon, verifiable Buddhist knowledge infrastructure" rather than a reading site, and the presence of an MCP server and a public verification endpoint supports that framing. Whether the aggregation is legally clean is a separate question the README does not answer, and I will come back to it.

How XiaoJin Retrieves and Why the Citations Are the Design

The Q&A assistant, XiaoJin, is a retrieval-augmented generation pipeline. According to the README, it retrieves over 670K+ embedded passages, applies optional cross-encoder reranking, and adds root-sutra recall. Answers carry clickable citations in the form 【《sutra》juan N】 that open the source passage, and a citation drawer shows side-by-side Chinese, Pali, and Tibetan parallels. The anti-hallucination layer is described as a deterministic citation whitelist plus a verbatim-quote downgrade plus a per-answer trust state. That combination matters more than the model choice: a whitelist means the system can only cite passages it actually retrieved, and the downgrade means an answer whose quote does not match verbatim is demoted rather than presented as sourced. The README claims roughly 98% of citing answers are served-trustworthy at temperature 0. That is a self-reported figure and I have not reproduced it. The more checkable claim is the separate endpoint, /api/verify/quote, which takes a sentence and a citation and returns exact, near-miss, or absent, with a character-level diff and the correct juan when the citation points at the wrong one. That endpoint is useful precisely because it does not require trusting FoJin's own answers.

Trilingual Alignment: The Part With Real Method Behind It

Cross-canon parallel reading is the feature that distinguishes FoJin from a search box over a merged index. The README describes 4,000+ LLM-verified chunk alignments across Chinese, Pali, and Tibetan, built over CBETA, SuttaCentral, and 84000. Named coverage includes the Heart Sutra, Vimalakīrti, the Lotus Sutra (法华 against Toh 113, 259 pairs), the 8,000-verse Prajñāpāramitā (小品般若 against Toh 11, 127 pairs), the Satipaṭṭhāna material, the Āgama to Nikāya corpus covering MN, DN, SN, and AN, and the Dhammapada. The phrase "LLM-verified chunk-level alignment" is doing a lot of work and the README does not explain the verification procedure or the error rate. Treat the pair counts as coverage claims, not accuracy claims. The practical consequence is that alignment quality is uneven by text: a heavily aligned sutra like the Lotus Sutra is a different experience from a text with no alignment at all, and the platform does not appear to surface an alignment-confidence value to the reader. If your work depends on a specific parallel, check that pair count before assuming the comparison view will help.

Running It: Docker, FastAPI, Elasticsearch, pgvector

The repository is Python, licensed Apache-2.0, with a FastAPI backend, Elasticsearch for full-text search, pgvector with HNSW indexes for the 670K+ embedding vectors, and a React frontend. The topics list names docker, elasticsearch, fastapi, react, and rag, so a container-based deployment is the expected path. The README does not include a copy-pasteable docker compose invocation or a full environment variable table in the material I have, so I cannot give you exact config keys without inventing them. What the material does give you is the consumption side, which is fully specified. The MCP server is published as fojin-mcp on PyPI and can be run with uvx fojin-mcp, or used hosted at mcp.fojin.ai with no key and anonymous access. It exposes eight read-only, URN-addressable tools. Every passage carries a stable URN in the form fojin:cbeta/T0001.1, and that identifier is the contract: the same string addresses the passage through the API, the MCP tools, and the citation drawer. If you only want to consume the corpus, you never touch the Docker stack. If you want to self-host, the deployment work is the Elasticsearch plus pgvector plus FastAPI combination, and that is a real operational commitment, not a single container.

Where FoJin Is the Wrong Tool

The README does not document per-source licensing for the 612 aggregated sources. That is the largest open question in the project. CBETA, SuttaCentral, BDRC, 84000, and GRETIL each carry their own terms, and aggregating them under an Apache-2.0 repository licence does not automatically relicense the underlying texts. The Apache-2.0 licence covers the code in this repository; it says nothing about the content the code serves. If you plan to redistribute the corpus, mirror it, or train on it, the repository as described does not give you the information you need to decide, and you would have to trace each source yourself. A second limitation is the hosted dependency. The easy path is mcp.fojin.ai and fojin.app, which means your tool's reliability is tied to someone else's uptime and rate policy, with no documented SLA. Third, the corpus is deep but not complete: 10,500+ texts is a large aggregation, yet any given Pali commentary or Tibetan tantra may be absent, and the README gives no coverage map per tradition. Finally, the knowledge graph at 110K+ entities and 27,900+ relations is impressive in count but the README does not describe the extraction method or precision, so treating its edges as scholarly assertions would be premature.

Alternatives and the Actual Difference in Approach

The obvious comparison is reading CBETA directly. CBETA gives you the Chinese canon with a mature, stable interface and its own citation conventions, and it does not attempt retrieval or generation. The difference is scope and mediation: CBETA is one canon, authoritative within it, and FoJin is many canons with a retrieval layer on top. If your question is entirely within Chinese Buddhist texts and you need citable juan and line numbers, CBETA alone is simpler and has no model in the loop. A second comparison is running your own RAG over a corpus you license yourself. That gives you control over provenance, chunking, and evaluation, at the cost of building the alignment and dictionary layers FoJin already has. The honest framing is that FoJin's value is concentrated in two places you would not want to rebuild: the trilingual alignment pairs and the URN scheme that makes passages addressable across tools. If you do not need either, a local index over CBETA plus SuttaCentral is a smaller system with fewer unknowns.

Maintenance, Versioning, and What the Release History Suggests

The release list is unusual. v4.0.0 is dated 2026-03-19 and v1.0.0 is dated 2026-03-23, four days later, which means the initial release tag was cut after the full-featured one. That is a versioning inconsistency worth noting before you pin a dependency: do not assume the semver numbers reflect a linear history. v3.4.0, labelled website UX improvements, sits between them at 2026-03-13. The last push is 2026-09-10, so the project is active. The fojin-mcp package is separately versioned on PyPI, which is the piece most consumers will actually depend on, and it is the piece whose API surface you should pin. The Apache-2.0 licence on the code is permissive and imposes no copyleft on your integration. It does not grant you rights to the aggregated texts, and nothing in the README suggests the project has cleared those rights on your behalf. Budget for a licensing review proportional to how much of the corpus you intend to serve, and pin fojin-mcp rather than tracking its latest release if you are embedding it in a pipeline.

Editorial conclusion

Adopt FoJin if you are building a Buddhist-studies tool, a citation checker, or an MCP client that needs URN-addressable canon passages, and you can live with a hosted-first design where the deployment path is the Docker and FastAPI stack in the repository. Do not adopt it if you need a fully offline, self-contained corpus with per-source licence metadata, or if your users need guaranteed uptime from a service you control rather than mcp.fojin.ai. Before committing, verify three things in this order: the redistribution terms of the 612 upstream sources you actually plan to serve, whether the trilingual alignment coverage extends to the text you care about (the README names Lotus Sutra, the 8,000-verse Prajñāpāramitā, and the Āgama/Nikāya corpus as covered), and whether the /api/verify/quote behaviour on your own test sentences matches the exact / near-miss / absent categories the README describes.

Official sources

Community notes