diff --git a/CLAUDE.md b/CLAUDE.md
index dffe1f4610..ec7e150208 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -117,3 +117,243 @@ Additional tools that can be added to `.pre-commit-config.yaml` for catching mor
 
 - **markdownlint-cli2** - Catches malformed tables, inconsistent list formatting, missing blank lines around fences
 - **lychee** - Validates all links including images, anchors, and external URLs
+
+## Writing Style
+
+### Avoid the em-dash
+
+Never use the em-dash character (the long dash) in user-facing documentation (markdown body, headings, table cells, admonitions).
+
+- **Why:** The em-dash is a strong "AI tell" and makes text feel machine-generated. Docs must read as human-written.
+- **How to apply:** Reach for a period (split into two sentences), a comma, parentheses for an aside, a colon when introducing an explanation, or a hyphen `-` when it must stay inline. When refactoring an existing page, sweep for the em-dash and replace every occurrence. Also keep an eye on other AI tells like "It's not just X, it's Y" constructions and overly polished transition phrases. This rule applies to everything the end reader sees, not to commit messages or internal notes.
+
+### No internal source, IDs, or jargon in docs
+
+User-facing docs describe behavior, not implementation. Do not include any of the following in `docs/`:
+
+- File paths from the product's private repos (Vue component paths, Python CRUD module paths, Scala package paths, etc.).
+- Hyperlinks to private product repositories.
+- Internal symbol names (frontend component classes, backend enum literals, internal constants).
+- Architecture jargon for internal infrastructure (task queues, message brokers, data processing engines, deployment planes, worker abstractions).
+- Internal ticket IDs in body text (the project's `<PREFIX>-NNNN` ticket pattern); those belong in commits and PR descriptions.
+- Phrases like "Verified against the frontend source" with explicit file or line citations.
+
+**Why:** The userguide repo is public. Use validation findings to inform the doc but render them in user-observable terms only.
+
+The specific names to flag (private repo names, the actual task-queue / message-broker / data-engine product names, deployment-plane internal labels, and internal symbol patterns) live in the project memory file `reference_qualytics_repos.md`. Cross-reference there when you need the exact term to flag in a review or to invoke against a private repo.
+
+### Terminology renames
+
+- The product feature formerly called **Catalog** is now **Sync**. Do not use "Catalog" or lowercase "catalog" as a product term. Replace with "datastore sync", "inventory of containers", "schema discovery via Sync", etc. Generic data-engineering uses are fine; product references are not.
+- In **rule type Sample Data tables**, mark only the offending cell with `<span class="anomalous-cell">VALUE</span>`. For array or multi-value violations, wrap the whole array literal. Add a short "What gets flagged" sentence noting the violation is per-field. Filter columns are scope, never highlighted. Replace older `<span class="text-negative">` patterns when touching the page.
+
+## Terminology: Team Permissions vs User Roles
+
+Two terminologies must not be mixed:
+
+- **User roles** (platform-level): `Member`, `Manager`, `Admin`. Always call these "role".
+- **Team permissions** (datastore-level): `Reporter`, `Viewer`, `Drafter`, `Author`, `Editor`. Always call these "team permission" (or just "permission" when context makes it obvious).
+
+**How to apply:** Write "the **Author** team permission on the datastore", not "the Author role". The Admin bypass admonition ("Users with the **Admin** role bypass...") stays as-is because Admin is a user role. Flag any "<level> role" wording in existing pages as a finding.
+
+## Page Structure
+
+### H1 icons in brick color
+
+Every page H1 leads with a Material Design icon in brick color. Body icons need an explicit override; cards do not.
+
+```markdown
+# :material-X:{ .middle style="color: var(--q-brick)" } Page Title
+```
+
+```markdown
+**Edit :material-pencil-outline:{ style="color: var(--md-default-fg-color)" }**
+```
+
+```markdown
+-   :material-X:{ .lg .middle } **Label**
+```
+
+**Picking the icon:**
+
+- Look it up in the frontend remote on `develop` first; each feature has an MDI icon already used in the UI.
+- Fallbacks when the frontend has no specific icon:
+  - Overview pages: `:material-book-alphabet:`
+  - Getting Started pages: `:material-book-open-page-variant:`
+  - Introduction pages: `:material-book-open-variant:`
+  - Examples pages: `:material-text-box-edit-outline:`
+  - How It Works pages: `:material-file-cog:`
+  - API pages: `:material-api:`
+  - FAQ pages: `:material-help-circle-outline:`
+  - Permissions pages: `:material-shield-lock-outline:`
+  - Navigation pages: `:material-compass:`
+  - Bulk-action pages: `:material-dots-vertical-circle:`
+  - Troubleshooting pages: `:material-tools:`
+- Single-action precedents: add uses `:material-plus-circle:`, remove uses `:material-minus-circle:`, edit uses `:material-pencil-circle:`, delete uses `:material-delete-circle:`.
+- **How-tos pages inside a feature sub-tree** use a plain H1 (no icon). The matching card in the parent hub may still carry an action icon (see the Cards section); the destination page itself stays plain.
+- **Deep Dive concept pages** (`introduction.md`, `how-it-works.md`, `examples.md` inside a feature sub-tree) without a frontend icon: rely on the standard book-* family (Overview / Getting Started / Introduction / Examples) and `:material-file-cog:` for How It Works. For any other concept page with no frontend icon, leave the H1 plain.
+- If a page documents a cross-cutting concept with no UI equivalent, leave the H1 plain rather than invent an icon.
+
+### Inline icon action labels
+
+When a step references an icon-only UI button, label it by the action it performs, not by the icon's shape. Pattern: `**Action :material-icon:**` (bold around the whole token, icon after label, no parentheses).
+
+Established label conventions: `Edit` (pencil), `Remove` or `Close` or `Unlink ticket` (close X), `Bulk menu` (vertical ellipsis), `Plus` (plus). Do not write "the vertical ellipsis", "three dots", or "the X button".
+
+### Deep Dive pages are concept-only
+
+Deep Dive pages have no screenshots, image references, asset folders, or `<!-- TODO: add screenshot -->` placeholders. They explain how something works. Screenshots belong to Getting Started and How-tos. There is one accepted exception (the Source Records viewer page) flagged as temporary debt; do not extend it.
+
+### Connector docs
+
+- Place the connector logo inline inside the H1 at ~36px, never as a centered hero below:
+
+```markdown
+# ![](../../../assets/shared/connector-logos/logo-<name>.svg){ width="36" style="vertical-align: middle;" } <Connector> Connector
+```
+
+- Every connector `add-source.md` has a top-level **Field reference** H2 that explains every field, separate from the **Steps** tutorials. Both sections use the same `=== "New Connection"` / `=== "Existing Connection"` tabs. Inside each tab, field groups (Connection Properties, Secrets Management optional, Datastore Properties) are bold-text labels, not headings, so the page TOC stays clean. Tutorials become short (click, fill, test, finish) and link back to the Field reference. REF. numbering restarts per screenshot. Connectors that cannot be enrichment targets must not ship a per-connector `add-enrichment.md`; link to the generic enrichment pages instead. The `managing/api.md` order is Connection Fields, Create with New Connection (auth-method tabs when applicable), Create with Existing Connection, Other Operations.
+
+### Reference card order
+
+When a Getting Started page (or any Reference grid) includes Troubleshooting alongside API and FAQ, the order is **Troubleshooting, API, FAQ** in both the card grid and the mkdocs.yml nav. If only API and FAQ exist, keep API before FAQ.
+
+### Section overview pages (Settings-style hubs)
+
+Top-level section overview pages (the landing page of a major feature area, e.g., `settings/overview.md`, `settings/security/overview.md`) use an **H2-per-subsection** layout. Under each H2 lives a single `<div class="grid cards" markdown>` block with one card per feature inside that subsection.
+
+- **Subsection with a single feature:** one card.
+- **Subsection with multiple features:** one card per top-level feature (do not nest beyond what the nav exposes at the same level).
+- **Subsections are separated by `---`** so the page reads as discrete blocks instead of a long flat grid.
+- **Card content:** each card has a bold title, a one-line description of what the feature gives the user, and an `:octicons-arrow-right-24:` link to the feature's own entry point (its Introduction, Getting Started, or single page).
+- **Card icons (verified-only):** use an MDI icon **only when that icon is actually used by the frontend** for the feature in question. Verify with `gh search code --repo <frontend-repo> 'mdi-<name>'` (the actual frontend repo name lives in `reference_qualytics_repos.md`) and require at least one hit before adopting. If no UI icon exists for the feature, the card stays plain. This is stricter than the general H1-icon rule because section hubs sit at a high level of abstraction and an invented icon misleads more than it helps.
+- **Tab-level cards stay plain:** when a card represents a Settings *tab itself* (single-card subsection, e.g., the Connections card under `## Connections` or the Platform Audit card under `## Audit`), the card stays plain because the Settings tabs in the frontend are text-only constants with no associated icons. The fact that the feature *uses* an MDI icon elsewhere in the UI (e.g., `mdi-history` inside the Audit page) does not make it the tab's icon.
+- **Mirror rule still applies:** when the card has an icon, it must match the destination page's H1 icon. If the destination has no icon (or its H1 uses a generic book-* fallback), the card stays plain.
+
+Why H2-per-subsection: a flat grid of 5+ cards hides the structure the user already saw in the side nav. The H2 layout keeps the page scannable and lets sections with many features (Integrations, Security) breathe.
+
+## Tables (Permission Matrices, Support Tables)
+
+### Canonical icons
+
+```markdown
+:material-check-circle:{ .lg title="Allowed" }
+:material-close-circle-outline:{ .lg title="Not allowed" }
+```
+
+- Positive cells: `mdi-check-circle` (filled) with `title="Allowed"` / `"Supported"` / `"Yes"` / `"Containers only"`.
+- Negative cells: `mdi-close-circle-outline` (outline) with `title="Not allowed"` / `"Not supported"` / `"No"` / `"Push-only"`.
+- Always include `.lg`; the default size is too small inside table cells.
+- The global stylesheet auto-colors icons by their `title` attribute. Do not add inline `style="color: ..."` and do not use `mdi-check` (no circle). State-indicator tables (UI badge colors) can keep inline color.
+
+### Keep permission rows explicit
+
+Permission matrices list every team permission as its own row even when 4 of 5 share identical "Not allowed" cells. Showing each level side-by-side with the allowed level puts the restriction in front of the reader. Do not consolidate Viewer/Reporter/Drafter/Author into a combined row, and do not replace the matrix with prose.
+
+### DRY tabs only when the table is shared neutral reference
+
+For pages with per-entry-point tabs that each embed a table:
+
+- **Extract (safe to DRY):** the table describes options of a shared UI surface that lives in the same place everywhere; only the screenshot varies. Example: a Sort table applied identically across every entry point.
+- **Keep inline (do not DRY):** the table affirms the capability at this entry point. Even if rows look identical, the per-tab listing does capability-affirmation work. When in doubt, leave inline.
+
+## Cards
+
+### Card icon mirrors the destination H1 exactly
+
+When a grid card links to another page, the card icon must match the destination page's H1.
+
+- If the destination H1 has an icon, the card uses the same icon.
+- If the destination H1 has no icon, the card has no icon either. Do not add one to make the grid look uniform, and do not restore an icon to the destination H1 just so the card can have one.
+
+**Exception for how-tos cards.** Cards that link to how-tos pages (Create, Edit, Delete, Filter, etc.) can use standard action icons as a fallback when the destination has no frontend-defined icon — how-tos pages themselves use a plain H1 (per the H1 icons rule), but their cards in the parent hub can still carry an action icon:
+
+| Action | MDI Icon |
+|:---|:---|
+| Add / Create | `plus-circle` |
+| Apply | `check-underline-circle` |
+| Edit | `pencil-circle` |
+| Remove (detach, unassign) | `minus-circle` |
+| Delete (destroy the item) | `delete-circle` |
+| Right Click Options | `mouse` |
+| Keyboard Shortcuts | `keyboard` |
+| Available Connectors | `view-list` |
+| Link | `link-variant` |
+| Unlink | `link-variant-off` |
+| Bulk action | `dots-vertical-circle` |
+| Troubleshooting | `tools` |
+
+**Remove vs Delete** are distinct: Remove = detach/unassign (item still exists elsewhere); Delete = destroy the item itself.
+
+### Screenshot naming
+
+- Tutorial walkthroughs: `step-N-<descriptive>.png` (for example, `step-1-settings-gear.png`, `step-4-select-next.png`). The number matches the Step in the page.
+- Field reference (annotated) screenshots: `<context>-fields-reference.png` (for example, `select-fields-reference.png`, `destination-fields-reference.png`).
+- One folder per page under `docs/assets/<section>/...`. Drop unused alternate captures rather than keeping them around.
+- Use descriptive markdown alt text, not the file basename.
+
+## Branches, Commits, and PRs
+
+### Release notes branches and commits
+
+- Branch name: `qua-XXXX-release-notes`. Do not use the Linear URL slug.
+- Commit message: `docs(changelog): add release notes for <version>` (for example, `docs(changelog): add release notes for 2026.4.8`). Do not append `(QUA-XXXX)`; the PR title carries the ticket.
+- When porting release notes from the local source into `docs/changelog.md`, strip every trailing `(QUA-XXXX)` or `(QUA-XXXX, QUA-YYYY)` reference. The public changelog has never carried ticket IDs.
+
+### Release notes PR template
+
+- **Title:** `QUA-<issue>: v<version>` (for example, `QUA-1747: v2026.4.23`).
+- **Body:** preserve the HTML comments from the repo PR template. Sections in order: `### Overview` (one sentence: "This PR includes the release notes of v<version>"), `### Key Changes` (one bullet per commit on the branch ahead of main, verbatim; do not rewrite as bold-feature handcrafted bullets), `### Screenshots` (optional).
+- **Label:** `release notes`. **Assignee:** `@me`. **Reviewers:** the standard set.
+- If `gh pr edit --body` fails with the classic-Projects GraphQL error, fall back to `gh api --method PATCH /repos/Qualytics/userguide/pulls/<N> -F body="$(cat /tmp/pr-body.md)"`.
+
+### Feature/docs PR description style
+
+For non-release-notes PRs, keep the body lean with three sections:
+
+1. **Overview:** one sentence on what the PR documents. Do not link the Linear URL; the title's `QUA-XXXX` prefix is enough.
+2. **Key Changes:** terse bullets in the form `**<page or section>**: <what changed>`. No prose paragraphs on source-of-truth verification or file paths.
+3. **Pages to Test:** a markdown checkbox list (`- [ ]`), one entry per modified page, with a brief specific verification note after the URL. Include legacy-redirect spot checks at the bottom when files move.
+
+## Workflow
+
+### Validate against the remote, not local clones
+
+When validating doc claims against system behavior, fetch from the GitHub remotes on the default branch `develop`, not local clones. The product's frontend, control plane, and data plane each have their own private GitHub repository.
+
+The exact remote names, local path mappings, and default branch live in the memory file `reference_qualytics_repos.md`. Cross-reference there to invoke `gh api repos/Qualytics/<repo>/contents/<path>?ref=develop` for file reads and `gh search code --repo Qualytics/<repo>` for grep-style searches against the right repo.
+
+Only fall back to local clones if remote access fails. Internal findings still must not appear in the doc body (see Writing Style).
+
+### Userguide review workflow
+
+When the user starts a page review or asks to "load the review context", adopt the dual-persona collaboration mode:
+
+- Assistant acts as **data engineer reviewer** (reads the page, critiques as an end user, proposes improvements).
+- User acts as **technical writer** (accepts or rejects each suggestion).
+- Fixes are applied in a separate chat via a **consolidated prompt** of the agreed fixes.
+- When the user says "pode olhar as mudanças feitas", read the file and confirm the changes were applied before moving on.
+- Consider both perspectives every time: factual accuracy and parity with parallel pages, plus clear language without heavy jargon (`rotated` becomes `changed`, `pre-populated` becomes `already filled in`, etc.).
+- Established patterns to honor without relitigating: Getting Started uses grid cards (not tables) and can include a hero/overview screenshot at the top; content and assets mirror mkdocs nav; page titles follow "Context + Type"; Introduction pages act as hubs (Deep Dive, Managing, API & FAQ); API pages carry a tip banner pointing to demo.qualytics.io/api/docs; Managing pages document the happy path only; success messages stay generic; "Before You X" admonitions appear only on destructive actions, with irreversibility warnings only when verified; same-tab links on Overview pages, `{:target="_blank"}` elsewhere; deployment terms are "self-hosted" and "managed deployment".
+
+### Do not run mkdocs build or serve unprompted
+
+Never run `mkdocs build` or `mkdocs serve` during a session unless the user explicitly asks. Builds take ~40-50 seconds and flood the context with warning lists. Pre-commit covers this on `git commit` via the `mkdocs-warnings` hook. The same applies to running the `run` skill against this project.
+
+### Batch pre-commit at most once per session
+
+Run `pre-commit run` at most ONCE per multi-task session, as the final task. For single-edit or trivial fixes, skip it entirely; the user runs it manually before committing. Each run takes ~55-60 seconds and floods the context with warning output.
+
+### Pre-commit needs the venv
+
+Always activate the venv before committing in this repo:
+
+```bash
+source venv/bin/activate && git commit ...
+```
+
+The `scripts/check-anchor-changes.py` hook uses Python 3.10+ union syntax (`str | None`). The system `python3` on the user's Mac is 3.9, so without the venv the hook fails with `TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'`.
+
+### Consolidated fix prompts must not include a commit step
+
+When writing the consolidated prompt of agreed fixes to copy into the other chat, do not append a `## Commit` section or any `git commit` instruction. Stop after the last fix. The review loop is review, apply in the other chat, re-review the applied diff here, then commit. Embedding a commit step short-circuits the verification step.
diff --git a/docs/assets/settings/audit/how-tos/export-activity/export-button.png b/docs/assets/settings/audit/how-tos/export-activity/export-button.png
new file mode 100644
index 0000000000..c0ebd89d39
Binary files /dev/null and b/docs/assets/settings/audit/how-tos/export-activity/export-button.png differ
diff --git a/docs/assets/settings/audit/how-tos/filter-activity/date-picker.png b/docs/assets/settings/audit/how-tos/filter-activity/date-picker.png
new file mode 100644
index 0000000000..1f4342b533
Binary files /dev/null and b/docs/assets/settings/audit/how-tos/filter-activity/date-picker.png differ
diff --git a/docs/assets/settings/audit/how-tos/filter-activity/filter-menu.png b/docs/assets/settings/audit/how-tos/filter-activity/filter-menu.png
new file mode 100644
index 0000000000..7daefd67ef
Binary files /dev/null and b/docs/assets/settings/audit/how-tos/filter-activity/filter-menu.png differ
diff --git a/docs/assets/settings/audit/how-tos/filter-activity/timeframe-dropdown.png b/docs/assets/settings/audit/how-tos/filter-activity/timeframe-dropdown.png
new file mode 100644
index 0000000000..5c7fec6076
Binary files /dev/null and b/docs/assets/settings/audit/how-tos/filter-activity/timeframe-dropdown.png differ
diff --git a/docs/assets/settings/audit/how-tos/summary-section/summary-cards-annotated.png b/docs/assets/settings/audit/how-tos/summary-section/summary-cards-annotated.png
new file mode 100644
index 0000000000..a9fa598667
Binary files /dev/null and b/docs/assets/settings/audit/how-tos/summary-section/summary-cards-annotated.png differ
diff --git a/docs/settings/audit/api.md b/docs/settings/audit/api.md
new file mode 100644
index 0000000000..f6da14f09a
--- /dev/null
+++ b/docs/settings/audit/api.md
@@ -0,0 +1,201 @@
+# :material-api:{ .middle style="color: var(--q-brick)" } Audit API
+
+The activity endpoints power the Platform Audit page in the UI. Both endpoints require the **Admin** user role and accept a shared set of filters so the activity log, summary cards, and chart can stay in sync.
+
+!!! tip
+    For complete API documentation, including request and response schemas, visit the [API docs](https://your-instance.qualytics.io/api/docs){:target="_blank"} on your Qualytics deployment.
+
+All endpoints are served from your Qualytics deployment (e.g., `https://your-instance.qualytics.io`). The paths below include the `/api` prefix.
+
+---
+
+## List Activity
+
+Return a paginated list of activity records, optionally filtered by user, action, date range, or timeframe window.
+
+**Endpoint**: `GET /api/activity`
+
+**Permission**: Admin user role
+
+### Query parameters
+
+| Parameter | Type | Description |
+| :--- | :--- | :--- |
+| `users` | `list[int]` | One or more user IDs. When set, only activity attributed to the listed users is returned. |
+| `actions` | `list[str]` | One or more action verbs (`create`, `update`, `delete`, and others). Filters to the listed verbs only. |
+| `start_date` | `date` | The earliest date to include. Use with `end_date` for an explicit range. |
+| `end_date` | `date` | The latest date to include. Use with `start_date` for an explicit range, or with `timeframe` as the anchor. |
+| `timeframe` | `string` | One of `week`, `month`, `quarter`, `year`. When set, derives `start_date` from `end_date`. |
+| `offset` | `int` | Timezone offset in minutes. Applied to the timeframe window boundaries so the date range honors the caller's local calendar. |
+| `include_internal` | `bool` | When `true` (the default), includes activity from internal users. Set to `false` to exclude them. |
+| `page` | `int` | Page number, starting at 1. |
+| `size` | `int` | Page size. |
+
+??? example "Example request and response"
+
+    **Request**:
+
+    ```bash
+    curl -X GET "https://your-instance.qualytics.io/api/activity?timeframe=week&end_date=2026-06-10&include_internal=false&page=1&size=20" \
+      -H "Authorization: Bearer YOUR_TOKEN"
+    ```
+
+    **Response**:
+
+    ```json
+    {
+      "items": [
+        {
+          "transaction": {
+            "id": 184221,
+            "issued_at": "2026-06-10T18:42:11Z",
+            "user": {
+              "id": 14,
+              "name": "Yannique Kameka",
+              "user_name": "yannique",
+              "email": "yannique@example.com"
+            }
+          },
+          "verb": "update",
+          "object_type": "QualityCheck",
+          "object_id": 9821
+        }
+      ],
+      "total": 134,
+      "page": 1,
+      "size": 20,
+      "pages": 7
+    }
+    ```
+
+### Response schema
+
+| Field | Type | Description |
+| :--- | :--- | :--- |
+| `items` | `list[object]` | The page of activity records. |
+| `items[].transaction.id` | `integer` | Unique transaction identifier. |
+| `items[].transaction.issued_at` | `string` | The action timestamp in UTC. |
+| `items[].transaction.user` | `object` or `null` | The actor (display name, username, email). `null` when the user account no longer exists. |
+| `items[].verb` | `string` | The action verb (`create`, `update`, `delete`, `activate`, `archive`, and so on). |
+| `items[].object_type` | `string` | The CamelCase entity type (`Datastore`, `QualityCheck`, `Anomaly`, and others). |
+| `items[].object_id` | `integer` or `null` | The ID of the affected entity, when applicable. |
+| `total` | `integer` | Total number of records matching the filters. |
+| `page` | `integer` | Current page number. |
+| `size` | `integer` | Page size. |
+| `pages` | `integer` | Total number of pages. |
+
+!!! info
+    For the UI equivalent, see [Filter Activity](how-tos/filter-activity.md){:target="_blank"}.
+
+---
+
+## Activity Insights
+
+Return aggregated activity statistics for the timeframe window. This is the endpoint that powers the summary cards and the activity chart.
+
+**Endpoint**: `GET /api/activity/insights`
+
+**Permission**: Admin user role
+
+### Query parameters
+
+| Parameter | Type | Description |
+| :--- | :--- | :--- |
+| `report_date` | `date` | The end of the timeframe window. Defaults to today when omitted. |
+| `timeframe` | `string` | One of `week`, `month`, `quarter`, `year`. Defaults to `month`. |
+| `offset` | `int` | Timezone offset in minutes. Applied before date extraction so daily bucketing in `actions_per_day` groups by the caller's local calendar date. |
+| `include_internal` | `bool` | When `true` (the default), includes internal users in `total_actions`, `top_actor`, `top_entity_type`, and `actions_per_day`. The `unique_actors` count always excludes internal users. |
+| `users` | `list[int]` | Limit the aggregation to one or more user IDs. |
+| `actions` | `list[str]` | Limit the aggregation to one or more action verbs (`create`, `update`, `delete`, and so on). |
+
+??? example "Example request and response"
+
+    **Request**:
+
+    ```bash
+    curl -X GET "https://your-instance.qualytics.io/api/activity/insights?timeframe=week&report_date=2026-06-10&include_internal=true" \
+      -H "Authorization: Bearer YOUR_TOKEN"
+    ```
+
+    **Response**:
+
+    ```json
+    {
+      "unique_actors": 7,
+      "total_actions": 134,
+      "top_actor": {
+        "id": 14,
+        "name": "Yannique Kameka",
+        "user_name": "yannique",
+        "email": "yannique@example.com",
+        "action_count": 48
+      },
+      "top_entity_type": {
+        "object_type": "Anomaly",
+        "count": 62
+      },
+      "actions_per_day": [
+        { "date": "2026-06-04", "user_count": 18, "system_count": 4 },
+        { "date": "2026-06-05", "user_count": 11, "system_count": 6 },
+        { "date": "2026-06-06", "user_count": 0,  "system_count": 0 },
+        { "date": "2026-06-07", "user_count": 0,  "system_count": 0 },
+        { "date": "2026-06-08", "user_count": 22, "system_count": 7 },
+        { "date": "2026-06-09", "user_count": 25, "system_count": 8 },
+        { "date": "2026-06-10", "user_count": 28, "system_count": 5 }
+      ]
+    }
+    ```
+
+### Response schema
+
+| Field | Type | Description |
+| :--- | :--- | :--- |
+| `unique_actors` | `integer` | Number of distinct *human* users with at least one action in the window. Always excludes internal users. |
+| `total_actions` | `integer` | Total number of actions in the window. Respects `include_internal`. |
+| `top_actor` | `object` or `null` | The user with the highest action count in the window. Includes `id`, `name`, `user_name`, `email`, and `action_count`. |
+| `top_entity_type` | `object` or `null` | The entity type with the highest action count. Includes `object_type` (CamelCase) and `count`. |
+| `actions_per_day` | `list[object]` | One entry per day in the window, with `date`, `user_count`, and `system_count`. The page aggregates these into wider buckets (week, month, quarter) when needed. |
+
+!!! info
+    For the UI equivalent, see [Summary Section](how-tos/summary-section.md){:target="_blank"}.
+
+---
+
+## Error Responses
+
+| Status Code | Description |
+| :--- | :--- |
+| `401 Unauthorized` | Missing or invalid API token. |
+| `403 Forbidden` | User does not have the **Admin** role. |
+| `422 Unprocessable Entity` | Invalid `timeframe`, `offset`, or date value. |
+
+??? example "Error response examples"
+
+    **403 Forbidden**:
+
+    ```json
+    { "detail": "Not enough permissions" }
+    ```
+
+    **422 Unprocessable Entity** (invalid timeframe):
+
+    ```json
+    {
+      "detail": [
+        {
+          "loc": ["query", "timeframe"],
+          "msg": "value is not a valid enumeration member; permitted: 'week', 'month', 'quarter', 'year'",
+          "type": "type_error.enum"
+        }
+      ]
+    }
+    ```
+
+---
+
+## Permission Summary
+
+| Operation | Minimum Permission |
+| :--- | :--- |
+| List activity | Admin user role |
+| Get activity insights | Admin user role |
diff --git a/docs/settings/audit/deep-dive/best-practices.md b/docs/settings/audit/deep-dive/best-practices.md
new file mode 100644
index 0000000000..5722db588b
--- /dev/null
+++ b/docs/settings/audit/deep-dive/best-practices.md
@@ -0,0 +1,48 @@
+# Best Practices
+
+Recommendations for getting the most out of the Platform Audit page during rollout, governance reviews, and day-to-day operations.
+
+## Use the Report Date as a fixed anchor
+
+The Report Date is the *end* of the timeframe window, not the start. When investigating a specific incident, set the Report Date to the day after the event you are looking into and then choose the timeframe that gives you the right amount of context (Week for a localized review, Month for a longer trend).
+
+If you change the Report Date while keeping the Timeframe constant, both the cards and the chart slide together: they always represent the same window.
+
+## Match the timeframe to the question
+
+| Question | Suggested timeframe |
+| :--- | :--- |
+| Did this user take any actions yesterday? | Week |
+| Who has been most active this month? | Month |
+| Is platform usage trending up or down? | Quarter or Year |
+| Are there spikes in delete activity around a release? | Week, anchored to the day after the release |
+
+A smaller timeframe gives finer chart bars (daily) at the cost of less historical context; a larger timeframe summarizes more history but coarsens the chart to weekly, monthly, or quarterly bars.
+
+## Separate user activity from automation early
+
+When trying to understand human adoption, enable the **Hide Qualytics** toggle so automated scheduled activity is removed from both the chart and the log. The **Active users** metric ignores internal users in both modes, but the other cards and the chart segments are easier to read with automation hidden.
+
+When investigating an operational anomaly (a runaway loop, a misconfigured schedule, an unexpected backfill), leave the toggle off so the **Automated** chart segment is visible alongside user activity.
+
+## Filter by actor or action before exporting
+
+The CSV export is **page-scoped**: it exports only the rows currently visible on the page. To export a focused dataset, narrow the log with the filters first (specific users, specific actions) and pick a page size that fits the population. Each export is a point-in-time snapshot. For full retrospective analysis, prefer the API.
+
+## Cross-reference with entity history
+
+The Audit page is a workspace-wide log. When you spot something suspicious, drill into the affected entity (datastore, check, anomaly) and use its dedicated **History** tab to see the per-entity change record with full before/after values. The Audit page tells you *who, when, and what kind of action*; the entity history tells you *exactly which fields changed*.
+
+## Use the chart as a leading indicator
+
+The stacked bar chart makes step-changes in activity easy to spot at a glance:
+
+- **Tall user bars** clustered on a few days suggest concentrated rollout activity (training, onboarding, bulk imports).
+- **Tall automated bars** spread evenly across the window indicate steady scheduled workloads.
+- **Empty days** between bars in a Week or Month view often signal weekends or quiet periods.
+
+Pair a glance at the chart with a click into the corresponding day in the log when an unusually tall bar warrants explanation.
+
+## Schedule regular reviews
+
+For governance, schedule a recurring review of the Audit page: for example, the first business day of each month with the Timeframe set to **Month** and the Report Date set to the prior month's end. Export the relevant pages for the audit trail you maintain outside of Qualytics, and document any unexpected actor or action concentrations in your change-management notes.
diff --git a/docs/settings/audit/deep-dive/how-it-works.md b/docs/settings/audit/deep-dive/how-it-works.md
new file mode 100644
index 0000000000..0693eaa742
--- /dev/null
+++ b/docs/settings/audit/deep-dive/how-it-works.md
@@ -0,0 +1,76 @@
+# :material-file-cog:{ .middle style="color: var(--q-brick)" } How It Works
+
+This page explains the mechanics behind the Platform Audit page: how the timeframe drives what activity the page shows, how rows are grouped, how the chart adjusts its bucketing, and how internal (automated) activity is separated from user activity.
+
+## How the page is populated
+
+The Audit page combines two complementary data sources into a single screen:
+
+| Source | Drives |
+| :--- | :--- |
+| Activity records | The paginated activity log: one row per recorded action, sorted by issue time. |
+| Activity insights | The four summary cards and the stacked activity chart. |
+
+Both sources share the same set of filters (date, timeframe, users, actions, and the **Hide Qualytics** toggle), so the cards, chart, and log always agree on the population they represent.
+
+## Report Date and Timeframe
+
+The page is anchored to a **Report Date** and a **Timeframe**. Together, these define the window of activity that the cards, chart, and log all show.
+
+| Timeframe | Window |
+| :--- | :--- |
+| Week | The seven days ending on the Report Date. |
+| Month | The prior month ending on the Report Date (roughly 30 days, varying by calendar month). |
+| Quarter | The prior three months ending on the Report Date (roughly 90 days). |
+| Year | The prior year ending on the Report Date (365 or 366 days on leap years). |
+
+The Report Date defaults to today and cannot be set to a future date. Changing either control refetches the summary cards, chart, and activity log, and resets pagination to page 1.
+
+## Day grouping in the activity log
+
+Rows in the activity log are grouped by **the local calendar day on which each action was issued**. Each group has a header showing the day label and the count of items in that group *on the current page*.
+
+This means:
+
+- A single day can span multiple pages if it has more activity than the current page size allows. In that case, the same day header appears on each page, with a count of items shown on that page only.
+- A page can contain multiple day groups when activity is light, in which case each group header marks the boundary.
+
+The day used for grouping comes from your local timezone, not raw UTC, so each row is grouped under the day it appeared to happen for you.
+
+## Timezone handling
+
+The page uses your browser's local timezone in two places:
+
+- Day grouping in the activity log.
+- Bucket grouping in the activity chart.
+
+This means the same audit log opened from two different timezones can show different day groupings for actions that occurred close to midnight UTC. That is intentional: each viewer sees activity grouped by their own local day.
+
+## Activity chart bucketing
+
+The chart is a stacked bar showing **User** vs **Automated** activity. The bucket width adjusts to keep the chart readable for the selected timeframe:
+
+| Timeframe | Bucket |
+| :--- | :--- |
+| Week | One bar per **day** |
+| Month | One bar per **week** |
+| Quarter | One bar per **month** |
+| Year | One bar per **quarter** |
+
+Activity is recorded as daily counts and aggregated into wider buckets based on the selected timeframe. Buckets with zero activity display as low, muted bars so the time axis stays continuous.
+
+## User vs Automated split
+
+Each action is attributed to a user. The platform tags certain accounts as **internal**, for example the Qualytics system account that runs scheduled operations and other platform-driven automation. The chart and summary cards treat internal users as **Automated** activity (the secondary bar segment) and external human users as **User** activity (the primary bar segment).
+
+The **Hide Qualytics** toggle in the filter menu removes internal activity from both the chart and the log. When the toggle is off (the default), internal activity is shown alongside user activity. The **Active users** card always reports the count of unique *human* actors, regardless of the toggle; the toggle only affects the rest of the page.
+
+## The masking audit overlay
+
+The activity log can also include data-masking audit rows. These appear when a user toggles "Show masked values" in surfaces such as Dry Run results or source-records views. They use the same row layout as standard activity items, but clicking them opens a dedicated masking-audit side panel rather than the generic activity side panel.
+
+## Empty and loading states
+
+- **First load**: the log shows a stack of skeleton rows while the first page is fetched.
+- **Subsequent loads**: the previously visible page stays in place while the new page is fetched and shown. The chart keeps the previously loaded data to avoid intermediate flicker.
+- **No results**: when no activity matches the filters, the log shows a "No activity found" empty state with a history icon. The Active users and Total actions cards display `0`, the Most active user and Top category cards fall back to dash placeholders, and the chart shows a zero-only bar series.
diff --git a/docs/settings/audit/deep-dive/introduction.md b/docs/settings/audit/deep-dive/introduction.md
new file mode 100644
index 0000000000..b874c76094
--- /dev/null
+++ b/docs/settings/audit/deep-dive/introduction.md
@@ -0,0 +1,76 @@
+# :material-book-open-variant:{ .middle style="color: var(--q-brick)" } Introduction
+
+The Platform Audit page is a workspace-wide activity log surfaced under **Settings → Audit**. It gives Admins a central place to review who is doing what across the platform, without needing to call the API or correlate the per-entity history tabs scattered across datastores, checks, and operations.
+
+## What gets recorded
+
+Every state-changing action taken against a tracked entity produces an audit record. Records include:
+
+- **User**: who performed the action (or the Qualytics system account for platform-driven changes).
+- **Action**: the verb performed (`create`, `update`, `delete`, `activate`, `archive`, and so on).
+- **Entity**: the type and ID of the affected object: datastore, container, check, anomaly, operation, schedule, user, team, integration, token, and others.
+- **Timestamp**: the moment the action was issued, in UTC, displayed in your local timezone.
+
+Some specialized records, such as data-masking audit entries, are surfaced inline with the same row layout and open a dedicated side panel when clicked.
+
+!!! info "Existing data, new view"
+    The audit log surfaces activity that the platform was already recording for every entity. The same history has been available on the per-entity history tabs across datastores, checks, operations, and other entities. The Audit page adds a workspace-wide UI on top of that history, plus aggregated metrics that power the summary cards and chart.
+
+## Why it exists
+
+Three needs drove the Platform Audit page:
+
+1. **Adoption tracking**: knowing which users have taken actions on the platform during rollout to new business teams.
+2. **Governance and change management**: answering "who changed this?" and "what changed during this window?" without leaving the platform.
+3. **Operational visibility**: spotting unusual spikes in delete actions, automated activity, or activity coming from a specific actor.
+
+## How the page is organized
+
+The page is a single scrollable view with four areas, stacked top to bottom:
+
+| Area | Purpose |
+| :--- | :--- |
+| **Filter bar** | Pick a report date, timeframe, optional filters, and trigger the CSV export. |
+| **Summary cards** | Headline metrics for the selected timeframe (active users, total actions, most active user, top category) plus the activity chart. |
+| **Activity log** | Paginated day-grouped list of individual actions. |
+| **Pagination controls** | Page size and next/previous navigation, mirrored at the top and bottom of the log. |
+
+Each area is documented in its own page in the **How-tos** section so you can jump directly to what you need.
+
+## Next Steps
+
+<div class="grid cards" markdown>
+
+-   :material-file-cog:{ .lg .middle } **How It Works**
+
+    ---
+
+    Day-grouped pagination, timezone handling, and the user-vs-automated activity split.
+
+    [:octicons-arrow-right-24: How It Works](how-it-works.md){:target="_blank"}
+
+-   **Summary Section**
+
+    ---
+
+    Read the five summary cards: four metric cards and the **Actions per day** chart.
+
+    [:octicons-arrow-right-24: Summary Section](../how-tos/summary-section.md){:target="_blank"}
+
+-   **Filter Activity**
+
+    ---
+
+    Narrow the log by date, timeframe, users, actions, or hide automated activity.
+
+    [:octicons-arrow-right-24: Filter Activity](../how-tos/filter-activity.md){:target="_blank"}
+
+-   :material-download-circle-outline:{ .lg .middle } **Export Activity**
+
+    ---
+
+    Download the current page of activity as a CSV file.
+
+    [:octicons-arrow-right-24: Export Activity](../how-tos/export-activity.md){:target="_blank"}
+
+</div>
diff --git a/docs/settings/audit/deep-dive/permissions.md b/docs/settings/audit/deep-dive/permissions.md
new file mode 100644
index 0000000000..897a44f9f7
--- /dev/null
+++ b/docs/settings/audit/deep-dive/permissions.md
@@ -0,0 +1,44 @@
+# :material-shield-lock-outline:{ .middle style="color: var(--q-brick)" } Permissions
+
+This page covers the role required to use the Platform Audit page and call the underlying activity endpoints.
+
+!!! note "Workspace-level only"
+    The Audit page is a global platform feature. It is not scoped to individual datastores or teams. Unlike datastore features that use two permission layers (user roles + team permissions), the Audit page is controlled **exclusively by user roles**. Team permissions do not apply.
+
+## User roles (workspace-level)
+
+User roles determine who can access the Audit page and which actions they can perform there.
+
+| Action | Member | Manager | Admin |
+| :--- | :---: | :---: | :---: |
+| Access the Audit page (view all sections) | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-check-circle:{ .lg title="Allowed" } |
+| View summary metrics and activity chart | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-check-circle:{ .lg title="Allowed" } |
+| Browse and filter the activity log | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-check-circle:{ .lg title="Allowed" } |
+| Export the current page as CSV | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-close-circle-outline:{ .lg title="Not allowed" } | :material-check-circle:{ .lg title="Allowed" } |
+
+## How permissions work
+
+The Audit tab is hidden from the Settings page for any user who does not hold the **Admin** role. Managers continue to see the other Settings tabs available to them, but **Audit** does not appear in their Settings menu. Members see only the limited subset of Settings tabs available to them, which does not include Audit.
+
+!!! info "Admin full access"
+    Users with the **Admin** role have unrestricted access to every part of the Audit page: filters, summary cards, the activity chart, the day-grouped log, and the CSV export.
+
+## What each role sees
+
+| Scenario | What the user sees |
+| :--- | :--- |
+| User has **Member** role | The Audit tab is not present in Settings. Navigating directly to the audit URL does not load the page. |
+| User has **Manager** role | The Audit tab is not present in Settings. Navigating directly to the audit URL does not load the page. |
+| User has **Admin** role | Full access to the page and all of its controls. |
+
+## API permissions
+
+The activity endpoints that power the page require the **Admin** user role. Calls made with a non-Admin token return `403 Forbidden`.
+
+| Endpoint | Method | Required role | Description |
+| :--- | :---: | :---: | :--- |
+| `/activity` | GET | Admin | Paginated activity log. |
+| `/activity/insights` | GET | Admin | Aggregated activity statistics for the timeframe (summary cards and chart data). |
+
+!!! info "Full permissions reference"
+    For the complete user roles matrix across all Qualytics features, see the [User Roles](../../security/users/roles/overview.md){:target="_blank"} page.
diff --git a/docs/settings/audit/faq.md b/docs/settings/audit/faq.md
new file mode 100644
index 0000000000..08cfa518a6
--- /dev/null
+++ b/docs/settings/audit/faq.md
@@ -0,0 +1,101 @@
+# :material-help-circle-outline:{ .middle style="color: var(--q-brick)" } Audit FAQ
+
+Answers to common questions about the Platform Audit page, the activity data it surfaces, and how the filters and export behave.
+
+## Access
+
+### Who can access the Platform Audit page?
+
+Only users with the **Admin** user role can access the Audit tab in Settings. The tab is hidden from Managers, Members, and any other role. The underlying `/activity` and `/activity/insights` API endpoints also require the **Admin** role. See the [Permissions](deep-dive/permissions.md){:target="_blank"} page for the full matrix.
+
+### Can a Manager see a subset of the audit data?
+
+No. The Audit page is Admin-only in both the UI and the API. Managers who need to review activity should request the data from an Admin or, for per-entity history, use the **History** tab on the affected entity (datastore, check, anomaly, and others).
+
+## Data and retention
+
+### How far back does the audit log go?
+
+The Audit page surfaces activity that the platform was already recording for every tracked entity. The same history is also available on the per-entity History tabs across datastores, checks, operations, and other entities. The Audit page adds a workspace-wide view on top of it. There is no separate, configurable retention period for audit records today.
+
+### Does the audit log show everything that happens on the platform?
+
+It shows every state-changing action against the entities the platform tracks (datastores, containers, checks, anomalies, operations, schedules, users, teams, integrations, tokens, and others), plus data-masking audit entries. Pure read operations (viewing a page, listing checks) are not recorded.
+
+### What is the difference between an Audit row and an entity's History tab?
+
+The Audit page is a workspace-wide log: it tells you *who, when, and what kind of action*. The History tab on a specific entity tells you *exactly which fields changed* for that entity. Use the Audit page to discover activity, and drill into the entity History tab to see the before/after detail.
+
+## Filters and timeframe
+
+### What does the Report Date represent?
+
+The Report Date is the **end** of the timeframe window. For example, with a **Week** timeframe and a Report Date of `2026-06-10`, the page shows activity from `2026-06-04` through `2026-06-10` inclusive. The Report Date cannot be set to a future date.
+
+### What timeframes are available?
+
+**Week** (7 days), **Month** (the prior month), **Quarter** (the prior three months), and **Year** (the prior year). Each timeframe ends on the Report Date. Month/Quarter/Year are calendar-relative, so the exact day count varies. See [How It Works](deep-dive/how-it-works.md){:target="_blank"} for details.
+
+### Why does the chart switch from daily bars to weekly bars when I change the timeframe?
+
+The bucket width adjusts so the chart stays readable. **Week** uses daily bars, **Month** uses weekly bars, **Quarter** uses monthly bars, and **Year** uses quarterly bars. The underlying data is always daily; the page aggregates it into the wider buckets above.
+
+### What does Hide Qualytics do?
+
+When **Hide Qualytics** is on, the page excludes activity from internal users (scheduled operations and other automated platform actors) from the chart, the Total actions card, the Most active user card, the Top category card, and the activity log. The **Active users** card always excludes internal users, regardless of the toggle.
+
+### Why is Active users not affected by Hide Qualytics?
+
+The Active users card is designed to answer "how many *people* are using the platform?". Automated accounts are never counted as people, so the card excludes them in both modes.
+
+## Activity log
+
+### Why does the same day appear on more than one page?
+
+The activity log paginates by row, not by day. If a day has more rows than the current page size allows, the same day header repeats on each page that contains rows from that day, with a count of items on that page in the sub-label.
+
+### What happens when I click a row?
+
+Clicking opens a side panel with the full audit-log detail for that action. For data-masking audit rows, clicking opens the dedicated masking-audit side panel instead.
+
+### Why is one row tinted?
+
+`Delete` actions appear with a tinted icon background to make them easier to spot at a glance. The data shape is identical to any other action.
+
+### Why does a row say "automated action" instead of an email?
+
+Actions issued by internal users (scheduled operations, platform automation) are labeled `automated action` in place of an email. The avatar also uses a dedicated styling. Use the **Hide Qualytics** filter to remove these rows entirely.
+
+## Export
+
+### What does the Export button download?
+
+A CSV file containing **only the rows currently visible on the page**. To export a larger dataset, increase the page size, paginate through the log and export each page, or use the [`GET /api/activity`](api.md#list-activity){:target="_blank"} endpoint directly.
+
+### What is the file naming convention?
+
+`audit-<report-date>.csv`, where `<report-date>` is the value in the **Date** field of the filter bar at the moment of export.
+
+### Why is the Export button disabled?
+
+The button is disabled whenever the activity log on the current page is empty: there are no rows to export. Adjust the filters or reset the page so the log shows rows, then click Export.
+
+## Timezone
+
+### Why is activity grouped under a different day than I expected?
+
+Day grouping uses **your local timezone**, not raw UTC. Actions that happened close to midnight UTC may be grouped under the previous or next calendar day depending on your timezone offset. The same audit log opened from two different timezones can show different day boundaries, by design.
+
+### Does the chart also follow my timezone?
+
+Yes. The daily counts that feed the chart are bucketed by your local calendar date, using the timezone offset sent with every request.
+
+## API and integrations
+
+### Can I script the audit data?
+
+Yes. Use the [`GET /api/activity`](api.md#list-activity){:target="_blank"} endpoint for the paginated log and [`GET /api/activity/insights`](api.md#activity-insights){:target="_blank"} for the aggregated statistics. Both endpoints accept the same filters as the UI and require the **Admin** role.
+
+### Did the schema fields change names?
+
+Yes. The insights schema previously used `total_activities` and `activities_per_day`. The current field names are `total_actions` and `actions_per_day`. The `top_actor` object now includes an `action_count` sub-field for the actor's action count. The field name `verb` on individual activity items is unchanged.
diff --git a/docs/settings/audit/getting-started.md b/docs/settings/audit/getting-started.md
new file mode 100644
index 0000000000..28bff86f8d
--- /dev/null
+++ b/docs/settings/audit/getting-started.md
@@ -0,0 +1,108 @@
+# :material-book-open-page-variant:{ .middle style="color: var(--q-brick)" } Platform Audit Getting Started
+
+The Platform Audit page is an Admin-only dashboard in **Settings** that gives you a paginated, day-grouped log of every action taken across your workspace, alongside summary metrics and an activity chart.
+
+Use it to answer questions like *who is using the platform*, *which datastores, checks, or anomalies are seeing the most activity*, and *how does activity trend across days, weeks, months, or quarters*.
+
+!!! info "Permissions"
+    Only users with the **Admin** user role can access the Platform Audit page. Managers and Members do not see the **Audit** entry in the Settings menu. See the [Permissions](deep-dive/permissions.md) page for the full matrix.
+
+---
+
+## Deep Dive
+
+Understand the data model behind the audit log, who can access it, and how to use it well.
+
+<div class="grid cards" markdown>
+
+-   :material-book-open-variant:{ .lg .middle } **Introduction**
+
+    ---
+
+    What the audit log records, where the data comes from, and how it fits into the platform.
+
+    [:octicons-arrow-right-24: Introduction](deep-dive/introduction.md)
+
+-   :material-file-cog:{ .lg .middle } **How It Works**
+
+    ---
+
+    Day-grouped pagination, timezone handling, user-vs-automated split, and the masking audit overlay.
+
+    [:octicons-arrow-right-24: How It Works](deep-dive/how-it-works.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Permissions**
+
+    ---
+
+    Admin-only access in the UI and at the API layer.
+
+    [:octicons-arrow-right-24: Permissions](deep-dive/permissions.md)
+
+-   **Best Practices**
+
+    ---
+
+    Patterns for rollout reviews, governance reporting, and adoption tracking.
+
+    [:octicons-arrow-right-24: Best Practices](deep-dive/best-practices.md)
+
+</div>
+
+---
+
+## How-tos
+
+Reference pages for each part of the Platform Audit UI.
+
+<div class="grid cards" markdown>
+
+-   **Summary Section**
+
+    ---
+
+    Read the five summary cards: four metric cards (Active users, Total actions, Most active user, Top category) and the **Actions per day** chart card.
+
+    [:octicons-arrow-right-24: Summary Section](how-tos/summary-section.md)
+
+-   **Filter Activity**
+
+    ---
+
+    Narrow the log by date, timeframe, users, actions, or hide automated activity.
+
+    [:octicons-arrow-right-24: Filter Activity](how-tos/filter-activity.md)
+
+-   :material-download-circle-outline:{ .lg .middle } **Export Activity**
+
+    ---
+
+    Download the current page of activity as a CSV file.
+
+    [:octicons-arrow-right-24: Export Activity](how-tos/export-activity.md)
+
+</div>
+
+---
+
+## Reference
+
+<div class="grid cards" markdown>
+
+-   :material-api:{ .lg .middle } **API**
+
+    ---
+
+    The `/activity` and `/activity/insights` endpoints, their parameters, and response shapes.
+
+    [:octicons-arrow-right-24: API](api.md)
+
+-   :material-help-circle-outline:{ .lg .middle } **FAQ**
+
+    ---
+
+    Retention, timezone, internal users, and other common questions.
+
+    [:octicons-arrow-right-24: FAQ](faq.md)
+
+</div>
diff --git a/docs/settings/audit/how-tos/export-activity.md b/docs/settings/audit/how-tos/export-activity.md
new file mode 100644
index 0000000000..98b1a6ae88
--- /dev/null
+++ b/docs/settings/audit/how-tos/export-activity.md
@@ -0,0 +1,31 @@
+# :material-download-circle-outline:{ .middle style="color: var(--q-brick)" } Export Activity
+
+The **Export** button in the Platform Audit filter bar downloads the **current page** of the activity log as a CSV file. This page covers how the export behaves and which fields it includes.
+
+!!! info "Permissions"
+    Only users with the **Admin** user role can access the Audit page. See the [Permissions](../deep-dive/permissions.md){:target="_blank"} page for the full matrix.
+
+## Exporting the current page
+
+![Export button highlighted in the Audit filter bar with the "Export current page as .csv" tooltip](../../../assets/settings/audit/how-tos/export-activity/export-button.png)
+
+Click the **Export** button :material-download-circle-outline: at the right edge of the filter bar. The browser downloads a file named `audit-<report-date>.csv`, where `<report-date>` is the value currently set in the filter bar's **Date** field.
+
+!!! note "Empty pages cannot be exported"
+    The Export button is disabled whenever the activity log is empty. A short tooltip *Export current page as .csv* appears on hover when the button is enabled.
+
+## CSV columns
+
+Each row corresponds to one activity entry and contains these columns:
+
+| Column | Description |
+| :--- | :--- |
+| `user` | The actor's display name. `Unknown` is written when the user account no longer exists. |
+| `action` | The action verb in human-readable form (`Create`, `Update`, `Delete`, and so on). |
+| `entity_id` | The numeric ID of the affected entity (blank when the action does not target a specific entity). |
+| `entity_type` | The entity type label (`Anomaly`, `Quality Check`, `Datastore`, and others). |
+| `issued_at_local` | The action timestamp formatted in the viewer's local timezone. |
+| `issued_at_utc` | The action timestamp in raw UTC ISO 8601. |
+
+!!! note "Export is page-scoped"
+    The export contains only the rows on the current page. To export a larger dataset, increase the page size or paginate through the log and export each page in turn. For full retrospective analysis at scale, prefer the [`GET /api/activity`](../api.md#list-activity){:target="_blank"} endpoint, which supports the same filters.
diff --git a/docs/settings/audit/how-tos/filter-activity.md b/docs/settings/audit/how-tos/filter-activity.md
new file mode 100644
index 0000000000..a18f8f710b
--- /dev/null
+++ b/docs/settings/audit/how-tos/filter-activity.md
@@ -0,0 +1,47 @@
+# Filter Activity
+
+The filter bar at the top of the Platform Audit page narrows both the activity log and the summary section (cards plus chart) to a focused subset of activity. This page covers every filter control available on the page.
+
+!!! info "Permissions"
+    Only users with the **Admin** user role can access the Audit page. See the [Permissions](../deep-dive/permissions.md){:target="_blank"} page for the full matrix.
+
+## Date and Timeframe
+
+The **Date** field is the **Report Date**: the *end* of the timeframe window. It defaults to today and cannot be set to a future date.
+
+![Audit filter bar with the Date field highlighted and the date picker open](../../../assets/settings/audit/how-tos/filter-activity/date-picker.png)
+
+The **Timeframe** dropdown, together with the Report Date, defines the window of activity the page shows.
+
+| Timeframe | Window |
+| :--- | :--- |
+| Week | The seven days ending on the Report Date. |
+| Month | The prior month ending on the Report Date (roughly 30 days). |
+| Quarter | The prior three months ending on the Report Date (roughly 90 days). |
+| Year | The prior year ending on the Report Date (365 or 366 days on leap years). |
+
+![Audit filter bar with the Timeframe dropdown open showing Week, Month, Quarter, Year](../../../assets/settings/audit/how-tos/filter-activity/timeframe-dropdown.png)
+
+!!! note "Changing the Date or Timeframe resets pagination"
+    The activity log returns to page 1 whenever the Date or Timeframe changes, because the activity shown has changed.
+
+## Filter menu
+
+Click the **Filter activity** button :material-filter-variant:{ style="color: var(--md-default-fg-color)" } to open the filter menu. The menu contains three filters:
+
+![Filter activity menu open with Users, Actions, and Hide Qualytics options](../../../assets/settings/audit/how-tos/filter-activity/filter-menu.png)
+
+| Filter | Description |
+| :--- | :--- |
+| **Users** | Multi-select list of users. Use the search box to filter by name, username, or email. Only actions attributed to the selected users are shown. |
+| **Actions** | Multi-select list of action verbs (`Create`, `Update`, `Delete`, and others). Use the search box to find a specific verb. |
+| **Hide Qualytics** | Toggle. When **on**, removes activity from internal users from both the chart and the log. When **off** (the default), internal activity is included. |
+
+Click **Apply** to commit the filters. The chart, summary cards, and log all refresh together with the new population, and pagination resets to page 1.
+
+## Clear filters
+
+To clear an individual filter, reopen the menu and deselect the values or toggle off the option. To clear all filters, deselect everything and apply.
+
+!!! info "Active users always excludes internal users"
+    The **Active users** summary card always counts unique *human* actors, regardless of the **Hide Qualytics** toggle. The toggle controls everything else on the page (the **Total actions**, **Most active user**, and **Top category** cards, the activity chart, and the activity log).
diff --git a/docs/settings/audit/how-tos/summary-section.md b/docs/settings/audit/how-tos/summary-section.md
new file mode 100644
index 0000000000..dcb2b965fc
--- /dev/null
+++ b/docs/settings/audit/how-tos/summary-section.md
@@ -0,0 +1,54 @@
+# Summary Section
+
+The summary section sits between the filter bar and the activity log. It packs five cards in a single row: four metric cards (Active users, Total actions, Most active user, Top category) and the **Actions per day** chart card on the right. All five share the same selected timeframe and the same set of filters.
+
+!!! info "Permissions"
+    Only users with the **Admin** user role can access the Audit page. See the [Permissions](../deep-dive/permissions.md){:target="_blank"} page for the full matrix.
+
+![Audit page summary section with the five cards numbered](../../../assets/settings/audit/how-tos/summary-section/summary-cards-annotated.png)
+
+## What each card shows
+
+A `Last N days` label above the cards confirms the active window (for example, `Last 7 days` for Week, `Last 30 days` for Month).
+
+| # | Card | What it shows |
+|:---:|:---|:---|
+| 1 | **Active users** | Count of distinct *human* users who took at least one action during the timeframe. This card always excludes internal users, even when the **Hide Qualytics** filter is off. |
+| 2 | **Total actions** | Total number of actions during the timeframe. Values above 999 are abbreviated (`1.2k`, `3.4M`); hover the card to see the exact, formatted number in a tooltip. |
+| 3 | **Most active user** | Avatar and display name of the user with the highest action count in the timeframe. Hover the card to see the exact action count. When no activity matches the filters, the card shows a dash placeholder. |
+| 4 | **Top category** | Icon and label of the entity type that received the most actions in the timeframe (for example, `Anomaly`, `Quality Check`, `Datastore`). The hint `Most actioned in period` sits below the value. Hover the card to see the exact action count for that type. When no activity matches the filters, the card shows a dash placeholder. |
+| 5 | **Actions per day** chart | Stacked bar chart of action volume over time. See the [Actions per day chart](#actions-per-day-chart) section. |
+
+## Actions per day chart
+
+The chart card breaks the total action volume in the timeframe into two series:
+
+| Color | Series |
+| :--- | :--- |
+| Primary :material-square:{ style="color: var(--q-primary)" } | **User** (actions from human users). |
+| Secondary :material-square:{ style="color: var(--q-secondary)" } | **Automated** (actions from internal users). |
+
+The legend sits in the top-right corner of the chart card. The **Automated** series and its legend entry are hidden whenever the **Hide Qualytics** filter is on.
+
+### Bucket width
+
+The chart title and bucket width adjust to the selected timeframe so the chart stays readable:
+
+| Timeframe | Chart title | Bucket |
+| :--- | :--- | :--- |
+| Week | Actions per day | One bar per day |
+| Month | Actions per week | One bar per week |
+| Quarter | Actions per month | One bar per month |
+| Year | Actions per quarter | One bar per quarter |
+
+### Tooltip and empty buckets
+
+Hover any bar to see its tooltip. The tooltip shows the bucket label (for example, `Mar 12`, `Mar 9`, `Q1 2026`) and the count of actions for each visible series in that bucket.
+
+Buckets with zero activity display as low, muted bars so the time axis stays continuous. This makes weekends and quiet periods easy to spot in Week and Month views.
+
+!!! info "Cards and chart refresh in lock-step with the log"
+    When you change a filter, the cards, the chart, and the activity log refresh together. While a refresh is in flight, the previously loaded values stay visible to avoid intermediate flicker.
+
+!!! note "Bucket aggregation"
+    Activity is recorded as daily counts and aggregated into the wider buckets above based on the selected timeframe, so the chart and the cards always describe the same population.
diff --git a/docs/settings/overview.md b/docs/settings/overview.md
index e2a979e58b..876356cda7 100644
--- a/docs/settings/overview.md
+++ b/docs/settings/overview.md
@@ -1,49 +1,1147 @@
-# Settings Getting Started
+# :material-book-alphabet:{ .middle style="color: var(--q-brick)" } Settings Overview
 
-Settings is the central hub for managing your Qualytics platform configuration. From here you can control data source connections, user access and team permissions, API tokens, and monitor system health.
+Settings is the central hub for managing your Qualytics platform configuration. From here you can control data source connections, set up integrations, manage user access and team permissions, generate API tokens, review platform activity, and monitor system health.
 
-In this section you will find:
+---
+
+## Connections
+
+<div class="grid cards" markdown>
+
+-   **Connections**
+
+    ---
+
+    Manage global data source connections, edit credentials, and associate datastores.
+
+    [:octicons-arrow-right-24: Connections](connections/manage-connections.md)
+
+</div>
+
+---
+
+## Integrations
+
+<div class="grid cards" markdown>
+
+-   **Integrations Overview**
+
+    ---
+
+    Every integration category available in Qualytics.
+
+    [:octicons-arrow-right-24: Integrations Overview](integrations/overview.md)
+
+-   **Single Sign-On**
+
+    ---
+
+    Enable secure access through your enterprise identity provider.
+
+    [:octicons-arrow-right-24: Single Sign-On](integrations/sso/sso.md)
+
+-   **Compute**
+
+    ---
+
+    Configure managed Kubernetes or external compute environments.
+
+    [:octicons-arrow-right-24: Compute](integrations/compute/compute.md)
+
+-   **Workflow**
+
+    ---
+
+    Embed data quality checks into your pipelines and transformations.
+
+    [:octicons-arrow-right-24: Workflow](integrations/workflow/workflow.md)
+
+-   **Analytics**
+
+    ---
+
+    Visualize data quality metrics through your preferred BI tools.
+
+    [:octicons-arrow-right-24: Analytics](integrations/analytics/analytics.md)
+
+-   **Data Catalogs Overview**
+
+    ---
+
+    Every supported data-catalog destination.
+
+    [:octicons-arrow-right-24: Data Catalogs Overview](integrations/data-catalogs/overview.md)
+
+-   **Atlan**
+
+    ---
+
+    Surface data quality insights directly inside Atlan.
+
+    [:octicons-arrow-right-24: Atlan](integrations/data-catalogs/atlan.md)
+
+-   **Alation**
+
+    ---
+
+    Push quality metrics and anomaly counts to Alation catalog assets.
+
+    [:octicons-arrow-right-24: Alation](integrations/data-catalogs/alation.md)
+
+-   **Microsoft Purview**
+
+    ---
+
+    Sync quality signals to Microsoft Purview for governance and discovery.
+
+    [:octicons-arrow-right-24: Microsoft Purview](integrations/data-catalogs/microsoft-purview.md)
+
+-   **Collibra**
+
+    ---
+
+    Publish data quality scores and anomalies to Collibra assets.
+
+    [:octicons-arrow-right-24: Collibra](integrations/data-catalogs/collibra.md)
+
+-   **DataHub**
+
+    ---
+
+    Stream data quality results into DataHub to enrich data discovery.
+
+    [:octicons-arrow-right-24: DataHub](integrations/data-catalogs/datahub.md)
+
+-   **External Tag Propagation**
+
+    ---
+
+    Mirror tags from your external catalog back into Qualytics datastores and containers.
+
+    [:octicons-arrow-right-24: External Tag Propagation](integrations/data-catalogs/external-tag-propagation.md)
+
+-   **Display Names and Descriptions**
+
+    ---
+
+    Override the source name and description of containers and fields surfaced in the catalog.
+
+    [:octicons-arrow-right-24: Display Names and Descriptions](integrations/data-catalogs/display-names-and-descriptions.md)
+
+-   **Alerting Overview**
+
+    ---
+
+    Every alerting destination supported by Qualytics.
+
+    [:octicons-arrow-right-24: Alerting Overview](integrations/alerting/overview.md)
+
+-   **Slack**
+
+    ---
+
+    Send data quality alerts and anomaly notifications to Slack channels.
+
+    [:octicons-arrow-right-24: Slack](integrations/alerting/slack.md)
+
+-   **Microsoft Teams**
+
+    ---
+
+    Send data quality alerts and anomaly notifications to Microsoft Teams channels.
+
+    [:octicons-arrow-right-24: Microsoft Teams](integrations/alerting/msft_teams.md)
+
+-   **PagerDuty Overview**
+
+    ---
+
+    Overview of the PagerDuty integration.
+
+    [:octicons-arrow-right-24: PagerDuty Overview](integrations/alerting/pagerduty/overview.md)
+
+-   **PagerDuty Deep Dive**
+
+    ---
+
+    How the PagerDuty integration works.
+
+    [:octicons-arrow-right-24: PagerDuty Deep Dive](integrations/alerting/pagerduty/deep-dive.md)
+
+-   **PagerDuty API**
+
+    ---
+
+    Manage PagerDuty integrations programmatically.
+
+    [:octicons-arrow-right-24: PagerDuty API](integrations/alerting/pagerduty/pagerduty-api.md)
+
+-   **PagerDuty FAQ**
+
+    ---
+
+    Common questions about the PagerDuty integration.
+
+    [:octicons-arrow-right-24: PagerDuty FAQ](integrations/alerting/pagerduty/pagerduty-faq.md)
+
+-   **Add PagerDuty Integration**
+
+    ---
+
+    Connect a new PagerDuty service to Qualytics.
+
+    [:octicons-arrow-right-24: Add PagerDuty Integration](integrations/alerting/pagerduty/managing-pagerduty/add-integration.md)
+
+-   **Edit PagerDuty Integration**
+
+    ---
+
+    Update credentials or routing for an existing PagerDuty integration.
+
+    [:octicons-arrow-right-24: Edit PagerDuty Integration](integrations/alerting/pagerduty/managing-pagerduty/edit-integration.md)
+
+-   **Remove PagerDuty Integration**
+
+    ---
+
+    Disconnect a PagerDuty integration from Qualytics.
+
+    [:octicons-arrow-right-24: Remove PagerDuty Integration](integrations/alerting/pagerduty/managing-pagerduty/remove-integration.md)
+
+-   **Ticketing Overview**
+
+    ---
+
+    Every ticketing destination supported by Qualytics.
+
+    [:octicons-arrow-right-24: Ticketing Overview](integrations/ticketing/ticketing.md)
+
+-   **Jira Introduction**
+
+    ---
+
+    Overview of the Jira integration for anomaly tracking.
+
+    [:octicons-arrow-right-24: Jira Introduction](integrations/ticketing/jira/introduction.md)
+
+-   **How the Jira Integration Works**
+
+    ---
+
+    Connection model, ticket fields, and sync behavior.
+
+    [:octicons-arrow-right-24: How the Jira Integration Works](integrations/ticketing/jira/deep-dive/how-it-works.md)
+
+-   **Jira Integration Permissions**
+
+    ---
+
+    User roles and Jira-side scopes required to use the integration.
+
+    [:octicons-arrow-right-24: Jira Integration Permissions](integrations/ticketing/jira/deep-dive/permissions.md)
+
+-   **Configure Jira**
+
+    ---
+
+    Set up the Jira side (project, fields, permissions) before connecting.
+
+    [:octicons-arrow-right-24: Configure Jira](integrations/ticketing/jira/managing/configure-jira.md)
+
+-   **Add Jira Connection**
+
+    ---
+
+    Connect a Jira workspace to Qualytics.
+
+    [:octicons-arrow-right-24: Add Jira Connection](integrations/ticketing/jira/managing/add-connection.md)
+
+-   **Edit Jira Connection**
+
+    ---
+
+    Update credentials or project mapping for an existing Jira connection.
+
+    [:octicons-arrow-right-24: Edit Jira Connection](integrations/ticketing/jira/managing/edit-connection.md)
+
+-   **Unlink Jira Connection**
+
+    ---
+
+    Remove a Jira connection from Qualytics.
+
+    [:octicons-arrow-right-24: Unlink Jira Connection](integrations/ticketing/jira/managing/unlink-connection.md)
+
+-   **Create a Jira Ticket**
+
+    ---
+
+    Open a new Jira ticket from a Qualytics anomaly.
+
+    [:octicons-arrow-right-24: Create a Jira Ticket](integrations/ticketing/jira/managing/create-ticket.md)
+
+-   **Link an Existing Jira Ticket**
+
+    ---
+
+    Attach an existing Jira ticket to a Qualytics anomaly.
+
+    [:octicons-arrow-right-24: Link an Existing Jira Ticket](integrations/ticketing/jira/managing/link-existing-ticket.md)
+
+-   **Unlink a Jira Ticket**
+
+    ---
+
+    Detach a Jira ticket from an anomaly without deleting the ticket.
+
+    [:octicons-arrow-right-24: Unlink a Jira Ticket](integrations/ticketing/jira/managing/unlink-ticket.md)
+
+-   **Jira Tips & Tricks**
+
+    ---
+
+    Best-practice patterns when running Jira against Qualytics anomalies.
+
+    [:octicons-arrow-right-24: Jira Tips & Tricks](integrations/ticketing/jira/managing/tips-and-tricks.md)
+
+-   **Jira Integration FAQ**
+
+    ---
+
+    Common questions about the Jira integration.
+
+    [:octicons-arrow-right-24: Jira Integration FAQ](integrations/ticketing/jira/faq.md)
+
+-   **ServiceNow Introduction**
+
+    ---
+
+    Overview of the ServiceNow integration for anomaly tracking.
+
+    [:octicons-arrow-right-24: ServiceNow Introduction](integrations/ticketing/servicenow/introduction.md)
+
+-   **How the ServiceNow Integration Works**
+
+    ---
+
+    Connection model, ticket fields, and sync behavior.
+
+    [:octicons-arrow-right-24: How the ServiceNow Integration Works](integrations/ticketing/servicenow/deep-dive/how-it-works.md)
+
+-   **ServiceNow Integration Permissions**
+
+    ---
+
+    User roles and ServiceNow-side scopes required to use the integration.
+
+    [:octicons-arrow-right-24: ServiceNow Integration Permissions](integrations/ticketing/servicenow/deep-dive/permissions.md)
+
+-   **Configure ServiceNow**
+
+    ---
+
+    Set up the ServiceNow side (table, fields, permissions) before connecting.
+
+    [:octicons-arrow-right-24: Configure ServiceNow](integrations/ticketing/servicenow/managing/configure-servicenow.md)
+
+-   **Add ServiceNow Connection**
+
+    ---
+
+    Connect a ServiceNow instance to Qualytics.
+
+    [:octicons-arrow-right-24: Add ServiceNow Connection](integrations/ticketing/servicenow/managing/add-connection.md)
+
+-   **Edit ServiceNow Connection**
+
+    ---
+
+    Update credentials or table mapping for an existing ServiceNow connection.
+
+    [:octicons-arrow-right-24: Edit ServiceNow Connection](integrations/ticketing/servicenow/managing/edit-connection.md)
+
+-   **Unlink ServiceNow Connection**
+
+    ---
+
+    Remove a ServiceNow connection from Qualytics.
+
+    [:octicons-arrow-right-24: Unlink ServiceNow Connection](integrations/ticketing/servicenow/managing/unlink-connection.md)
+
+-   **Create a ServiceNow Ticket**
+
+    ---
+
+    Open a new ServiceNow ticket from a Qualytics anomaly.
+
+    [:octicons-arrow-right-24: Create a ServiceNow Ticket](integrations/ticketing/servicenow/managing/create-ticket.md)
+
+-   **Link an Existing ServiceNow Ticket**
+
+    ---
+
+    Attach an existing ServiceNow ticket to a Qualytics anomaly.
+
+    [:octicons-arrow-right-24: Link an Existing ServiceNow Ticket](integrations/ticketing/servicenow/managing/link-existing-ticket.md)
+
+-   **Unlink a ServiceNow Ticket**
+
+    ---
+
+    Detach a ServiceNow ticket from an anomaly without deleting the ticket.
+
+    [:octicons-arrow-right-24: Unlink a ServiceNow Ticket](integrations/ticketing/servicenow/managing/unlink-ticket.md)
+
+-   **Find ServiceNow Values**
+
+    ---
+
+    Locate the ServiceNow IDs and table names needed during configuration.
+
+    [:octicons-arrow-right-24: Find ServiceNow Values](integrations/ticketing/servicenow/managing/find-servicenow-values.md)
+
+-   **ServiceNow Tips & Tricks**
+
+    ---
+
+    Best-practice patterns when running ServiceNow against Qualytics anomalies.
+
+    [:octicons-arrow-right-24: ServiceNow Tips & Tricks](integrations/ticketing/servicenow/managing/tips-and-tricks.md)
+
+-   **ServiceNow Integration FAQ**
+
+    ---
+
+    Common questions about the ServiceNow integration.
+
+    [:octicons-arrow-right-24: ServiceNow Integration FAQ](integrations/ticketing/servicenow/faq.md)
+
+</div>
+
+---
+
+## Security
+
+<div class="grid cards" markdown>
+
+-   **Security Getting Started**
+
+    ---
+
+    Manage users, teams, and Service Users.
+
+    [:octicons-arrow-right-24: Security Getting Started](security/overview.md)
+
+-   :material-account-outline:{ .lg .middle } **Personal Accounts**
+
+    ---
+
+    Human user accounts with role-based access.
+
+    [:octicons-arrow-right-24: Personal Accounts](security/users/introduction.md)
+
+-   **How Personal Accounts Work**
+
+    ---
+
+    Account model, identity provider integration, and lifecycle states.
+
+    [:octicons-arrow-right-24: How Personal Accounts Work](security/users/how-it-works.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Personal Account Permissions**
+
+    ---
+
+    What each user role can do at the workspace level.
+
+    [:octicons-arrow-right-24: Personal Account Permissions](security/users/permissions.md)
+
+-   **Personal Account Best Practices**
+
+    ---
+
+    Patterns for onboarding, deactivation, and ongoing user maintenance.
+
+    [:octicons-arrow-right-24: Personal Account Best Practices](security/users/best-practices.md)
+
+-   :material-badge-account-outline:{ .lg .middle } **User Roles**
+
+    ---
+
+    The three workspace-level roles (Admin, Manager, Member) and their hierarchy.
+
+    [:octicons-arrow-right-24: User Roles](security/users/roles/overview.md)
+
+-   **Admin**
+
+    ---
+
+    Full-platform access. Includes all Manager and Member capabilities.
+
+    [:octicons-arrow-right-24: Admin](security/users/roles/admin.md)
+
+-   **Manager**
+
+    ---
+
+    Mid-tier role with most workspace-level capabilities, subject to team permissions.
+
+    [:octicons-arrow-right-24: Manager](security/users/roles/manager.md)
+
+-   **Member**
+
+    ---
+
+    Base role limited to its team's datastores, with primarily read-only access to platform features.
+
+    [:octicons-arrow-right-24: Member](security/users/roles/member.md)
+
+-   **Edit a User**
+
+    ---
+
+    Update an existing user's name, email, role, or team assignments.
+
+    [:octicons-arrow-right-24: Edit a User](security/users/managing/edit-user.md)
+
+-   **Deactivate a User**
+
+    ---
+
+    Disable an account to revoke access while keeping its audit trail.
+
+    [:octicons-arrow-right-24: Deactivate a User](security/users/managing/deactivate-user.md)
+
+-   **Reactivate a User**
+
+    ---
+
+    Re-enable a previously deactivated user account.
+
+    [:octicons-arrow-right-24: Reactivate a User](security/users/managing/reactivate-user.md)
+
+-   **Sort Users**
+
+    ---
+
+    Reorder the user list by name, role, creation date, or last login.
+
+    [:octicons-arrow-right-24: Sort Users](security/users/managing/sort-users.md)
+
+-   **Filter Users**
+
+    ---
+
+    Narrow the user list by role, team, status, or other facets.
+
+    [:octicons-arrow-right-24: Filter Users](security/users/managing/filter-users.md)
+
+-   **Users List Columns**
+
+    ---
+
+    Interactive columns available in the Users list view.
+
+    [:octicons-arrow-right-24: Users List Columns](security/users/managing/list-columns.md)
+
+-   :material-api:{ .lg .middle } **Personal Account API**
+
+    ---
+
+    Manage personal accounts programmatically.
+
+    [:octicons-arrow-right-24: Personal Account API](security/users/api.md)
+
+-   :material-help-circle-outline:{ .lg .middle } **Personal Account FAQ**
+
+    ---
+
+    Common questions about user accounts and roles.
+
+    [:octicons-arrow-right-24: Personal Account FAQ](security/users/faq.md)
+
+-   :material-account-group-outline:{ .lg .middle } **Teams**
+
+    ---
+
+    Group users and apply datastore-level permissions through team membership.
+
+    [:octicons-arrow-right-24: Teams](security/teams/introduction.md)
+
+-   **How Teams Work**
+
+    ---
+
+    Team membership, datastore scoping, and inheritance behavior.
+
+    [:octicons-arrow-right-24: How Teams Work](security/teams/how-it-works.md)
+
+-   **Team Best Practices**
+
+    ---
+
+    Patterns for naming, sizing, and reorganizing teams over time.
+
+    [:octicons-arrow-right-24: Team Best Practices](security/teams/best-practices.md)
+
+-   **Team Membership Strategy**
+
+    ---
+
+    How to organize users into teams to match your governance model.
+
+    [:octicons-arrow-right-24: Team Membership Strategy](security/teams/membership-strategy.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Team Permissions**
+
+    ---
+
+    The five datastore-level permissions (Editor, Author, Drafter, Viewer, Reporter).
+
+    [:octicons-arrow-right-24: Team Permissions](security/teams/team-permissions/overview.md)
+
+-   **Editor**
+
+    ---
+
+    Highest team permission. Full read and write within the datastore.
+
+    [:octicons-arrow-right-24: Editor](security/teams/team-permissions/editor.md)
+
+-   **Author**
+
+    ---
+
+    Create and update most datastore content, with some restrictions.
+
+    [:octicons-arrow-right-24: Author](security/teams/team-permissions/author.md)
+
+-   **Drafter**
+
+    ---
+
+    Author content as drafts that require promotion before becoming live.
+
+    [:octicons-arrow-right-24: Drafter](security/teams/team-permissions/drafter.md)
+
+-   **Viewer**
+
+    ---
+
+    Read-only access to datastore content.
+
+    [:octicons-arrow-right-24: Viewer](security/teams/team-permissions/viewer.md)
+
+-   **Reporter**
+
+    ---
+
+    Minimal access, limited to specific reporting and dashboard views.
+
+    [:octicons-arrow-right-24: Reporter](security/teams/team-permissions/reporter.md)
+
+-   **Add a Team**
+
+    ---
+
+    Create a new team and assign users to it.
+
+    [:octicons-arrow-right-24: Add a Team](security/teams/managing/add-team.md)
+
+-   **Edit a Team**
+
+    ---
+
+    Update a team's name, description, or membership.
+
+    [:octicons-arrow-right-24: Edit a Team](security/teams/managing/edit-team.md)
+
+-   **Delete a Team**
+
+    ---
+
+    Remove a team and detach its datastore permissions.
+
+    [:octicons-arrow-right-24: Delete a Team](security/teams/managing/delete-team.md)
+
+-   **Sort Teams**
+
+    ---
+
+    Reorder the team list by name, size, or creation date.
+
+    [:octicons-arrow-right-24: Sort Teams](security/teams/managing/sort-teams.md)
+
+-   **Teams List Columns**
+
+    ---
+
+    Interactive columns available in the Teams list view.
+
+    [:octicons-arrow-right-24: Teams List Columns](security/teams/managing/list-columns.md)
+
+-   :material-api:{ .lg .middle } **Teams API**
+
+    ---
+
+    Manage teams programmatically.
+
+    [:octicons-arrow-right-24: Teams API](security/teams/api.md)
+
+-   :material-help-circle-outline:{ .lg .middle } **Teams FAQ**
+
+    ---
+
+    Common questions about teams and membership.
+
+    [:octicons-arrow-right-24: Teams FAQ](security/teams/faq.md)
+
+-   :material-account-key-outline:{ .lg .middle } **Service Users**
+
+    ---
+
+    Non-human accounts for automation, pipelines, and integrations.
+
+    [:octicons-arrow-right-24: Service Users](security/service-users/introduction.md)
+
+-   **How Service Users Work**
 
-- **Connections** — Manage global data source connections, edit credentials, and associate datastores.
-- **Security** — Manage user roles, team permissions, service users, and access controls across the platform.
-- **Access Tokens** — Generate and manage Personal Access Tokens and Service Tokens for API authentication.
-- **Status** — Monitor platform health, dataplane configuration, license management, and system resources.
+    ---
+
+    Service-user lifecycle, ownership, and identity separation from human users.
+
+    [:octicons-arrow-right-24: How Service Users Work](security/service-users/deep-dive/how-it-works.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Service User Permissions**
+
+    ---
+
+    What service users can do and how they inherit roles and team membership.
+
+    [:octicons-arrow-right-24: Service User Permissions](security/service-users/deep-dive/permissions.md)
+
+-   **Service User Best Practices**
+
+    ---
+
+    Patterns for Service User naming, scope, and rotation.
+
+    [:octicons-arrow-right-24: Service User Best Practices](security/service-users/deep-dive/best-practices.md)
+
+-   **Create a Service User**
+
+    ---
+
+    Provision a new service user for automation or integration purposes.
+
+    [:octicons-arrow-right-24: Create a Service User](security/service-users/managing/create-service-user.md)
+
+-   **Edit a Service User**
+
+    ---
+
+    Update a service user's metadata or team assignments.
+
+    [:octicons-arrow-right-24: Edit a Service User](security/service-users/managing/edit-service-user.md)
+
+-   **Deactivate a Service User**
+
+    ---
+
+    Disable a service user without deleting it.
+
+    [:octicons-arrow-right-24: Deactivate a Service User](security/service-users/managing/deactivate-service-user.md)
+
+-   **Reactivate a Service User**
+
+    ---
+
+    Re-enable a previously deactivated service user.
+
+    [:octicons-arrow-right-24: Reactivate a Service User](security/service-users/managing/reactivate-service-user.md)
+
+-   **Generate Token for Service User**
+
+    ---
+
+    Create a Service Token bound to a specific service user.
+
+    [:octicons-arrow-right-24: Generate Token for Service User](security/service-users/managing/generate-token.md)
+
+-   :material-api:{ .lg .middle } **Service User API**
+
+    ---
+
+    Manage service users programmatically.
+
+    [:octicons-arrow-right-24: Service User API](security/service-users/api.md)
+
+-   :material-help-circle-outline:{ .lg .middle } **Service User FAQ**
+
+    ---
+
+    Common questions about service users.
+
+    [:octicons-arrow-right-24: Service User FAQ](security/service-users/faq.md)
+
+</div>
 
 ---
 
+## Access Tokens
+
 <div class="grid cards" markdown>
 
--   :material-connection:{ .lg .middle } **Connections**
+-   **Access Tokens Getting Started**
 
     ---
 
-    Manage global data source connections, edit credentials, and associate datastores.
+    Compare Personal Tokens and Service Tokens.
 
-    [:octicons-arrow-right-24: Connections](connections/manage-connections.md)
+    [:octicons-arrow-right-24: Access Tokens Getting Started](access-tokens/getting-started.md)
+
+-   :material-key-variant:{ .lg .middle } **Personal Access Tokens Introduction**
+
+    ---
+
+    Self-service tokens tied to your user account.
+
+    [:octicons-arrow-right-24: Personal Access Tokens Introduction](access-tokens/personal-token/introduction.md)
+
+-   **How Personal Tokens Work**
+
+    ---
+
+    Token lifecycle, scope, and security model.
+
+    [:octicons-arrow-right-24: How Personal Tokens Work](access-tokens/personal-token/deep-dive/how-it-works.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Personal Token Permissions**
+
+    ---
+
+    Permissions tied to a Personal Token, derived from its owning user.
+
+    [:octicons-arrow-right-24: Personal Token Permissions](access-tokens/personal-token/deep-dive/permissions.md)
+
+-   **Personal Token Best Practices**
+
+    ---
+
+    Patterns for safe storage, naming, and rotation of Personal Tokens.
+
+    [:octicons-arrow-right-24: Personal Token Best Practices](access-tokens/personal-token/deep-dive/best-practices.md)
+
+-   **Generate Personal Token**
+
+    ---
+
+    Create a new Personal Token from the Settings page.
+
+    [:octicons-arrow-right-24: Generate Personal Token](access-tokens/personal-token/managing/generate-token.md)
+
+-   **Revoke Personal Token**
+
+    ---
+
+    Temporarily disable a Personal Token without deleting it.
+
+    [:octicons-arrow-right-24: Revoke Personal Token](access-tokens/personal-token/managing/revoke-token.md)
+
+-   **Restore Personal Token**
+
+    ---
+
+    Re-enable a previously revoked Personal Token.
+
+    [:octicons-arrow-right-24: Restore Personal Token](access-tokens/personal-token/managing/restore-token.md)
+
+-   **Delete Personal Token**
+
+    ---
+
+    Permanently delete a Personal Token.
+
+    [:octicons-arrow-right-24: Delete Personal Token](access-tokens/personal-token/managing/delete-token.md)
+
+-   **Personal Tokens List Columns**
+
+    ---
+
+    Interactive columns available in the Personal Tokens list view.
+
+    [:octicons-arrow-right-24: Personal Tokens List Columns](access-tokens/personal-token/managing/list-columns.md)
+
+-   :material-api:{ .lg .middle } **Personal Token API**
+
+    ---
+
+    Manage Personal Tokens programmatically.
+
+    [:octicons-arrow-right-24: Personal Token API](access-tokens/personal-token/api.md)
+
+-   :material-help-circle-outline:{ .lg .middle } **Personal Token FAQ**
+
+    ---
+
+    Common questions about Personal Tokens.
+
+    [:octicons-arrow-right-24: Personal Token FAQ](access-tokens/personal-token/faq.md)
+
+-   :material-lock-outline:{ .lg .middle } **Service Tokens Introduction**
+
+    ---
+
+    Admin-managed tokens tied to Service Users.
+
+    [:octicons-arrow-right-24: Service Tokens Introduction](access-tokens/service-token/introduction.md)
+
+-   **How Service Tokens Work**
+
+    ---
+
+    Service Token lifecycle, ownership, and integration with Service Users.
+
+    [:octicons-arrow-right-24: How Service Tokens Work](access-tokens/service-token/deep-dive/how-it-works.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Service Token Permissions**
+
+    ---
+
+    Permissions tied to a Service Token, derived from its Service User.
+
+    [:octicons-arrow-right-24: Service Token Permissions](access-tokens/service-token/deep-dive/permissions.md)
+
+-   **Service Token Best Practices**
+
+    ---
+
+    Patterns for safe storage, naming, and rotation of Service Tokens.
+
+    [:octicons-arrow-right-24: Service Token Best Practices](access-tokens/service-token/deep-dive/best-practices.md)
 
--   :material-shield-lock-outline:{ .lg .middle } **Security**
+-   **Generate Service Token**
 
     ---
 
-    Manage user roles, team permissions, service users, and access controls.
+    Create a new Service Token for a Service User.
 
-    [:octicons-arrow-right-24: Security](security/overview.md)
+    [:octicons-arrow-right-24: Generate Service Token](access-tokens/service-token/managing/generate-service-token.md)
 
--   :material-key-variant:{ .lg .middle } **Access Tokens**
+-   **Revoke Service Token**
 
     ---
 
-    Generate and manage Personal Access Tokens and Service Tokens for API authentication.
+    Temporarily disable a Service Token without deleting it.
+
+    [:octicons-arrow-right-24: Revoke Service Token](access-tokens/service-token/managing/revoke-service-token.md)
+
+-   **Restore Service Token**
+
+    ---
+
+    Re-enable a previously revoked Service Token.
+
+    [:octicons-arrow-right-24: Restore Service Token](access-tokens/service-token/managing/restore-service-token.md)
+
+-   **Delete Service Token**
+
+    ---
+
+    Permanently delete a Service Token.
+
+    [:octicons-arrow-right-24: Delete Service Token](access-tokens/service-token/managing/delete-service-token.md)
+
+-   **Service Tokens List Columns**
+
+    ---
+
+    Interactive columns available in the Service Tokens list view.
+
+    [:octicons-arrow-right-24: Service Tokens List Columns](access-tokens/service-token/managing/list-columns.md)
+
+-   :material-api:{ .lg .middle } **Service Token API**
+
+    ---
+
+    Manage Service Tokens programmatically.
+
+    [:octicons-arrow-right-24: Service Token API](access-tokens/service-token/api.md)
+
+-   :material-help-circle-outline:{ .lg .middle } **Service Token FAQ**
+
+    ---
+
+    Common questions about Service Tokens.
+
+    [:octicons-arrow-right-24: Service Token FAQ](access-tokens/service-token/faq.md)
+
+</div>
+
+---
+
+## Audit
+
+<div class="grid cards" markdown>
+
+-   :material-book-open-page-variant:{ .lg .middle } **Platform Audit Getting Started**
+
+    ---
+
+    Overview of the Admin-only Platform Audit feature.
+
+    [:octicons-arrow-right-24: Platform Audit Getting Started](audit/getting-started.md)
+
+-   :material-book-open-variant:{ .lg .middle } **Audit Introduction**
+
+    ---
+
+    What the audit log records and how it fits into the platform.
+
+    [:octicons-arrow-right-24: Audit Introduction](audit/deep-dive/introduction.md)
+
+-   :material-file-cog:{ .lg .middle } **How the Audit Page Works**
+
+    ---
+
+    Day-grouped pagination, timezone handling, and the user-vs-automated split.
+
+    [:octicons-arrow-right-24: How the Audit Page Works](audit/deep-dive/how-it-works.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Audit Permissions**
+
+    ---
+
+    Admin-only access in the UI and at the API layer.
+
+    [:octicons-arrow-right-24: Audit Permissions](audit/deep-dive/permissions.md)
+
+-   **Audit Best Practices**
+
+    ---
+
+    Patterns for rollout reviews, governance reporting, and adoption tracking.
+
+    [:octicons-arrow-right-24: Audit Best Practices](audit/deep-dive/best-practices.md)
+
+-   **Summary Section**
+
+    ---
+
+    Read the four metric cards and the Actions per day chart.
+
+    [:octicons-arrow-right-24: Summary Section](audit/how-tos/summary-section.md)
+
+-   **Filter Activity**
+
+    ---
+
+    Narrow the log by date, timeframe, users, actions, or hide automated activity.
+
+    [:octicons-arrow-right-24: Filter Activity](audit/how-tos/filter-activity.md)
+
+-   :material-download-circle-outline:{ .lg .middle } **Export Activity**
+
+    ---
+
+    Download the current page of activity as a CSV file.
+
+    [:octicons-arrow-right-24: Export Activity](audit/how-tos/export-activity.md)
+
+-   :material-api:{ .lg .middle } **Audit API**
+
+    ---
+
+    The `/activity` and `/activity/insights` endpoints and response schemas.
+
+    [:octicons-arrow-right-24: Audit API](audit/api.md)
+
+-   :material-help-circle-outline:{ .lg .middle } **Audit FAQ**
+
+    ---
+
+    Retention, timezone, internal users, and other common questions.
+
+    [:octicons-arrow-right-24: Audit FAQ](audit/faq.md)
+
+</div>
+
+---
+
+## Status
+
+<div class="grid cards" markdown>
+
+-   **Platform Status Getting Started**
+
+    ---
+
+    Monitor platform health and manage the analytical engine.
+
+    [:octicons-arrow-right-24: Platform Status Getting Started](status/getting-started.md)
+
+-   :material-monitor-dashboard:{ .lg .middle } **Platform Status**
+
+    ---
+
+    Real-time health and configuration of every platform component.
+
+    [:octicons-arrow-right-24: Platform Status](status/deep-dive/platform-status.md)
+
+-   :material-routes:{ .lg .middle } **Private Routes**
+
+    ---
+
+    Connectivity verification for datastores reached through private networks.
+
+    [:octicons-arrow-right-24: Private Routes](status/deep-dive/private-routes.md)
+
+-   :material-shield-lock-outline:{ .lg .middle } **Platform Status Permissions**
+
+    ---
+
+    Who can view status and who can restart the analytical engine.
+
+    [:octicons-arrow-right-24: Platform Status Permissions](status/deep-dive/permissions.md)
+
+-   :material-refresh:{ .lg .middle } **Refresh Status Summary**
+
+    ---
+
+    Pull the latest health and configuration data from all services.
+
+    [:octicons-arrow-right-24: Refresh Status Summary](status/managing/refresh-status-summary.md)
+
+-   :material-restart:{ .lg .middle } **Restart Dataplane**
+
+    ---
+
+    Trigger a graceful restart of the analytical engine (Admin).
+
+    [:octicons-arrow-right-24: Restart Dataplane](status/managing/restart-dataplane.md)
+
+-   :material-content-copy:{ .lg .middle } **Copy Status Summary**
+
+    ---
+
+    Copy the full status data as JSON for sharing or troubleshooting.
+
+    [:octicons-arrow-right-24: Copy Status Summary](status/managing/copy-status-summary.md)
+
+-   :material-api:{ .lg .middle } **Status API**
+
+    ---
 
-    [:octicons-arrow-right-24: Access Tokens](access-tokens/getting-started.md)
+    Check health and restart the analytical engine programmatically.
 
+    [:octicons-arrow-right-24: Status API](status/api.md)
 
--   :material-monitor-dashboard:{ .lg .middle } **Status**
+-   :material-help-circle-outline:{ .lg .middle } **Status FAQ**
 
     ---
 
-    Monitor platform health, dataplane configuration, license management, and system resources.
+    Health indicators, restart effects, and troubleshooting.
 
-    [:octicons-arrow-right-24: Status](status/getting-started.md)
+    [:octicons-arrow-right-24: Status FAQ](status/faq.md)
 
 </div>
diff --git a/docs/settings/security/users/roles/admin.md b/docs/settings/security/users/roles/admin.md
index cc5becd2aa..ef78c91eec 100644
--- a/docs/settings/security/users/roles/admin.md
+++ b/docs/settings/security/users/roles/admin.md
@@ -45,9 +45,10 @@ Admin includes all capabilities of **Manager** and **Member**.
 | | Assign datastores to groups | :material-check-circle:{ title="Allowed" } |
 | **Field Status** | Full access to all field status operations | :material-check-circle:{ title="Allowed" } |
 | | View masking audit log | :material-check-circle:{ title="Allowed" } |
-| **Settings UI** | All tabs (Connections, Tokens, Security, Integrations, Status) | :material-check-circle:{ title="Allowed" } |
+| **Settings UI** | All tabs (Connections, Integrations, Defaults, Security, Tokens, Audit, Status) | :material-check-circle:{ title="Allowed" } |
 | **Platform** | Manage global settings | :material-check-circle:{ title="Allowed" } |
 | | View health status | :material-check-circle:{ title="Allowed" } |
+| | View platform activity log (Audit) | :material-check-circle:{ title="Allowed" } |
 | | Restart analytical engine | :material-check-circle:{ title="Allowed" } |
 
 !!! note
diff --git a/docs/settings/security/users/roles/manager.md b/docs/settings/security/users/roles/manager.md
index 8439800d76..83468a8250 100644
--- a/docs/settings/security/users/roles/manager.md
+++ b/docs/settings/security/users/roles/manager.md
@@ -1,6 +1,6 @@
 # Manager
 
-The Manager role provides administrative access over global assets such as datastores, tags, notifications, and connections. However, Managers **are subject to team permissions** when interacting with datastore content — they can list all datastores but cannot view their content without explicit team permission.
+The Manager role provides administrative access over global assets such as datastores, tags, notifications, and connections. However, Managers **are subject to team permissions** when interacting with datastore content. They can list all datastores but cannot view their content without explicit team permission.
 
 ## Who Should Have Manager Access?
 
@@ -49,9 +49,12 @@ Manager includes all capabilities of **Member**.
 | | Assign datastores to groups (with Editor team permission) | :material-check-circle:{ title="Allowed" } |
 | **Tokens** | Generate personal tokens | :material-check-circle:{ title="Allowed" } |
 | | Generate service tokens | :material-close-circle-outline:{ title="Not allowed" } |
-| **Settings UI** | All tabs (Connections, Tokens, Security, Integrations, Status) | :material-check-circle:{ title="Allowed" } |
+| **Settings UI** | Connections, Integrations, Security, Tokens, Status tabs | :material-check-circle:{ title="Allowed" } |
+| | Defaults tab | :material-close-circle-outline:{ title="Not allowed" } |
+| | Audit tab | :material-close-circle-outline:{ title="Not allowed" } |
 | **Health** | View health status | :material-check-circle:{ title="Allowed" } |
+| | View platform activity log (Audit) | :material-close-circle-outline:{ title="Not allowed" } |
 | **Field Status** | Manage field status (with Editor team permission) | :material-check-circle:{ title="Allowed" } |
 
 !!! note
-    Managers **cannot** manage users, teams, or service users. For those capabilities, [Admin](admin.md){:target="_blank"} access is required. Managers are also **subject to team permissions** — they can list datastores but need team membership to view datastore content.
+    Managers **cannot** manage users, teams, or service users. For those capabilities, [Admin](admin.md){:target="_blank"} access is required. Managers are also **subject to team permissions**. They can list datastores but need team membership to view datastore content.
diff --git a/docs/settings/security/users/roles/member.md b/docs/settings/security/users/roles/member.md
index 527b8476e6..538560ab58 100644
--- a/docs/settings/security/users/roles/member.md
+++ b/docs/settings/security/users/roles/member.md
@@ -17,7 +17,7 @@ Member is designed for **data quality analysts**, **business analysts**, **data
 
 ## Includes
 
-Member is the base role — it does not include any other roles.
+Member is the base role: it does not include any other roles.
 
 ## Capability Table
 
@@ -44,8 +44,9 @@ Member is the base role — it does not include any other roles.
 | **Flows** | Create, edit, delete flows | :material-close-circle-outline:{ title="Not allowed" } |
 | **Security** | View or manage users and teams | :material-close-circle-outline:{ title="Not allowed" } |
 | **Settings UI** | Connections and Tokens tabs only | :material-check-circle:{ title="Allowed" } |
-| | Security, Integrations, Status tabs | :material-close-circle-outline:{ title="Not allowed" } |
+| | Integrations, Defaults, Security, Audit, Status tabs | :material-close-circle-outline:{ title="Not allowed" } |
 | **Health** | View health status | :material-close-circle-outline:{ title="Not allowed" } |
+| | View platform activity log (Audit) | :material-close-circle-outline:{ title="Not allowed" } |
 | **Integrations** | Add or sync integrations | :material-close-circle-outline:{ title="Not allowed" } |
 
 !!! note
diff --git a/docs/settings/security/users/roles/overview.md b/docs/settings/security/users/roles/overview.md
index 3cdb31c291..f5fc986294 100644
--- a/docs/settings/security/users/roles/overview.md
+++ b/docs/settings/security/users/roles/overview.md
@@ -14,7 +14,7 @@ There are three user roles: **Admin**, **Manager**, and **Member**. Admins have
 
 ## Role Hierarchy
 
-Roles follow a hierarchical model — higher roles include all capabilities of lower roles:
+Roles follow a hierarchical model: higher roles include all capabilities of lower roles:
 
 | Level | Role | Includes |
 | :---: | :--- | :--- |
@@ -67,9 +67,12 @@ Roles follow a hierarchical model — higher roles include all capabilities of l
 | Tokens tab | :material-check-circle:{ title="Allowed" } | :material-check-circle:{ title="Allowed" } | :material-check-circle:{ title="Allowed" } |
 | Security tab | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } | :material-check-circle:{ title="Allowed" } |
 | Integrations tab | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } | :material-check-circle:{ title="Allowed" } |
+| Defaults tab | :material-close-circle-outline:{ title="Not allowed" } | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } |
+| Audit tab | :material-close-circle-outline:{ title="Not allowed" } | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } |
 | Status tab | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } | :material-check-circle:{ title="Allowed" } |
 | **Platform** | | | |
 | View health status | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } | :material-check-circle:{ title="Allowed" } |
+| View platform activity log (Audit) | :material-close-circle-outline:{ title="Not allowed" } | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } |
 | Restart analytical engine | :material-close-circle-outline:{ title="Not allowed" } | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } |
 | Manage global settings | :material-close-circle-outline:{ title="Not allowed" } | :material-close-circle-outline:{ title="Not allowed" } | :material-check-circle:{ title="Allowed" } |
 | Subject to team permissions | :material-check-circle:{ title="Allowed" } | :material-check-circle:{ title="Allowed" } | :material-close-circle-outline:{ title="Not allowed" } |
@@ -84,7 +87,7 @@ For detailed descriptions of each role, see the individual pages:
 
     ---
 
-    Full platform access — manage users, teams, datastores, connections, and all settings.
+    Full platform access. Manage users, teams, datastores, connections, and all settings.
 
     [:octicons-arrow-right-24: Admin](admin.md)
 
@@ -92,7 +95,7 @@ For detailed descriptions of each role, see the individual pages:
 
     ---
 
-    Global asset management — create datastores, manage tags, notifications, and connections.
+    Global asset management. Create datastores, manage tags, notifications, and connections.
 
     [:octicons-arrow-right-24: Manager](manager.md)
 
@@ -100,7 +103,7 @@ For detailed descriptions of each role, see the individual pages:
 
     ---
 
-    Standard access — inherits permissions from team membership, manages own tokens.
+    Standard access. Inherits permissions from team membership, manages own tokens.
 
     [:octicons-arrow-right-24: Member](member.md)
 
diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css
index acec27b991..0d08600e11 100644
--- a/docs/stylesheets/extra.css
+++ b/docs/stylesheets/extra.css
@@ -215,6 +215,7 @@
 [data-md-color-scheme="default"] {
   /* Brand Colors */
   --q-primary: #FF9933;
+  --q-secondary: #86AA5B;
   --q-brick: #B83200;
 
   /* Base Colors */
@@ -533,6 +534,7 @@
 [data-md-color-scheme="slate"] {
   /* Brand Colors */
   --q-primary: #FF9933;
+  --q-secondary: #86AA5B;
   --q-brick: #B83200;
 
   /* Base Colors */
diff --git a/mkdocs.yml b/mkdocs.yml
index e54bcd4a70..97578be61f 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -655,6 +655,19 @@ nav:
             - List Columns: settings/access-tokens/service-token/managing/list-columns.md
           - API: settings/access-tokens/service-token/api.md
           - FAQ: settings/access-tokens/service-token/faq.md
+      - Audit:
+        - Getting Started: settings/audit/getting-started.md
+        - Deep Dive:
+          - Introduction: settings/audit/deep-dive/introduction.md
+          - How It Works: settings/audit/deep-dive/how-it-works.md
+          - Permissions: settings/audit/deep-dive/permissions.md
+          - Best Practices: settings/audit/deep-dive/best-practices.md
+        - How-tos:
+          - Summary Section: settings/audit/how-tos/summary-section.md
+          - Filter Activity: settings/audit/how-tos/filter-activity.md
+          - Export Activity: settings/audit/how-tos/export-activity.md
+        - API: settings/audit/api.md
+        - FAQ: settings/audit/faq.md
       - Status:
         - Getting Started: settings/status/getting-started.md
         - Deep Dive: