Fluxtion and execution inference in the academic landscape

Fluxtion's genesis

Fluxtion was designed from first principles to solve a practical problem — deterministic, low-latency, auditable event processing on the JVM — by a self-taught engineer, not from a compiler-theory background. The mapping onto the academic literature in this paper is retrospective: the references were found after the design existed, to locate it, name it, and borrow vocabulary and proofs.

We state this deliberately, for two reasons. First, honesty: we are not claiming to have read this work first or to have improved on it. Second, it is the stronger claim. Independent convergence on results that an established field arrived at separately is evidence that the design rests on sound foundations rather than fashion. Where Fluxtion matches the literature, the literature validates Fluxtion; where it diverges, the divergence is the contribution. Throughout, "we already do X" means "the design independently arrived at X," and the citation is the after-the-fact locator.

1. The one-sentence thesis

Fluxtion applies closed-world, whole-program compilation to the business event-coordination layer — the part of an application everyone else leaves as an open-world runtime — by inferring the execution schedule from a fully-known object graph and specialising it into a flat, deterministic dispatcher.

Every section below is either a field Fluxtion re-derived (so the field supplies proofs and vocabulary) or the gap between fields that Fluxtion is the first to cross.

2. Closest relative: synchronous dataflow languages

Lustre, Esterel, Signal, SCADE (Halbwachs, Caspi, Raymond, Pilaud, 1991; Berry & Gonthier; Colaço, Pagano & Pouzet, Scade 6, 2017).

These languages take a dataflow graph of nodes and statically schedule it into a single deterministic reaction loop with no runtime scheduler — same deterministic inputs ⇒ repeatable outputs, in bounded time. SCADE is certified for avionics (DO-178C) and flies flight-control software. This is, structurally, Fluxtion.

What the field supplies that Fluxtion re-derived:

• Causality analysis — proving the graph has no instantaneous cycles. Fluxtion's topological inference, formalised.
• Clock calculus — a formal algebra for "under what condition does this node compute." Fluxtion's dirty/trigger conditions, and the natural home of its trigger-control feature (an activation clock fired at end-of-reaction).
• Clock-directed modular code generation (Biernacki, Colaço, Hamon, Pouzet, LCTES 2008) — compiling a node separately and linking it into a larger one without re-analysing its internals. This is precisely the embedding/composition problem Fluxtion is now formalising; the corner cases are pre-solved here.

Divergence (and it is the whole point): synchronous languages applied closed-world dataflow compilation to embedded control and signal processing. Fluxtion applies it to general business event-driven coordination on a managed runtime (JVM), with audit and replay as first-class concerns. Same compiler discipline, an entirely different domain — see §7.

3. The change-propagation core: incremental computation & glitch-free FRP

Fluxtion's dispatch carries a change-signal (boolean dirty / void ≡ true), not data; data is pulled from node state or pushed to sinks.

• Self-adjusting / incremental computation (Acar, Self-Adjusting Computation, CMU 2005; Hammer et al., Adapton, PLDI 2014; Mokhov, Mitchell & Peyton Jones, Build Systems à la Carte, ICFP 2018). Fluxtion's dirty-bit propagation is incremental computation; the field offers optimality results for minimal recomputation.
• Glitch-freedom. In reactive propagation, a node should fire at most once per tick, with consistent inputs — never on a partial/stale combination. Fluxtion's topological single-visit dispatch is glitch-free by construction (the OR-guarded single call at convergent nodes — "path factoring" — is the mechanism). The FRP literature (Cooper & Krishnamurthi, FrTime, 2006; REScala; early Elm) treats glitch-freedom as a headline correctness property. Fluxtion should claim it by name.
• Push-pull FRP (Elliott, Push-Pull Functional Reactive Programming, Haskell Symposium 2009). Elliott argued the correct split is push for events, pull for values. Fluxtion independently arrived at exactly this: push the dirty signal, pull the data. The theory says this split is not arbitrary — it is the efficient one.

4. The generation mechanism: partial evaluation & whole-program compilation

• Partial evaluation / Futamura projections (Futamura, 1971; Jones, Gomard & Sestoft, Partial Evaluation and Automatic Program Generation, 1993). Specialising a generic dispatch mechanism with respect to a specific graph to produce a dedicated processor is the first Futamura projection (specialise an interpreter w.r.t. a program ⇒ a compiled program). Fluxtion is a partial evaluator for event graphs.
• Truffle / GraalVM (Würthinger et al., One VM to Rule Them All, Onward! 2013) does this at runtime — partial-evaluating an AST interpreter to native code. Fluxtion does the same thing ahead-of-time for the coordination layer. Same axis, different stage.
• Closed-world / whole-program optimisation. Devirtualisation, inlining, dead-code elimination and static scheduling are only sound under a closed-world assumption — the whole program is known, nothing loads dynamically. GraalVM native-image is explicitly closed-world (Wimmer et al., Initialize Once, Start Fast, PLDI 2019); that constraint is the source of its speed and small footprint. Fluxtion makes the same bet, one layer up (§7).

5. Internal representation & classical optimisation

Fluxtion's EventProcessorModel is, in compiler terms, an intermediate representation (IR), and several textbook analyses apply directly:

• SSA & φ-nodes (Cytron et al., TOPLAS 1991). Fluxtion's convergent-path OR-guard (isDirty_a | isDirty_b) is the dataflow analogue of an SSA φ-node merging values at a join. An SSA-style IR would make dead-node elimination, constant propagation, and a general form of path-factoring (common-subexpression elimination) fall out as standard passes rather than special cases.
• Sea of nodes (Click & Paleczny, A Simple Graph-Based Intermediate Representation, 1995; HotSpot C2). A graph IR unifying data and control flow — close to Fluxtion's node graph; dispatch generation is scheduling a sea of nodes.
• Liveness analysis ⇒ dead-node elimination. A node whose output reaches no sink/export/audit point is dead and can be pruned — a standard backward dataflow analysis, shrinking the generated processor.

6. The novel bridge: dependency injection is a latent closed-world graph

This is the section with the sharpest practical consequence.

Dependency injection frameworks — Spring above all — already build a closed object graph. A Spring ApplicationContext wires beans by constructor/field injection at startup; once booted, the graph is fixed. Spring is, structurally, constructor-reference wiring of a node graph — the same shape as a Fluxtion graph, minus the compilation.

The decisive empirical evidence that this graph is closed-world in practice: the industry tried to make Spring dynamic — Spring Dynamic Modules / OSGi (later Gemini Blueprint) — and effectively abandoned it. Real runtime dynamism was complex, fragile, and unwanted; the overwhelming majority of applications have a bean graph that is fully determined at boot. The market ran the open-world experiment and rejected it.

Consequence: essentially every Spring application is a closed-world business-coordination graph — a prototype Fluxtion application awaiting ingestion and optimisation. Fluxtion already demonstrates the path with FluxtionSpring (Spring bean definitions → AOT-compiled processor). The DI graph everyone already maintains is precisely Fluxtion's input.

So the bridge no one crossed:

• the synchronous-language community had the compiler discipline but stayed in embedded/control;
• the DI / middleware community had the business-application closed graph but treated it as something to interpret at runtime forever, never to compile.

Fluxtion connects them: take the closed graph the DI container already proves exists, and compile it instead of interpreting it.

7. What is genuinely new

Stripped to its core, the contribution is not "compile a dataflow graph" (Lustre did that) and not "whole-program closed-world compilation" (Graal did that). It is the conjunction nobody formed:

Apply closed-world, whole-program compilation to the general business event-coordination layer, collapsing the boundary between system and application.

In the conventional stack there are two contexts: a general-purpose, open-world system/runtime (broker, ESB, actor framework, DI container) built without knowledge of your application, and the application riding on top. The runtime cannot optimise across that boundary — hence dynamic dispatch, reflection, runtime routing, scheduling.

Fluxtion collapses much of that boundary. There is no general runtime interpreting your graph; the system functions — dispatch, wiring, change-propagation, lifecycle, audit — are partial-evaluated into your specific application as one compiled artifact. System context becomes application context. Whole-program optimisation then applies to business logic, yielding determinism, microsecond dispatch, a readable artifact, and audit/replay as first-class generated-processor concerns.

The patented mechanism — execution inference (deriving the execution schedule from the closed object graph) — is what makes the closed-world business-context compilation possible.

8. Functional core, imperative shell: Fluxtion and Mongoose

The platform's two-layer split — Fluxtion (the deterministic decision engine) and Mongoose (the deployment runtime that hosts it: connectors for Kafka/Aeron/Chronicle, agent-threading, an admin console, the integration with the enterprise's real, messy systems) — is a textbook instance of a named pattern: functional core, imperative shell (Bernhardt, Boundaries, 2012), and its architectural cousins hexagonal / ports-and-adapters (Cockburn) and the I/O boundary of pure functional languages.

• Fluxtion is intended as the functional core. I/O, wall-clock access, threads and nondeterminism belong at the shell boundary — leaving inferred, glitch-free, replayable dispatch in the core, which can then be reasoned about formally precisely because it is pure. (Today this is an architectural discipline; §10 covers how a checked effect boundary would make it a guarantee.)
• Mongoose is the imperative shell. All the nondeterminism the world actually contains — networks, brokers, failure, time, the enterprise's broken systems — is contained at the edge.

This is not tidiness for its own sake; it is why the audit/regulated story works structurally. Push all nondeterminism to the shell and the core's decisions become deterministic, replayable, and signable — because nothing impure can reach them. The thing that must be defensible (the decision) is mathematically clean; the thing that is inherently messy (integration) is walled off. No event-driven enterprise stack offers this, for a simple reason: they never made the core pure in the first place — their "core" interprets, dispatches dynamically, and does I/O inline, so there is no boundary to audit across.

And — connecting to §10 — an effect system is what would turn this split from a discipline into a guarantee: the compiler could prove the Fluxtion core performs no I/O and that Mongoose is the only place the world can leak in. That single boundary, made checkable, is the regulated-AI moat in one sentence: with that boundary made checkable, the decision core could be made provably pure, and the shell would be the only permitted ingress.

As with everything else here, the convergence is retrospective: the decomposition was forced by the determinism requirement — you cannot be deterministic if I/O lives in the core — not read from the pattern literature, which is exactly why it lands on the pattern that literature already named.

9. Paradigm neutrality: coordination is inferred, so computation is free

Fluxtion lets imperative POJO nodes (@OnEventHandler / @OnTrigger) and a functional DSL (map / filter / groupBy) sit in one graph and compile to one processor. That is usually framed as a convenience — three authoring surfaces, one artefact. It is more accurately a consequence of where execution inference operates.

Object-oriented and functional code are hard to combine because they disagree about how state and effects flow: mutation, identity, and message-passing on one side; immutability, purity, and composition on the other. That disagreement is a coordination concern, not a computation one. Execution inference works one level beneath it — on structure: a node with inputs, outputs, and references. An imperative handler and a functional combinator lower to the same object there, a vertex in a dependency graph, and the dispatch schedule is inferred from that graph identically for both (§1, §6). The paradigm distinction does not survive the descent to structure, so it never has to be reconciled.

The claim is interoperation without the usual tax — not fusion. A Fluxtion node is still imperative, or still functional, internally; Fluxtion does not blend the two into a third paradigm. What it removes is the friction that normally appears at the boundary between them — because that boundary is exactly the coordination layer, and Fluxtion infers the coordination layer rather than asking the program to author it.

Stated at the paradigm level, this is coordination/computation separation (Gelernter & Carriero, Coordination Languages and Their Significance, CACM 1992): a system has a computation model and a separate coordination model, and the leverage is in keeping them apart. Linda made the coordination model something you write — the tuple space. Fluxtion's variation is to infer it from the object graph's structure and specialise it away. Because coordination is a derived, separate layer, the computation inside each node is free to be whichever paradigm fits; OO-vs-FP stops being a decision the program makes globally. It is Appendix B's "dispatch as a property of structure," read through language paradigms rather than scheduling.

10. The one thing worth importing (vs. naming)

The literature mostly supplies validation, not parts: causality, glitch-freedom, push-pull, partial evaluation are all things Fluxtion already has. Two exceptions worth importing:

1. Modular dataflow compilation (Lustre, §2) — the pre-solved corner cases of composition/embedding; an exported-symbol manifest per compiled processor is the concrete borrow (see the companion spec on registeredEventTypes()).
2. Type-and-effect systems (Lucassen & Gifford, 1988; Koka) — the one genuinely additive feature: statically proving that nodes perform no I/O or nondeterminism, turning Fluxtion's determinism convention into a compiler-checked, certifiable property. For the regulated-AI / auditable-agent market, "the compiler rejects nondeterministic logic" is a categorically stronger claim than "by discipline, we don't write it" — e.g. the compiler can prove an agent's decision graph cannot call a random URL or read the wall clock.

11. Summary table

12. References (retrospective)

• N. Halbwachs, P. Caspi, P. Raymond, D. Pilaud. The synchronous data flow programming language LUSTRE. Proc. IEEE, 1991.
• J.-L. Colaço, B. Pagano, M. Pouzet. Scade 6: A formal language for embedded critical software development. TASE, 2017.
• D. Biernacki, J.-L. Colaço, G. Hamon, M. Pouzet. Clock-directed modular code generation for synchronous data-flow languages. LCTES, 2008.
• U. A. Acar. Self-Adjusting Computation. PhD thesis, CMU, 2005.
• M. Hammer et al. Adapton: Composable, demand-driven incremental computation. PLDI, 2014.
• A. Mokhov, N. Mitchell, S. Peyton Jones. Build systems à la carte. ICFP, 2018.
• C. Elliott. Push-pull functional reactive programming. Haskell Symposium, 2009.
• G. Cooper, S. Krishnamurthi. Embedding dynamic dataflow in a call-by-value language (FrTime). ESOP, 2006.
• Y. Futamura. Partial evaluation of computation process — an approach to a compiler-compiler. 1971 (reprinted 1999).
• N. Jones, C. Gomard, P. Sestoft. Partial Evaluation and Automatic Program Generation. 1993.
• T. Würthinger et al. One VM to rule them all. Onward!, 2013.
• C. Wimmer et al. Initialize once, start fast: application initialization at build time. OOPSLA (SPLASH), 2019.
• C. Click, M. Paleczny. A simple graph-based intermediate representation. IR Workshop, 1995.
• R. Cytron, J. Ferrante, B. Rosen, M. Wegman, K. Zadeck. Efficiently computing SSA form and the control dependence graph. TOPLAS, 1991.
• J. M. Lucassen, D. K. Gifford. Polymorphic effect systems. POPL, 1988.
• Spring Dynamic Modules / Eclipse Gemini Blueprint (OSGi) — industry history of dynamic-Spring, largely abandoned.
• T. Uustalu, V. Vene. The essence of dataflow programming. APLAS, 2005. (Comonads for dataflow.)
• D. Gelernter, N. Carriero. Coordination languages and their significance. Communications of the ACM, 1992.
• S. Mac Lane. Categories for the Working Mathematician. (Adjunctions.)
• G. Bernhardt. Boundaries (functional core, imperative shell). 2012.
• A. Cockburn. Hexagonal Architecture (Ports and Adapters). 2005.

Appendix A — Conjecture: Fluxtion is an adjunction

Recorded as an open conjecture, not a result. The design's author intuits a categorical adjunction underneath Fluxtion but has not formalised it; this sketches the two most likely homes and what a proof would require.

Candidate 1 — compilation as a free construction. Let Graph be the category of wired node graphs (objects: specifications — nodes + constructor-reference edges; morphisms: structure-preserving maps) and Proc the category of executable dispatchers. Generation is a functor F : Graph → Proc; recovering the underlying structure/behaviour is a forgetful functor U : Proc → Graph. The conjecture is F ⊣ U (free ⊣ forgetful). The defining property of a left adjoint is a universal construction: the inferred dispatcher is the canonical executable consistent with the graph — "there is no choice in the schedule; the wiring forces it." That felt inevitability is universality, and universal constructions are exactly what adjoints produce. (This is also why the design feels inevitable.)

Candidate 2 — the push/pull duality as a monad/comonad pair. Every adjunction induces a monad on one side and a comonad on the other. Dataflow has a known comonadic semantics — Uustalu & Vene, "The essence of dataflow programming" (2005): comonads model streams / context-dependent (pull) computation, while events/accumulation are monadic (push). Fluxtion's push-dirty (monadic) / pull-data (comonadic) split is precisely this shape, so the adjunction may surface as the monad/comonad pair behind push-pull (cf. Elliott, §3).

What a proof needs: pin down Graph and Proc (objects + morphisms), the functors F, U, and either the natural bijection Proc(F G, P) ≅ Graph(G, U P) or the triangle identities. Bounded, real category-theory work — a good collaboration with a categorical-semantics researcher. Payoff: an adjunction would hand you compositionality theorems for embedding for free — adjoints compose, left adjoints preserve colimits, so composing sub-graphs (the manifest work) would have predictable, provable behaviour rather than case-by-case reasoning.

Appendix B — Conjecture: dispatch as a property of structure ("coordination-first")

Observation (the design's author): mainstream paradigms — OO, FP, DSL, SQL — are primarily about structure: ways to organise and express. Behaviour/coordination (who runs, when, reacting to what) is then authored on top. Fluxtion inverts this: you declare the structure (the node graph) and the coordination — dispatch, order, propagation — is derived. Dispatch becomes a property of the structure. Coordination is the goal; structure is merely the input that pins it down.

Honest placement. This is not virgin territory — it is an under-named unifying lens over precedents that all "derive coordination from declared structure," and naming it is the contribution, not discovering it from nothing:

• Spreadsheets — the purest and most-used example on earth: declare cells + dependencies; the recalc engine derives evaluation order. Fluxtion is, in one line, a compiled, typed spreadsheet recalc engine for event-driven systems — the spreadsheet for the managed runtime. (The most accessible hook anywhere: everyone understands how a spreadsheet re-derives the answer; Fluxtion does that, compiled and typed, for events.)
• Hardware description languages (Verilog/VHDL) — you describe structure (gates, wires); behaviour (signal propagation) is the structure's emergent property; synthesis derives it. A circuit is dispatch-as-a-property-of-structure.
• Query optimisers (SQL, Datalog) — declare the query structure; the execution plan is derived.
• Build systems (Make) — declare the dependency structure; build order derived.
• Synchronous dataflow (Lustre) — schedule derived from the graph (§2).

So the useful move is the framing/name: coordination-oriented programming — coordination intent as the first-class declared artifact, dispatch as an inferred property — applied to general stateful event-driven business systems, where OO/FP/DSL otherwise force you to hand-author the coordination. Fluxtion's specific, novel point in that space is the conjunction in §7 (compiled, typed, closed-world, audited, managed-runtime).

Is it a new field? Honestly: not a new field ex nihilo — but a real, under-recognised paradigm worth naming, whose most relatable ancestor is the spreadsheet. Stating it crisply — "make dispatch a property of structure" — may change how people think about coordination, which is contribution enough.