{"slug": "ship-your-interpreter", "title": "Ship Your Interpreter", "summary": "Researchers at Basis, including Kiran Gopinathan, Nikhil Pimpalkhare, Yiyun Liu and Zenna Tavares, reported an experiment in which LLMs wrote a formal semantics for a small language and proved in Lean that it matches the language's real interpreter on every program, after compiling that interpreter to RISC-V, whose meaning is already formally defined. The team published the full semantics and proof on GitHub, arguing that specification, not theorem proving, is now the bottleneck for scaling verified software. The work follows Basis agents' April JavaScript-to-WebAssembly compiler and later verification of Linux's nftables compiler, and MIT researchers Frans Kaashoek and Nickolai Zeldovich's September verification of the xv6 kernel down to machine code.", "body_md": "# Ship Your Interpreter\n\nPublished:\n\n##### Article:\n[Kiran Gopinathan](https://www.basis.ai/about/people/kiran-gopinathan/), [Nikhil Pimpalkhare](https://www.basis.ai/about/people/nikhil-pimpalkhare/), [Yiyun Liu](https://www.basis.ai/about/people/yiyun-liu/), [Zenna Tavares](https://www.basis.ai/about/people/zenna-tavares/)\n\n[Kiran Gopinathan](https://www.basis.ai/about/people/kiran-gopinathan/)\n\nLLMs are growing alarmingly capable at finding and exploiting bugs in\nproduction software, with increasing reports of AI-assisted hacks\nin the wild.\nFortunately, LLMs are advancing quickly in their ability to write\n*verified software*: programs that come with mathematical proofs,\nchecked by a computer, that rule out entire classes of bugs.\nIn April, our agents [built a JavaScript-to-WebAssembly\ncompiler](https://www.basis.ai/blog/verified-compiler/) but could not prove that it preserved\nprogram behaviour. Months later, our agents [verified Linux’s nftables\ncompiler](https://www.basis.ai/blog/verified-nftables/), which translates firewall rules\ninto instructions the kernel executes. In September, MIT researchers\nFrans Kaashoek and Nickolai Zeldovich used AI agents to [verify the xv6\noperating-system kernel](https://arxiv.org/abs/2609.04043) down to its\nmachine code.\n\nOur goal at Basis is to develop verification methods that could plausibly scale to all software, so that the systems powering critical infrastructure are secure by design and keep pace with attackers’ growing capabilities. As LLMs advance in capability, the bottleneck is shifting away from theorem proving and towards the problem of specification: how can we be sure that the statements we prove capture the behaviour we actually care about?\n\nTo prove anything about a program, we first need a mathematical description of what it does.\nThis starts with describing the programming language it is written in: what every statement, loop, and function call means when it runs.\nThese descriptions are called a *formal semantics*, and can be written with pen and paper, but are increasingly expressed in a proof assistant such as Lean.\nA handful of languages have one (Standard ML, WebAssembly, and C via CompCert), as does the RISC-V instruction set that a growing number of processors execute.\nDeveloping each of these semantics took years of expert effort.\n\nMost programs, however, are written in languages that do not have a formal semantics, presenting a major bottleneck for deploying verified software at scale: without a semantics, there is nothing precise to prove against. A natural solution is to use LLMs to write semantics, but LLMs make mistakes, and a broken semantics undermines every proof built on it. Testing helps, but as we show below, a semantics can pass every test and still be wrong. What is needed is a means to verify the semantics itself.\n\nLanguages without a formal semantics still have interpreters or compilers, which in practice define what their programs mean. Here we consider a radical idea: make the LLM prove that its semantics agrees with the real interpreter on every program, treating the interpreter as ground truth. To do this, we compile the interpreter to RISC-V, whose meaning is already formally defined. That gives an exact, if unreadable, description of what the interpreter does with any program. The LLM then writes readable rules for the language and proves in Lean that, for every possible program, those rules predict exactly what the compiled interpreter prints. If a rule is wrong, the proof gets stuck.\n\nWe report on an experiment where we had LLMs develop a semantics and\nits proof together for a small language. We used Lean to prove that the interpreter, the\nprogram that runs code written in that language, follows those rules\neven after being compiled into low-level machine instructions. The\nwhole development, semantics and proof, is\n[on GitHub](https://github.com/BasisResearch/ship-your-interpreter).\nThe rest of this post walks through this\nexperiment, explaining first why semantics are the bottleneck for\nlarger verification efforts and why tests aren’t sufficient to build\ntrust in them. We then show how the proof process refined the semantics,\nhow we handled the memory reasoning, and what tools we built on the result.\n\n# Every verified program starts from a semantics\n\nBefore you can prove a program does anything, you have to define how\neach operation transforms its state, that is, define its *semantics*.\nMost languages describe their semantics informally in prose, in a\nreference manual, and leave the concrete details to the compiler or\ninterpreter implementation. A *formal*\nsemantics writes the rules down in mathematics, precisely enough for a\nproof checker like Lean 4 to use them. Notable examples include\nCompCert’s semantics for C, CakeML’s for ML, and JSCert’s for JavaScript.\nEach one took years of expert effort, and often covers only a restricted\nsubset of its language.\n\nFor this experiment we used an extended version of WHILE, the small\nimperative language used in textbooks such as Nielson and Nielson’s\n[*Semantics with Applications*](https://orbit.dtu.dk/en/publications/semantics-with-applications-a-formal-introduction/).\nOur version has integers, strings, first-class functions with closures, `if`, `while`\nand `for` loops, and runtime errors. Its interpreter is 1,855 lines of\nC, and a WHILE program looks like this (it prints 55):\n\n``` js\nvar i = 0;\nvar sum = 0;\nwhile (i < 10) {\n    i = i + 1;\n    sum = sum + i;\n}\nprintln(sum);\n```\n\nThe semantics an LLM wrote for WHILE is a set of rules, one for each kind of expression and statement. These rules describe how to evaluate an expression in terms of its subexpressions. For integer addition, the rule is:\n\n```\nst, env ⊢ l ⇓ a, st'    st', env ⊢ r ⇓ b, st''    a + b = c\n──────────────────────────────────────────────────────────\n                 st, env ⊢ l + r ⇓ c, st''\n```\n\nA rule reads from the bottom up. The line at the bottom is its\nconclusion. Starting from state `st` in environment `env`, the\nexpression `l + r` evaluates (`⇓`) to `c` and leaves state `st''`.\nThe state holds variable values, closures and everything printed so\nfar; the environment says which variables are in scope. The premises\nabove the line explain how the result follows from the subexpressions.\nFirst `l` evaluates to `a`, leaving state `st'`. Then `r` evaluates to\n`b` in that state, leaving `st''`. The final premise, `a + b = c`,\nadds the two integer values using WHILE’s 64-bit wrapping arithmetic.\n\nTake `(1 + 1) + x`, with state `[x ↦ 5]` and environment `{x}`:\n`x` holds 5 and is in scope. Applying the rule gives:\n\n```\n[x ↦ 5], {x} ⊢ (1 + 1) ⇓ 2, [x ↦ 5]    [x ↦ 5], {x} ⊢ x ⇓ 5, [x ↦ 5]\n                              2 + 5 = 7\n─────────────────────────────────────────────────────────────────────\n              [x ↦ 5], {x} ⊢ (1 + 1) + x ⇓ 7, [x ↦ 5]\n```\n\nThat is, to evaluate `(1 + 1) + x`, we first evaluate `(1 + 1)` to get\n2, then look up `x` to get 5, and add the two values to get 7. Neither\nsubexpression changes the state, so `[x ↦ 5]` remains unchanged.\n\nTo justify the first premise, we apply the addition rule again:\n\n```\n[x ↦ 5], {x} ⊢ 1 ⇓ 1, [x ↦ 5]    [x ↦ 5], {x} ⊢ 1 ⇓ 1, [x ↦ 5]\n                           1 + 1 = 2\n───────────────────────────────────────────────────────────────\n              [x ↦ 5], {x} ⊢ 1 + 1 ⇓ 2, [x ↦ 5]\n```\n\nThese rule applications form a tree that derives the value of the whole expression from the values of its parts.\n\nThe LLM wrote about 400 lines of rules like these, in Lean ([the full\nsemantics](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/Vsa/While/Semantics.lean)).\nEach rule looks reasonable on its own, but an end user has no rigorous\nway to tell whether they faithfully describe how WHILE programs behave\nwhen they are actually run.\n\n# A semantics can pass every test and still be wrong\n\nThe usual way to check a semantics is to run it. Take a test suite, run each program under the semantics and under the real interpreter, and compare what they print. Unfortunately, in practice, this process is insufficient to build trust in the generated semantics.\n\nFor example, an early version of our semantics passed the test suite generated for the WHILE interpreter, but disagreed with the binary when a function’s name reached 59 characters:\n\n```\nfn aaa…aaa() {}           // a name of 59 a's\nprintln(\"\" + aaa…aaa);\n\nsemantics:  <fn aaa…aaa>\nbinary:     <fn aaa…aaa\n```\n\nThe semantics said that concatenating a function with a string would\ninclude its full name between `<fn` and `>`. The binary dropped the\nclosing `>`, and for longer names it dropped part of the name too.\nNo test in the suite tried functions with names this long.\n\nThe reason is in the [C\ninterpreter](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/c/src/interp.c#L80)\nthat turns a value into a string when you concatenate it with `+`:\n\n```\nstatic char *stringify(Value v) {\n    ...\n    char buf[64];\n    switch (v.kind) {\n    ...\n    case VAL_FN: {\n        const char *name = v.as.fn->fn_expr->as.fn.name;\n        if (name)\n            snprintf(buf, sizeof buf, \"<fn %s>\", name);\n        else strcpy(buf, \"<fn>\");\n        break;\n    }\n    default: strcpy(buf, \"<native fn>\"); break;\n    }\n    ...\n}\n```\n\n`stringify` returns a string value as it is. Any other value is first\nprinted into a 64-byte buffer on the stack and then copied into a\nfreshly allocated string. A named closure is printed with `snprintf` as\n`<fn name>`, an anonymous one as `<fn>`, and the built-ins fall through\nto the default case, `<native fn>`.\n\n`snprintf` writes at most 63 characters into the 64-byte buffer. The\ninitial semantics used the same rendering rule for concatenation and\nprinting, and missed this limit. To prove agreement with the binary,\nthe LLM had to give concatenation its own renderer. The\n[corrected\nsemantics](https://github.com/BasisResearch/ship-your-interpreter/commit/d0d2609425f0024a0b8a2ad0570f14723b391a8d)\ncuts a closure’s rendering to its first 63 bytes:\n\n```\n\"\" + f        ⇓  take 63 (\"<fn \" ++ f ++ \">\")\n```\n\nThis is the kind of detail an implementation accumulates internally but nobody writes down explicitly, which is precisely why a semantics transcribed by hand, or written by an LLM, can miss it. Nor is it a detail no program would notice: code in dynamic languages routinely relies on the string form of a function, for logging, for dispatch keyed on a name, or for comparing serialised values. Even simple violations like this undermine any verification effort built on top of the semantics, and can leave holes that hide security vulnerabilities. To build secure and scalable semantics, we need to go beyond tests, since a test suite only checks the programs someone (or an agent) thought to write.\n\n# Ship your interpreter\n\nShipping your interpreter means checking the semantics against the\nimplementation people actually run. Compile the interpreter the\nlanguage already has, and make the LLM prove that the binary\n*refines* the semantics, that is, that the two agree on what every\nprogram prints.\n\nThe theorem we\n[proved](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/VsaIris/Interp/EndToEnd.lean#L159)\nis this one:\n\n```\ntheorem endToEnd_refinement :\n  ∀ p c, Loaded interpRunLayout p (fillZero c) →\n    (∀ out, BigStep p out ↔ Halts c out 0) ∧\n    (Diverges c → ¬ ∃ out, BigStep p out)\n```\n\nThe theorem says for any WHILE program `p`, and *any* machine\nconfiguration `c`, if the machine configuration satisfies a property\n`Loaded`, then the semantics match what the compiled binary will\ndo. `Loaded interpRunLayout p (fillZero c)` here says that `c` is a\nmachine about to run `p` through the interpreter binary. The first\nconclusion, `(∀ out, BigStep p out ↔ Halts c out 0)`, says that the\nsemantics derives output `out` if and only if the machine halts with\nexit code `0` having printed `out`, i.e. for successfully terminating\nprograms the predicted outputs are equivalent. The second says that any program\n`p` on which the machine runs forever (`Diverges c`), is a program the\nsemantics derives no terminating output for.\n\nWe can visualise this theorem as a *commuting square*, showing how the\nsemantics and the binary agree on a program’s output. In the diagram\nbelow, the top arrow relates a program `p` to the output\n`out` predicted by the semantics. The bottom arrow relates a machine\nstate `c` to the output printed when the binary halts successfully.\nThe dashed line on the left is the `Loaded` condition connecting the\nprogram to that machine state. Under this condition, the theorem says\nthe two outputs agree, shown by the double line on the right. The\norange arrow shows how a failed attempt to prove that agreement sends\nthe LLM back to revise a rule of the semantics.\n\nThe theorem catches a wrong semantics in both directions. If the semantics is too permissive, it derives an output the binary never prints, and the left-to-right half fails. If it is too strict, it has no rule for something the binary does, and the right-to-left half fails. Either way the LLM gets a proof obligation it cannot discharge. In our experience, that obligation usually points at the rule that is wrong.\n\nRISC-V is an open processor design. We use its formal model, written\nin [Sail](https://github.com/riscv/sail-riscv) and translated into Lean,\nto define how each machine instruction executes. The binary is the\nactual ELF executable: 1,855\nlines of interpreter C compiled by gcc, linked against dlmalloc and\nnewlib, 25,336 instructions in all. For comparison, the xv6 kernel\nverified with MachCSL is 8,697 RISC-V instructions, built from 6,593\nlines of C and assembly, although its proof also covers concurrency,\nwhich ours does not need. The C compiler’s output, the C library and\nthe memory allocator are all inside our theorem. A person\nwho wants to trust the result reads the statement above, the hypothesis\n`Loaded`, and the two short definitions of `Halts` and `Diverges`. They\ndo not need to trust `BigStep`, because the proof checks it against the\nbinary.\n\n# Developing the semantics and proof together\n\nDeveloping the proof forced the LLMs to account for four details in the semantics:\n\n- integer arithmetic had to wrap at 64 bits, because negating the smallest integer was unsatisfiable against the machine;\n- a `for` loop’s initialiser had to ignore an abrupt status, because\nthe C does;\n- built-ins had to render differently in `print` and in concatenation;\n- long closure names had to be cut at 63 bytes.\n\nEach correction started either as an obligation that would not close or as a run of the binary that disagreed with the semantics.\n\nThe 63-byte cut is a representative example. The proof of the concatenation case needed the semantics’ rendering to equal the binary’s, and for long names it didn’t, so the obligation could not be discharged until the rule changed.\n\nThe proof also caught mistakes in the LLM-generated lemmas about the C\nlibrary. The LLMs stated what each function does and then proved\nthat statement against the machine code. An allocator reserve that no\nheap satisfied after a single `malloc(24)`, a `realloc` lemma that was\nfalse for sizes that wrap, and an `exit` routine that writes `errno`\nwithout its lemma saying so all showed up the same way, as obligations\nthat would not close.\n\n# Separation logic makes the binary proof tractable\n\nLLMs wrote all of the proof. Most of the difficulty lay in reasoning\nabout memory. We needed a specification for `malloc`, the function\nthat allocates memory, which would let us prove that allocating a new\nblock preserves the data already held by the interpreter. Even\n`println(\"n = \" + x)` allocates three strings and frees two of them.\nThroughout those calls, the program’s variables and the half-built\nresult must remain intact.\n\nThe textbook way to do this is to give each function a Hoare triple\ntogether with a *footprint*, a set of bytes the function may write.\nFacts about memory outside the footprint carry across a call\nunchanged. A triple `{ P } code { Q }` reads as “if `P` holds before\n`code` runs, then `Q` holds after it”. For `malloc`, such a\nspecification reads roughly as follows, where `F` is a fixed set of\naddresses:\n\n```\n{ heap H }\n  p := malloc(n)\n{ heap ((p, n) :: H)  and  p is fresh }\nmodifies F\n```\n\nUnfortunately, no such `F` exists. From the same heap, `malloc(32)`\nwrites the header of the new top chunk at address `0x82000238`, so `F`\nmust contain that address. `malloc(64)` instead returns the block\n`[0x82000210, 0x82000250)`, which contains it. Once the caller owns\nthat block, facts about its bytes have to survive later calls, so `F`\nmust also exclude `0x82000238`. The LLMs [proved in\nLean](https://github.com/BasisResearch/ship-your-interpreter/blob/92470bdbbfe24c8c25b5be44128aa6395e6acce8/VsaIris/DlHeap.lean#L515)\nthat no fixed set of addresses can satisfy both requirements, after a\nfirst attempt that worked around the problem one fact at a\ntime had stalled for three weeks.\n\nSeparation logic solves this by making the footprint depend on the\nheap. We ported [MachCSL](https://arxiv.org/abs/2609.04043), the logic\nbehind the xv6 proof, to the newly released\n[iris-lean](https://arxiv.org/abs/2609.24252).<sup>[1](#fn:1)</sup> In separation\nlogic the allocator *owns* the free bytes of its arena, and `malloc`’s\n[specification](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/VsaIris/DlHeap.lean#L209)\nhands part of them to the caller:\n\n```\n{ isHeap H }\n  p := malloc(n)\n{ (p = 0 ∗ isHeap H)\n  ∨ (isHeap ((p, n) :: H) ∗ blockOwn p n) }\n```\n\nHere `∗` is the *separating conjunction*, which says that its two\nhalves hold of disjoint parts of memory, and the result `p` is either\nnull or a fresh block. `isHeap H` owns every byte of the arena outside\nthe live blocks `H`. Initially, the allocator owns `0x82000238`, so\n`malloc(32)` may write it. If the caller instead requests `malloc(64)`,\nthat byte passes to the caller through `blockOwn`, and later calls\ncannot touch it. Anything else the caller owns is not\nmentioned in the specification, and the frame rule carries it across\nthe call in one step. After the port, the rest of the proof closed in a\nfew days.\n\nAt its peak the proof was about a million lines of Lean, two thirds of\nit generated by 35 scripts the LLMs wrote, which read the binary and\nemit a proof rule for each of about 11,800 instructions. A later pass\nreplaced the generated proof families with abstractions proved once,\nsuch as a symbolic executor for machine code, and brought the proof\nunder 200,000 lines. It uses no axioms beyond Lean’s standard\nones (`propext`, `Classical.choice` and `Quot.sound`).\n\n# The theorem applies to real programs\n\nA theorem with a hypothesis is only useful if that hypothesis can be\nsatisfied. If `Loaded` described a machine state that never occurs,\nour theorem would hold vacuously and tell us nothing about the binary.\n\nWe had the LLMs [prove in Lean that `Loaded` holds for ten\nprograms](https://github.com/BasisResearch/ship-your-interpreter/tree/fb07094cff916318c34b07494a7d739f1e53989b/Vsa/Sim/Boot/Gen).\nFor each one, they constructed a machine state at the interpreter’s\nentry, with the program in memory alongside the binary, the runtime\nand the allocator. Lean checked that each state met the theorem’s\nprecondition.[2](#fn:2)\n\nWe also replayed 85,483 machine steps from the executable and checked\nthat the resulting memory matched the constructed state byte for\nbyte. The link from the executable file and its boot trace to that\nstate was checked by scripts; Lean checked the precondition and the\nexecution from that state onwards. For the full [loop test\nprogram](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/c/tests/while.wl),\nwhich extends the earlier example with two more sums, the binary\nprovably halts after printing `55`, `2500` and `36` on separate lines.\n\nThe precondition includes enough heap and stack space for the program.\nA [later\ntheorem](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/VsaIris/Interp/EndToEndChecked.lean#L12)\nreplaces these two assumptions with checkers that run on the program.\n\n# Once you trust the semantics, the tools are cheap\n\nA validated semantics also works as an interface. Anything you prove\nsound against `BigStep` is sound for the binary, by composing it with\nthe refinement theorem, and that composition is a few lines of\nLean. So we had LLMs build four tools on top of it.\n\nThe refinement proof took about a month and is about 140,000 lines of Lean. The four tools below were opened as pull requests over three days, and come to about 33,000 lines between them, most of it the compiler.\n\nThe first tool is a [type\nchecker](https://github.com/BasisResearch/ship-your-interpreter/pull/5).\nIt catches invalid operations before a program runs. For example,\nthese two programs are rejected:\n\n```\n\"a\" - 1;               // subtracting an integer from a string\njs\nvar x = 1;\nx = \"s\";               // assigning a string to an integer variable\n```\n\nThe [proofs for these\nexamples](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/Vsa/While/TypeExamples.lean)\nshow that neither program can pass the checker. Its soundness theorem\nrules out type errors in accepted programs, including when they run\nthrough the interpreter binary. Division by zero, a failed `assert`\nand the interpreter’s call-depth limit remain possible; those require\nreasoning about values as well as types.\n\nThe second tool is a [program\nlogic](https://github.com/BasisResearch/ship-your-interpreter/pull/2),\nwhich lets us prove what a particular program computes. The loop near\nthe start of this post adds the integers from 1 to 10. The full [test\nprogram](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/c/tests/while.wl)\nalso adds the odd integers from 1 to 100, using `break` and `continue`,\nand computes a third sum with nested loops. The LLMs used the logic\nto prove that running this program through the interpreter binary\nterminates and prints exactly:\n\n```\n55\n2500\n36\n```\n\nThe third tool is an [abstract\ninterpreter](https://github.com/BasisResearch/ship-your-interpreter/pull/3),\nan analysis that tracks possible values through a program and raises\nalarms for potential runtime errors. It analyses that same test\nprogram with [no\nalarms](https://github.com/BasisResearch/ship-your-interpreter/blob/fb07094cff916318c34b07494a7d739f1e53989b/Vsa/AbsInt/Examples.lean),\nproving it free of runtime errors. It also establishes that the final\nvalues of `sum`, `total` and `acc` are 55, 2500 and 36. The analysis\ncomputes these results automatically, and its soundness proof connects\nthem to execution of the binary.\n\nThe fourth tool does without the interpreter entirely. In April, our\nagents built a compiler but could not prove it correct. Here the\nsemantics came first, and the LLMs built a [verified\ncompiler](https://github.com/BasisResearch/ship-your-interpreter/pull/9)\nfrom all of WHILE (strings, closures, calls, `for`, `return` and\n`assert`) straight to RISC-V. Compile the sum program above, and the\nresulting machine code prints the same three numbers. The correctness\ntheorem establishes agreement for every program meeting its\npreconditions. A [checked\nversion](https://github.com/BasisResearch/ship-your-interpreter/pull/10)\nanalyses allocation cost, so its theorem needs no assumption about\navailable heap space.\n\nDropping the interpreter also makes WHILE programs faster. We ran\nevery program in the interpreter’s test suite both ways on the\n[spike](https://github.com/riscv-software-src/riscv-isa-sim) RISC-V\nsimulator. Counting the interpreter from the moment it starts evaluating, so that\nparsing is not charged against it, compiled code retires between 2.7\nand 8.2 times fewer instructions, and both routes print the same\noutput. These are instruction counts on a simulator rather than timings\non hardware.\n\nOnce the semantics is trusted, it *is* the language, and the binary we\nstarted from is no longer needed to run WHILE programs.\n\n# What’s next: Lua, OCaml and, one day, CPython\n\nOur experiment with WHILE targeted a toy language. LLMs developed its formal semantics, proved that the compiled interpreter follows it, and built verified tools on top. We are now scaling this approach up to real languages.\n\n[Ship your Lua](https://github.com/BasisResearch/ship-your-lua)\ntargets Lua 5.4.7 compiled to bare-metal RISC-V. The binary already\nruns on the Sail model and agrees with native Lua, and the plan cuts\nthe proof at the VM: first the bytecode interpreter against a bytecode\nsemantics, fragment by fragment over opcodes, then the source language\nagainst the bytecode.\n\n[Ship your OCaml](https://github.com/BasisResearch/ship-your-ocaml)\ntakes advantage of the way OCaml bootstraps itself. OCaml’s bootstrap compiler is checked\ninto its repository as bytecode, `boot/ocamlc`, and runs on `ocamlrun`.\nWe have `ocamlrun` running on the Sail model, compiling programs with the\nreal `boot/ocamlc`. The plan there ends in a fixpoint: if the source\nsemantics says the compiler compiles its own sources to exactly the bytes\nof `boot/ocamlc`, and the compiler’s back end is proved correct, then\nthose bytes get a meaning without verifying their 412,000 bytecode\ninstructions one at a time.\n\nFor both projects, we have already stated the headline theorems in Lean. What remains is to close their proofs.\n\nThe north star is CPython. We believe that current agents make an LLM-written, machine-validated semantics for Python feasible, given enough compute. Tools like the ones in the previous section could then be built on it, with guarantees that reach the CPython binary.", "url": "https://wpnews.pro/news/ship-your-interpreter", "canonical_source": "https://www.basis.ai/blog/ship-your-interpreters/", "published_at": "2026-10-17 14:16:33+00:00", "updated_at": "2026-10-17 14:35:10.016070+00:00", "lang": "en", "topics": ["ai-safety", "ai-research", "large-language-models", "artificial-intelligence"], "entities": ["Basis", "Kiran Gopinathan", "Nikhil Pimpalkhare", "Yiyun Liu", "Zenna Tavares", "Lean", "RISC-V", "Frans Kaashoek"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ship-your-interpreter", "markdown": "https://wpnews.pro/news/ship-your-interpreter.md", "text": "https://wpnews.pro/news/ship-your-interpreter.txt", "jsonld": "https://wpnews.pro/news/ship-your-interpreter.jsonld"}}