# Audit and compliance

> What Helix records: an org-wide activity trail of administrative actions, per-execution traces, and the retention questions still open.

Helix records two different things, and telling them apart is the first step in answering any audit question. Administrative actions across the organization go into an org-wide **activity trail**. What an app did on a given request goes into that project's **execution logs**. The activity trail answers "who changed what", and execution logs answer "what did the app do".

## The activity trail

The activity trail is a single org-wide feed of administrative actions. Org admins read it in the [Admin console](/documentation/governance/admin-console/), under Recent activity, with a shorter preview on the console's Overview.

Every entry carries four fields:

| Field | Contents |
|---|---|
| Action | What was done |
| Actor | The person who did it |
| Workspace | Which workspace it happened in |
| Timestamp | When it happened |

### What gets recorded

| Action | Recorded when |
|---|---|
| Deployed a project | A deployment goes out |
| Created a project | A project is provisioned for the first time |
| Deleted a project | A project is removed |
| Created a schedule | A deployment introduces a [scheduled job](/documentation/guides/scheduled-functions/) the project did not have |
| Deleted a schedule | A deployment lands without a scheduled job the project used to have |
| Paused a schedule | Someone pauses a scheduled job in the dashboard |
| Resumed a schedule | Someone resumes a paused scheduled job |
| Granted access to a project | Someone is given access to a published app |
| Changed access settings for a project | A project's Access Control setting changes |
| Created an authentication | An authentication is linked for use by projects |
| Deleted an authentication | An authentication is removed |
| Changed a role | A member's organization role changes between Admin and Contributor |
| Changed a project's URL | A project's alias is set, changed, or released |
| Changed the URL namespace | The organization's namespace is set or changed, moving every project URL |

Those are the action types the trail produces. If an action is not in that list, do not assume it is captured.

### What is not recorded there

Ordinary use of a published app does not appear in the activity trail. If you need to know who called an app, when, and what came back, that is in the project's execution logs.

There is also no CLI command for the activity trail. The Admin console is the only place to read it.

## Execution logs

Each project has a Logs tab holding one entry per execution, whether an HTTP request or a scheduled job run: time, status, trigger type, the route or job, duration, and who initiated it. Opening an entry gives the full execution trace, including the trace ID, execution ID, deployment ID, the tree of operations the run performed, which authentication each third-party call used, and the request and response payloads. See [the dashboard](/documentation/governance/dashboard/) for the full walkthrough.

## Which one answers your question

| | Activity trail | Execution logs |
|---|---|---|
| Scope | The whole organization | One project |
| Granularity | One administrative action | One execution |
| Where | Admin console, org admins only | The project's Logs tab |
| Contains payloads | No | Yes, request and response bodies |
| Answers | Who changed what, and where | What the app did, and why it failed |

:::warning{title="Execution traces hold whatever the app handled"}
Payloads are stored as they were sent and received. An app that processes personal, financial, or health data will have that data sitting in its traces. Factor this into which teams you let build on Helix and which data you let them route through it.
:::

## Retention and export

Talk to your Helix contact before treating retention, export, or redaction as settled for a control document or compliance questionnaire. In particular, confirm:

- How long activity-trail entries and execution logs are retained.
- Whether the activity trail can be exported, or streamed to a SIEM.
- Whether the trail is tamper-evident.
- Whether, and how, request and response payloads in execution traces are redacted.
- Whether org admins can read execution payloads for projects outside their own workspaces.

## Hosting region

Helix runs as four regional deployments: `us1` (the default), `eu1`, `ap1`, and `ap2`. Your workspace, and every project in it, lives in one region; see [regions](/documentation/concepts/configuration/#regions) for how that's set and how it shows up in the CLI and dashboard URL.

This page doesn't cover what's guaranteed to stay in-region, such as backups, logs, or support tooling. If your organization has an EU or in-country residency mandate, confirm the specifics with your Helix contact before you deploy anything that carries regulated data.

Credentials stay out of project code today through the alias mechanism described in [IT & governance](/documentation/governance/).

---

Canonical: https://helix.tray.ai/documentation/governance/audit-and-compliance/
Any link on this page is available as markdown by appending .md to its URL.
Full corpus: https://helix.tray.ai/documentation/llms-full.txt