Inferred Orchestration Programming

The problem

Event-driven systems do not fail because developers cannot write business logic. They fail because the coordination layer becomes implicit, scattered and hard to inspect — spread across callbacks, listeners, brokers, runtime schedulers, workflow definitions and hand-written glue. The behaviour you ship is an emergent property of code nobody can point to.

The idea

Move orchestration out of hand-written runtime code and into compile-time inference. Developers write ordinary components, event handlers and dependencies. The compiler analyses the object graph, derives the event flow, and emits the runtime dispatcher as plain source.

Write ordinary Java components. Fluxtion infers the orchestration and generates the dispatcher.

Nothing is guessed. Orchestration is inferred from explicit structure you already wrote.

The Fluxtion implementation

Fluxtion is a Java implementation of inferred orchestration programming. Developers write POJOs, annotations, functional pipelines or wiring definitions; Fluxtion analyses the object graph at compile time, infers the event schedule, and generates a deterministic dispatcher that can be inspected, tested, audited, replayed and deployed across host runtimes.

The compiler technique is execution inference: closed-world compilation applied to the coordination layer of business software. Inferred orchestration programming is what this feels like to the developer; execution inference is how the compiler does it.

Alongside other paradigms

Inferred orchestration programming does not replace object-oriented, functional, reactive or workflow approaches. It sits alongside them by removing hand-written orchestration from event-driven software.

Why it matters

The generated dispatcher is not an implementation detail. It is the executable specification of the event graph — and that makes coordination a thing you can read, test and prove instead of a runtime behaviour you hope is correct.

• Deterministic dispatch — same inputs, same order, every time.
• Audit — hooks are generated from the graph, not bolted on.
• Replay — a structural property: replay any decision from its input events.
• Portability — the same generated processor model across supported JVM, server, edge and WASM environments.
• Less integration code — coordination is inferred, not hand-wired.
• Less runtime magic — the graph you review is the graph that executes.

The economics

Because orchestration is inferred from metadata attached to components, integration cost moves from repeated consumer-side glue to a one-time, supplier-side description. Suppliers describe a component once; consumers compose it at near-zero marginal integration cost — which is what makes a modulith tenable.

Proof you can open now

Event-driven systems become difficult when coordination is scattered and implicit. Fluxtion uses inferred orchestration programming instead: you write ordinary components and dependencies, and the compiler infers the event flow — emitting a generated dispatcher that makes dispatch order, trigger propagation, lifecycle calls and audit hooks explicit as source you can read, test and replay.