telamin.
← All examples

EXAMPLE 05 · Runnable maintenance example

An unfamiliar application. A focused repair. A checked extension.

Support receives an order that should have been rejected. A fresh AI session examines an unfamiliar 11-node application, explains the wrong shipping calculation and asks for approval. The team repairs it, checks the boundaries and extends the process without discarding the original evidence.

11 → 12 processing nodes · 85 repair assertions · 80 extension assertions · 45 independent boundary assertions

View the extended candidate investigationDownload PDF reportRead the diagnosis and approval

Original: recorded incident. Repaired: human-approved shipping correction. Extended: proposed handling-charge extension, not owner-approved as a business rule.

A synthetic engineering demonstration, with actual runs and saved investigations. Not a customer incident or a production-readiness claim. Reports require no registration.

SUGGESTED TEAM WORKFLOW

From a support case to a checked revision

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 repair has actual human approval. The handling-charge extension is a local proposal awaiting review.

From a support case to a checked revision1. Open the case: Original bundle + source. 2. Explain the finding: Recorded values + rule. 3. Approve and repair: Authorized change + tests. 4. Extend and check: New graph + regression. 5. Review the candidate: Build + evidence handoff1. SUPPORT + LLMOpen the caseOriginal bundle + source2. LLM + ANALYSERExplain the findingRecorded values + rule3. PERSON + LLMApprove and repairAuthorized change + tests4. LLM + REVIEWERExtend and checkNew graph + regression5. PERSON + TEST REVIEWERReview the candidateBuild + evidence handoffPeople guide intent and approve changes. Each handoff carries the context needed for the next check.From a support case to a checked revision1. Open the case: Original bundle + source. 2. Explain the finding: Recorded values + rule. 3. Approve and repair: Authorized change + tests. 4. Extend and check: New graph + regression. 5. Review the candidate: Build + evidence handoff1. SUPPORT + LLMOpen the caseOriginal bundle + source2. LLM + ANALYSERExplain the findingRecorded values + rule3. PERSON + LLMApprove and repairAuthorized change + tests4. LLM + REVIEWERExtend and checkNew graph + regression5. PERSON + TEST REVIEWERReview the candidateBuild + evidence handoff
Follow the same application from the initial question to a versioned handoff. Return to an earlier step when a check reveals a gap.

  1. Open the case

    Receive the reported outcome, matching source and original investigation.

  2. Explain the finding

    Connect the recorded result to the relevant source and state what was actually inspected.

  3. Approve and repair

    Agree the intended correction before editing and test the original failure.

  4. Extend and check

    Review the extension separately; test the changed topology, events and failure boundaries.

  5. Review the candidate

    Inspect before and after investigations with the source and reproducible checks.

The problem

A £105 order receives a 10% discount. Merchandise is now £94.50, below the £100 free-shipping threshold. But the application charges no shipping and releases the order against a £97 credit limit. Which rule caused that result, and can it be changed without breaking the rest of the process?

What was done in this recorded example · 5 stages

  1. Open the support case

    Start with the reported decision and its original investigation bundle.

  2. Explain the mismatch

    Connect £94.50 merchandise, missing shipping and the £97 limit to the Shipping.java comparison.

  3. Approve the repair

    The human authorizes the focused change and regression checks.

  4. Extend and test

    Add one handling-charge node and one event handler, then test boundaries, non-propagating updates and recovery.

  5. Return the evidence

    Inspect separate original, repaired and extended investigations with the source and tests.

Keep the original intake, the approved repair and the extension as separate revisions. Each saved investigation contains that revision’s captured log and graph. The code and runnable tests travel in the source package.

One repaired comparison. Then a visible structural change.

The approved repair compares the shipping threshold with discounted merchandise: £94.50 + £5 shipping = £99.50, so the order is rejected against a £97 limit. That repair leaves the generated topology unchanged. The subsequent candidate adds a HandlingCharge node and a HandlingFeeUpdate event on the existing Policy node, producing a new 12-node graph.

Observed in the supplied synthetic fixture
Case or componentRecorded result
Original recorded decision£94.50 total; RELEASED — inconsistent with the shipping requirement
Approved repair£99.50 total; REJECTED_CREDIT
Repair checks85 assertions pass; the original fails the shipping regression
Independent boundary checks45 assertions pass
Extended graph12 processing nodes; four business event types
Extension capture9 order attempts; 10 updates; 8 publications; 23 audit records
Failure and recoveryOverflow publishes nothing; fee reset and the next order succeed on the same instance
Original captured record: discountedPence 9450, shippingPence 0, outcome RELEASED. The shipping node detail is visible; the outcome is recorded in the same audit event.
Original captured record: discountedPence 9450, shippingPence 0, outcome RELEASED. The shipping node detail is visible; the outcome is recorded in the same audit event.
Extended application: the graph includes HandlingCharge beside Shipping; the approved repair remains in place.
Extended application: the graph includes HandlingCharge beside Shipping; the approved repair remains in place.
View the extended candidate investigationDownload HTML reelDownload investigation bundle

Original: recorded incident. Repaired: human-approved shipping correction. Extended: proposed handling-charge extension, not owner-approved as a business rule.

View the reel directly in your browser. For an offline handoff, save the HTML reel and investigation bundle in the same folder.

Why this matters

The team can see both the small repair and the larger structural change, inspect why each result changed, and hand the same context to another reviewer. This demonstration measures checks and observed outcomes; it does not establish diagnostic time or cost savings.

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 one representative process, its expected outcomes and failure cases. Agree the checks and evidence before evaluating a candidate change; finish with an adopt, extend or stop decision.

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 package and run from its complex-maintenance directory:

Download this example’s source and reproduction package

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

The runner verifies the public runtime checksum, compiles the supplied generated Java and executes the checks locally. No generation credit, model request or network service is used. Use a new output directory.

Source, supplied generated code, test harnesses and README are included. Runtime terms remain separate from the Apache 2.0 demonstration source.

Generated orchestration is included for offline execution. No hosted compiler is called by reproduction. Changing topology requires regeneration.

Captured files

Detailed walkthrough

  1. Receive the intake

    A synthetic Jira-ready ticket, source, generated graph and evidence bundle were supplied. Nothing was posted to Jira. The fresh session received no creator oracle or previous conversation.

  2. Diagnose from recorded facts

    The fresh model found Shipping.java tested the pre-discount subtotal. Its Analyser MCP calls were refused by the tool approval policy, so this diagnosis used the supplied files. The supervising assistant independently checked record 4 in the isolated Analyser.

  3. Obtain actual human approval

    The owner replied “Approve the repair and tests”. The visible conversation includes that real approval. The one-expression repair and boundary tests followed.

  4. Add the requested structural extension

    The owner requested a new intermediate node and a new event/handler. The assistant proposed a configurable handling charge as the concrete local candidate. That particular business rule remains for the owner to review.

  5. Review and preserve evidence

    An independent agent reran the tests and found a recovery test that swallowed assertion failures. The gate now fails on those errors and requires the expected 80-assertion completion. Original session messages and captures are preserved separately.

Scope and interpretation

  • Synthetic unfamiliar-code exercise, not a real customer incident or a formal blinded study. The creator knew the fault; the fresh diagnosis session was not given its oracle.
  • The original session’s MCP access was blocked. Analyser inspection and exports were performed separately by the supervising assistant through the local action API; no successful fresh-model MCP workflow is claimed.
  • Handling charge is a proposed local extension, not an owner-approved business rule. Human approval in the transcript applies to the shipping repair and tests.
  • The failure/recovery checks cover this synchronous fixture, not transaction rollback, arbitrary failures or production resilience.
  • Three model task prompts and actual visible messages are available; CLI default model/effort were not recorded. No token, cost or model-level comparison is claimed.
  • Bundles contain selected logs, matching graphs and saved investigations. They are unsigned and do not carry the complete source or execute a replay.

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 public fluxtion-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

Replay goes further: reproduce captured input events from a declared starting state and compare an intentional rule change.

Replay and compare

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