telamin.
← All examples

EXAMPLE 03 · Runnable two-library workflow

Coordinate two reusable libraries

An order release needs several capabilities to agree: calculate its value, check available stock, apply a limit and obtain a risk decision. This example assembles those responsibilities from two synthetic Java libraries and a small application output component.

2 libraries assembled · 7 nodes coordinated · 7 scenarios checked

Download PDF reportOpen the investigation reel

Synthetic demonstration with recorded results, not a customer case study. Reports require no registration.

SUGGESTED TEAM WORKFLOW

From existing components to one checked process

How your team can use the tools, with an owner and an output at each stage. The recorded demonstration is documented separately below.

The captured example below connects two synthetic libraries, exercises seven scenarios and exports its own graph and investigation.

From existing components to one checked process1. Define the process: Requirements + interfaces. 2. Reuse the capabilities: Component selection. 3. Compile the joins: Application + new topology. 4. Exercise the process: Audit + evidence bundle. 5. Hand over the revision: Versioned build + evidence1. PERSON + LLMDefine the processAgree the joint decisionand failure behaviourRequirements + interfaces2. LLM + EXISTING LIBRARIESReuse the capabilitiesSelect supported componentsAdd application-specific rulesComponent selection3. FLUXTION COMPILERCompile the joinsDerive the coordinationInspect the resulting graphApplication + new topology4. APPLICATION + ANALYSERExercise the processTest success and failureInspect recoveryAudit + evidence bundle5. PERSON + TEST REVIEWERHand over the revisionLabel application and librariesShare tests and investigationVersioned build + evidencePeople guide intent and approve changes. Each handoff carries the context needed for the next check.From existing components to one checked process1. Define the process: Requirements + interfaces. 2. Reuse the capabilities: Component selection. 3. Compile the joins: Application + new topology. 4. Exercise the process: Audit + evidence bundle. 5. Hand over the revision: Versioned build + evidence1. PERSON + LLMDefine the processAgree the joint decisionand failure behaviourRequirements + interfaces2. LLM + EXISTING LIBRARIESReuse the capabilitiesSelect supported componentsAdd application-specific rulesComponent selection3. FLUXTION COMPILERCompile the joinsDerive the coordinationInspect the resulting graphApplication + new topology4. APPLICATION + ANALYSERExercise the processTest success and failureInspect recoveryAudit + evidence bundle5. PERSON + TEST REVIEWERHand over the revisionLabel application and librariesShare tests and investigationVersioned build + evidence
Follow the same application from the initial question to a versioned handoff. Return to an earlier step when a check reveals a gap.

  1. Define the process

    Describe what the whole process must achieve, including refusal and failure cases. Identify the components and interfaces the team is willing to reuse.

  2. Reuse the capabilities

    Use the existing components instead of asking the model to recreate their algorithms. Add adapters or application-specific code where the contracts require it.

  3. Compile the joins

    Generate the coordination between the selected components. Review the new graph so the joined process is explicit before it runs.

  4. Exercise the process

    Test the connected application. Use the Analyser to inspect the resulting values, failure paths and recovery, then save the investigation as a bundle.

  5. Hand over the revision

    Keep the component versions with the application revision. Pass the build, acceptance tests and bundle to an independent reviewer or testing agent.

The problem

An order should not be released unless its value, stock and risk checks agree. Rewriting every existing capability adds work; joining them carelessly can hide a failed check or produce a misleading success. The integration needs explicit decisions, failure behaviour and evidence.

What was done in this recorded example · 5 stages

  1. Define the joined decision

    An order needs acceptable value, available stock and a successful risk check before release.

  2. Package the value checks

    The first library provides the order input, amount calculation and stock check.

  3. Package the policy checks

    The second library provides the limit, risk and release decision. Both libraries are synthetic demo components.

  4. Compile their coordination

    Fluxtion connects the seven-node graph; the application adds an output recorder and builds against the two JARs.

  5. Check failures and recovery

    Seven scenarios pass. The synthetic risk exception produces no output; the next valid order succeeds.

The assistant defines component relationships. Fluxtion generates their coordination at build time. The Java host supplies each order; value, stock, limit and risk nodes feed a release decision and output recorder. Configured audit hooks expose intermediate facts. Neither an LLM nor the compiler is called per event.

Seven scenarios check branching decisions, a dependency exception and recovery.

The local run builds two separate JARs and executes freshly generated coordination across seven nodes. Normal and equality cases are accepted; limit and stock failures are rejected with the expected priority. A deliberately unavailable risk check raises an exception and produces no output. The next valid event succeeds. All seven scenarios match the expected outcomes.

Observed in the supplied synthetic fixture
Case or componentRecorded result
Normal / exact limitACCEPTED / ACCEPTED
Above limit / insufficient stockREJECTED_LIMIT / REJECTED_STOCK
Both checks failREJECTED_LIMIT (defined priority)
Risk unavailable / next valid eventEXCEPTION, no output / ACCEPTED
The new application graph includes the order event and seven processing nodes.
The new application graph includes the order event and seven processing nodes.
The next valid order is accepted after the risk-check exception.
The next valid order is accepted after the risk-check exception.
Download HTML reelDownload investigation bundle

To reopen the investigation in the Analyser, save both files in the same folder.

Why this matters

The calculation and policy capabilities stay separately packaged while the application defines their relationships. The checks make rejection priority and one exception path visible, so reuse does not hide how the combined workflow behaves.

The Analyser created an evidence bundle for reopening this investigation. The HTML reel and PDF provide a readable account to share.

Apply it to your process

Bring two real libraries or in-house capabilities whose coordination is costly to maintain. A pilot can assess adapters, dependency conflicts, exception paths and what the combined system records. Compatibility and licensing must be established for those specific libraries.

See the five-stage pilot journey
Technical appendix: reproduce the result and inspect the files

Run this example

Reproduction prerequisites

Use Python 3 and JDK 21. Download the public, version-pinned runtime below; no account or compiler credit is required for this download or these reproduction runs.

Download fluxtion-runtime 1.1.3 · Published Maven metadata

Maven coordinates: com.telamin.fluxtion:fluxtion-runtime:1.1.3.

The runtime’s published metadata declares AGPL-3.0. Its terms are separate from the example code’s Apache 2.0 licence. See the published licence and product licensing.

Download into the unzipped example directory:

curl -fL https://repo.repsy.io/mvn/fluxtion/fluxtion-public/com/telamin/fluxtion/fluxtion-runtime/1.1.3/fluxtion-runtime-1.1.3.jar \
  -o fluxtion-runtime-1.1.3.jar

Expected SHA-256 (the runner checks this before compiling):

2bd45eb62409403422d5a676a7ad177f1984aa80dc399c20ceb6b467eab4b775

Unzip the two-library reproduction package, then run from its library-workflow directory with the separately supplied reviewed runtime:

Download this example’s source and reproduction package

python3 run.py \
  --runtime ./fluxtion-runtime-1.1.3.jar \
  --out results

The runner builds two synthetic JARs and the included fresh generated Java, then checks seven scenarios. It verifies the runtime hash and records portable javac, jar and java commands. No generation, network or model call is needed.

The local README explains the component boundaries, captured scenarios and generated-output notice. Regeneration is separate from rebuilding the captured processor.

Compiler 1.0.83 generated this workflow locally. The owner-authorized Apache 2.0 notice was applied without changing the Java package/body, then the included processor was rebuilt and all seven scenarios passed.

Captured files

Detailed walkthrough

  1. Select two reusable capability groups

    The values library supplies the event contract, input, amount calculation and stock check. The policy library supplies limit, risk and release checks. Both are synthetic libraries written for this demonstration, not vendor products or independent organizations.

  2. Define a non-trivial graph

    GenerateWorkflow.java connects an input to parallel value, stock and risk paths. The limit depends on value; the release decision joins limit, stock and risk, then feeds a recorder. Relationships determine generated coordination.

  3. Generate and package

    The cached local Fluxtion compiler 1.0.83 generated source and GraphML. The runner builds values and policy JARs separately, then compiles the generated processor and output recorder against those JARs and the hash-pinned runtime.

  4. Check accepted and rejected paths

    The harness verifies normal acceptance, exact equality, limit rejection, stock rejection and defined limit-first priority when both fail. Each successful dispatch records exactly one outcome.

  5. Exercise an exception and recovery

    RiskCheck deliberately throws a synthetic dependency-unavailable exception. The harness requires no output for that event and verifies that the next valid order succeeds. This is not a real network-outage simulation or a general rollback guarantee.

  6. Share a reproducible result

    The package includes the definition, generated Java and GraphML, both libraries’ source, harness, commands and captures. Demo code is Apache 2.0 by owner authorization. Runtime dependencies are supplied separately under their own terms.

Scope and interpretation

  • Both JARs are synthetic; this demonstrates component boundaries and coordination, not compatibility with arbitrary vendor libraries.
  • The synthetic risk exception tests one in-process failure and subsequent event. No transaction rollback, network recovery, dependency conflict, throughput or production readiness is established.
  • This is a new tested workflow, not a before-and-after repair. Seven processing nodes and an additional order-event vertex appear in the application graph. Its branches are dependencies, not parallel execution threads.
  • The actual Analyser capture used its isolated local REST action socket with hosted OpenAI inference, not MCP transport or a local model. Its unsigned bundle was verified and reopened on the same machine. Source roots, flags and replay payload do not travel in the bundle.
  • The audit contains 12 records and all seven logged node IDs match the supplied graph. The native harness separately checks the synthetic exception and unchanged output count; absence of an audit output alone would not prove non-execution. Initialization wall time precedes a fixed fixture clock, so the investigation follows record indexes and values, not wall-time claims.

Example code is released under Apache 2.0. Runtime, third-party and general customer-output terms remain separate. Member hashes compare bytes; they do not certify a business decision.

Read and download
No registration. Pages, PDFs and source package are public for released examples.
Run the supplied code
No Telamin sign-in. Python 3, JDK 21 and the separately supplied runtime 1.1.3 JAR.
Use the playground
Pre-generated order example runs signed out. Its code editor is best on a desktop or laptop. The first run downloads a Java runtime.
Generate or interpret
Your own processor requires sign-in and allowance. Review data flows and licensing before generating.
Deployment and data flowsApplicable product rights

Continue exploring

See how an ordinary Java host owns the processor lifecycle and consumes its decisions.

Embed in an application

ONE WORKFLOW. A REVIEWABLE RESULT.

Discuss a pilot on your process.

Bring the workflow owner, a representative process and the constraints that matter. We will agree what the evaluation should establish.

Discuss a pilot