AgentTwin
Start with the result you needed
A receipt records evidence from a run. It can help explain what happened, but only if you know what the test required.
For a support workflow, the business rule might be one new ticket and one notification. Begin there. A wall of JSON becomes easier to read when you have a specific question: did this action happen exactly once?
This guide explains how to review evidence. It does not present a new measured run or promise that every receipt has identical fields across versions.
Read four things in order
| Inspect | Why it matters |
|---|---|
| Required and observed outcomes | Shows the concrete mismatch or satisfied rule |
| Requested and triggered condition | Shows whether the intended failure was exercised |
| Starting state and scenario identity | Makes the comparison interpretable |
| Application source identity | Connects the result to the code that ran |
“Expected one ticket, observed two” is a useful lead. “Failed” alone does not tell you whether the problem was a duplicate action, setup failure or unsupported operation.
Separate application failure from setup failure
If the workflow never started, you have not yet tested its retry behavior. If the dependency operation was unsupported, do not interpret the run as evidence about that real provider.
Check the clean baseline and the event sequence. Ask where execution stopped and whether the action reached the operation you meant to exercise.
AgentTwin's evidence guide explains its receipts and verification. Use that versioned documentation for exact commands rather than guessing a field name from an example.
Compare broken and repaired source fairly
Keep the input, starting state, fault and required outcomes stable. Change the application repair. Then compare the final state and check that the requested fault triggered in both relevant trials.
A source identity change is expected when you repair code. A changed specification deserves review: did the business rule change, or did someone weaken it to get a green result?
The retry walkthrough describes a historical synthetic example in which the source changed while the specification stayed fixed. It is evidence for that recorded example, not a customer case study.
Know what replay adds
Replaying a captured run helps check whether its saved application and conditions reproduce the observed evidence. Running today's application checks the code you are considering releasing.
Those are different questions. Do not use replay of an old passing run as proof that an untested new change is safe.
Also review what you share. Receipts can contain application details. Inspect an export before sending it outside your team, and use synthetic data during evaluation.
Turn evidence into the next action
For a mismatch, identify the smallest application behavior that could explain it. For a pass, list what the test does and does not cover. Then decide whether a new scenario would answer a remaining risk.
Run the sample to inspect a concrete receipt. If your team needs a repeatable test for a difficult workflow, discuss that workflow with its required outcome and dependency operations.