telamin.
← All examples

EXAMPLE 06 · Captured-input replay

Same captured inputs. Reproduced behaviour. Visible differences.

An investigation explains an observed decision. Replay asks a different question: can the application reproduce that behaviour from the captured events and starting conditions? This demonstration records a live synthetic host session, replays its journal, then runs the same inputs through a changed rule.

16 / 16 host observations match · 9 / 9 order audit records match · 2 intentional rule differences

View the investigation reelDownload PDF report

These reels show saved investigations. The application runner executes replay and compares the observations.

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 captured sequence to a measured comparison

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

Application processes perform replay. The Analyser investigates the resulting records; it does not execute the processor.

From a captured sequence to a measured comparison1. Capture the inputs: Journal + starting state. 2. Replay the sequence: Fresh run + observations. 3. Compare observations: Explicit match counts. 4. Evaluate a change: Changed-rule differences. 5. Share the evidence: Runs + investigations1. APPLICATION HOSTCapture the inputsJournal + starting state2. APPLICATION RUNNERReplay the sequenceFresh run + observations3. CHECKS + REVIEWERCompare observationsExplicit match counts4. DEVELOPER + RUNNEREvaluate a changeChanged-rule differences5. ANALYSER + REVIEWERShare the evidenceRuns + investigationsPeople guide intent and approve changes. Each handoff carries the context needed for the next check.From a captured sequence to a measured comparison1. Capture the inputs: Journal + starting state. 2. Replay the sequence: Fresh run + observations. 3. Compare observations: Explicit match counts. 4. Evaluate a change: Changed-rule differences. 5. Share the evidence: Runs + investigations1. APPLICATION HOSTCapture the inputsJournal + starting state2. APPLICATION RUNNERReplay the sequenceFresh run + observations3. CHECKS + REVIEWERCompare observationsExplicit match counts4. DEVELOPER + RUNNEREvaluate a changeChanged-rule differences5. ANALYSER + REVIEWERShare the evidenceRuns + investigations
Follow the same application from the initial question to a versioned handoff. Return to an earlier step when a check reveals a gap.

  1. Capture the inputs

    Record inputs before dispatch and identify all starting conditions and dependency values.

  2. Replay the sequence

    Run a matching build in a fresh process with controlled clocks and external effects.

  3. Compare observations

    Compare the specified outputs and recorded values, without claiming whole-log byte identity.

  4. Evaluate a change

    Run the same captured inputs against a deliberately changed application rule.

  5. Share the evidence

    Inspect the original and changed records, then supply bundles alongside the runnable input package.

The problem

A sequence of orders changes its limits, stock and dependency availability over time. Checking isolated inputs is not enough: the order of updates and the starting conditions matter. A reviewer needs to distinguish changes caused by the code from changes caused by the environment.

What was done in this recorded example · 5 stages

  1. Record the session

    Save actual incoming commands and the explicit starting-state contract.

  2. Reproduce it

    Start a fresh application process using the saved inputs.

  3. Compare the records

    Check exact host observations and selected audit records.

  4. Evaluate a change

    Apply a stricter limit rule and identify the two changed decisions.

  5. Share the result

    Hand over the runner, inputs, comparison and saved investigations.

Capture inputs and starting conditions, execute the matching build, compare the defined observations, then inspect an intentional changed build. The application runner performs the replay; the Analyser opens the resulting records and saves investigations.

The same build matches. A stricter rule changes exactly two decisions.

The host saves each command before dispatch and captures its initial state. The original input producer is then deleted. Fresh JVMs replay only that saved journal and state. All 16 host observations and all nine order audit records match. Changing the limit rule from “at or below” to “below” rejects exactly the two equality orders; the other observations retain their expected behaviour.

Observed in the supplied synthetic fixture
Case or componentRecorded result
Captured inputs16 commands: nine orders and seven host-state updates
Starting conditionsFresh processor; explicit limit, stock, risk availability and clock
Same-build host observations16 of 16 match
Resolved order inputs9 of 9 match
Selected order audit records9 of 9 match, including recorded node observations and injected clocks
Original execution8 decision publications and one synthetic dependency exception
Changed rule2 equality decisions change from ACCEPTED to REJECTED_LIMIT
Negative controlsDifferent state/order change behaviour; malformed state, sequence, overflow and clock mismatch are refused before execution
Original recorded values: valuePence 10000, limitPence 10000, withinLimit true, outcome ACCEPTED. Mixed clock sources make the timeline span unsuitable as an elapsed duration.
Original recorded values: valuePence 10000, limitPence 10000, withinLimit true, outcome ACCEPTED. Mixed clock sources make the timeline span unsuitable as an elapsed duration.
Changed-build recorded values: valuePence 10000, limitPence 10000, withinLimit false, outcome REJECTED_LIMIT. The application runner compares the recorded observations.
Changed-build recorded values: valuePence 10000, limitPence 10000, withinLimit false, outcome REJECTED_LIMIT. The application runner compares the recorded observations.
View the investigation reelDownload HTML reelDownload investigation bundle

These reels show saved investigations. The application runner executes replay and compares the observations.

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

A reviewer can reproduce this captured scenario, see that state and event order matter, and identify the exact effects of a changed rule. In a pilot, the same discipline can support regression review and incident investigation when the necessary inputs and external conditions have been captured.

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 captured-replay 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. Capture before dispatch

    The host journals all 16 actual incoming synthetic commands before dispatch. Limit, stock and risk updates are host-owned; the processor receives resolved OrderRequest snapshots.

  2. Remove the producer

    The producer CSV is deleted before replay. Saved journal and starting-state bytes are retained and checked by hash.

  3. Run in fresh JVMs

    The same compiled build runs from a fresh processor with its captured initial host state. No network services or irreversible external effects are invoked.

  4. Compare meaningful observations

    Compare all 16 host rows, 9 resolved inputs and 9 OrderRequest audit records, including injected event/log/end clocks. Initialization, lifecycle and clock-install records are outside this comparison.

  5. Change one rule

    Compile a second build changing <= to <. Only the two equality decisions change; this is an intentional alternative requirement, not a claimed defect fix.

  6. Inspect and hand over

    The Analyser saves original, same-build replay and changed-build investigations. Downloadable source and inputs supply the execution path separately from the unsigned bundles.

Scope and interpretation

  • Synthetic captured-input session, not replay of a production incident. Starting state means a fresh processor plus explicit host values, not arbitrary heap checkpointing.
  • Risk availability is a controlled synthetic dependency. Unrecorded service responses, randomness, uncontrolled clocks, shared concurrent state or irreversible effects require separate capture/control.
  • Nine order audit records are compared. Raw complete logs are not byte-identical; initialization and clock-install records contain wall-clock/object-identity differences.
  • The Analyser screenshots contain mixed initialization and fixture clocks. Their displayed multi-year span is not an elapsed-time measurement; follow record order.
  • The application runner executes replay. Opening a bundle or stepping through an HTML reel only reopens the saved investigation.
  • Member hashes detect changed contents; they do not authenticate the sender or attest an actual production deployment.

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

The maintenance example shows a diagnosis, real human approval, focused correction and a new intermediate node.

Maintain 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