Almost nothing on this page is a language model. It is grammar, executed — rule engines that derive a form, place an accent, split a compound or classify a sentence, and that cite the sūtra they did it by. The model, when it comes, will be trained on what these produce.
This page sets out what we wrote ourselves, what we build on top of, which apps run on them, and who made the work that came before ours.
Deterministic · Cited · Refusable
An engine, in this project, is a program that reaches an answer by rule and can show the rule. Three properties are required of every one of them, and a component that lacks any of the three is not shipped as an engine.
It is deterministic. The same input gives the same output on every machine, every time. No sampling, no temperature, no weights.
It cites. A derived form carries its Aṣṭādhyāyī sūtra chain; an accent carries the Phiṭsūtra that placed it; a dictionary attestation carries the kośa and the printed page. An answer without a citation is not an answer we publish.
It refuses. Where the grammar itself leaves a question open — where 2.3.18 permits both the kartā and the karaṇa, where a scholar has not yet signed off a meaning — the engine returns the ambiguity and names what needs deciding. It does not pick. A confident wrong answer is treated throughout this project as worse than a visible gap.
Why this matters more than accuracy figures. A statistical parser that is right 95% of the time is unusable for scholarship, because the 5% is not marked. A rule engine that is silent on 20% of cases is usable, because the 20% is exactly the set a paṇḍita needs to look at. We optimise for the second shape.
Nine engines are our own work. Each exists because the thing it does either had no implementation, or had one that stopped short of what Vedic material requires.
Python · pada_kosha.phit · 95 rules, 3 adhikāras, 32 declarable senses
The accent of an underived nominal stem is governed by Śāntanava's 87 Phiṭsūtras. Vidyut, on which the rest of our grammar work rests, implements one of them — Phiṭ 1 फिषोऽन्त उदात्तः, applied to every stem without condition. That is no fault of Vidyut's, which is built for Sanskrit at large and is excellent at it: Phiṭ 1 is the rule of last resort and it is the right default. But the other 86 exist precisely to override it, and for Vedic material the overrides are the substance. A kośa that accents every stem on its final vowel has not accented anything; it has printed a default.
So we wrote all 87, from the sūtras themselves. The engine keeps the mechanism the sūtras have: a first-match cascade with apavāda before utsarga; the three adhikāra sūtras recorded above each rule they govern rather than folded into it; and वा rules that return both readings, because an optional sūtra collapsed to one form has thrown away half of what it said.
About a quarter of the sūtras turn on what a word means — आर्यस्य स्वाम्याख्या चेत्, अर्जुनस्य तृणाख्या चेत्. No morphology decides those. The caller declares the sense; where one was never declared, the engine reports which rule it therefore did not apply, so the reader is told that the accent turns on a question nobody has answered.
Python · pada_kosha.svara
Two upstream libraries disagree about accent notation in a way that fails silently:
one emits / for udātta, the other reads / as a literal
slash. Piping one into the other produces राम/ः — an ASCII
character sitting inside scripture, with no error raised. This module is the guarded
crossing between them.
Its representation is phonological, not typographic: a bare SLP1 string plus a per-vowel accent value, carrying no assumption about which glyph prints which accent. Which convention is printed — and Unicode names U+0951 udātta while the Ṛgvedic printing tradition uses it for svarita — is a scholarly decision, so it is one swappable table rather than a hard-coded choice.
Python · pada_kosha.generator · subanta, tiṅanta, kṛdanta, taddhita
A Pāṇinian form generator that emits kośa entries rather than bare strings: every form carries its ordered sūtra chain, and every accent is routed through the bridge above rather than through a bare transliterator.
It adds Vedic identification by contrast. With the chandasi rules enabled, each form is re-derived with those rules switched off; a form the classical grammar cannot produce is a genuinely Vedic form and is flagged as such. Guessing from the lakāra alone would miss most of them.
Python · shaabda.sarvaveda.info · /analyse /construct /patterns /nyaya /dhatus /all
Deconstruction and construction over one shared morphological stage. Deconstruction runs segmentation, then morphology, then kāraka assignment, then samāsa classification, then the Navya-Nyāya relational analysis. Construction goes the other way: from a resolved analysis it generates three paraphrases of the same sentence, each putting a different thing at the centre — Vyākaraṇa (the operation is chief), Mīmāṃsā (the impulse to accomplish is chief), Navya-Nyāya (the nominative entity is chief).
The refusal is built in at the seam. Where Pass 1 left a kāraka ambiguous — as 2.3.18 requires it to — the construction module declines to build on it and names what needs adjudicating.
Data + gate · 2,086 dhātus · services/sbm-api/phala.py
A śābdabodha paraphrase needs each root's vyāpāra (the operation) and phala (the result) — प्रापण-अनुकूल-व्यापारः for आप्, with व्याप्तिः as its result. The vyāpāra can be derived; the phala cannot, because it does not follow from the Dhātupāṭha's two-word gloss.
So the phala-kośa is a scholar's resource with a signature gate: a row is usable by the construction engine only when a named reviewer has signed it on a recorded date. Unsigned rows produce output stamped draft, all the way to the page. This is the gating resource for the whole construction side, and it is deliberately slower than the code.
Four layers · specification and data
VKG's method for determining the kind of every Vedic sentence, built as four separable layers so that a disputed classification is traceable to the layer that made it:
TypeScript + API · varnakrama-web.web.app · web, iOS and Android
Analyses a Sanskrit word by Vedic varṇakrama rules in five ways — śuddha · svara · mātrā · aṅga · varṇasāra, the last with an interactive breakdown — in any of the four Vedic traditions, with an on-screen Inscript keyboard, udātta/anudātta/svarita marks, and the VijayaDV typeface throughout. Shipped and in use; it is not being rebuilt.
Batch · 862,849 stems · 1,708,513 forms
An exhaustive sweep that asks, for every dhātu and every kṛt affix, what the grammar can build. Its purpose is a boundary rather than a list: a word the sweep can derive is yaugika and citable to a sūtra, and a word it cannot is rūḍha and must be citable to a printed lexicon instead. The sweep is what lets the lexicon keep those two claims apart.
Python + static front end · sarvaveda.info/pk
Builds the searchable lexicon as a front-coded static index — no database at read time, so it is fast and cheap and cannot go down separately from the page. Its gating test is the index round-trip between builder and browser, because a one-character disagreement there makes every lookup miss silently rather than loudly.
Reuse before rebuilding
A standing rule of this project is that nothing is rebuilt that already exists and works. The Pāṇinian derivation core, script conversion, form lookup, segmentation and sandhi all come from Vidyut, an MIT-licensed Sanskrit toolkit by Arun Prasad of ambuda-org. It is vendored at a pinned commit and is the single largest piece of software in this project that we did not write.
What follows is what each part gives us and what we had to add on top of it. The additions are not criticisms — Vidyut is built for Sanskrit generally, and this project needs the Vedic corner of it.
| Component | What it gives | What we add |
|---|---|---|
| vidyut-prakriya | Aṣṭādhyāyī derivation with the sūtra chain — subanta, tiṅanta, kṛt, taddhita, samāsa | Accent safety on every form; Vedic identification by contrast; the 87 Phiṭsūtras it does not carry |
| vidyut-lipi | Transliteration between Indic and Latin schemes | PUA-safe guards and an explicit accent-notation crossing; no Unicode normalisation anywhere |
| vidyut-kosha | A compact FST mapping a form back to its stems and affixes | We keep every analysis it returns, not the best one — disambiguation is a later stage's job |
| vidyut-cheda | Trained segmentation of a continuous sentence | Used for word boundaries only; the morphology of each resulting pada is taken from the kośa instead |
| vidyut-sandhi | Sandhi joining and splitting rules | Run backwards at every position to generate samāsa candidate splits, keeping only halves the kośa holds |
| vidyut-chandas | Metre identification | Used as supplied |
Beyond Vidyut, the lexicon's dictionary material comes from established digitisation projects rather than from any scanning of our own — 32 kośas from the Cologne Digital Sanskrit Dictionaries and 18 from the indic-dict collection, with one, the Śrautapadārthanirvacanam, digitised here because no one had done it. They are named individually on the lexicon itself, each with its printed edition, and credited below.
What we publish from them, and what we do not. Only attestation is published — which kośa records a word, and on what printed page. Entry text is not published. Where a work is in copyright the card says to cite the printed edition rather than this site.
What the engines are for. Everything marked live is running now; the published surfaces need no account and cost nothing.
| App | What it does | Where |
|---|---|---|
| Śābdabodha | Analyses a Sanskrit sentence and reconstructs it three ways — the drill surface for the engine above | shaabda.sarvaveda.info |
| Vaidika Pada Kośa | 1.23 million words — 51 published lexicons, seven Padapāṭha texts, and the Pāṇinian generator, in one search | sarvaveda.info/pk |
| Veda Vākya Prakāratā Nirūpaṇam | The four-layer classification of every Vedic sentence — specification and data; no public surface yet | in progress |
| Jaiminīya Nyāyamālā-Vistara | Adhikaraṇa reader for the Pūrva-Mīmāṃsā | sarvaveda.info/jaimini |
| Vaiyāsika Nyāyamālā | Adhikaraṇa reader for the Brahmasūtra | sarvaveda.info/brahmasutra |
| Varṇakrama Darśikā | Five varṇakrama analyses across four Vedic traditions — web and mobile | varnakrama-web.web.app |
| Śrutam | Sanskrit speech recognition | asr.sarvaveda.info |
| Mudraṇa | The press — sets a corpus text as a finished book | members |
The API
The engines are not only ours to use. The lexicon is served as a public API, so a dictionary app, a reader, a classroom tool or a research script can query it directly rather than reimplementing any of the above.
The Pada Kośa API exposes source listing, search, and per-word lookup over the same 1.23 million-word pool the site searches, with free, scholar and institutional tiers. Signup is open on every tier. The Śābdabodha engine is reachable the same way, for analysis, construction and the Navya-Nyāya pattern set.
Three conditions apply to anyone building on this data, and they are conditions of the project rather than of the software: register an interest in which data is being used and for what; meet the costs of data production and API service; and accept that SarvaVeda retains rights over products developed on its data collection. The production cost — the scanning, the correction, the scholarship — is the large number, and it is not recovered by the hosting fee.
This project stands on work that other people did first, much of it given away freely. Where we have written our own implementation of something, it is because the Vedic case needed more than the existing one covered — never because the existing one was poor, and in several cases we learned how to build ours by reading theirs.
The Sanskrit toolkit this project's grammar work rests on — Pāṇinian derivation with full sūtra chains, transliteration, form lookup, segmentation, sandhi and metre. Released under the MIT licence and vendored here at a pinned commit. Without it, the Pada Kośa would not exist in this form. github.com/ambuda-org/vidyut
Three open engines — tiṅanta and subanta generation, sandhi, and an accent generator covering all 87 Phiṭsūtras with the sūtra shown for every accent, built from Kielhorn's edition of the Phiḍvṛtti, the Siddhāntakaumudī with the Subodhinī, and the Svarasiddhāntacandrikā. Ours is an independent implementation written from the sūtras, but the mechanism is theirs: the first-match cascade, the closed vocabulary of accent placements, and the practice of showing the responsible sūtra were all learned from reading their work, and it remains the reference we test against. Dr. Patel is separately the digitiser of five of the kośas in our lexicon. github.com/drdhaval2785
Thirty-two of the lexicons searchable here are the Cologne project's digitisations, and 26 carry his name in their headers. Decades of work that made the printed Sanskrit lexicographical tradition machine-readable at all, released for anyone to use. sanskrit-lexicon.uni-koeln.de
Eighteen further kośas come from the indic-dict collection, whose maintainers have gathered and normalised dictionary material across Indian languages and kept it openly available. github.com/indic-dict
Encoding and lexical standards work for Sanskrit, and a digitised kośa carried in this lexicon. sanskritlibrary.org
The Sanskrit Heritage engine and its verb-form databases — the long-standing reference implementation of computational Sanskrit morphology, and one of the independent datasets against which generated forms can be checked. sanskrit.inria.fr
The critical edition of Śāntanava's Phiṭsūtras with the Phiḍvṛtti, from which the gaṇa enumerations in our accent engine are taken. Long in the public domain, and still the edition the work is done from.
Named in that project's own acknowledgements for its layout and its transliteration code respectively — carried forward here, since credit passed on is credit kept.
The three editions of the dictionary of sacrificial terms — Kashi Rajkiya Sanskrit Pathashala; the second of 1919; and Prithvi Prakashan's third. It is the one kośa in this lexicon digitised by us, because no one had done it, and the scholarship in it is entirely theirs.
For the texts, the tools and the standard that Sanskrit software should be free to read, free to fork and honest about its sources. ambuda.org
Corrections welcome. If your work is used here and named wrongly, or not named at all, write to tech@dharmaposhanam.in and it will be fixed. Attribution is not a courtesy in a project like this one; it is part of the method.