Audit & outputs
Auditing
Every run is recorded as it happens: what each step did, how long it took, what it read and wrote, what it cost and the code it ran. Nothing has to be switched on.
What is recorded
| Record | What it holds |
|---|---|
| Traces | Each step's work as a timeline: its model calls, scripts and connector calls, how long each took, and which failed. |
| Metrics | Measurements taken while it ran: durations, retries, tokens, CPU and memory, approvals and guardrail decisions. |
| Logs | What happened, in order: each step starting, waiting, succeeding or failing, its errors, and each approval asked and answered. |
| Baggage | The run's context carried through every call: organization, project, session, workflow, step and run - so any record can be traced back to where it came from. |
| Lineage | Which data each step consumed and produced, and which steps or connected sources it came from. |
| Cost | Every model call and connector use: provider, model, tokens and cost. |
| Scripts | The code each step ran, every version of it, and whether the system or a person wrote it. |
Every record carries the same identifiers - the organization, project, session, workflow, step and run - so the records of one run can be read together.
Where to read them
| Where | What you see |
|---|---|
| The step console | Select a step in the DAG tab: one tab per record, for that step. Pick a run to see one run, or all of them. See The step console. |
| Usage and Insights | Totals and patterns across runs: spend, tokens, errors, run time. See Usage and spend and Insights. |
| Schedules | Each scheduled run: how it started, how it ended, its attempts, tokens, cost and error. See Schedules. |
| The chat | System errors that stop a step appear in the run's card; warnings and details stay in the logs. |
What it is good for
- Explaining a result: lineage shows where a number came from, the scripts show how it was computed.
- Finding why a step failed: its logs and traces show what it tried, in order, and where it broke.
- Producing the same result again: the saved scripts are replayed on the next run; see Reruns replay saved code.
- Knowing what was allowed: every guardrail decision and approval is recorded with its reason; see Guardrails.
- Reviews: the records give compliance and security reviews a full history of each run. Recording does not by itself make you compliant with a regulation.
How long records are kept
Logs, baggage and metrics are removed automatically after 30 days; traces are kept for a shorter time. Lineage, cost and scripts are kept until you delete them. You can delete any of them sooner, or export your data, from Data controls. Deleting a project deletes its records with it.
Content is not stored in the recordsThe records hold who, what, when and how much - not the content of your data or of the model's replies. Your files and chat are stored separately and deleted with their own controls.
Something wrong or missing? Write to [email protected] about “Auditing”.Updated 11 Oct 2026