Keep the original answer

A result tells you what a run produced. Its history lets you examine the outside observations it used. Make another successful lookup and open the recorded history below the result.

use "./service"

pub flow main() -> Result<Int, ToolProblem<Text>> = service.lookup()

@tool pub flow lookup() -> Result<Int, Text>

Follow the call

Find the call and its reply in the record. The program asked the declared Tool for an amount; the fixture supplied the successful answer. That reply matters because the program could not compute it on its own.

History is not a transcript of every expression. A multiplication that follows from the source and its values can be computed again. An outside reply cannot be assumed to happen again, so it must be retained.

Replay, then run

After a successful run, select Declared failure without making another run. Choose Replay. You still get the original successful result, and the replay reports that no Tool implementation was used.

Now choose Run. This is a new execution, so the current fixture answers it and you see the failure. The difference is the lesson: replay explains a recorded execution; running asks for new observations.

What makes a record useful?

A record has to belong to the source and inputs that produced it. The playground's downloaded record includes its source bundle, canonical history and blobs. Replay checks those relationships. A changed file or corrupted reply is not silently accepted as the same execution.

History covers the run's observations. It does not tell you everything a remote service did internally, or prove that the service told the truth. Keep that distinction when using a record to investigate a problem.

Exact rules: semantic history, stored trace format.