Activity
Activity is a single entry in the workspace sidebar holding three tabs: Activity log, Audit trail, and Review requests.
They are three distinct surfaces, not one merged feed. Each tab reads a different record, keeps its own filters, pagination, exports, and browser history, and carries its own permissions. Nothing is blended into a common timeline: the three records have different visibility floors and no shared ordering key that means the same thing across all three, so a single stream would either show a viewer rows they may not read or silently drop them — and both failures look like a perfectly plausible list.
| Tab | What it records | Path | Who sees it |
|---|---|---|---|
| Activity log | Workspace change events — policies, catalog curation, data sources, deployments, tokens, members, billing | /[tenantSlug]/activity/log | Every member |
| Audit trail | Decision records from agent tool calls, with evidence detail | /[tenantSlug]/activity/audit-trail | Every member; exports and raw content are admin/owner |
| Review requests | The steward inbox for agent access requests | /[tenantSlug]/activity/review-requests | Admins and owners only |
/[tenantSlug]/activity is not a page of its own — it sends you to the Activity log tab.
Review requests is not universally visible. Editors and viewers do not get the tab, do not get its open-count badge, and get a not-found response if they navigate to the path directly. The restriction is not cosmetic: for an unauthorized member the workspace does not run the request queries at all, so there is no count to hide and nothing to strip from the page. Full detail is on the Review requests page.
Older links still work. /[tenantSlug]/audits, /[tenantSlug]/requests, and their sub-paths redirect to the matching tab and carry the query string through, so a bookmarked filtered view lands where it did before. Those redirects are temporary — they may be withdrawn once the new paths are settled, so use the canonical paths above in anything you write down.
Activity logDirect link to Activity log
The Activity log is an append-only record of governance-relevant events in the workspace, readable by every member. Events are written by the platform at the moment of change — there is no way to add, edit, or delete entries from the app — and event payloads are constrained to display fields, never secrets, credentials, or raw provider responses. The header shows how many events the workspace has recorded under the active filter.
What gets recordedDirect link to What gets recorded
- Workspace and members — workspace creation, invitations sent, re-sent, revoked, and accepted, role changes, and members disabled or removed.
- Policies — created, drafts saved, review requested, approved, rejected, archived.
- Catalog curation — table metadata edits, manual column classifications, classification runs, custom classification types, collections, and scenario labels.
- Data sources — connectors created and updated, activated and deactivated, credential reads and rotations, connection tests, sync scope changes, and syncs.
- Deployments — plans created and discarded, applies started, succeeded, or failed, and serving state published.
- MCP tokens — issued and revoked.
- Billing — subscription created, plan changed, updated.
Each entry shows what happened, the entity family it belongs to, who acted — a resolved member or a system badge for platform-driven events — and when, as a relative time with the exact timestamp on hover.
Reading and filteringDirect link to Reading and filtering
The list is grouped by day, newest first, fifty events per page. You can narrow it two ways: by entity facet — Tenant, Members, Policies, Data Sources, Billing, Collections, Scenarios — or by an exact event type. Filters are applied server-side and live in the URL, so a filtered view is shareable and safe to bookmark for recurring checks.
What to use it forDirect link to What to use it for
Change review. Before or after publishing, filter to Policies and Deployments to see exactly what changed between publications — who approved which version, and when the deployment went live.
Incident reconstruction. The log is chronological and spans domains, so you can line up a catalog sync, a policy change, and a deployment publication into one sequence and establish what the workspace looked like at a given moment.
Agent-decision follow-up. Metatate's answers are advisory, so when an agent acts on one you'll sometimes want to trace it. Use explain_why to have the decision itself explained from the published state, the Audit trail tab for the record of the call, and the Activity log for the human history around it: who approved the policy version involved, when the current deployment publication was published, and whether the catalog changed in between.
Background jobsDirect link to Background jobs
Long-running work — data-source syncs, classification runs, deployment applies — runs as background jobs, and each job reports its lifecycle into the log as enqueued, succeeded, or failed events. That makes the Activity log the place to confirm that queued work completed, and to spot a failed sync or apply without digging through any other surface.
RetentionDirect link to Retention
How far back the log goes depends on your plan: the Free plan retains 30 days of activity, and paid plans retain it without limit. See plans for the full comparison. The log is workspace-scoped — members see their own workspace's events and nothing from any other workspace.
Audit trailDirect link to Audit trail
Where the Activity log records what people changed, the Audit trail records what agents asked — the durable, citable decision records written when an agent calls authorize_use or validate_query_context. Every member can read the list and open a record; exports and raw content are restricted, as described below.
Each record is an audit receipt: the question as the server normalized it, the published state that answered it, the answer state and decision, and the identifiers an agent was handed. Ledger identifiers stay resolvable later, which is what makes explain_why able to re-explain a decision from a stored id.
Reading and filteringDirect link to Reading and filtering
The list filters on date range, actor, tool, answer state, decision or outcome, and asset. Filters live in the URL, so a narrowed view is shareable. An invalid filter is never quietly widened to "everything" — the page says the filter was invalid and shows no list rather than a broader result than you asked for.
Opening a row gives the evidence detail at /[tenantSlug]/activity/audit-trail/[kind]/[id], where kind is authorization or validation. Each bundle carries a completeness badge that states what it can and cannot show: Complete, Partial — removed under retention, Partial — record unavailable, or Standalone — no review workflow. A record purged under retention leaves a content-free marker rather than disappearing silently.
The bundle describes an advisory answer. Metatate evaluates and records; it does not execute anything against your platforms, and the detail page says so rather than implying a change was or was not applied downstream.
Permissions and exportsDirect link to Permissions and exports
| Capability | Roles |
|---|---|
| View the list and open evidence detail | Every member |
| View opt-in raw SQL or raw use text | Admins and owners |
| Export a record as JSON, or the list as CSV | Admins and owners |
| See another agent's review-workflow timeline | Admins and owners |
Raw SQL and raw use text appear only when your workspace had the raw-text privacy switch enabled at the time the call was evaluated — turning it on later does not retroactively populate older records. Members below admin see the evidence bundle without the review-workflow timeline section.
Exports are route-level: /[tenantSlug]/activity/audit-trail/export for the filtered list as CSV, and /[tenantSlug]/activity/audit-trail/[kind]/[id]/export for one record as a JSON bundle. Both re-check the role, and both answer an unknown record and a record in another workspace identically, so neither can be used to probe for what exists.
Review requestsDirect link to Review requests
The third tab is the steward inbox for access requests filed by agents through request_access — what a request is, how the inbox reads, and how to resolve one are covered on its own page: Review requests.
It is admin and owner only, including its open-count badge. It is also the only Activity tab where you do something: the other two are records you read.
RelatedDirect link to Related
- Review requests — the steward inbox, in full
- MCP tools — issuing tokens, and the separate per-token MCP request log
explain_why— re-explaining a recorded decision from its id- plans — activity retention by plan