When Your Workflow Becomes a Fossil Record: Semantic Persistence for LLM Workflows

Paper: 2607.08740 Authors: Emanuele Quinto, Carlo Andrea Rozzi, Francesco Zanitti Categories: cs.AI, cs.PL, cs.SE

The Gap

The LLM workflow space has exploded: LangGraph, CrewAI, AutoGen, and similar frameworks now let you wire up tool calls, retrieval, branching, checkpointing, and human approval into explicit graphs. These systems are execution engines—they run your workflow, produce outputs, and maybe dump logs.

But here’s the problem: once a workflow finishes (or crashes mid-execution), the workflow itself—its definition, its runtime state, its reasoning decisions, its dependency relationships—scatters across logs, databases, and your own memory. You can’t ask “why did step 7 happen?” in a structured way. You can’t resume a workflow from a decision point and reason about what changed. The execution leaves footprints in sand; nothing is fossilized into inspectable knowledge.

Existing systems (LangChain, workflow orchestrators, even traditional BPM) treat workflows as things to execute. This paper asks: what if workflows were things to know?

Problem: LLM workflows produce outputs but
         their reasoning structure is lost
         after execution
     |
     v
Assumption: workflows can be represented as
            first-class knowledge objects in a
            persistent, shared substrate
     |
     v
Method: Lisp-inspired symbolic model with
        object identity + derive/infer distinction
     |
     v
Evidence: conceptual framework + illustrative
          examples (no empirical evaluation)
     |
     v
Conclusion: semantic persistence is achievable;
            formal transition semantics left
            for future work

The Increment

One sentence: Before this paper, LLM workflows were ephemeral execution artifacts; after, there’s a conceptual vocabulary for treating workflow definitions, instances, inference records, and context snapshots as persistent, inspectable knowledge objects in their own right.

Core Mechanism

The framework proposes a Lisp-inspired (but language-independent) conceptual model built on three pillars: symbolic forms, object identity, and live-image thinking.

First, everything in the workflow ecosystem—definitions, running instances, individual inference calls, context snapshots, dependency edges—is represented as a symbolic form with stable identity. Think of each entity as having a permanent address, not just a label that gets garbage-collected when the process ends.

Second, the model introduces a critical semantic distinction between two kinds of computation. Derive is deterministic: given inputs X and Y, the output is Z, always. This is traditional computation—string manipulation, database lookups, format conversions. Infer is LLM-mediated judgment: given a context window, a prompt, and a capability policy, an LLM produces an answer that’s probabilistic, context-dependent, and requires human reviewability. The framework makes this distinction explicit at the type level rather than letting it hide behind a function call.

[Workflow Definition]
       |
       v
[Workflow Instance] -----> [shared knowledge substrate]
       |                         |
       +--- [derive: deterministic steps]
       |
       +--- [infer: LLM-mediated steps]
       |         |
       |         v
       |    [Inference Record]
       |    (prompt, context, policy,
       |     response, confidence)
       |
       +--- [Context Snapshot]
       |    (state at any point)
       |
       +--- [Dependency Relations]
            (what depends on what)

Data flows through this system as symbolic transformations on a shared knowledge substrate. When a workflow runs, it doesn’t just execute—it emits knowledge objects that accumulate in the substrate. Any node, any edge, any state is addressable and retrievable later.

The architectural blueprint metaphor: Imagine a city where every building remembers its own blueprints, construction history, every renovation decision, and who approved what—embedded in the walls themselves.

• The workflow definition is the original blueprint: the plan for what the building should be.
• A workflow instance is a specific construction project following that blueprint. One blueprint, many buildings.
• Derive steps are the construction crews following specs exactly—pour concrete to 3000 PSI, no judgment involved. If you redo them with the same inputs, you get the same result.
• Infer steps are the architect’s field decisions: “This wall looks load-bearing, let me consult the engineer.” These are judgment calls mediated by an expert (the LLM), and each one gets logged as an inference record—what was seen, what was decided, under what policy, with what confidence.
• Context snapshots are the as-built photos at each stage. At any point, you can freeze the state and ask: what did the building look like here?
• Dependency relations are the structural connections: this floor depends on that foundation, this electrical run depends on that wall being finished.

The key insight: in a traditional city, this information lives in filing cabinets across multiple offices. In this framework, it’s all in one searchable repository where the building itself is the archive. You can walk up to any wall and ask it why it exists.

Key Concepts

• Semantic Persistence: The paper’s central concept. Traditional persistence means “saved to disk.” Semantic persistence means the saved thing carries its *meaning with it—not just bytes, but structured knowledge you can query, inspect, and reason about. Example: A traditional workflow log says “Step 5 called GPT-4 and got ‘yes’.” A semantically persistent record says “Step 5 was an inference under policy P2, using context C3, with confidence 0.87, and the ‘yes’ depended on evidence E1 which came from derive step 3.” The latter is a knowledge object; the former is a log line.

• Derive vs. Infer: This is the paper’s sharpest contribution. Most workflow systems treat all steps as black boxes—some happen to call an API, some happen to be Python functions. This paper says: no, these are fundamentally different *kinds of computation. Derive is repeatable, auditable, deterministic. Infer is probabilistic, requires declared context, and must be governed by executor-controlled capability policies (essentially: who allowed this LLM to make this judgment call?). Making this distinction explicit changes how you build, debug, and audit workflows.

• Live-Image Thinking: Borrowed from Smalltalk. The idea that the running system *is the system—you don’t compile and deploy; you inspect, modify, and resume the living thing. Applied to workflows: you should be able to pause a workflow, inspect its full state (every inference record, every context snapshot), modify it, and resume. The workflow is a living knowledge object, not a script you re-run from scratch.

Framework Shift

Before (mainstream approach):          After (this paper):

[Workflow Script]                      [Workflow Definition] *
       |                                      |
       v                                      v
   Execute                          [Workflow Instance] *
       |                                      |
       v                              +-------+-------+
     Outputs                          |               |
       |                           [derive]        [infer]
       v                              |               |
     Logs/Traces                   [deterministic]  [LLM judgment]
    (scattered, flat)                   |               |
                                   [resumable]    [inference record]
                                      |               |
                                   [Context Snapshot]  |
                                      |               |
                                   [Knowledge Substrate]
                                   (unified, queryable)

From execution traces to knowledge objects, the core shift is treating the workflow itself—not just its outputs—as structured, persistent, inspectable knowledge.

Expert Assessment

Problem choice: This is a real gap, not manufactured. The LLM workflow ecosystem is sprinting toward more complex agentic systems, and the abstractions are lagging. Teams building multi-step LLM pipelines genuinely struggle with debugging, auditing, and resuming workflows. The paper identifies the right tension: workflows produce knowledge but aren’t themselves knowledge objects. That said, it’s more of a *conceptual gap than a technical one—nobody has a system that fails in a specific, measurable way that this fixes.

Method maturity: This is a clever framing exercise, not a system or an experiment. The Lisp/Smalltalk heritage is invoked tastefully—symbolic forms, object identity, live images are well-chosen lenses. But the contribution is a vocabulary and a set of distinctions, not a mechanism you can implement. The derive/infer distinction is genuinely useful and probably the paper’s most transferable idea. However, the framework doesn’t address how you actually *build a knowledge substrate that scales, how you manage versioning of symbolic forms, or how you handle the combinatorial explosion of inference records in long-running workflows.

Experimental integrity: There are no experiments. This is a conceptual paper that explicitly acknowledges “formal transition semantics remain future work.” The examples are illustrative, not evaluated. There’s nothing to scrutinize numerically, which also means there’s nothing to validate the claims against.

Writing quality: The paper reads like a well-argued workshop position paper stretched to conference length. The core ideas (Section 3-4) are clear and well-structured. But Section 2 (background) spends too long on Lisp history and BPM that readers familiar with the space will skim, while readers unfamiliar won’t be converted. The “live-image thinking” metaphor is compelling but under-explained—this section should be rewritten to make the Smalltalk parallel concrete, not just gestured at. The paper would benefit enormously from a running worked example that traces one workflow through the entire framework, from definition to multiple instances to resumed execution.

Verdict: weak accept — The derive/infer distinction alone is worth the read, and the conceptual framing fills a real blind spot in how we think about LLM workflows. But the paper’s ambition outpaces its delivery: it promises a framework and delivers a vocabulary. If the authors formalize the transition semantics and demonstrate even a toy implementation, this becomes a strong accept.

Takeaways

Three things you can steal:

1. The derive/infer distinction as a design principle. Even if you never build a “knowledge substrate,” you can enforce this type-level separation in your workflow code. Wrap LLM calls in a distinct abstraction that captures prompt, context, policy, and response—not just the output. This alone will dramatically improve your debugging and audit trails.

2. Treat workflow state as queryable knowledge, not just checkpoints. Instead of serializing a JSON blob for “resume from here,” maintain a structured record of *why each state exists: what was derived, what was inferred, under what conditions. This is cheap to implement and pays dividends when debugging production workflows.

3. Capability policies for LLM judgment. The idea that every inference step should be governed by an explicit policy (“who authorized this LLM to make this decision, under what constraints”) is a governance pattern that scales beyond this paper’s framework. Useful for any system where LLM outputs have consequences.