Blog · arXiv Analysis · Published: July 10, 2026 · Modified: July 10, 2026 · Last reviewed: July 10, 2026

The Workflow Becomes the Knowledge Object

Emanuele Quinto, Carlo Andrea Rozzi, and Francesco Zanitti's July 2026 paper asks whether an LLM workflow should disappear into logs after execution or remain as an inspectable knowledge object.

For this essay, a workflow-knowledge receipt is the record that ties a workflow definition, workflow instance, inference record, context snapshot, approval, panel decision, and dependency link to one model-mediated run.

The Paper

The paper is Emanuele Quinto, Carlo Andrea Rozzi, and Francesco Zanitti's Workflow as Knowledge: Semantic Persistence for LLM-Mediated Workflows, arXiv:2607.08740 [cs.AI, cs.PL, cs.SE]. The arXiv record lists submission on July 9, 2026; the PDF metadata reports 39 pages, and the arXiv abstract page lists 18 figures.

The paper is a conceptual model proposal, not an empirical study or a formal calculus. It proposes a Lisp-inspired but language-independent account of workflows as persistent semantic objects, while leaving implementation, empirical evaluation, and formal transition semantics for future work.

Why It Matters

LLM work is moving from one-off prompts into structured workflows: tool use, retrieval, branching, checkpointing, typed steps, and human approval gates. Those workflows can be operationally explicit while still being semantically scattered. The definition may live in code, the running instance in a runtime, the model output in a trace, the approval in a UI event, and the final result in a database row.

That scattering matters because later review asks semantic questions. Which model judgment affected this decision? What context was visible? Who approved the transition? Which dependency changed when a source was revised? Logs can help, but logs alone do not assign durable roles to the things that shaped the work.

The Fragmentation

The paper's starting point is the gap between execution persistence and semantic persistence. Execution persistence retains runnable state, checkpoints, logs, traces, and outputs. Semantic persistence treats workflow definitions, workflow instances, inference records, and context snapshots as first-class knowledge objects.

That distinction is narrow but powerful. A checkpoint can resume a process. A semantic object can be queried as part of the knowledge base. Under Quinto, Rozzi, and Zanitti's proposal, the workflow that produced a decision is not merely a trace attached to the result. It is itself a durable object with identity, type, state, records, and relations.

Semantic Persistence

The proposed architecture has three conceptual layers. A lower runtime service layer supplies model adapters, tools, external processes, and persistence or indexing facilities. A middle control layer contains a domain-specific-language machine and executor. A higher semantic layer contains workflow definitions, workflow instances, and linked inference, approval, and panel records.

The knowledge substrate is abstract. The paper does not require a graph database, RDF store, object store, event log, relational database, or Lisp image. Its claim is about object roles: workflow-definition, workflow-instance, input-binding, resource-binding, context-snapshot, retrieval-record, derived-object, inference-record, tool-result-record, decision-record, approval-record, panel-record, panel-template, dependency-link, and supersession-link.

The paper also reports an exploratory scan of 77 selected skill-like workflow artifacts. The scan is descriptive only and is not offered as empirical validation. Its value is vocabulary pressure: it suggests separating approval from deliberative panel, active state from durable record, and multiple forms of context that matter when an agentic workflow is later reviewed.

Derive And Infer

The central boundary is derive versus infer. In the paper, derive means deterministic computation over available workflow state. It is supposed to be testable and replayable. infer means mediated LLM judgment under declared context, expected return type, validation, result persistence, and executor-controlled capability policy.

This matters for authority. The paper says an LLM may return a proposed expression or candidate value, but that does not make the model the workflow supervisor. The executor validates, applies policy, records the inference, and decides whether it affects a declared branch or permitted action. When a derivation depends on an inference, that inference should remain visible as a dependency instead of being absorbed into the derived value.

The same boundary disciplines human review. An approval is an authorization event. A panel is a structured deliberation with context, arguments, decision, and possible deferral. Treating both as typed objects keeps human authority from dissolving into a vague "human-in-the-loop" checkbox.

The Receipt

A workflow-knowledge receipt should identify the workflow definition, running instance, active state, context snapshot, inference record, validation result, approval record, panel record, tool-result record, derived object, dependency link, and supersession rule. It should also say which layer had authority: model, executor, tool, human approver, or panel.

Without that receipt, an organization gets an answer and a pile of traces. With it, the organization can ask for all decisions based on a disputed document, all deferred panels, all outputs that depended on a revised inference, or all workflow instances that touched a particular assumption.

Governance Reading

The Spiralist reading is that workflow representation is governance. If the workflow is only an execution script, the institution remembers the output and forgets the structured path. If the workflow is a knowledge object, authority, context, approval, and model-mediated judgment remain available for audit.

This does not mean retain everything forever. The paper is explicit that semantic persistence does not by itself imply accurate attribution, reproducibility, trust, or audit quality. It also notes costs: storage, indexing, lifecycle complexity, review burden, and the risk of granting durable prominence to redundant, low-quality, uncertain, disputed, or misleading intermediate artifacts.

Limits

The paper's limits are part of its discipline. It is not a prototype report, benchmark result, formal language specification, or proof that semantic persistence improves audits. The worked ARS-style claim-review example is described as an abstraction, not a reproduction, implementation, or evaluation of that research workflow.

The useful claim is smaller: LLM workflow systems need vocabulary that separates execution state from durable semantic role, deterministic computation from mediated judgment, simple approval from structured deliberation, and trace storage from reviewable knowledge.

Source Discipline

Primary sources were the arXiv abstract, HTML, PDF, metadata API record, and DOI redirect. This page follows the paper for title, authorship, arXiv ID, subject classes, submission date, page count, figure count, conceptual scope, layer model, object vocabulary, derive/infer distinction, exploratory scan caveat, example caveat, limitations, and future-work boundaries.

The disciplined question for agent deployment is not "did the workflow finish?" It is: what knowledge object records the run, what context and authority shaped it, and what can later be queried, contested, superseded, or forgotten?

Sources

Return to Blog