Activity log

Added

The sustained awareness of what has happened across actors and time, transforming a stream of discrete events into an accountable, reviewable history.

Event anatomy

  • Actor: user, other humans, system, LLM, etc.
  • Activity: what the actor did
  • Object: the specific item that was affected by the action
  • When: when the action happened
  • Available actions

Inspecting an event

An event entry can expand from a record into an interactive surface. Closer inspection might reveal decision context, trigger follow-up actions, or simply satisfy curiosity — it isn’t limited to corrective scenarios.

Decision context

The factors that contributed to the event: inputs, rules, model confidence, actor permissions, or prior state. For deterministic system actions, this might be a rule trace. For AI-driven decisions, it could be a reasoning chain, feature attributions, or a natural-language summary. Explanation and transparent reasoning provide the content; the log provides the anchor.

Actions from inspection

What an actor might do after inspecting an event depends on the domain and what the inspection reveals:

  • Follow up — continue a conversation, ask a clarifying question, or act on what they’ve learned
  • Flag or dispute — mark the event for review if something looks wrong
  • Adjust settings — change conditions that led to the event (permissions, preferences, thresholds)
  • Escalate — route to a human reviewer or support channel

Anti-patterns

  • Theatre transparency — surfacing decision factors that are technically accurate but too abstract to be meaningful (“Based on your profile”). The context must be specific enough for the actor to evaluate what happened.
  • Inspection without action — showing why something happened but offering no way to act on it.

Examples

Human actions

Agent actions and reasoning

Consequences

  • the path is recoverable: discrete events read as a reviewable history, each with an actor, an action, an object and a time attached
  • the record is what accountability now rests on, which makes what it leaves out as consequential as what it holds
  • histories only grow, so the log is useful in proportion to how narrowable it is — a complete record nobody can read is the same as no record

Related patterns

Serves

  • Delegation — the log serves as the supervisory record for delegation's monitoring and hood to look under touchpoints during execution

Enacts

  • Temporality — a chronological record that makes the passage of actions over time legible

Complements

  • Activity feed — distinct from activity logs; feeds aggregate content of interest to users from diverse sources, whilst logs are histories of actions taken by a specific entity
  • Collaboration — Uses activity logs to provide transparency and accountability in shared workspaces
  • Explanation
  • Commenting — tracks commenting activity over time

Related

  • Deletion — Historical record of deletions
  • Selective memory — what the system did versus what it keeps
  • Status feedback — Records status changes as Events for chronological review
  • Undo — displays a history of actions that can be undone
  • Workflow — the workflow is the prescription, the log is the account of what actually ran; monitoring reads them against each other

Preceded by

  • Agent — actions and reasoning are tracked and displayed in the activity log.
  • Transparent reasoning — provides the detailed reasoning steps that get recorded in the activity log.
  • Workspace — shows history within a workspace
  • Cognitive forcing functions — the actor has had to do something — wait, commit an answer first, name a reason, finish an incomplete argument — before accepting, so the judgement on record is theirs; where that something was writing down why, the reasons accumulate into a trail somebody else can read

Enabled by

  • Progressive disclosure — individual log entries expand on demand, managing detail depth without losing the timeline flow