Classical Indian philosophy organizes itself into six orthodox schools, the shad-darshana: Nyaya, Vaisheshika, Samkhya, Yoga, Purva Mimamsa, and Vedanta. Each one is, at its core, an attempt to answer a narrow, specific question about how knowledge and reality are structured. I read through all six while researching my book, expecting a history lesson. What I found instead was a set of arguments that map, almost too cleanly, onto problems I argue about with engineers every week when we're designing how a system should reason.
I want to be precise about what I'm claiming here. This isn't a mystical parallel and I'm not treating any of these schools as settled truth. What I found useful is structural: each darshana isolates one question that any reasoning system, human or artificial, eventually has to answer. Here's the mapping as I see it, and in a couple of places it's more than a mapping I find personally interesting, it's language that's already made its way into how my own team talks about our architecture.
Nyaya: how do you know what you know
Nyaya is built around pramana, the accepted means of valid knowledge: perception, inference, comparison, and testimony. The school's real contribution is insisting that "knowing something" isn't one undifferentiated act, it has distinct, checkable sources.
That's precisely the gap in a lot of deployed AI systems. An LLM's output and a grounded, retrieved, source-checked answer often look identical on the screen, but they were arrived at through completely different means. A system that can't distinguish its own pramana, what it inferred versus what it retrieved versus what it's pattern-matching from training, will eventually produce a confident answer it has no real basis for. This is close enough to how we think about query classification internally that I'll leave it there for now and come back to it properly another time.
Vaisheshika: the categories you choose determine everything downstream
Vaisheshika is the school of categories: substance, quality, action, and the particulars that combine to form them, including a category for what's simply absent. Its central bet is that getting the basic categories right is most of the work, everything else is combination.
Tokenization and embeddings make a version of this bet, silently, early, and rarely revisited. But the sharper version of the idea, the one that changed how I think about knowledge systems generally, is Vaisheshika's insistence that absence is its own category, not just a null value. A system that can only represent what it knows, with no structured way to represent what it has explicitly failed to find out, is missing half the ontology. This is, again, closer to home for me than a pure analogy. I'll leave exactly how much closer for another post.
Samkhya: separate the observer from the substance
Samkhya draws a hard line between purusha, the witnessing principle, and prakriti, the material substrate that changes and combines. Whatever one thinks of that as metaphysics, as an engineering habit it's excellent: know what part of your system is watching and deciding, and keep it distinct from the part that is raw computation, weights, and context.
The architectures that hold up under load tend to respect this separation. The ones that don't usually conflated the two early, orchestration logic quietly buried inside a prompt, or a model expected to both generate content and judge its own output with no separation between the two roles.
Yoga: an insight without a practice stays theoretical
Yoga is traditionally paired with Samkhya as its applied discipline, the repeatable practice that turns the distinction into something operational rather than just understood. Samkhya tells you what's different, Yoga is the method for acting on it consistently.
This is evaluation loops, retraining discipline, and the unglamorous operational work that never makes it into a keynote. An architecture diagram that correctly separates concerns is worth nothing without the repeatable practice of testing, measuring, and refining that keeps the separation real in production. Plenty of good architecture dies from the absence of this discipline, not from a flawed design.
Purva Mimamsa: precision in interpreting the rule
Purva Mimamsa is the school of ritual interpretation, an extremely literal, rule-focused discipline built around correctly reading injunctions and resolving ambiguity in how they should be carried out. Centuries of commentary exist purely to settle what a given instruction actually requires.
Anyone who has debugged a prompt that was technically followed but produced the wrong action has run into this exact problem. Instruction-following is an interpretation exercise, and ambiguity in the rule produces unreliable behavior no matter how capable the underlying model is. The discipline Purva Mimamsa brings, treat the instruction as something requiring precise, checkable interpretation rather than a vibe, is directly transferable to how I think about prompt and policy design.
Vedanta: the debate that still isn't settled
Vedanta asks how the particular relates to the universal, and its own sub-schools disagree with each other about how unified reality actually is. Some argue for a strict non-dualism, others for a qualified version that preserves real distinctions within the whole.
That disagreement never fully resolved within the tradition, and I don't think it's an accident that AI architecture is having a version of the same argument right now. Is the right shape one large, unified model doing everything, or a compositional system of specialized modules and agents coordinating with each other. Neither side has won, and I suspect, like Vedanta's sub-schools, both will keep finding legitimate ground to stand on for a long time. We've sketched what a Vedanta-informed synthesis step could look like on our own roadmap. It's not built yet, so there's nothing concrete to say about it here beyond that the question is live for us too, not just academically.
What the six schools actually taught me
Not one of these six systems agrees with the others on the answer. What they share is a discipline: define your terms before you argue, name your assumptions before you build on them, and be explicit about what counts as valid knowledge before treating anything as settled. That habit, more than any specific mapping above, is the part worth borrowing. A surprising amount of what goes wrong in deployed AI systems traces back to skipping exactly that step, and it's the same habit I keep having to relearn in my own team's architecture decisions, not just in what I read about everyone else's.