← Latest papers
🤖 AI

Agentic Interpretation: Lattice-Structured Evidence for LLM-Based Program Analysis

This paper proposes "agentic interpretation," a framework that applies lattice-based static analysis principles to LLM-driven program reasoning by decomposing analysis goals into localized claims tracked within a finite-height lattice, thereby enabling more robust, evidence-based, and iterative program analysis compared to brittle one-shot approaches.

Original authors: Jacqueline L. Mitchell, Chao Wang

Published 2026-05-14
📖 5 min read🧠 Deep dive

Original authors: Jacqueline L. Mitchell, Chao Wang

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to solve a massive, complex mystery: "Is this computer program safe to use?"

In the past, you had two main ways to answer this:

  1. The Robot Detective (Static Analyzer): This is a strict, rule-following machine. It looks only at the code written on the screen. It's great at finding math errors, but it can't read the user manual, check the news for recent security hacks, or understand the "unwritten rules" of how a library is supposed to work.
  2. The Human Expert (LLM): This is a super-smart AI that can read manuals, check security news, and understand context. But if you ask it, "Is this whole program safe?" in one big question, it often gives a shaky answer. It might miss a crucial detail because it's trying to swallow too much information at once, or it might contradict itself without realizing it.

This paper proposes a new way to work: Agentic Interpretation.

Think of this not as asking the AI to solve the whole puzzle in one go, but as hiring the AI to be a team of specialized investigators working under a strict project manager.

The Core Idea: Breaking the Mystery into Tiny Clues

Instead of asking the AI, "Is the program safe?", the framework breaks the big question down into hundreds of tiny, specific claims.

  • Claim 1: "Does this specific library handle bad data safely?"
  • Claim 2: "Does the security check cover all the right fields?"
  • Claim 3: "If the check fails, does the program actually stop?"

The AI (the "Agent") investigates each tiny claim one by one. But here is the magic part: The Project Manager (the Framework) keeps a very specific scorecard for every single claim.

The Scorecard: The "Lattice"

Imagine a scorecard that doesn't just say "Yes" or "No." It tracks the strength of the evidence for and against each claim.

  • Support: Do we have proof this is safe? (Weak, Strong, or None?)
  • Refutation: Do we have proof this is unsafe? (Weak, Strong, or None?)

This scorecard is called a Lattice. It's like a grid where you can move up or down as you find new information.

  • If the AI finds a security alert saying a library has a bug, the "Refutation" score goes up to Strong.
  • If the AI finds a manual saying it's safe, the "Support" score goes up to Strong.

The Workflow: The "Worklist" Game

The system uses a "Worklist" (like a to-do list) to manage the investigation. Here is how the game plays out, using a real example from the paper:

  1. The Setup: The program uses a "black box" library (we can't see its code, only its name). The goal is to see if it's safe.
  2. Round 1 (Broad Search): The AI looks at the library's general documentation.
    • Result: "We found no obvious bugs, but the manual is vague."
    • Scorecard: Weak Support (maybe safe), Weak Refutation (maybe not).
  3. The "Aha!" Moment (Feedback Loop): The system looks at the big picture. It realizes: "Wait, the main program relies on this library to stop hackers, but the library's documentation is vague. That's a risk!"
    • The Project Manager sends a Feedback Signal back to the AI: "Go back and look specifically for 'object-shape' attacks in this library."
  4. Round 2 (Targeted Search): The AI, now knowing exactly what to look for, digs deeper.
    • Result: "Found it! There is a known security alert about a specific bug in this version."
    • Scorecard Update: The "Refutation" score jumps to Strong.
  5. Stabilization: The system updates the big picture. Because the library is now proven unsafe, the final conclusion for the whole program changes from "Maybe Safe" to "Unsafe." The system stops when no new clues can be found.

Why This is Better Than Just Asking the AI

  • No "Black Box" Answers: You don't get a single, confusing paragraph. You get a clear map showing exactly which part of the program is risky and what evidence proves it.
  • Self-Correction: If the AI makes a mistake or misses a clue, the "Feedback Loop" catches it. The system forces the AI to re-examine its work if the big picture doesn't add up.
  • It Stops: Because the scorecard has a limit (you can't get "more than strong"), the system knows when to stop looking. It won't get stuck in an infinite loop of thinking.

The Bottom Line

This paper introduces a framework that treats Large Language Models not as magic answer machines, but as evidence-gathering agents. By forcing them to break big problems into small claims, track the strength of their evidence on a structured scorecard, and constantly check their work against the big picture, we can use their intelligence to analyze complex software safely and reliably—even when the code involves mysterious, third-party parts we can't see.

It turns a chaotic, one-shot guess into a disciplined, auditable investigation.

Drowning in papers in your field?

Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.

Try Digest →