दर्शनम् · foundations
दर्शनम्॥
More code is generated than ever. Karaka makes the parts that carry authority and consequence explain themselves, so the humans, auditors, and policy engines that have to trust that code can actually read it. This is the why: the thesis, the one-screen review grammar, a computational formalization of classical reasoning, and the kit that generates Karaka from plain language.
सिद्धान्तः · the thesis
Accountability by default, not by convention॥
The opportunity is not that developers will learn to write Sanskrit code. It is that AI will write Karaka, and humans, auditors, platform teams, and policy engines will be able to read it. When the model writes the syntax, the ergonomics of writing stop being a moat. The properties that matter move downstream of authorship: easier to verify, to audit, to generate correctly, to review, to govern, to explain.
AI-generated code has one structural weakness. It produces working-looking code with no explicit account of responsibility, intent, evidence, or authority. A model might emit this:
transfer(src, dst, amount)It runs. It also hides everything a reviewer actually needs to ask: who is the actor, what is being acted on, what is the source, what is the destination, what policy permitted this, what evidence was used, what will be recorded. Positional arguments carry none of that, and the reconstruction of intent from names and context is exactly where errors and policy bypasses hide.
Karaka forces those questions into the shape of the program. Every meaningful action declares its कारक roles, so ambiguity has nowhere to hide:
हस्तान्तरणम्(
कर्ता: ग्राहकः, # actor
अपादानम्: खातम्१, # source
सम्प्रदानम्: खातम्२, # recipient
कर्म: ५०००, # object
अधिकरणम्: सत्रम् # context / locus
)The honest part of the claim, stated plainly: you can write accountable, role-explicit code in any serious language. Python keyword arguments, TypeScript types, Rust structs, Rego or Cedar policies, SQL lineage metadata. Existing languages are not wrong. They are just not shaped for this. In all of them, semantic accountability lives outside the language: a logging library, a policy engine, a naming convention, audit middleware, code-review discipline. The compiler does not care whether an action names its actor, object, source, instrument, context, or evidence. So accountability is optional, and optional accountability is what fails under volume.
Karaka's claim is narrower and stronger. It makes accountability the default shape of the program, not a convention each team has to remember. The roles, the rule, the evidence, and the trace are the grammar of meaningful action, not afterthoughts bolted on per team. The roles are present, or they are visibly absent and the lint says so.
And the moat is not the syntax. It is the runtime artifact. The pipeline runs कारक source through role-checked execution, attaches प्रमाणम् evidence, and emits the अभिलेख trace as an audit, provenance, and lineage record by construction. The code is half the product. The trace is the other half, and it is the half the market is short on.
अनुशीलनम् · the review grammar
The review grammar fits on one screen॥
A human does not have to master Karaka the way they master Rust. They have to be able to review it, and reviewing role-declared code is a one-page mental model. AI generates the rest.
| role | what it names |
|---|---|
कर्ता | who acts (actor / agent) |
कर्म | what is acted on (object) |
करणम् | instrument / tool / means |
सम्प्रदानम् | recipient (to whom) |
अपादानम् | source (from where) |
अधिकरणम् | context / locus / session |
नियमः | rule |
प्रमाणम् | evidence |
फलम् | result |
दोषः | failure |
That is the whole vocabulary a reviewer needs. Here is a tiny role-declared rule and the अभिलेख it produces. Edit it, run it in place, or open it in the playground.
शास्त्र-गणना · classical reasoning, formalized
Computational formalization of classical reasoning॥
A formal language can make a body of reasoning explicit, executable, checkable, and reproducible. It cannot make a tradition true. Karaka can establish the internal consistency of a rule set, the derivability of a conclusion from stated premises, and decidable conformance of a case to those rules. That is real rigor, in the way formal verification is rigorous.
Whether a tradition's claims about the world are true is a separate, empirical question that data and experiment answer, not a language. This section formalizes arguments. It does not claim to prove any tradition.
The point is that the same नियम / प्रमाणम् / अभिलेख engine that decides an agent's tool call also runs over a humanities corpus, pointed at a different kind of rule. Two demos run in current Karaka.
धर्मसंकटःa defeasible duty
A classic Mahābhārata dilemma. Truth-telling is the general duty; protecting an innocent life is the more specific, higher duty. Dharma is sūkṣma, subtle: the specific duty defeats the general one. This is defeasible reasoning by specificity, the Mīmāṃsā pattern. The trace records which duty applied and why. It formalizes the moral argument; it does not claim the tradition is true.
अनुमानम्inference, grounded in its means of knowledge
The classic Nyāya inference: the hill has fire because it has smoke. The conclusion is grounded in its pramāṇas, the valid means of knowledge: perception of smoke on the locus, and the invariable concomitance that wherever there is smoke there is fire. The trace records which pramāṇa grounds the inference, so the conclusion is auditable rather than asserted. Be honest about depth: Navya-Nyāya has technical structure that resists naive formalization. Karaka models the shape of pramāṇa-traceable inference, not the full calculus.
क्षेत्रे स्थानम् · prior art
Where this sits in the field॥
Formalizing classical Indian reasoning is an established, active research program at serious venues. Karaka is positioned relative to it, not as the inventor of the idea. What is far less developed is an executable, role-native, trace-producing substrate for that reasoning, generated and checked with AI in the loop. That is the opening.
- Mīmāṃsā deontic logic. Agata Ciabattoni's logic group with the indologist Elisa Freschi turned the Mīmāṃsā school's rules for interpreting Vedic injunctions into formal deontic systems, resolving conflicting injunctions by specificity, published in Artificial Intelligence and Law. This is the closest serious prior art, and the same defeasible-by-specificity pattern the dharma demo uses. AI & Law paper · Rules and Logic of Mīmāṃsā
- Navya-Nyāya formalization. A lineage from Matilal (first-order logic) to Ganeri (higher-order) to type-theoretic treatments. A 2026 paper, Pramana, makes LLM reasoning auditable by grounding each step in a pramāṇa, independently the same idea as Karaka's प्रमाणम् and अभिलेख. Later Nyāya Logic: Computational Aspects · Pramana (arXiv)
- Defeasible deontic logic and LegalRuleML. The Western formal home for obligations, permissions, prohibitions, and conflict resolution by priority. Recent work formalizes legal text into defeasible deontic logic with LLMs, a direct parallel to the NL-to-Karaka idea in the legal domain. Reasoning with LegalRuleML · Legal texts to DDL via LLMs
- Computational ethics adjacents. Automated Kantian ethics and policy-as-code for AI regulation show that formalizing a normative tradition into executable rules is a recognized move. Automated Kantian Ethics · ArGen: policy-as-code
Karaka's distinct contribution is to be the runnable, inspectable substrate. Roles are first-class, so who-acts-on-what-with-what-authority is in the program shape. Evidence and trace are primitives, so a formalized norm does not just decide, it produces an auditable justification automatically. And AI generates the formalization, validated by the compiler in the loop. That is the same shape as the legal-text-to-logic work, pointed at a śāstric corpus.
Karaka is also the representation layer of a larger franchise, and that coherence is a moat no single competitor holds:
उपकरणम् · the kit
Generate Karaka with your AI assistant॥
The whole adoption thesis is that a model needs only about one page of context to generate correct, reviewable Karaka. Paste the kit below as context, describe the action or rule in plain language, and validate the output in the क्रीडास्थलम्. In early testing, five plain-English governance requests, generated by fresh models from this kit alone, all produced runnable, semantically correct Karaka once the kit itself was correct. The instructive part: the first-round failures were models faithfully copying a defect in the kit, which the compiler caught at once. The mechanism is not trust the model, it is kit plus validator in the loop.
# Karaka Generation Kit (NL → Karaka)
This is the in-context reference for generating Karaka from a natural-language
request. It is deliberately ~one page: the whole adoption thesis is that a model
needs only this much context to generate correct, reviewable Karaka. Everything
below is current v0.1 syntax (no unbuilt features).
## What Karaka is
A Sanskrit-native, role-semantic language. Every meaningful action names its
kāraka roles, so who-did-what-to-what-with-what-authority is explicit in the code.
## The role glossary (the review grammar)
कर्ता who acts (actor / agent)
कर्म what is acted on (object)
करणम् instrument / tool / means
सम्प्रदानम् recipient (to whom)
अपादानम् source (from where)
अधिकरणम् context / locus / session
## Core constructs
# comment
प्रारम्भः # the main program block; everything top-level runs here
...
समाप्त # every block (प्रारम्भः, क्रिया, नियमः, जातिः, यदि) closes with समाप्त
लिख(x) # print; parentheses are REQUIRED
नाम = मूल्यम् # assignment (e.g. क = १००)
# numbers use Devanagari digits ०१२३४५६७८९ ; decimals use a dot (३.१४)
# strings: "..." with {interp} interpolation, e.g. "नमस्ते {नाम}"
# lists: [१, २, ३]
# booleans: सत्य (true) / मिथ्या (false)
# decisions (for नियम rules): अनुमतम् (permit) / निषिद्धम् (deny) / अनिश्चितम् (uncertain)
# comparison: == < > <= >= arithmetic: + - * /
# member access: कर्ता.भूमिका , अधिकरणम्.ग्राहकः.प्रमाणितः
### जातिः: a type with fields
जातिः उपयोगकर्ता
गुणः भूमिका: वाक्यम् # गुणः declares a field; type names: वाक्यम्=string, संख्या=number, सत्यता=boolean
गुणः चल सक्रियः: सत्यता # गुणः चल = a MUTABLE field; the TYPE is सत्यता, the VALUES are सत्य/मिथ्या
समाप्त
# Construct with named fields: उपयोगकर्ता(भूमिका: "व्यवस्थापकः", सक्रियः: सत्य)
# CRITICAL: a field's type is a TYPE NAME (वाक्यम्, संख्या, सत्यता, or a जातिः name), never a value.
# Write गुणः सक्रियः: सत्यता (type), not गुणः सक्रियः: सत्य (value).
### क्रिया: an action (returns a value with फलम्)
क्रिया हस्तान्तरणम्
अपेक्षते # declare the roles this action expects
अपादानम्: खातम्
सम्प्रदानम्: खातम्
कर्म: संख्या
यदि अपादानम्.शेषः < कर्म तदा
दोषः "अपर्याप्तः शेषः" # दोषः returns a failure value (no crash)
समाप्त
अपादानम्.शेषः = अपादानम्.शेषः - कर्म
सम्प्रदानम्.शेषः = सम्प्रदानम्.शेषः + कर्म
फलम् सत्य # फलम् = return
समाप्त
# Call with roles: हस्तान्तरणम्(अपादानम्: क१, सम्प्रदानम्: क२, कर्म: ३०)
### नियमः: a policy rule (returns a decision, records evidence)
नियमः प्रवेश-अनुमतिः
अपेक्षते
कर्ता: उपयोगकर्ता
यदि कर्ता.सक्रियः == मिथ्या तदा
प्रमाणम् "खाता-निष्क्रियः" # प्रमाणम् attaches evidence to the branch taken
फलम् निषिद्धम्
समाप्त
यदि कर्ता.भूमिका == "व्यवस्थापकः" तदा
प्रमाणम् "व्यवस्थापक-भूमिका"
फलम् अनुमतम्
अन्यथा
प्रमाणम् "अपर्याप्त-अधिकारः"
फलम् निषिद्धम्
समाप्त
समाप्त
# Multi-condition: put च (and) / वा (or) at the START of a continuation line:
# यदि कर्ता.भूमिका == "support"
# च कर्म.मूल्यम् <= ५००० तदा
# Chain branches with अन्यथा यदि ... तदा and a final अन्यथा.
## Generation rules (follow exactly)
1. Close EVERY block with समाप्त (program, क्रिया, नियमः, जातिः, and each यदि/अन्यथा chain).
2. A keyword and the name it introduces go on the SAME line (क्रिया नाम, नियमः नाम, जातिः नाम).
3. Definitions (जातिः/क्रिया/नियमः) go at the top level, before प्रारम्भः.
4. A नियमः must return a decision (अनुमतम्/निषिद्धम्/अनिश्चितम्) on EVERY branch, and should attach प्रमाणम् "..." evidence on each branch.
5. लिख always takes parentheses: लिख(x).
6. Reserved words you must NOT use as names: न (negation), प्रमाणम्, कर्म, कर्ता, the role words, and the keywords above.
7. Use Devanagari digits (५०००, not 5000).
8. Prefer role-declared क्रिया/नियमः (with अपेक्षते) for any action that has an actor, object, authority, or consequence. That is the whole point of the language.
9. To FAIL inside a क्रिया, write दोषः "message" as its own statement on its own line. Never write फलम् दोषः ...; दोषः is a statement, not a returnable expression.
10. Output ONLY the Karaka program. No prose, no explanation.
Karaka formalizes reasoning. It makes a rule set explicit, executable, checkable, and reproducible, and it produces an audit trail by construction. It does not prove that any tradition's claims about the world are true.
For a codified rulebook such as Vastu, mainstream scientific consensus is that it lacks empirical support. The only honest use is conformance checking: does a given layout satisfy the stated rules, framed as constraint satisfaction. Conformance is decidable and checkable. Whether following the rules produces any real-world benefit is a separate empirical question Karaka must not pretend to answer.