telamin.
← All examples

EXAMPLE 01 · Runnable example

From a business rule to running software

A team needs to reject orders above an agreed limit and explain each decision. This worked example follows one request through an actual AI authoring conversation, generated coordination and checked runtime results.

1 prompt · 4 application nodes authored · 7 decision cases passed

Download PDF reportRead the authoring conversationOpen the investigation reel

Recorded worked example with prepared SDK notes and local compiler setup. Reports require no registration.

SUGGESTED TEAM WORKFLOW

From a requirement to a testable application

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

The recorded trial below covers authoring, generation and verification. Template setup, SOP input and a formal testing-agent handoff describe the wider team workflow.

From a requirement to a testable application1. Start with a template: Project + working context. 2. Describe the outcome: Requirements + checks. 3. Author, compile, run: Application + audit records. 4. Check the evidence: Findings + evidence bundle. 5. Label and hand over: Build + tests + bundle1. PERSON + LLMStart with a templateCreate a starter projectOpen it in the AnalyserProject + working context2. PERSON + LLMDescribe the outcomeExplain the app or supplyan approved SOPRequirements + checks3. LLM + FLUXTIONAuthor, compile, runUse skills and componentsGenerate the coordinationApplication + audit records4. PERSON + ANALYSER + LLMCheck the evidenceCompare recorded behaviourwith the requirementsFindings + evidence bundle5. PERSON + TEST REVIEWERLabel and hand overFreeze the candidate buildPass on the same contextBuild + tests + bundlePeople guide intent and approve changes. Each handoff carries the context needed for the next check.From a requirement to a testable application1. Start with a template: Project + working context. 2. Describe the outcome: Requirements + checks. 3. Author, compile, run: Application + audit records. 4. Check the evidence: Findings + evidence bundle. 5. Label and hand over: Build + tests + bundle1. PERSON + LLMStart with a templateCreate a starter projectOpen it in the AnalyserProject + working context2. PERSON + LLMDescribe the outcomeExplain the app or supplyan approved SOPRequirements + checks3. LLM + FLUXTIONAuthor, compile, runUse skills and componentsGenerate the coordinationApplication + audit records4. PERSON + ANALYSER + LLMCheck the evidenceCompare recorded behaviourwith the requirementsFindings + evidence bundle5. PERSON + TEST REVIEWERLabel and hand overFreeze the candidate buildPass on the same contextBuild + tests + bundle
Follow the same application from the initial question to a versioned handoff. Return to an earlier step when a check reveals a gap.

  1. Start with a template

    Ask your LLM to create a starter project and open it in the Analyser. Connect the project, tools and authoring skills before changing the application.

  2. Describe the outcome

    Describe what the application must do, or work from an approved SOP or company document. Review the rules, exceptions and acceptance checks with the assistant.

  3. Author, compile, run

    The assistant uses Fluxtion authoring skills and Analyser tools. Fluxtion generates the coordination and configured audit instrumentation. Running the application produces the records to inspect.

  4. Check the evidence

    Direct the Analyser to inspect the run and create an evidence bundle. Iterate on the application and its tests until the captured behaviour meets the agreed checks.

  5. Label and hand over

    Approve and label a candidate revision. Give a testing agent or reviewer the build, requirements, test inputs and evidence bundle so they can check it independently. A later change produces a new candidate.

The problem

An order check is small enough to understand, but it still needs a clear contract: which values enter the calculation, what happens at the limit, and what the reviewer can inspect afterwards. A plausible explanation is not a substitute for those checks.

What was done in this recorded example · 4 stages

  1. State the rule

    Calculate quantity multiplied by price in integer pence. Accept a valid order at or below its limit, reject a higher value and refuse invalid input.

  2. Author the application

    With gpt-6.1-sol configured at low reasoning effort, the recorded session authored four application nodes plus an input type, generator and verifier.

  3. Generate and run

    The assistant invoked the prepared local compiler helper. Fluxtion emitted Java and GraphML, then the runtime-only verification checked seven decisions and four invalid constructions.

  4. Check the evidence separately

    Reviewer-authored checks independently exercised nine valid cases with exact audit facts, five invalid constructions and a subsequent valid event. The original seven captured records were also checked against the requirements.

Stated requirements lead to authored components and an application definition. Fluxtion generates their coordination, and the runtime records the values behind each decision. Separate checks compare those observations with the agreed requirements.

The same order is rejected twice. A different limit changes the answer.

In the captured run, 10 units at GBP 12 produce a GBP 120 order. With a GBP 100 limit it is rejected, including a second identical input. With a GBP 150 limit it is accepted. Equality is accepted. All seven decision cases match the stated rule; four invalid or overflowing inputs are refused.

Observed in the supplied synthetic fixture
RequirementObserved check
Calculate quantity × unit price10 × GBP 12 = GBP 120
Reject an order above its limitGBP 120 / GBP 100: REJECTED
Accept at or below the limitGBP 120 and GBP 150 limits: ACCEPTED
Repeat the same input consistentlyBoth identical inputs: REJECTED
Refuse invalid or overflowing inputFour invalid inputs refused
The newly authored application connects four application nodes to the recorded order checks.
The newly authored application connects four application nodes to the recorded order checks.
An order at its limit is accepted in the reopened investigation.
An order at its limit is accepted in the reopened investigation.
Download HTML reelDownload investigation bundle

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

Why this matters

The request, visible conversation, application graph and test outcomes remain available for review. A reviewer can compare the intended rule with what the generated application actually did, including repeated input and boundary cases.

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

A pilot could replace this small rule with one representative approval or operational control. Your team supplies examples, exceptions and acceptance criteria; together we assess the implementation and its evidence before deciding whether to adopt, extend or stop.

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 this example’s standalone source package and run from its authoring-session directory with Python 3, JDK 21 and 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 verifies the runtime and original trial manifest, compiles the actual generated Java and authored nodes, then executes the model’s verifier and separate reviewer checks. The original decision CSV must match. No model or generation request is made.

The recorded local-build.sh is redacted historical context, not a portable installation script. Use run.py for reproduction. Regeneration needs separately configured compiler access.

This is the actual fresh processor from the recorded trial. Four application nodes and their definition were authored without a previous order implementation; Fluxtion generated the coordination. The curated Java was rebuilt after its owner-authorized demo licence notices were applied.

Captured files

Detailed walkthrough

  1. Prepare the recorded task

    The session received requirements, generic SDK notes, cached dependencies and an offline compiler helper. No previous order implementation was supplied.

  2. Record the actual conversation

    The configured model was gpt-6.1-sol with low reasoning effort in CLI 0.164.0. One user prompt led to one completed CLI turn, three visible assistant messages and eight completed command actions. A CLI turn is not one underlying inference request.

  3. Author four application nodes

    OrderInput accepts events, Calculation computes the amount, LimitComparison applies the rule and Decision publishes outcomes. Order.java supplies input validation; GenerateApplication and VerifyApplication supply generation and checks. All seven Java files were newly authored.

  4. Generate and execute

    The first local generation and verification attempts passed. The emitted OrderProcessor and its original events.yaml are included, with separate source and artifact hashes. Initial lifecycle timestamps precede application clock configuration.

  5. Verify requirements independently

    The separate ReviewerChecks harness checks expected results, exact captured quantity/price/limit/value/decision fields, repeat dispatch, invalid inputs and a subsequent valid event. It is separate from the model-authored verifier.

  6. Preserve the actual record

    The curated conversation retains visible messages and completed command results in order. Local roots and expanded compiler classpaths are redacted; private reasoning and credentials are excluded. The full session receipt documents counts, setup and timing scope.

Scope and interpretation

  • One prepared authoring demonstration, not a benchmark or general success-rate estimate. Generic SDK notes, a compiler helper and cached dependencies were supplied; no previous order implementation was provided.
  • One completed CLI turn contains multiple visible messages and command actions. The number of underlying model requests is not exposed. The receipt’s elapsed time excludes prepared setup and is not a total-effort measure or timing guarantee.
  • The model-authored verifier checks seven valid cases and four invalid constructions. The separate reviewer checks nine valid cases, five invalid constructions and recovery. These establish the tested requirements, not universal correctness or human acceptance.
  • The original audit contains lifecycle wall time before the application clock is configured. Compare record values and event order rather than treating these mixed timestamps as a production chronology.
  • The subsequent Analyser capture used its isolated REST action socket with hosted OpenAI inference. Its bundle contains the original trial audit and graph, not the additional reviewer events or source tree. It was verified and reopened on the same machine. Ordinary member hashes do not authenticate origin or deployed-binary identity.

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

Follow the same rule into a real Analyser investigation of the deliberately wrong comparison.

Investigate and fix

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