arXiv:2607.08740 – Workflow as Knowledge: Semantic Persistence for LLM-Mediated Workflows

Note: The work discussed here is an arXiv preprint. It has not yet undergone a regular peer review process; the concepts presented have not been independently verified.

What is it about?

Applications with large language models (LLMs) no longer rely solely on individual prompts. They increasingly utilize explicit workflows: graphs with typed steps, loops, tool calls, checkpoints, and human approvals. The arXiv preprint 2607.08740 by Emanuele Quinto, Carlo Andrea Rozzi, and Francesco Zanitti recognizes this as a meaningful step away from the implicit, hard-to-follow control flow of pure prompt chains – but sees a deeper underlying problem unresolved: The components of a workflow remain scattered across source code, runtime layers, logs, traces, and chat histories, without being assigned clear semantic roles.

The authors propose a concept in which workflow definitions, running workflow instances, and the associated decision and inference datasets exist as permanent, queryable knowledge objects in a shared repository called “Knowledge-Substrate” – rather than merely as ephemeral log files or configuration data.

What is it good for / what does it bring?

The concept addresses a practical problem of today’s LLM workflow systems: When a workflow is interrupted or needs to be reviewed later, it is often difficult to trace what information was available at what time, what decision a human made, and what role a language model played in an outcome. The authors argue that their model offers three concrete advantages: first, a queryable workflow history – one could specifically ask for all postponed approvals or all workflows that touched on a certain assumption. Second, precise later verifiability, as each model request would be logged with its exact context. Third, a clearer separation of responsibilities: deterministic computation, judgments of the language model, human approvals, and the system-controlled process management would remain recognizable as distinct concepts, rather than blurring into a single execution trace.

How does it work (simplified)?

At the center of the proposal is a distinction between two types of computation steps. “derive” refers to deterministic calculations over existing state – such as scripts, parsers, schema checks, or routing rules that consistently yield the same value. “infer,” on the other hand, refers to an assessment mediated by the language model under a defined context and a permission policy controlled by the execution system. Importantly: The model’s response does not gain decision-making power over the workflow process – this authority remains with the execution system (“Executor”), which decides on declared branches itself.

The following diagram illustrates how a central control layer (the “DSL machine”) interprets semantic workflow objects, coordinates runtime services, and writes results back to the knowledge repository:

Figure 1: Architecture diagram of the proposal. Source: arXiv:2607.08740 (CC-BY-SA 4.0).

The authors define a vocabulary of recurring semantic objects – such as workflow definition, workflow instance, context snapshot, inference dataset, approval dataset, and panel dataset (“Panel”) – as well as operational basic terms like resource, guard condition (“Guard”), state, and dependency linkage. The following representation specifically shows the distinction between “derive” and “infer”:

Figure 3 in the paper: Comparison of “derive” and “infer.” Source: arXiv:2607.08740 (CC-BY-SA 4.0).

As a model for explanation, the authors draw from the Lisp programming world, where programs, data, and state traditionally exist in a shared, interactively inspectable environment – not as an implementation mandate, but as an analogy for how closely workflow definitions and the data they generate could be related. To illustrate, the authors work through an example in the appendix where a workflow verifies a scientific claim: It allocates resources, deterministically checks the completeness of a claim, has the language model provide a risk assessment, obtains human approval, and can convene a structured panel for clarification if needed – each step remains as its own, traceable dataset.

Additionally, the work conducts a small exploratory inventory: The authors reviewed 77 existing workflow-like artifacts (such as internal templates and agent and automation scripts) to check which of the proposed terms already appear in practice and where the vocabulary still needs refinement – for example, in distinguishing between a simple approval and a structured panel decision.

Classification & Limitations

The authors themselves emphasize that this is a conceptual design, not a finished, empirically tested implementation. They explicitly name open questions: How long should the many generated datasets be retained before storage needs and search efforts become too large? Not every intermediate result of a language model deserves permanent retention, as models can also produce redundant, low-quality, or misleading outputs. The boundary between “derive” and “infer” also requires, in the authors’ words, discipline from the developers of a workflow and should remain verifiable in case of doubt. Whether the proposed datasets actually improve verifiability, traceability, and reproducibility in practice is, according to the authors themselves, still open and requires further investigation.

Important for classification: This is an arXiv preprint without independent review. The architecture presented is currently illustrated only conceptually and based on a single worked-out example; a complete technical implementation or a comparison with existing workflow and provenance systems in practice is, according to the authors, still pending. As next steps, they mention among other things a prototype in Common Lisp and a broader investigation of additional practical workflows.

FAQ

What does the arXiv preprint 2607.08740 propose? A concept in which LLM workflows, their running instances, and the decision and model datasets generated in the process are stored as permanent, queryable knowledge objects instead of ephemeral logs.

What do “derive” and “infer” mean in this model? “Derive” stands for deterministic, reproducible calculations without a language model. “Infer” stands for an assessment mediated by the language model under a defined context, whose logged value can influence a system-controlled transition without possessing decision-making power itself.

What is a “Knowledge-Substrate”? An abstract, technology-independent storage layer that gives workflow objects a fixed identity, typed roles and relationships, and queryability across individual executions – for example, realizable through graph databases or other storage systems.

Has the concept already been practically implemented and tested? No. It is a conceptual proposal with a worked-out example in the appendix and a small exploratory review of existing workflow artifacts; a complete implementation is mentioned by the authors as a future step.

Has the work been reviewed by independent experts? No. It is an arXiv preprint that has not yet undergone a regular peer review process; the concepts presented have not been independently verified.