INSIDE THE PLATFORM
Determinism,
explained.
A plain-English look at the engineering. Follow one order check through the application: 10 units at £12, against a £100 limit. The numbers are illustrative; the concepts explain how the tools fit together.
Nodes & services
Small pieces of business logic.
Explicit connections.
A node is a component that handles an event, calculates a value or responds to a change upstream. A service supplies a capability the application uses, such as a limit lookup or an output connection. Your team can reuse existing components and add the logic specific to the business.
In our example, an order arrives for 10 units at £12. A value node calculates £120. A limit-check node compares that with an agreed £100 limit. A decision node reports rejection.
Teams and AI assistants can work on focused pieces instead of repeatedly inventing the entire coordination layer.
Orchestration
Who runs next—and why?
Orchestration is the coordination between those pieces: which handler receives an event, which dependent calculations follow and which conditions allow a result to propagate. Fluxtion uses the declared event handlers, dependencies and trigger rules to generate that coordination.
The limit check needs the calculated order value, so it follows the value calculation. The decision then uses the check result. Different events or conditions can select different paths through the same application.
The execution relationships become something engineers can inspect and test, with less hand-written dispatch and callback wiring.
Compilation
Resolve the coordination
before deployment.
The Fluxtion compiler examines the component structure and generates the event processor: source code that coordinates calls into your components. The graph and generated source make those relationships visible. Audit hooks can be generated alongside the dispatch path.
You review and test the resulting application, then deploy it on Mongoose or embed it in your own host. The processor still uses its application components and required libraries. It does not ask the authoring LLM to choose the next step.
Move repeatable integration work into the build, and run explicit software whose execution can be measured and reviewed.
Determinism
The same conditions.
A repeatable decision.
Determinism means a defined execution produces the same result when its relevant inputs and starting conditions are the same. For an event-driven application, that includes event order, initial state, application version and the values obtained from external services.
With the same order, the same £100 limit snapshot and the same application behaviour, the £120 order is rejected again. If the limit changes to £150, acceptance is an expected consequence of a changed input—not a contradiction of determinism.
Reproduce decisions, compare a change against known cases and investigate differences without relying on another model explanation.
Evidence recording
Put the observations
alongside execution.
Generated audit hooks give the application places to record event handling and node activity. Your instrumentation and capture configuration choose the fields and values retained. The execution graph and audit records therefore share application context that the Analyser can use.
The Analyser loads a capture with its matching graph. With the local project configured, engineers and a connected AI assistant can relate observations to the source, investigate the result, propose a change and check it through tests or replay.
Follow an explanation back to recorded facts and application structure, then share the investigation as an evidence bundle.
THE EXAMPLE, AS AN INVESTIGATION
“Why was this
order rejected?”
A useful answer links the input, calculation, applicable limit and decision. Run this small example yourself: the same £120 order is rejected twice under a £100 limit, then accepted when the limit changes to £150.
The playground makes the claim testable. Run the application and inspect the facts behind its answer—without installing software or reading the code first.
Use a desktop or laptop for the playground’s code editor. Select Main.java, then Run. This pre-generated example runs without sign-in; the first run downloads a Java runtime, so loading time depends on your connection. Regenerating the processor requires sign-in and compilation allowance.
How investigations become evidence bundles- Input10 units × £12
- Calculated value£120
- Limit snapshot£100
- Recorded decisionRejected: value exceeds limit
The explanation comes from the recorded values and rule. In the wider workflow, an AI assistant can help examine that evidence; people review the conclusion and approve any change.
See the actual playground audit trace
PUT THE PIECES TOGETHER
Author. Compile. Run.
Investigate. Improve.
Fluxtion provides the generated coordination. Mongoose supplies hosting and operational integration. The Analyser connects captured behaviour to application context. People remain responsible for requirements, review and acceptance.
Repeatable does not automatically mean correct.
A rule can be consistently wrong. Requirements, tests and human review establish whether the behaviour is the behaviour you intended. Our developing Assurance work builds on these explicit artefacts and checks.
EXPLORE THE NEXT STEP
See your workflow through this lens.
Bring a process with decisions you need to understand. We can walk through its components, coordination and the evidence that would make an investigation useful.