> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Org history > An append-only record of the consequential actions in your organization — approvals decided, pages published, permissions and flags changed, members added or removed — each one attributed to whoever performed it, on whose behalf, and under which approval. # Org history The Activity feed answers "what needs me right now?"; the **History** answers a different, quieter question — "what happened?". When you come back from a week away, when a page turns out to be public that shouldn't be, or when you want to know exactly what Erdo did on its own while you weren't watching, you need a durable record of the consequential things that changed in your organization, each one attributed to whoever caused it. That record is the org history. It is append-only. An entry is written the moment an action happens and is never edited or removed afterwards, so the history is a faithful account of the past rather than a view of the present that rewrites itself as things change. That is the property that makes it worth trusting when something has gone wrong. ## What it records History captures the actions that have consequences worth answering for later — not every read, click, or intermediate step, but the mutations an operator would want a trail of: * **Approvals** — when an approval is requested and when it is decided, who decided it, and what it authorized. The decision is kept even after the approval request itself ages out, because "who approved this, and when" is precisely the record you want when an approved action turns out badly. * **Publishing** — when a page is made public and when it is taken back private, and who did each. Un-publishing is recorded just as publishing is. * **Permissions** — when access to a resource is granted, changed, or revoked, with the access level before and after. * **Feature flags** — when a capability is turned on or off for your organization, and by whom. * **Membership** — when someone is added to or removed from the organization, or their role changes. * **Destructive and configuration changes** — deleting a dataset, changing an integration's configuration, and similar actions an administrator most wants a trail for. Every entry carries the same attribution, because the whole point is to be able to tell one actor's actions apart from another's. Each records **who** performed it — a specific person, a named agent, or Erdo itself acting as the system — and, where it applies, **on whose behalf** the action ran and **which approval** authorized it. This chain is what lets you distinguish "Jeremy published this page" from "the repair agent republished it, under the approval Jeremy granted an hour earlier" — two very different facts that, without the chain, look identical. That attribution matters more as Erdo takes on more of the work itself. An agent that acts independently is only trustworthy if its actions leave a trail you can read, and the history is that trail: every agent or system action wears its authorization plainly — approved by a named person, or autonomous with no approval required — so "show me everything the agents did this week" is a question you can actually answer. ## Three ways to read it **In the app.** The **History** view sits alongside the Activity feed and reads as a story rather than a table. Actions that belong together — an approval and the agent work it unlocked — are grouped into a single episode you can expand to see the individual events beneath, so a rebuild that re-bound four datasets reads as one thing that happened, not five disconnected rows. Every entry is a plain sentence naming the actor, what they did, and the resource, with its authorization shown as a badge. **Over the API.** `GET /v1/activity/history` returns the raw events, newest first, for a headless caller or a dashboard built on top of Erdo. It is read-only and org-scoped, authorized like every other Platform API call. **On the command line.** `erdo history` is built for forensics — precise filters over a time window, printed as scannable sentences. It is the fastest way to answer an incident question from a terminal. ```bash theme={null} # everything that happened in the last day (the default window) erdo history # who changed permissions on one page this week, and under whose authority erdo history --resource page:9f3c2a10 --since 7d # only what the agents and the system did on their own — the autonomy review erdo history --actor-kind agent --since 3d # a specific person's recent actions, as raw JSON for a script erdo history --actor usr_1a2b3c4d --since 48h --json ``` The command groups related events into episodes exactly as the app does: an initiating action heads a block and the consequences it authorized are indented beneath it, each line stamped with the local time. An episode header shows the approval that authorized it, or marks the action autonomous when an agent or the system acted with no approval required. ## Filtering Every surface shares the same filter set, so a question you can ask in the app you can ask on the CLI or over the API: * **Time window** — `--since` and `--until`. The CLI accepts a relative duration like `2h`, `3d`, or `1w`, or an exact RFC3339 timestamp; `--since` defaults to the last 24 hours. * **Actor kind** — `--actor-kind` narrows to a person, an agent, the system, or a token, which is how you separate what people did from what Erdo did. * **Actor** — `--actor` limits to a single user's actions. * **Resource** — `--resource ` scopes to one thing, like `page:`, to reconstruct its whole story. * **Verb** — `--verb` selects specific kinds of action, comma-separated, such as `approval.decided,page.published`. * **Limit** — `--limit` caps how many events come back. ## When history begins History is append-only and starts recording from the moment the feature is enabled for your organization — there is no reconstruction of actions that happened before then. Older facts remain wherever they already lived (a page's revision history, a dataset's own event log), and the history links out to those deeper records rather than duplicating them: it tells you *what* happened and who caused it, and the owning resource shows you exactly *how*. If a filter returns nothing, it usually means either nothing matched or the window reaches back before the ledger was turned on.