What are symbolic flows?

A symbolic flow is a pipeline in which every step is an explicit, typed operation drawn from a closed vocabulary, so the path from input to output can be replayed exactly, inspected step by step, and checked against invariants. No step guesses: when a step cannot produce a checkable result, the flow refuses and says why.

A Perslis Research term. “Symbolic flow” is our name for this discipline, and the definition above is ours. The ingredients are not new; §2 names their sources.

1. What is a symbolic flow?

The same idea is sometimes described as a symbolic pipeline, a deterministic AI pipeline or a verifiable AI workflow; we use symbolic flow and its plural, symbolic flows. A pipeline is a symbolic flow when four things are true of every step in it:

1. It is named. It is one operation from a closed vocabulary fixed before the flow was written. There is no “run this code” step and no free-text step.
2. It is typed. It declares what it accepts and returns; a flow whose types do not line up never runs.
3. It is deterministic. Given the same input, the step returns the same output every time. Nothing is sampled.
4. It is checked, and it may refuse. Its output is checked against a stated condition; if that cannot be met, it returns a refusal naming the reason, which travels to the end of the flow in place of an answer.

From these follow the three properties a user cares about: the run can be replayed exactly, inspected step by step (the trace of named operations is the explanation), and checked against invariants proved once per step (§5).

Who coined the term. Perslis Research uses “symbolic flow” as a defined term for this discipline. As far as we know it has no earlier standard meaning in AI engineering; in mathematics the phrase appears in symbolic dynamics with an unrelated meaning. “Symbolic” here is used as it is in symbolic AI: the steps manipulate explicit, human-readable symbols with defined meanings, rather than learned weights.

2. What it builds on

Every ingredient has a long history. What the term adds is the combination, applied to AI systems, with refusal as a first-class outcome. The debts, in rough chronological order:

• Program assertions and Hoare logic. Robert Floyd attached assertions to flowcharts in 1967 [2]; Tony Hoare made them an axiomatic system in 1969, writing $P\left\{Q\right\}R$ for “if $P$ holds before program $Q$ runs, $R$ holds when it finishes”, today usually written $\left\{P\right\}C\left\{Q\right\}$ [1]. His rule of composition, chaining two triples into one, is the proof in §5.3.
• Unix pipelines. Doug McIlroy argued in a 1964 memo for connecting programs “like garden hose”; pipes arrived in Third Edition Unix in 1973. The 1978 Bell System Technical Journal foreword put the discipline in two maxims: “Make each program do one thing well” and “Expect the output of every program to become the input to another, as yet unknown, program” [5]. A symbolic flow keeps the composition and adds what a byte stream lacks: types and a defined way to fail.
• Dataflow programming. Jack Dennis’s 1974 data flow procedure language treats a program as a graph of operators through which values flow, where procedures “always define functional transformations of values” [3]; Johnston, Hanna and Millar survey what followed [4]. The functional reading of each step is what makes replay possible.
• Proof pipelines. In the LCF proof assistant [9], any tactic may propose a proof, but only a small kernel of inference rules can construct a theorem. Anything may propose; only a trusted core may admit. That is the relationship a symbolic flow sets up between a language model and its floor (§6).
• Workflow engines and ETL. Extract-transform-load jobs and workflow engines run graphs of tasks; van der Aalst and colleagues catalogued their control-flow patterns [6]. The difference is in what a step may be (§8).
• Compiler passes and their verification. A compiler is a sequence of passes over intermediate representations. CompCert proves in Coq that each pass preserves the program’s meaning, so the whole compiler does [7]. Translation validation instead checks each individual run with an independent validator [8]. Both routes appear in §5, as Theorems 2 and 4.

None of these was designed for a pipeline whose most capable component, a language model, is also its least predictable one. That is the situation symbolic flows address.

3. Why flows: the trouble with agent chains

The common way to build a multi-step AI system is a prompt chain: each step goes to a language model and each output feeds the next prompt. Wu, Terry and Cai studied this pattern as AI Chains and found it improved transparency and control for its users [10]. LLM agents go further: in loops such as ReAct the model interleaves reasoning with actions and chooses the next step itself [11].

Chaining is a real improvement over a single prompt. It still leaves three problems that per-step quality does not remove:

• Errors compound. Each step is a stochastic transformation. Ten steps that are each right 95% of the time, with none able to repair an earlier error, are right about 60% of the time together (Proposition 3).
• Errors are silent. A wrong intermediate value is fluent text in the same format as a right one, so an error at step 2 surfaces, if ever, as a confident answer at step 10.
• Nothing can be replayed. Sampling, model updates and changing context mean the same input need not produce the same run twice, and a decision you cannot reproduce you cannot audit.

The deeper problem is where properties live. Our preprint The Orchestration Gap [12] argues that a property proved of each model, such as refusing a harmful request, does not compose into a property of a system that can select and sequence those models: authority lives in the orchestration chain. Chain-level invariants need a layer outside every model: deterministic, model-independent, provenance-aware and inspectable. A symbolic flow builds the chain itself so that such invariants can be stated and proved.

4. Anatomy of a symbolic flow

Six parts, each a property you can check by reading the flow rather than by trusting its author.

1. A closed vocabulary of operations. The set of things a step may do is fixed and finite, written before any flow is. A flow composes vocabulary items with fixed parameters, such as filter(approved) or sum(amount); a question that needs anything else is reported as unmappable, not approximated.
2. Typed inputs and outputs. Every operation declares its input and output types, and the flow type-checks before it runs.
3. Determinism. Every operation is a function in the mathematical sense: no sampling, no hidden clock, no network read mid-step. An external value enters as a pinned input, not as a call made during the run.
4. Provenance on every output. An output says which inputs it came from, through which steps. A Perslis floor answer carries its derivation, the same string checked before the tool was admitted (§6).
5. Invariants checked at each step. Each step has a stated condition on its output, checked when the step runs; an output that fails it is not passed on.
6. Refusal instead of guessing. A refusal is a typed outcome, not an exception or an empty string. It names its reason, such as no evidence, unmappable or invariant failed, and passes through the remaining steps unchanged, so the flow ends in either a checked answer or the place and reason it stopped.

5. The math

None of the mathematics is new. The point is to show which guarantee comes from which assumption, so you know what you lose when you drop one.

5.1 Setup

The flow’s output and its trace are

with refusals passing through. The flow is deterministic when every $f_i$ is a function: for each input it has exactly one value, a result or a refusal.

5.2 Replay

The proof is trivial; the content is in the hypothesis. It stops applying the moment any step samples: a model call at non-zero temperature, a clock or network read, iteration over an unordered collection. Replay is what makes audit possible: to check a past decision, run it again. As the Perslis defense runtime puts it, a non-deterministic safety layer cannot be replayed, and a layer that cannot be replayed cannot be certified (defense/runtime).

5.3 Invariants that compose

A Hoare triple [1] in which refusal is always acceptable: a step may decline, but whatever it returns satisfies $Q$.

This is Hoare’s rule of composition applied $n-1$ times, and it is the same shape as CompCert’s argument: a property proved once per step holds for the whole pipeline [7]. Steps can be verified one at a time and reused in any flow whose types and invariants line up.

This is the formal meaning of “invariants checked at each step”: you need not prove an operation correct to get Theorem 2, only a decidable invariant and the willingness to refuse. The guarantee is only as strong as what $Q$ says (§10).

5.4 Error compounding in unverified chains

Now drop determinism and checking. Model a chain of $k$ stochastic steps, and let $S_i$ be the event that step $i$ produces a correct output.

No independence is assumed: each $q_i$ is conditioned on the steps before it. For ten steps each right 95% of the time,

so four runs in ten are wrong, with no marker of which four.

The no-repair assumption is a model, not a law: where a later step can catch mistakes, the product is a lower bound. But a repair step is itself a check, which is the next result.

5.5 A sound check turns errors into refusals

Keep the stochastic steps, but put a verifier $V_i$ after each. It sees the step’s input and output and accepts or rejects; a rejection becomes a refusal. Call $V_i$ ${\epsilon }_i$-sound if, on a correct input, the probability that the step’s output is wrong and $V_i$ accepts it is at most ${\epsilon }_i$.

and with exact verifiers (every ${\epsilon }_i=0$) every run ends in a correct answer or a refusal.

This is easy to oversell. A verifier does not make the chain more capable: if the verifiers also accept every correct output, the flow still answers with probability $\prod q_i$, so ten steps of 0.95 answer 59.9% of the time and refuse 40.1% of the time. What changes is where that 40.1% goes: not into wrong answers that look right, but into refusals that name the step and the reason. Retrying a refused step helps when attempts are independent: at $q=0.95$ two attempts give $1-{0.05}^2=0.9975$ per step and ${0.9975}^{10}\approx 0.975$ end to end. That figure is optimistic, since a model resampled on the same prompt tends to repeat its mistakes; the safety comes from soundness, not retries.

We have measured the effect in-house: in a kinase identification task (What is a fail-safe model?), letting a model’s guesses count as facts cut correct identification from 1.000 to 0.753; admitting only verified facts kept it at 1.000 [14].

6. Where a model belongs in a flow

A symbolic flow does not ban language models; it fixes their role. A model may propose a flow; it never executes a guess. The proposal is written in the closed vocabulary, so it can be checked before anything runs, and once admitted the flow runs without the model.

The Perslis symbolic floor (Ask once. Own the answer.) [13] is the public example. Authoring a tool is itself a flow, with the model at exactly one step:

DESCRIBE → PROPOSE SPEC → ADMIT OR REFUSE → KEEP THE TOOL

1. Describe. You describe the question once, in English (“total value of approved invoices”). The tool prints a prompt carrying your column names and the closed vocabulary of primitives.
2. Propose. A model composes a specification. It is not code; it is a pipeline such as rows → filter(approved) → sum(amount). The model can only compose from the vocabulary, and there is no escape hatch into Python.
3. Admit or refuse. The floor decides whether the specification is admissible, by a fixed set of checks (seven, per the public page). Nothing the model writes is run until it has been admitted.
4. Keep. An admitted specification is signed, promoted and served over MCP from your own machine, with model_calls: 0.

The page lists three refusals, each an instance of §4: it will not guess (NO_EVIDENCE, not a plausible number); it will not run an unadmitted tool (a hand-edited specification is refused and named); and it will not invent a domain (a question the floor cannot check is reported unmappable). It also says why the admission gate is not in the download: a wrong specification that bypassed it would answer confidently, offline and indefinitely, with no model left to catch it. That is Theorem 1 cutting both ways: determinism makes a flow replayable, not right.

Two other placements respect the rule. A model may rank inside a set the flow has already computed, without being able to add to it. And a model’s output may enter as data: recorded once and labelled with its origin, it becomes an input the flow can replay. Recording a guess makes it reproducible, not true, so it stays out of any step that admits facts.

7. Symbolic flows in Perslis

Three public examples, at the level their pages describe them; all are research prototypes.

7.1 The answer flow of a floor tool

A promoted floor tool is the simplest symbolic flow: rows → filter(approved) → sum(amount). Its published answer carries a status (DERIVED), a value (1290.49), model_calls: 0, and a derivation that is the answer’s justification, not a log line. The vocabulary is small: rows, filter and seven reducers over plain JSON rows. The executor is 303 lines of standard-library Python with no network code, downloadable so anyone can read it (research/floor).

7.2 The VDSG decision flow

VDSG, the military Peel, is the floor at the wheel of id Software’s DOOM and Wolfenstein 3D, through one fixed chain, published on its demo page:

ENGINE STATE → SITUATION REPORT → RULES → ORDERS → EVIDENCE → ACTUATOR

• Facts. The situation report, built from engine state, is the whole input to the decision.
• A closed vocabulary of goals. Seven goals (HEAL, DODGE, RETREAT, ATTACK, SEARCH, RESUPPLY, EXPLORE) in fixed priority, each admissible only when its object is present.
• Deterministic rules. About 300 lines of plain Python, no weights, no state: the same report gives the same goal every time.
• Orders that only narrow. Orders such as don’t fire are parsed by a fixed phrase vocabulary, not a model. Unrecognised text is refused, never guessed; an order the world cannot satisfy is refused with a reason until it can be.
• Learning inside the set. An evidence memory ranks only inside what rules and orders left, so learning cannot take a forbidden action.

The runtime page states the general contract as facts → admissible set → objective → projection → memory → action, with a refusal that names its evidence; only the first stage is domain-specific. One precision matters for replay: the evidence memory is state, so a decision is a function of the report, the orders and the memory at that moment, and replay needs the memory snapshot too. That is how the demo replays a recorded run panel for panel. Its honest results: it clears E1M1 on Hurt Me Plenty, not on Nightmare, and does not yet clear E1M2.

7.3 The Peel fail-safe loop

Peel’s learning loop, published on What is a fail-safe model?, is a symbolic flow over the record of failures:

FAIL → OBSERVE → EXPLAIN → BUILD RULE → VERIFY → RETRY

Each stage is a named operation with a defined output: a recorded failure; the facts at the decision; the decision the failure is charged to; a rule that cites the failures that earned it and forms only when its harm is statistically clear against the base rate; a check that the rule applies only inside the admissible set; and a retry without the condemned option. Learning is readable counts, with no neural network in the loop that decides. A model may propose; only the floor admits a fact.

8. Symbolic flow vs agent chain vs workflow engine

This is the practical answer to “AI workflow vs agent chain”. It is not a verdict against workflow engines, which are good at scheduling and retries, or against language models, which are good at what a closed vocabulary cannot do: reading open-ended text and proposing structure. The claim is narrower. When a step’s output will be treated as a fact or cause an action, that step should be symbolic.

9. Symbolic flows and fail-safe models

A fail-safe model fails closed when evidence is missing, learns in ways that can narrow but never widen what it is authorised to do, and cites evidence for every refusal. Each is a property of a symbolic flow:

• Failing closed is refusal as a typed outcome (§4, item 6).
• Accountable refusals are provenance and the trace (§4, items 4 and 5).
• Bounded learning is Theorem 2 with the invariant “the chosen option lies in the admissible set”. A learner whose output is always a subset or reordering of its input preserves it; the fail-safe model page’s bounded-learning theorem is this argument, specialised.

A fail-safe model is, in these terms, a deciding loop built as a symbolic flow with the learner confined to one step. Peel, by Perslis Research, is to our knowledge the first fail-safe model; the exact claim and the closest earlier work are on What is a fail-safe model?. It is a research prototype, not a certified safety system.

10. What symbolic flows cannot do

These are the classic limits of symbolic AI, stated as plainly as the guarantees.

• Determinism is not correctness. A deterministic flow can be wrong every time. Theorem 1 guarantees reproducibility, not truth, which is why a flow needs an admission step, not just an executor.
• An invariant only guarantees what it says. Theorem 2 carries whatever $I$ states and nothing more; a property nobody wrote down is not protected.
• A closed vocabulary is closed. A question outside the vocabulary can only be reported as unmappable. Widening the vocabulary is human work: the knowledge-acquisition bottleneck that limited expert systems (see the history of symbolic AI).
• Perception is still hard. Getting reliable symbols out of pixels or prose is the symbol grounding problem, and it is where learned models earn their place. VDSG’s colour-based eye, for instance, agrees with its engine-taught labels 78–92% of the time on DOOM, and its cards are treated as a second witness, never as the map.
• Refusal has a cost. A sound verifier turns wrong answers into refusals, not into right answers. A flow that refuses 40% of the time may be safe and still useless (§5.5).
• Composition can explode. The number of possible flows grows exponentially with length, so searching for a flow, rather than checking a proposed one, is expensive: the combinatorial explosion classical planning met, and one reason proposing is left to a model.

Practical systems will therefore be hybrids: learned components for perception and proposal, symbolic flows for anything admitted as a fact or turned into an action. Neuro-symbolic AI covers that design space more broadly, and symbolic systems covers the representations the steps operate on.

11. Questions

What is a symbolic flow?

A symbolic flow is a pipeline in which every step is an explicit, typed operation drawn from a closed vocabulary, so the path from input to output can be replayed exactly, inspected step by step, and checked against invariants. No step guesses: when a step cannot produce a checkable result, the flow refuses and says why.

Who coined the term symbolic flow?

Perslis Research uses symbolic flow as a defined term, and the definition is ours. As far as we know it has no earlier standard meaning in AI engineering. The ingredients are older: dataflow programming, Unix pipelines, compiler passes, proof assistants and Hoare logic.

Is a symbolic flow the same as an AI agent workflow?

No. In an agent workflow or prompt chain each step is a model call, often choosing the next step too, so runs are not reproducible and a wrong intermediate value passes forward looking right. In a symbolic flow each step is a deterministic operation from a fixed vocabulary, every run replays exactly, and a step that cannot be checked refuses instead of returning a value.

Can an LLM be part of a symbolic flow?

Yes, in a fixed role. A language model may propose a flow in the closed vocabulary, rank options inside a set the flow has computed, or supply a recorded input. It never executes a guess: a proposal is admitted or refused before anything runs, and the admitted flow runs without the model.

Why does determinism matter?

Because a decision that cannot be reproduced cannot be audited. With deterministic steps the same input always gives the same output and trace, so any past result can be checked by running it again. Determinism does not make a flow correct; it makes it checkable.

Is a symbolic flow the same as a workflow engine or an ETL pipeline?

Not quite. A workflow engine or ETL tool schedules a graph of tasks, usually arbitrary code. A symbolic flow restricts what a step may be: one typed, deterministic, checked operation from a closed vocabulary, with refusal as a defined outcome. A symbolic flow can run on a workflow engine.

What happens when a symbolic flow cannot answer?

It refuses, naming the step where it stopped and the reason, such as no evidence, a question outside the vocabulary, or a failed invariant. It never returns a plausible value in place of a checked one.

Does a deterministic flow guarantee a correct answer?

No. Determinism guarantees the same output for the same input; a wrong flow is wrong every time. Correctness comes from the checks: invariants on each step, sound verifiers where they exist, and an admission step that refuses flows it cannot check.

12. References

1. C. A. R. Hoare. An Axiomatic Basis for Computer Programming. Communications of the ACM 12(10):576–580, 1969. doi:10.1145/363235.363259.
2. R. W. Floyd. Assigning Meanings to Programs. In Mathematical Aspects of Computer Science, Proceedings of Symposia in Applied Mathematics 19:19–32, American Mathematical Society, 1967.
3. J. B. Dennis. First Version of a Data Flow Procedure Language. In Programming Symposium, Lecture Notes in Computer Science 19:362–376, Springer, 1974. doi:10.1007/3-540-06859-7_145.
4. W. M. Johnston, J. R. P. Hanna, R. J. Millar. Advances in Dataflow Programming Languages. ACM Computing Surveys 36(1):1–34, 2004. doi:10.1145/1013208.1013209.
5. M. D. McIlroy, E. N. Pinson, B. A. Tague. UNIX Time-Sharing System: Foreword. Bell System Technical Journal 57(6):1899–1904, 1978. doi:10.1002/j.1538-7305.1978.tb02135.x.
6. W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski, A. P. Barros. Workflow Patterns. Distributed and Parallel Databases 14(1):5–51, 2003. doi:10.1023/A:1022883727209.
7. X. Leroy. Formal Verification of a Realistic Compiler. Communications of the ACM 52(7):107–115, 2009. doi:10.1145/1538788.1538814.
8. A. Pnueli, M. Siegel, E. Singerman. Translation Validation. In TACAS 1998, Lecture Notes in Computer Science 1384:151–166, Springer, 1998. doi:10.1007/BFb0054170.
9. M. J. C. Gordon, R. Milner, C. P. Wadsworth. Edinburgh LCF: A Mechanised Logic of Computation. Lecture Notes in Computer Science 78, Springer, 1979. doi:10.1007/3-540-09724-4.
10. T. Wu, M. Terry, C. J. Cai. AI Chains: Transparent and Controllable Human-AI Interaction by Chaining Large Language Model Prompts. CHI 2022. doi:10.1145/3491102.3517582. arXiv:2110.01691.
11. S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, Y. Cao. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629.
12. Perslis Research. The Orchestration Gap: why model-level alignment cannot survive multi-model runtimes. Preprint, 2026. research.perslis.com/orchestration-gap
13. Perslis Research. Ask once. Own the answer. The symbolic floor, runtime 1.0.0, 2026. research/floor
14. Perslis Research. Inference Placement: where learned inference earns authority in a provenance-constrained symbolic system. 2026. research.perslis.com/inference-placement