Knowledge Systems · Reverse Engineering · Source Maps

Semantic Decompilation — Recover the Design Hidden Inside Prose and Code

A summary asks what the source says. Semantic decompilation asks what it is made of, what each part does, and what becomes visible when that part is related to another world — then checks whether the implementation still matches the idea.

Scott Farrell · LeverageAI · July 2026

Most teams treat long documents the way they treat opaque binaries: open the file, skim for the gist, maybe paste it into a retrieval system that returns “similar chunks.” That feels like understanding. It is usually compression under another name. You trade a rich argument for a blurrier one, then wonder why the graph never knows which claim depends on which, or whether the shipping code still embodies the doctrine you published last quarter.

There is a different move. Treat the artefact as territory whose internal design can be recovered. Decompose it at boundaries the source already declared. Give every unit an address. Reconstruct what each unit asserts, what role it plays, why it matters, and how it joins the rest of the corpus. Then run the loop the other way — from idea into prompts and code — and compare. Where the two directions disagree, you do not have a documentation problem. You have a lint finding.

A summary asks what the source says. Semantic decompilation asks what the source is made of, what each part does, and what becomes visible when that part is related to another world.

Why “related to the whole document” fails

When an ebook carries fifty ideas and you ask how it relates to everything you already know, you are forced toward a general answer. Three themes. A resemblance to two frameworks. An overall significance score. That is not relational precision — it is an average. Averages destroy edges.

Semantic Refraction named the grain problem on the publishing side: meaning-complete units can form joins the undifferentiated whole was too coarse to hold.¹ This piece does not re-derive that thesis. It takes the next engineering step: how you recover those units from compiled prose and from the prompts and code that implement the doctrine, without reducing the work to a summary or a fixed token window.

Industry retrieval guidance already warns that fixed-size chunking is a poor default when semantic understanding matters.² Hierarchical and tree-organised approaches keep trying to restore the big picture chunks erase.³ Vector search still struggles when the question requires multi-hop connection rather than local similarity.⁴ Those are symptoms of the same ceiling: you cannot recover design by decorating opaque slabs of text.

The software analogy is load-bearing

A whole repository is often too large to reason about as one object. A single line is usually too small. A file, class, or function is often the working grain — because it has a purpose, declared dependencies, and an interface. Claims play that role for idea systems.

Writing linearises an argument. The call graph of ideas is flattened into narrative order for a human reader. Structure is still there — headings, lists, callouts, paragraph boundaries — but the relational design is no longer first-class. Decompilation recovers the symbol table and the call graph. Public “claims and edges” knowledge-base practice is already groping toward that IR shape.⁵ Compilers have used intermediate representations for the same reason: you need a stage where structure is explicit before you lower again.⁶

Code finds the pieces. AI judges what they can mean.

The practical pipeline is not “let the model invent chunks.” It is:

HTML structure is not mere formatting. It is a disassembly map: trustworthy boundaries, stable addresses, hierarchy, emphasis signals, exact recoverability. Headings are the author’s own declaration of where one idea ends and the next begins — a natural key of intent, not a random token boundary. The same discipline shows up in soft-data joins: prefer deterministic keys over resemblance when the source already named the cut.⁷

Then the model reviews units in isolation and may recombine them. Pure atomisation destroys meaning; a heading plus its paragraph, a setup plus its punchline, two reinforcing boxes — those combinations are often the real closed unit. Deterministic code supplies candidates. The model supplies judgment. That is the Deterministic–AI Pendulum applied cleanly: ground truth and exact recovery on one side, nuance on the other.⁸

You kept the debug symbols

Most reverse engineering of software is hard because binaries ship stripped. Variable names, comments, and intent are discarded at compile time. Teams recovering business logic from decades-old systems still do heroic work reconstructing purpose from behaviour alone.⁹

AI-native work is different when you refuse to throw the intermediate representations away. Intent, prompts, agent instructions, tests, transcripts, and starting repository state form a source package upstream of generated code. Generated source is often simultaneously the compiled output of intention and the input to a conventional compiler. That cascade matters: “source” is relative to the stage.

Keep-the-bronze discipline is not nostalgia. It is the argument that you should never discard a representation a later decompiler may need.¹⁰ With exhaust preserved, decompilation is source-mapped: structure recovered from the artefact, intent recovered from the symbols you never deleted. Without them, you are back to guessing — the same predicament legacy reverse engineering never fully escapes.¹¹

Three directions, one verification loop

Forward engineering

Start with a conceptual claim and trace it into implementation: North Star intent → selection prompt → permission to combine and overlap → deterministic scopes → model judgment → rendered output → regression evidence. Doctrine predicts what the system should do.

Reverse engineering

Start with code, prompts, and behaviour. Recover the latent principle: structure supplies handles; AI supplies judgment; truth remains in source. The implementation may reveal a design only half-articulated when it was built.

Cross-engineering

Compare both directions. When published idea, wiki claims, prompts, code, and observed behaviour disagree, one of them is lying — or all of them are incomplete — and the disagreement is information. That is a differential test neither wiki nor repository can run alone.

That is the proof surface this doctrine needs: not a slogan about “deeper understanding,” but retained scope IDs, prompt pointers, claims, edges, observed behaviour, and at least one documented mismatch that changed the system.

What this is not

It is not a tutorial in binary reverse engineering. It is not an argument that every excerpt deserves graph citizenship — storage is not free, and prose-as-claim floods the map. It is not the full critique of unary metadata in RAG systems; that narrow explanation belongs with the later piece on relational meaning versus metadata. It is not the architecture of a quote satellite or promotion rules; those are adjacent layers. Attention-native publishing owns the interrupt doctrine for feed surfaces.¹² Semantic refraction owns why closed pieces can mean more relationally than the pillar average.¹ This piece owns the reverse-engineering method and the round-trip lint.

The sentence to hold

RAG retrieves the source. Semantic decompilation reconstructs the design — and the design is only trustworthy when forward doctrine and reverse-engineered implementation can be forced to agree.

If you already compile archives into a wiki IR and run agents as the runtime,¹³ you have half the toolchain. If you already denoise structure into addressable scopes,⁸ you have the symbol table. What remains is to treat reconstruction and mismatch as first-class products: claims as functions, edges as calls, exhaust as debug symbols, and every doctrine/implementation disagreement as a ticket worth filing.