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

# Activity

> How operator-visible state surfaces — system.activity items and severity levels

`system.activity` is the platform's operator-facing surface for "things that happened" — sync progress, errors, reauthorisation prompts, scheduled-job results. Each activity is an item, attributed to the Connection that produced it, queryable through the standard item filter DSL.

The pattern lets connectors and platform components surface state without bespoke notification or log infrastructure. Listings, filters, audit, and permissions all work the same way they do for any other item.

## Severity levels

| Severity          | Meaning                                                                                      | Example                                                  |
| ----------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------- |
| `info`            | Routine state. Schedule completed, n items synced, nothing actionable.                       | "Polled feed, fetched 3 new entries."                    |
| `warning`         | Degraded state, no user action required.                                                     | "Upstream rate-limited; backed off, will retry."         |
| `error`           | Something failed; the system has handled it (retry, skip) but the operator may want to know. | "Webhook delivery failed; entered DLQ."                  |
| `action_required` | The connector cannot proceed without operator intervention.                                  | "OAuth re-authorisation needed for Calendar Connection." |

Severity is the primary filter for the operator surface. The `action_required` slice surfaces in the console as a Repairs-style inbox; the others stream through a feed.

## Fields

| Field           | Meaning                                             |
| --------------- | --------------------------------------------------- |
| `connection_id` | The Connection this activity is attributed to.      |
| `severity`      | One of the four levels above.                       |
| `summary`       | Short human-readable description shown in lists.    |
| `detail`        | Optional structured payload for deep-dive surfaces. |

Like every other `system.*` type, activities use the bounded lifecycle `active | revoked` (not the universal three-state). Activities are also tier-less — `system.*` items don't carry a `tier` field. Operators flip activities to `revoked` once they've handled them; the row stays in the audit trail.

## Optional connection-level feed behavior

A Connection can carry `feed_activity: true` in its properties, which causes the operator console to render that Connection's activity rows in a feed-style surface (high-volume, less prominent) rather than the default library-style listing. The flag rides on the `system.connection` item, not the activity item itself — `system.activity` doesn't have a `tier` field. The underlying rows observe the bounded `active | revoked` lifecycle.

## Why items, not a separate log table

Treating activity as items means the platform gets querying, retention, search, audit, and permissions for free through the same surfaces. No separate log infrastructure, no separate UI to build for the console — list views work uniformly.

The pattern matches `system.device`, `system.credential`, `system.webhook`, and `system.app`: items with reduced operability in a reserved namespace. See [System types](/concepts/system-types) for the wider pattern.

## How operators read activity

Standard item queries:

```
GET /items?type=system.activity&filter=properties.severity eq "action_required"
GET /items?type=system.activity&filter=properties.connection_id eq "<id>"&sort=timestamp&direction=desc
```

Activity fields live under `properties.*` — the filter DSL addresses item properties as `properties.<field>`. The full filter grammar is in [Search and query](/api/search-and-query).

A console view filters by severity and groups by Connection; an SDK consumer queries directly. The data is the same in both cases.