Round-Trip Is a Signal, Not a Promise: How a Verifiable IR Checks Code Against Intent
We keep using one word to carry the whole argument. Verifiable. A verifiable context layer, a verifiable code IR, code checked against intent on every change. It is the word that separates what we build from every index that calls itself a context graph, so it is worth being precise about it, because a word doing that much work should be able to survive someone opening the box and asking what a check actually consists of.
This is that note. Not the pitch, the mechanism. What is in the contract, what runs when a change lands, what the check returns, and just as importantly, what it does not and cannot tell you. If “verifiable” is going to be the moat, it has to mean something you could implement, not something you feel. So here is the honest version, including the part that trips up every tool that reached for this and overclaimed.
The trap we are trying not to fall into
Start with the mistake, because the whole design is shaped by avoiding it. The seductive idea is a two-way machine. You compile code into a representation, and the representation is rich enough that you can regenerate the code back out of it, lossless, a perfect round-trip. Code becomes IR becomes code, and now the IR is the source of truth and you edit that instead.
It does not hold. A layer that was reverse-engineered out of your code cannot also be the thing your code is derived from. If you rebuild the code from the IR and it comes back different, which one was right? You have no answer, because both were generated from the same reading and neither is anchored to anything outside it. The moment you promise reversibility you have promised that a derived artifact is authoritative over the thing it was derived from, and that is circular. Several tools made exactly this promise and quietly walked it back.
So we do not make it. The code stays the source of truth. The IR is a contract derived from the code, and its job is not to replace the code but to hold what the code is supposed to mean and to notice when the code stops meaning it. That reframing, from “rebuild the program” to “check the program,” is the entire difference between an overclaim and a thing that works.
What the contract actually is
Before you can check code against intent, you have to have written intent down somewhere the machine can read. That is what the compile step produces. A model reads each file once and lowers it into the IR, and for every unit it records not just the syntax a parser would keep but the things the syntax throws away: what this file is for, how it does it, why it exists in business terms, and how it connects to the rest of the system across repositories, including the connections that are not call edges at all but shared contracts, event buses, generated clients, deployment assumptions.
That derived intent is the contract. It is not a separate PRD living in a wiki that drifts the day after you write it. It is a view of the IR, linked by hash to the exact code that enacts it. When we say a change is “checked against intent,” the intent is this: the candidate specification the codebase itself implied when it was last in a state everyone accepted. Not what someone wished the system did. What the system, as written and agreed, actually claimed to do.
This is the piece a plain code graph does not have. A symbol graph kept the functions and the edges and threw away the why, so it can tell you what calls what and never whether a change still matches purpose. You cannot verify code against intent you did not keep. The compile keeps it.
What one verification check consists of
Now the change arrives. An agent, or a human, edits some code. Here is what actually runs, and it is more mundane and more mechanical than the word “verify” makes it sound.
First, the changed files get re-lowered. The same compile that built the contract runs again, but only on the diff, and it produces a fresh candidate reading of what this code now claims to be for and how it now connects. Call it the candidate spec. It is the answer to “if I had never seen this file before and read it today, what would I say it does?”
Second, that candidate gets diffed against the held contract. Not the code diffed against the old code, a git diff already does that and it tells you the letters changed, not whether the meaning did. The candidate spec diffed against the stored intent. Did the purpose shift? Did a cross-repo relationship the contract depended on disappear or quietly appear? Did the unit pick up a behavior nobody declared it should have? These are semantic questions, and you can only ask them because you kept a semantic contract to ask against.
Third, the change gets walked against the connection graph the IR still holds, which is where cross-repository blast radius lives. A change can be perfectly faithful to its own local intent and still break a consumer three repositories away that depended on the old contract. The layer knows about that consumer because the compile captured the link, so it can check the proposed change against what the neighbors were promised, not just against the file it lives in.
The check returns one of two things. Either the candidate matches the contract and the connections still hold, and the change lands. Or something diverged, and it gets surfaced, with citations to the exact files and lines, as a flag that says the code just stopped meaning what it used to mean. That is the whole loop. Re-derive, diff against intent, walk the blast radius, pass or flag.
Why round-trip is a signal and never a promise
Look closely at the second step, because it is the round-trip, and it is the exact place the overclaim lives. We do regenerate. But we do not regenerate code from the IR. We regenerate a candidate spec from the new code and compare it to the spec we already held.
That distinction is everything. A promise to rebuild code from the IR is a claim that the IR is complete and authoritative, and it is neither, and it fails the moment the rebuild differs from reality. A signal derived by re-reading the code and comparing the reading to the last accepted reading claims nothing about authority. It only claims that two readings of the same intent should agree, and when they do not, one of two true things happened: the code changed what it means, or the intent genuinely moved and the contract should be updated to match. Both are exactly what you want a human to look at. Neither pretends the layer is the source of truth.
So a mismatch is not a failed build and it is not an auto-revert. It is the layer raising its hand. The round-trip is the instrument that lets it raise its hand, a way to turn “the meaning drifted” into a concrete, checkable disagreement between two derived specs instead of a vibe. It is a weaker promise than reversibility and it produces a far stronger result, because it survives contact with a codebase that is the truth and an IR that is only ever a faithful reading of it.
If you want the one sentence: you never ask the IR to become the code, you ask the code to keep agreeing with the IR, and round-trip is how you measure the agreement.
What it catches, and what it honestly cannot
A technical note that only lists what a thing catches is a brochure. The boundary is where the credibility is, so here is the boundary.
It catches drift from stated intent. A refactor that quietly changes what a payment retry does, an agent edit that adds a side effect nobody declared, a function that grew a second responsibility it was never supposed to have. It catches broken cross-repository contracts, the change that satisfies its own file and breaks a consumer elsewhere, which is the failure mode a single-repo view and a flat similarity search both miss entirely. And it catches the silent addition, code that now claims to do something the contract never said it should, which is often where the real bug is hiding.
It does not prove correctness, and we will not say it does, because that is the next overclaim waiting after reversibility. Matching intent is not the same as being right. If the intent itself was wrong, if the contract encoded a mistaken idea of what the system should do, then code that faithfully matches it is faithfully wrong, and the check passes. Verification against intent finds divergence from what you declared. It cannot find that what you declared was a bad idea. That is still a human’s job, and pretending otherwise would undo the whole point of being precise about the word.
It also does not observe runtime. The check reasons over the code and the contract, not over a production trace it never saw. It will catch that a change contradicts the declared behavior. It will not, by itself, catch a race condition that only appears under a load the representation was never shown. It is a strong static conscience for a codebase, not an oracle, and the honest framing is the reason to trust it on the things it does claim.
Why this is cheap enough to actually run on every change
None of this matters if verification is something you run once a quarter because it costs too much. It is cheap for the same structural reason the compile is cheap. You verify the diff, not the world.
Every file in the IR is fingerprinted with a SHA-256 hash. A commit that touches twelve files re-lowers twelve files and re-checks twelve candidate specs against their contracts and walks the blast radius from those twelve, while the other hundred and fifty thousand files sit untouched because their content did not change and their hash did not change. Verification cost is proportional to churn, not to repo size, which is what makes it run on every commit instead of never. This is the same discipline a build system uses when it caches object files and recompiles only what changed. The verifiable IR applies it to meaning instead of to binaries.
For scale, on the run we keep coming back to, 46 Kubernetes-ecosystem repositories, about 150,000 files and 8 GB of code, the compile lands at open-source-model rates of roughly 13 per 1,000 files, once, and the per-file diff keeps the ongoing verification trivial. In that same run, feeding the model from the compiled representation instead of letting it rediscover the codebase answered correctly about 94% of the time on roughly a fifth of the tokens, and average cost per task fell from 0.22. The cheap check on every change is downstream of the same property, which is that the understanding was paid for once and kept, instead of paid for again on every session and thrown away. The research points the same direction: RepoGraph (ICLR 2025) lifted SWE-bench resolution to 32.8% by handing agents real repository structure, and CodexGraph (NAACL 2025) showed graph-grounded retrieval beating flat similarity search, and a January 2026 paper found AST-derived graphs score highest on architectural questions at low cost. Structure and intent, kept and checked, beats rediscovery every time.
This is ByteBell
ByteBell is the verifiable context layer for code, and this note is what the word in the middle of that phrase actually means. We run the LLM compiler pattern, lowering every file once into a verifiable code IR that holds purpose, business context, and cross-repository relationships, and we diff per file with SHA-256 so only what changed gets re-checked. The contract is derived from the code you already have, so it works on brownfield, not just a blank greenfield page. It runs on your own infrastructure through Docker, which matters more here than anywhere, because the contract now holds the derived intent of your business logic and that is precisely the thing you cannot let leave your perimeter. Every engineer and every agent queries it over one MCP url, on any copilot, and every change they make gets checked against the contract before it lands.
Round-trip is how we measure whether your code still agrees with what it was meant to do. It is a signal, not a promise, and that is exactly why it holds up. Especially now, as machines write code faster than any team can read it, the only thing worth trusting is a clear statement of what the system must do, with continuous proof the code still does that and nothing more. The engine is open source. Clone it, bring your own keys, point it at your own repositories, and watch the check fire on your code instead of taking the word on faith.