Skip to main content

​
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.
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 <type:id> scopes to one thing, like page:<id>, 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.