Best use
Trust and diagnosisReplay is where you go when status alone is not enough.
Guidance
Mission Replay
Mission Replay is not just a conversation history. It is the run’s proof-of-work layer, showing execution events, meaningful moments, risks, review pressure, and the path to the final artifact.
Guide summary
Use this page to understand the surface before you act inside it.
Use the proof-of-work timeline to understand what happened during execution and why the result should or should not be trusted.
Guide type
GuidanceThis guide reflects the current product workflow and surface ownership.
Sections
7Summary first, then steps, mistakes, and recovery notes.
Related guides
4Written against the current product structure and core execution workflow.
Difference from chat
Execution narrativeReplay explains process and proof, not just message output.
Related action
Open the linked runReplay and run detail work best together.
Guide section
What it is
Mission Replay is the event timeline for a run.
When to use it
Use it after failures, before shipping important output, when review raised concerns, or when you need to explain what happened to someone else.
Where to find it
Find it from run detail pages.
What happens next
You use this surface as part of the broader mission -> task -> run -> artifact workflow.
Common mistake
Treating Replay as a transcript only
Related action
Use Replay before retrying a failed run so you know whether the next move should be technical, contextual, or support-oriented.
Guide section
Why it matters
It makes the path to the artifact inspectable and gives you a stronger basis for trust, diagnosis, and future improvement.
Guide section
How it fits into the workflow
Replay sits after and around execution. It explains the run that just happened and informs what should happen next.
Guide section
Step-by-step usage
- Open the replay from the run detail page.
- Scan key moments first.
- Review operator contributions, risks, and evidence usage.
- Check how the artifact formed.
- Decide whether to continue, retry, approve, or escalate.
Guide section
Inputs and outputs
Inputs needed
A run with recorded execution state
Outputs produced
Timeline events
Operator contributions
Risk and approval signals
Artifact formation context
Guide section
Common mistakes
- Treating Replay as a transcript only
- Ignoring review challenges
- Looking only at the final artifact when trust is the actual question
Guide section
Troubleshooting
If Replay looks thin, the run may not have progressed far enough or the relevant signals may live on the run detail surface instead.