Evidence
Read the activity timeline
The timeline is written for the person accountable for the site, not for the person who wrote the integration.
- Activity & evidence
- 4 min read
Filters
Five filters, and they compose: agent, event, outcome, date, and session.
The two that solve most problems quickly are outcome and session. Filtering to refused outcomes shows you every boundary that was hit; filtering to one session shows you everything a single connection did in one stretch, in order.
What an entry contains
Each entry leads with a human-readable summary and a linked identity, with the technical detail one click away:
- Which agent acted, and in which environment.
- Which Ability was requested.
- Which gate the request reached, and what it decided.
- The outcome, and what changed in WordPress.
- Linked evidence and the request fingerprint.
Questions it answers directly
| Question | How |
|---|---|
| What did this agent do last week? | Filter by agent and date. |
| Why was this request refused? | Open the entry; the gate and reason are named. |
| Has this Ability ever actually been used? | Per-Ability invocation summaries in the Explorer. |
| Who approved this? | The approval decision is recorded with the administrator. |
| What else happened in that burst? | Filter by session. |
Administrative events are here too
Agent creation, activation, restriction, pause and revocation, permission changes, high-risk allows, approval decisions, connection rotations, and emergency mode changes are all recorded alongside agent activity.
That matters during an investigation: “the agent did X” and “someone allowed the agent to do X, twenty minutes earlier” are both in the same timeline.
Activity & evidence
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.