VedAnvaya is a reading and research interface for the four Vedic Samhitas. It holds 20,210 verses across 4 collections, with the deities, seers, rites, conditions and shared wording that connect them — and with a statement, attached to every figure, of what that figure does not establish.
What this is
The Vedas are usually met one verse at a time, in a book, in order. That is the right way to read them and a poor way to see them. A hymn to Agni in the first mandala of the Rigveda is connected to a verse in the Samaveda that reuses it, to a formula that turns up in the Atharvaveda, to a metre it shares with hundreds of other hymns, and to a seer whose family composed a whole book. None of that is visible on the page.
VedAnvaya is an attempt to make it visible without making it up. Every connection here is one of a small number of stated kinds — an exact parallel, a directed reuse, a shared formula, a named deity, a traditional ascription — and each kind carries its own scope and its own evidence. There is no single similarity score anywhere in this product, because the eight things it would average are not degrees of one quantity.
The name is वेदान्वय, vedānvaya: the following of a connection through the Veda. Anvaya is the grammarian’s word for the thread you follow to resolve a sentence — the order in which the words actually connect, as opposed to the order in which they are written. That is close enough to what this is doing.
Why it exists
I started this because I kept wanting to ask questions that the available tools could not answer, and because the questions were not exotic. Which deity does the Atharvaveda actually invoke most, once you account for it being a little over half the size of the Rigveda? Which Rigvedic verses does the Samaveda take, and does it change them? What does the corpus name when it talks about illness, and is a demon in that list?
Each of these is answerable, and each of them is answerable wrongly in a way that looks fine. The last one is the example I keep coming back to: an early version of this project asked what conditions the corpus addresses and returned a confident ranked list whose top entries were demons and sorcery. The numbers were correct. The answer was not, because the question was about illness and the data was about everything a verse asks protection from. Fixing it took typing every condition in the registry as an affliction, a threat or a named cause, and it is why that plate has two panels rather than one list.
So the project is as much about the failure modes as about the corpus. A knowledge system over an ancient text is very good at producing answers that are precise, reproducible and subtly about the wrong thing. Most of the engineering here is spent making that harder.
What you can do here
Read any of the four collections by its own divisions, with the Sanskrit, a translation where one exists, a recitation where one is catalogued, and the source of each.
Follow a deity, a seer, a rite or a condition across all four collections, and see where the layer that tracks it stops.
Read the plates — seven figures, each answering one question about the corpus and stating what it does not show.
Open the knowledge graph and move through the relationships themselves, asking any one of them to explain what it is and where it came from.
There is one rule underneath all of this, and it is the rule that costs the most to keep: an absence must say which kind of absence it is.
If you ask this product how many Samavedic verses carry an English translation of their own, the answer is zero — and that zero means no Samavedic translation has been released here, not that the Samaveda resists translation. A few of its verses do show an English rendering, and it is Griffith’s Rigvedic one, shown because the text was verified identical; it is labelled as borrowed and it is not this collection’s own. If you ask which Atharvavedic hymns are dedicated to Indra, the answer is a list — but the dedications are recorded as the index’s own descriptive phrases rather than as names in the deity registry, so they answer the question in the index’s words and not in ours. Neither of those is a zero or a list you could have inferred, and both are the kind of thing an interface returns as an empty list if nobody makes it do otherwise.
That is why coverage statements travel with the data rather than sitting in documentation, why a null is never drawn as a bar of length zero, and why the sources and method page is as long as it is. The alternative — a clean interface that quietly turns gaps in the build into facts about the Vedas — would be worse than not building this at all.
How it was built
It began in September 2026 as VedaGraph, which was a database problem before it was anything else. The first question was not what to show but what could honestly be loaded: which editions exist, what they are licensed under, whether two witnesses to the same verse agree, and what a canonical citation should even be for a corpus whose four collections number their contents four different ways.
That work produced the layers everything else sits on, roughly in this order. A provenance registry, so that every verse could name the file it came from and the terms that file is held under. A canonical key and citation for each verse, reconciled across witnesses. The traditional apparatus — seer, deity, metre — where a collection has one. A lexical mention layer, matching registered Sanskrit aliases against the text. A relationship layer: exact parallels, near parallels, directed reuse, variants, formula families. Then the product layers: a reader, a recitation catalogue, a search index, an API, an Ask pipeline that retrieves evidence before it generates anything, and finally the three-dimensional knowledge world.
Along the way the ontology was rebuilt three times and frozen once. Each rebuild came from an adversarial pass that found a new stratum of something the model had been quietly wrong about — most often about what counts as a deity, since the traditional index that names one for every hymn also names twenty-two human patrons, seven praise-of-a-gift labels, and twenty-eight abstractions that name a hymn’s subject rather than anyone it addresses. It also names a dog, and the dog is a deity: thirteen other animals are in the pantheon, and excluding this one on the shape of its label would have been an accident of grammar.
The name changed last. VedaGraph described the technique, and by the time there was a reader, a recitation player and a graph you could walk through, the technique was no longer the thing. VedAnvaya describes what a person does with it. The internal identifiers still say VG:, and they will keep saying it: renaming a stable identity to match a brand is how you lose the ability to compare two builds.
Who built it
I am Himanshu Mohanty. I am a software engineer, and VedAnvaya is an independent personal research and engineering project.
My working life is in software engineering, machine learning and the design of systems that have to hold knowledge without distorting it. My reading life is in history and language. This project sits exactly where those overlap, which is why it exists: I wanted to ask structural questions of the Vedas, I could not find a tool that would answer them without inventing things, and building one turned out to be within reach.
I'm not a Sanskrit scholar by training. I'm a software engineer approaching these texts through computation, data, and a genuine interest in how their internal connections can be made easier to explore. VedAnvaya is not an institutional edition of the Vedas, and it does not claim to replace traditional study, philology, or scholarship. What I have done is read carefully, record provenance obsessively, and refuse to ship a figure I could not account for. Where the corpus needed a judgement I was not qualified to make, the project records the question rather than answering it — which is why the limits page is one of the larger things here.
If you are a scholar and something on this site is wrong, I would genuinely like to know. Most of the errors that have been caught so far were caught by taking a confident-looking answer and asking what question it was actually answering.
Himanshu MohantyBegun September 2026. Still being worked on.
What VedAnvaya is not
This matters enough to be its own section rather than a line in a footer. VedAnvaya is a computational research and exploration interface. It is not any of the following, and it does not want to be.
Not a replacement for reading the VedasNothing here is a substitute for sitting with a text. A graph can show you that a phrase appears in four collections; it cannot tell you what it is like to read the hymn it belongs to.
Not philologyThe textual work here is ingestion, alignment and provenance — reconciling editions, pinning citations, recording what a witness says. That is a different discipline from establishing a text, and this project does not do the second.
Not a commentaryThe commentarial traditions — Sayana, and everything before and since — are not held here and are not summarised. Where this site offers an interpretation it says so and marks it as one reading among possible others.
Not a teacherThe Vedas were transmitted by people, to people, for three thousand years before anyone wrote them down. That relationship is not something software participates in.
Not a claim about historyCounting how often a word appears tells you about the corpus. It does not tell you about the society that produced it, and this site is careful never to let the first quietly stand in for the second.
Not finishedThe Samavedic gana corpus is absent, the Krishna Yajurveda is absent, several layers reach one collection and not the others. The limits page is a real page with real entries in it, not a disclaimer.
What it can do is hold four collections of verses, and the layers built over them, in a form where you can follow a connection, check it, and find out what checking it did not establish. That is a narrow thing, and it is worth doing well.