> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Trace & Replay

> The trace view is the human-readable projection of the audit chain — every step, input, output, decision, and side effect for every workflow run.

The **trace view** shows every detail of a workflow run: each step, its inputs and outputs, decisions made at conditional branches, AI inference calls with prompts and responses, integration calls with payloads, and any side effects. It is the primary surface for debugging and the human-readable projection of the audit chain.

## Anatomy of a trace

A workflow run trace shows:

| Element                    | What you see                                                                                                                                                                    |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Run metadata**           | Run ID, trigger type and payload, start time, duration, status (completed / failed / in-progress)                                                                               |
| **Step-by-step execution** | Each step in order: type, inputs, outputs, duration                                                                                                                             |
| **AI inference steps**     | Model, prompt sent (with substituted values), response received, token usage, confidence scores                                                                                 |
| **Integration steps**      | Outbound call payload, response received, latency                                                                                                                               |
| **Conditional branches**   | Which branch was taken and why (the evaluated condition and its values)                                                                                                         |
| **Data-change events**     | Which entity records were written and what changed                                                                                                                              |
| **Side-effect markers**    | In production: *"sent email to [patient@example.com](mailto:patient@example.com)."* In sandbox: *"would have sent email to [patient@example.com](mailto:patient@example.com)."* |
| **Errors and retries**     | Error details, retry count, final disposition                                                                                                                                   |

## PHI in traces

Trace view applies your org's PHI policy. If a step processed PHI, the trace renders the processed (de-identified) version unless you are on a role that has explicit PHI-view access. Raw PHI is never stored in the trace — it is processed through the PHI substrate before the trace record is written.

## Sandbox vs. production

| Mode           | Side-effect markers   | Integration calls              |
| -------------- | --------------------- | ------------------------------ |
| **Sandbox**    | *"would have done X"* | Edge-sandboxed — no real calls |
| **Production** | *"did do X"*          | Real calls to external systems |

Same UI, different verb. The distinction is always visible so you know which mode you're in.

## Replay

Replay re-runs a past workflow execution with its original trigger payload. Use it to:

* Reproduce a bug exactly as it occurred
* Verify a fix against a historical failure case
* Test a contract change against a real payload from production

### How to replay

1. Open the trace for the run you want to replay.
2. Click **Replay**.
3. Confirm: replay runs in sandbox mode by default. You can switch to production if you need to re-trigger real side effects (requires explicit confirmation).
4. A new run fires. The trace for the new run appears alongside the original. Differences are highlighted.

<Warning>
  Replaying in production mode triggers real side effects — real emails sent, real API calls made, real entity records written. Confirm you intend this before proceeding.
</Warning>

## Trigger simulation

For headless workflows (scheduled, webhook, external event), you can compose and fire a synthetic trigger payload from the test/run console without waiting for a real external event:

1. Open the test/run console for the workflow.
2. The system generates a sample trigger payload matching the schema. Edit field values to match your test case.
3. Click **Run**.
4. The workflow fires in sandbox mode. The trace appears immediately.

This is the primary authoring loop for headless workflows — describe, compile, simulate, inspect trace, iterate.

## Accessing traces

* **From the project overview:** recent failures surface in the health rollup with a click-through to the failing run's trace.
* **From the workflow resource view:** a list of recent runs with status, duration, and trigger type. Click any run to open its trace.
* **From the audit log:** the trace is the user-facing projection of the run's audit chain entries. Every event in the trace has a corresponding integrity-anchored audit record.

## Run history

The test/run console shows recent runs for the workflow with:

* Status (completed, failed, in-progress)
* Trigger type and key payload fields
* Duration
* Whether side effects were real or sandboxed

Click any run to open its full trace.

## Compliance use

Traces are durable audit artifacts. Every step, every AI inference call, every side effect, and every data mutation is integrity-anchored per the audit chain architecture. Traces are retained per your org's compliance retention policy and are exportable for regulatory review.

See [Compliance & Audit](/studio/compliance-audit) for the full audit chain and export model.