The Lossless Semantic Tree: a compiler-accurate model of your code

Every codebase

Code isn’t text. Your tools read it that way.

Moderne sees tens of millions of repositories across its customers. The hard part was never finding a match. It’s finding every real one and changing it safely, everywhere at once.

Grep, the IDE, and an agent reading files all treat code as characters on a page. So every answer comes back approximate, and every tool re-derives the same understanding from scratch, file by file, run after run.

The compiler already knows far more. It knows the real type behind every symbol, what each call resolves to, and how your code connects to its dependencies. Capture that knowledge once and code stops being text. It becomes data you can query. Scroll down and we’ll descend from all of them to a single line to show what that takes.

Just text

Characters on a page know nothing.

The cheapest way to read code is as text, the way grep and ripgrep do. It runs fast and stays completely blind to what any of it means.

Search for a class name and you’ll hit comments, strings, and unrelated variables, while missing every place the same thing arrives under an alias, behind a factory, or through a parent class.

Text has no notion of a type, where a symbol is declared, or what a call resolves to. Across tens of millions of repositories, “probably these, give or take” is not an answer you can act on.

The syntax tree

A parse tree sees shape. Not meaning.

Parse that text into a tree of nested nodes (methods, ifs, calls) and you have an AST. It helps with highlighting and formatting, but it still doesn’t understand the code.

An AST knows this node is a constructor call. It does not know which class is being constructed, what that class extends, or whether the interface it ultimately implements governs a security check. There’s no symbol table, no resolved types, and no links across files, and the formatting is thrown away.

This is the trap: people see a syntax tree and call it “context.” It’s structure without meaning, and you can’t safely rewrite structure. To know what code does, you have to resolve it the way the compiler did when it built it.

The Lossless Semantic Tree

Everything the compiler knows.

The LST is your code as structured data, not text and not an AST. It’s a compiler-accurate model in which every symbol is resolved to the exact type it binds to.

Each identifier ties back to its real declaration. Each call binds to the exact method, generics and overloads included. Each type resolves through the full inheritance graph, across your files, out into your dependencies, and down into the language runtime itself, whether that’s the JDK, the .NET base class library, or Python’s standard library. The model captures the types, the dependencies, and the relationships between them.

It also stays lossless. Formatting, comments, and structure are preserved, so an automated edit reads like a person wrote it. Built once and reused across the org, it becomes a queryable dataset the whole estate can be searched and rewritten against. Compiler-grade meaning with file-perfect fidelity is what makes change safe at scale.

The LST follows the type

Four types deep to prove it.

The LST didn’t match a name. It followed the type. Proving this one line disables the check meant resolving four layers of inheritance, from the class in your code down to the runtime interface it ultimately implements.

AllowAllHostnameVerifier extends AbstractVerifier, which implements X509HostnameVerifier, which extends javax.net.ssl.HostnameVerifier, the JDK interface whose verify() is the check being neutralized.

That chain runs through your code, the library, and the JDK. Because the match is on meaning rather than text, one recipe finds this exposure in every variant across every repository, and the fix lands the same way every time.