⚙️ Jankrish Project 📄 Paper GitHub ↗
An independent research project

Human-readable. Machine-verifiable.

A constructed language for deterministic computing. Jankrish explores whether one representation can serve, at the same time and without ambiguity, as language, executable specification, audit trail, and communication protocol.

✓a language a person can read
✓an executable specification software runs by fixed rules
✓an audit trail that can't be quietly rewritten
✓a communication protocol between humans and machines
8
applications
125
tests passing
100%
deterministic · 0 silent-wrong
~0.03 ms
per query · no model
stdlib
pure-Python core
Why it matters

Today, humans and machines keep two different records.

A person reads a sentence. A computer verifies a payload. Software translates between them — and nothing guarantees the two describe the same decision. Every hop is a chance for them to drift apart.

Two records — drift at every hop
human→ sentence⇄ software⇄ JSON→ database⇄ explanation→ audit
The sentence a person reads is generated from the payload a machine checks. That generator can carry bugs, change over time, or be told to say something different. Nothing proves the two agree.
One canonical record
human→ Jankrish→ everything
The sentence a person reads is the string software verifies — the same bytes, no translation step. There is only one source of truth, so there is nothing to diverge.
See the three design principles behind the guarantee →
What makes Jankrish different

English words. Grammar borrowed from two older languages.

Meaning lives inside each word, not in its position — so word order becomes optional and the parse is deterministic. Three lineages, each doing one job:

English

Readable roots

The vocabulary is ordinary English words, so a person can still read the sentence. The root is opaque payload — the parser never has to understand it.

chef · book · give · refund
Sanskrit

Structure inside the word

Number and tense are welded into the word as inflection — so grammatical structure travels with the word instead of depending on where it sits.

book → book·au (two books)
Japanese

Invariant particles

A small, fixed set of particles tags each word's role — subject, object, recipient. The machine reads the tag and never has to guess what attaches to what.

ga subject · o object · ni to
See it yourself

Scramble the words. The meaning doesn't move.

Because every word carries its own role, order is decoration. Shuffle a sentence and the parse is byte-identical — try it live.

chefasga  bookauo  studentasni  giveati
   ≡   studentasni  giveati  bookauo  chefasga
Both say "the chef gives two books to the student." The parse is identical either way.
Applications

The same engine, pointed at different problems.

Every application shares one guarantee: it compiles meaning by fixed rules, or it refuses — never a silent wrong answer.

Juard — guardrail for AI SQL product
Verify an LLM's SQL before it runs — read-only and every identifier real — or deny it with a named reason.
Deterministic text-to-SQL
Ask your data in English; it compiles to SQL by rule, on your own infra — nothing sent to a model.
Drift-proof retrieval
Weld each fact to its noun so a retrieved chunk can't attach a date to the wrong part.
Try all eight applications live →
Going deeper
The research
Three design principles — local completeness, distributed redundancy, external grounding — and the correctness proofs behind the guarantee. Read the whitepaper.
The language
The grammar, worked examples, and the deterministic parser — a technical specification of how a sentence becomes structure.
The story
Why this exists at all. It started with a cognitive win after learning Hiragana — and became a question about human–machine communication.
Research

One representation for humans and machines — by construction.

Jankrish is a design experiment: if you weld each word's grammatical role into the word, a sentence stops being ambiguous to a machine while staying readable to a person. Three principles make that work, and the technical paper carries the formal grammar, the parsing algorithm, and the correctness proofs.

01

Local completeness

Every word carries its full grammatical role locally — number and tense as inflection, role as a particle. The parser never needs the rest of the sentence to know what a word is doing. If a role can't be determined, parsing fails rather than guessing: the constraint points one way, toward refusal, never toward an invented answer.

02

Distributed redundancy

Because role is marked on each word rather than by position, the information that fixes meaning is spread across the words themselves. Shuffling the sentence rearranges nothing that matters — the structure survives any word order, which is exactly what makes two phrasings of the same decision produce one identical, hashable parse.

03

External grounding

Roots are opaque payload. The machine never trusts what the text claims — at execution it re-resolves each root against the world: does this order exist, is this really the balance, is this within policy. Determinism lives inside the language; truth is checked outside it. The result runs and is recorded, or it is refused with a named reason.

Read the technical paper — grammar, parsing algorithm, proofs, benchmarks →
The language

A specification you can read in three minutes.

English roots, Sanskrit inflection, Japanese particles. Meaning lives inside each word, so word order is optional and every valid sentence has exactly one interpretation.

Particles — a word's role

A small, fixed set of suffixes tags what each word does in the sentence. The parser reads the tag; it never guesses.

ParticleRoleReads as
gasubjectwho acts
oobjectwhat is acted on
nirecipient / directionto whom / to where
deinstrument / meanswith what
watopicas for…
nogenitiveof / belonging to

Inflection — number and tense, welded in

Number rides on the noun as a suffix, so grammatical detail travels with the word instead of depending on where it sits.

SuffixNumberExample
-asonebook·as → a book
-autwobook·au → two books
-āsmanybook·ās → books

Verbs carry tense the same way (present -ati, with a prefix for the past). When two heads share a signature, an optional trailing digit keeps them distinct.

A worked example

Read the pieces of each word, and the sentence assembles itself regardless of order:

chef·as·ga   book·au·o   student·as·ni   give·ati
  subject       object (×2)      recipient        verb
“the chef gives two books to the student.” Rearrange the four words and the parse does not change.

The parser

Parsing is a deterministic segmentation — strip the particle, read the number, keep the root as payload — with no statistics and no model in the loop. It runs in about 0.03 ms per sentence on the pure-Python core. Every valid sentence has one parse; anything it can't resolve is refused, not approximated.

Compile and shuffle a sentence yourself →  ·  Full formal grammar (BNF) in the paper →
Playground

English → Jankrish → shuffle → still parses.

Type an ordinary English sentence. It compiles to Jankrish, gets scrambled into a different word order, and both orderings parse to the identical structure — live, no model.

The story

It started with a cognitive win.

⚙️
Mohit Mishra
Creator of Jankrish

I had just finished learning Hiragana. It was slow, humbling work, and when it finally clicked I wanted a cognitive win — something to build with the new shapes rattling around in my head.

What stuck with me was how Japanese marks a word's job with a tiny particle — this one is the subject, that one is the object — no matter where the word sits. English makes you infer all of that from word order. I started wondering what a language would look like if it took that idea to the limit: every word carrying its own role, so order stopped mattering at all.

I'd also studied the basics of Sanskrit, where number, tense, and case are welded straight into the word as inflection — so a word's grammar travels with it instead of depending on where it lands. Put those two instincts together and the shape of Jankrish falls out: English roots you can read, Sanskrit inflection carrying the structure inside each word, and Japanese particles tagging each word's role. Three languages, each doing the one thing it does best.

If a word always tells you what it's doing, a machine never has to guess — and if a machine never has to guess, the sentence a person reads can be the exact thing a computer verifies.

That question — can one representation be readable by people and verifiable by machines at the same time — turned out to be bigger than a puzzle. It became Jankrish: a language, a parser, and a growing set of applications where being unambiguous is the whole point.

Read the full story on Substack →

About the project

Jankrish is an independent research project exploring whether language can serve simultaneously as a human communication medium and a deterministic computational representation. It investigates topics spanning linguistics, programming languages, information theory, AI safety, and human–computer interaction — with applications including explainable AI, agent communication, deterministic compilation, verifiable digital records, and even a card game.

Language→ Parser→ Text-to-SQL→ Guardrail→ Agent ledger→ Future

Applications

Each is the same engine pointed at a different target — text-to-SQL, a data guardrail, drift-proof retrieval, a compact wire format, a flat parse graph, an agent action ledger, even a card game. All share one guarantee: deterministic, or it refuses. Pick a product and try it live.

Text-to-SQL
JQL Compiler
Hybrid Router
Parser
Serialize
Star-Graph
RAG Anchor
Syntax Clash
Juard
Agent Ledger
Benchmarks
text_to_sql

Ask your data in English — safely enough to show a regulator

ProblemA finance analyst asks an "ask-your-data" bot for last quarter's enterprise revenue; it silently joins the wrong table, the wrong figure lands in a board deck — and the query shipped your data to a third-party API.
WhyAn LLM writes SQL by predicting plausible tokens from training patterns — it has no model of your schema, can't check a column exists or a join is right, and samples differently each run. Fluent, ungrounded, non-deterministic.
SolutionCompile the question to SQL against your real schema, on your own infra — or refuse if it can't be grounded.
HowThe question becomes an unambiguous Jankrish structure; a compiler binds each part to a real table/column by fixed rules. Anything it can't bind it refuses instead of inventing — and nothing leaves the box.
English question→nl2jql→ JQL→compile→ SQL→run on demo DB
deterministic — refuses instead of guessing
JQL · the Jankrish Query Layer

Why deterministic text-to-SQL is even possible

ProblemAsk the same text-to-SQL LLM "how many active users last month?" twice and you can get two different queries and two different counts.
WhyLLM output is sampled from a probability distribution over tokens — text→SQL is a guess, not a function, so nothing guarantees the same (or a correct) result twice.
SolutionExpress the query in a controlled form a compiler turns into SQL by fixed rules — same input, same SQL, always.
HowJQL makes each SQL construct one self-contained Jankrish word block carrying its own role, so the map to SQL is a pure function and order is irrelevant. Scramble the blocks — the SQL is identical.
JQL stream→compile→ SQL→run — word order is irrelevant; try scrambling the blocks
the core language engine

The one property that makes everything else trustworthy

ProblemExtract data from "the invoice from the vendor that was overdue" — was the invoice or the vendor overdue? Models guess, and guess inconsistently.
WhyEnglish marks grammatical role by position and function words, so a parser (or an attention head) must infer which noun attaches to what — a probabilistic guess that goes wrong (attachment ambiguity).
SolutionA representation where each word states its own role, so there is nothing left to infer.
HowJankrish welds role/number/tense into each word as fixed tags; the parser just reads them — order carries no information, so meaning can't shift. Hit Scramble & verify to watch the parse stay identical.
Jankrish stream→parse→ order-independent structure + English gloss
text_to_sql · the hybrid router

An LLM's flexibility without its hallucinations

ProblemYour BI dashboard can't answer a question nobody pre-built ("churn by region for trial users"); the LLM alternative invents a churn_rate column that doesn't exist and returns a plausible, wrong number.
WhyA rigid system only covers what you explicitly built; an LLM covers everything but is ungrounded, so it hallucinates columns and joins. Neither alone is both broad and safe.
SolutionA router: deterministic first, an LLM only for the tail, with a safety gate on the model's output. Set JANKRISH_LLM_BASE_URL (e.g. local Ollama) to enable it.
HowGround & compile what it can; refuse the rest to an LLM, then re-check the model's SQL against your schema (any non-existent column is rejected) and flag it for confirmation. The verifier is deterministic — the model can't slip a wrong column through.
question→deterministic linker→ ✅ compile — or, if refused → verified LLM fallback→confirm
deterministic when it can ground; else a schema-verified model answer
serialize · Jankrish as a data format

Half the bytes of JSON — and it survives a bad connection

ProblemA field sensor on a flaky cellular link sends a JSON packet; one dropped byte in the braces corrupts the whole message — and half the packet was just { } " : ,.
WhyJSON encodes structure out-of-band — meaning lives in the surrounding punctuation and key order, not the values — so the syntax is large, and losing one brace makes the whole thing unparseable.
SolutionEncode structure in-band, inside each word — no punctuation to lose, no order to preserve.
HowJankrish bakes the field's key into the word (its role particle): ~54% smaller, and a corrupted word loses one field, not the packet — any order still decodes. (Decode a wire below.)
star_graph · vs the English AST

Why a machine reads this faster — and can't misattach

ProblemA semantic-search pipeline parses millions of support tickets; each sentence builds and walks a deep tree just to find who-did-what — burning CPU and mis-attaching modifiers.
WhyBecause English marks roles by position, a parser must build a nested tree (NounPhrase → PrepPhrase → …) and recursively resolve which node attaches where — O(depth) work, and ambiguous.
SolutionA flat graph with no nesting to walk or resolve.
HowEach Jankrish noun names its own role (a particle), so the parser links it straight to the verb hub in one hop — no tree, O(1) routing, no ambiguous attachment.
rag_anchor · zero-hallucination retrieval

Stop RAG pipelines from hallucinating on the text they retrieve

ProblemA RAG assistant over a compliance manual cites the wrong manufacturing date because the retrieved sentence — "…the valve beneath the tank which was made before 2024" — attached the date to the wrong part.
WhyA relative clause attaches by proximity and context, which an LLM's attention resolves probabilistically; chunk and inject that text and the fragile attachment can bind to the wrong noun.
SolutionEncode the retrieved fact so its attachment is explicit and unbreakable.
HowJankrish gives the modifier the same number+particle tag as its target noun; the binding is by tag-match, not position, so it survives chunking/reordering and can't drift. (See the bindings below.)
syntax_clash · the core idea, made playable

Feel free word order — in a card game you can't cheat at

Problem"Word order doesn't matter" sounds like a slogan until you feel it. And game engines that read a player's move usually accept a malformed one silently, then resolve something nobody intended.
WhyIn a normal card game the layout is the move — position carries meaning, so you can't shuffle it, and an illegal arrangement still gets interpreted somehow.
SolutionWeld each card's role onto the card (a case particle), so the engine reads who-does-what-to-whom from the tags, not the arrangement — and refuses an illegal proclamation instead of guessing.
HowSame Jankrish core: -ga subject, -o object, -de instrument. Scramble the words — the resolved meaning is identical, or it's refused as an illegal move. The duel below runs the exact grammar this platform compiles.
1-vs-AI, opens in a new tab
proclamation→resolve (order-independent)→ one meaning — or refused if illegal
sql_guardrail · the safety gate as a product

Stop your AI analytics bot from running a DELETE — or a hallucinated column

ProblemYou ship an "ask-your-data" feature and someone senior asks "what stops it running a DELETE?" An LLM can also emit a valid-looking query over a column that doesn't exist (revenue), returning a plausible wrong number.
WhyThe model writes SQL by predicting tokens — it has no guaranteed model of your schema and no notion of "read-only," so a hallucinated identifier or a write smuggled into a WITH … DELETE can reach the database.
SolutionA deterministic gate in front of the DB: verify every statement — read-only and every identifier grounded to the real catalogue — before it executes, or deny it with a named reason. It does not replace your LLM.
HowSame ground-or-refuse engine: check the operation, reject statement stacking, match every table/column against the introspected schema, and run only on a read-only connection. A denial names exactly what was wrong, clean enough to show a user.
this tab is the engine; Juard is the hosted product
LLM SQL→guardrail: read-only?→ every identifier real?→ ✅ allow /🛑 deny + reason
demo catalogue: customer · account · transaction
agent_ledger (JAL) · where Jankrish is load-bearing

An execution boundary for AI agents — the record is the cause of what ran

ProblemOnce an AI acts — refunds, cancels, account changes — someone must answer what it did and why that was allowed. Today that's a transcript no computer can check and logs no person will read, and they don't have to agree.
WhyThe artifact a human trusts and the one the machine ran are two different things generated from each other — so they can drift, and nobody can prove they match.
SolutionThe agent emits an ordinary tool call; the executor writes the Jankrish, grounds every term against real records, checks policy, signs it, runs it, chains it. The action exists because the instruction compiled, so the record can't diverge from what happened.
HowOne artifact projects to both a human gloss and the executed action from the same parse; canonical form makes decisions hashable and replay-suppressed; ground-or-refuse means an action exists only if it compiled. Per-tool observe / shadow / gate modes, stamped into each signed record. Connect any agent over MCP.
MCP endpoint · signed chain · tamper demo · enforcement modes · run the agents
measured, reproducible

Why you can trust the numbers

ProblemA text-to-SQL vendor cites "95% on Spider" — but you can't reproduce it, can't tell if it holds on your schema, and don't know which 5% silently lies.
WhyAggregate accuracy on a benchmark never tells you when it's wrong — and "wrong" here is a fluent query returning a plausible false number, invisible at a glance.
SolutionMeasure live and per-app, and track the one metric that governs trust.
HowEvery figure is computed from the running code on demand; and because each app is deterministic-or-refuses, silent-wrong = 0 is a real, checkable guarantee — not an average.

Pick a report above.

← Applications
Powered by Jankrish · deterministic · 0 silent-allow

Juard — a guardrail for AI-generated SQL

Your analytics bot lets an LLM write SQL. Juard sits in front of your database and verifies every statement — read-only, and every identifier real — before it runs, or denies it with a reason clean enough to show a user. It does not replace your model, and it can't run a DELETE.

Try it — no integration required

Loading catalogue…

Every check is recorded in the dashboard below — that's the whole product.

Your dashboard

The value is invisible when it works — so the product makes it visible. This is a live demo dashboard seeded with a week of traffic; your live checks above are added to it.

Top rejected identifiers — what your model keeps reaching for

Recent audit trail

timestamp · question · SQL · verdict · reason · executed · verification active

How it works

Two deterministic gates stand between the model and your database. A statement must pass both — and it never executes to be judged.

Gate 1

Read-only

Must be a single SELECT/WITH query. Statement stacking, DDL, and writes — including a write smuggled into a WITH … DELETE — are rejected.

Gate 2

Identifier grounding

Every table and column is matched against the introspected catalogue. A hallucinated identifier is caught at prepare time, against no data — and the query then runs on a read-only connection.

If Juard is ever unreachable, a proxy can fail-open to keep analytics up — but each such line is recorded verification_active: false, so it's never a silent hole.

Integration

Evaluate with one HTTP call; adopt by switching one environment variable in staging. No LLM change.

Verify over HTTP (this endpoint is live)

curl -s https://jankrish.com/juard/verify \
  -H 'content-type: application/json' \
  -d '{"sql":"SELECT revenue FROM customer"}'

# → {"verdict":"deny",
#    "reason":"query referenced column `revenue`, which does not exist in this database",
#    "identifier":"revenue", "audit":{…}}

Or as a gate in your data path

verdict = juard.check(llm_sql, catalog)      # deterministic, sub-millisecond
if verdict.allowed:
    rows = conn.execute(llm_sql)             # on a read-only connection
else:
    return {"error": verdict.reason}         # clean enough to show the user

Developer API — get a key

Self-serve an API key and call the authenticated, persistent product API (/juard/v1/*). Your audit history is private to your tenant and survives restarts — a real SQLite store, not the shared demo above.

Pricing

The free tier keeps a full audit trail ready — so when an audit, a security review, or a near-miss makes retained history and export suddenly necessary, the evidence is already there. That's what the paid tiers retain for you.

 
Free
$0
For evaluating and small projects.
  • 1 database
  • Live verification (read-only + grounding)
  • 7-day audit history
  • Community support
Most popular
Pro
$49 / mo
For teams shipping an AI analytics feature.
  • Up to 5 databases
  • Unlimited retained history
  • Weekly digest email (the feedback signal)
  • CSV / JSON audit export
  • Slack & webhook alerts
  • Email support
 
Enterprise
Custom
For regulated & audited environments.
  • Unlimited databases
  • Tamper-evident audit store
  • SSO / SAML, RBAC
  • On-prem / VPC deployment
  • SLA & dedicated support

Honest note — demo vs. production

The verification engine here is real, deterministic, and the same code the paper proves sound. The dashboard on this page is a live in-memory demo shared across visitors and reset on redeploy. Production Juard adds persistent, per-tenant, tamper-evident storage, authentication, and multi-database coverage — none of which change the engine.

JAL · Jankrish Agent Ledger · connect over MCP

Let your AI agents act — accountably.

Point any agent at JAL over MCP. Every tool call it makes is grounded against your live records, checked against your policy, and sealed into a signed, hash-chained record — one line a human reads and a machine verifies, that can't be quietly rewritten or bypassed.

Connect an agent (MCP)

This is a live MCP endpoint (Streamable HTTP, Bearer-authenticated). Point claude.ai or Claude Desktop at it — every tool the agent calls is recorded below, in the same ledger.

Endpoint


      
Claude Desktop / claude.ai config

      

      

    

  


  
  

    
The ledger

    
Run a scripted agent to watch records land live, or call a tool yourself. Each record is grounded, policy-checked, signed, and linked to the one before it.

    

      
      
      
      
    

    

    

    
  


  
  

    
Call a tool yourself

    
An ordinary {tool, args} call — the executor canonicalises it into Jankrish and compiles from that. The agent never writes Jankrish.

    

      
      
      
    

    

  


  
  

    
Enforcement modes

    
observe records only · shadow records what a gate would block · gate blocks in the critical path. The mode and its guarantee (caused vs recorded) are stamped into every signed record.

    

  


  
  

    
Why the record can be trusted

    

      

        
Tamper-evident
Falsify a record

        
Rewrite an executed record's human line to a lie. Verification re-derives the line from the stored instruction and catches it on that exact field.

        

          
          
        

        

      

      

        
No bypass
Attempt a direct call

        
Try to reach a side effect without compiling an instruction through the executor. There is no un-gated path — the record is the antecedent of every action.

        

        

      

    

  


  
  

    
Grounded world

    
The live records the executor resolves against — never the agent's claims.

    

  


  
  

    
Get your workspace

    
A workspace gives you an API key for the MCP endpoint and your own persistent, verifiable, exportable ledger.