What exactly does `fleet log` record?

A unified, chronological timeline that merges fabric decision events (such as `pr_approved` and `ticket_shipped`) with activity events (agents starting, running, and stopping). It answers who did what, when, and why across the fleet.

Can I export the audit trail for compliance?

Yes. `fleet log --json` emits the timeline as machine-readable JSON, and you can combine it with `--agent`, `--type`, and `--since` to export exactly the slice you need to archive.

Does the audit trail leave my infrastructure?

The decision and activity history is stored locally in Fleet's database (`~/.fleet/fleet.db` by default), and that local store is the source of truth — you query it with `fleet log`. Your source code is never sent to Fleet. If you register the instance with the dashboard, Fleet also syncs decision events to the control plane for cross-repo visibility; that is operational metadata, not your source code.

How do I verify an AI agent actually reviewed a PR?

Look for the reviewer's `pr_approved` fabric event in `fleet log --type decision`. Because fleet agents share one GitHub identity, that fabric event — not the `approved` label — is the trustworthy evidence the merge gate also relies on.

How to Build an Audit Trail for AI Agent Decisions with Fleet

Name: Fleet
Author: Fleet

When AI agents write and merge code on their own, "who decided this, and when?" stops being a nice-to-have and becomes a requirement. A pull request that an agent approved and another agent merged needs a record you can replay later — for debugging, for review, and for compliance. Without one, an autonomous fleet is a black box that happens to push commits.

Fleet keeps a unified decision and conversation history through fleet log. It merges fabric events (the structured decisions agents publish — pr_approved, ticket_shipped, and the rest) with activity events into one chronological timeline. Fleet is a self-hosted, local-first Go binary: the trail is stored locally in ~/.fleet/fleet.db and you query it with fleet log. The local store is the source of truth; if you register Fleet with the dashboard, it also syncs decision events to the control plane for cross-repo visibility — operational metadata, never your source code. This guide shows how to read, filter, and export it.

Before you start

Fleet installed and initialized (`curl -fsSL https://fleetctl.ai/install | sh`)
At least one agent that has run and published fabric events
Familiarity with the reactive chain events: pr_created, pr_needs_review, pr_approved, ticket_shipped
`jq` installed if you want to post-process the JSON export

Understand what gets recorded

Fleet's log layer (fleetlog) merges two streams into one timeline. The first is fabric decision events — the structured records agents publish at key moments, such as pr_created, pr_needs_review, pr_approved, pr_changes_requested, ci_pass, ci_fail, and ticket_shipped. The second is activity events — the operational record of agents starting, running, and stopping. Together they answer who did what, when, and why.

# Show the full unified timeline (most recent first):
fleet log

# The output interleaves fabric decision events and activity
# events in chronological order.

Filter the trail to a single agent

When you are investigating one agent's behavior — say a reviewer whose approval you want to verify — use --agent to scope the timeline to just its events. This is the fastest way to reconstruct exactly what one agent decided across a run.

# Everything the tech-lead reviewer did:
fleet log --agent tech-lead

# Combine with a time window:
fleet log --agent tech-lead --since 24h

Filter by event type to see only decisions

The --type flag narrows the timeline by kind. Use --type decision to drop the operational noise and see only the significant milestones — the fabric decision events like pr_approved and ticket_shipped. This is the view you want for an audit: the load-bearing choices, not every heartbeat.

# Only the decision-level milestones across the fleet:
fleet log --type decision

# Decisions in the last 30 days, e.g. for a monthly review:
fleet log --type decision --since 30d

Scope the window with --since

Audit questions are usually time-bounded: "what shipped this week?" or "what happened in the hour before that bad merge?" The --since flag accepts relative durations so you can frame the timeline tightly around the period you care about.

# Last hour (incident triage):
fleet log --since 1h

# Last 7 days, decisions only (weekly report):
fleet log --type decision --since 7d

Export the trail as JSON for compliance

For a compliance record or to feed the trail into an external system, use --json. You get the structured timeline as machine-readable JSON that you can archive, diff, or query with jq. Combine it with the other filters to export exactly the slice you need to retain.

# Export the last 90 days of decisions as JSON:
fleet log --type decision --since 90d --json > audit-q.json

# Pull just the pr_approved events with jq:
fleet log --type decision --json \
  | jq '.[] | select(.kind == "pr_approved")'

Cross-check an approval against the merge gate

The audit trail is the source of truth for release decisions. Because fleet agents share one GitHub identity, an approved label alone is not proof of review — Fleet's merge gate requires a real pr_approved fabric event from a reviewer. Use the log to confirm that event exists and was published before the merge, which is exactly the evidence an auditor wants.

# Confirm a pr_approved event exists for a PR before the merge:
fleet log --type decision --json \
  | jq '.[] | select(.kind == "pr_approved")'

# The release-manager gate reads this fabric event, not just the
# GitHub label — so the trail and the gate agree.

Common pitfalls

An `approved` label on a PR is not, by itself, an approval. Fleet agents share one GitHub identity, so the audit trail evidence is the `pr_approved` fabric event published by a reviewer — verify that event in the log, not just the label.
If an agent exits without publishing its expected fabric event, the timeline has a gap and a downstream stage may stall silently. When a stage seems stuck, check `fleet log` for the missing decision event rather than assuming the work completed.
`fleet log` reflects Fleet-managed activity. A Claude Code session you started by hand outside Fleet does not publish fabric events, so it will not appear in the trail. Keep audited work inside Fleet-managed agents.
The trail is stored locally in Fleet's database (`~/.fleet/fleet.db` by default). It is not replicated anywhere automatically — if you need long-term retention for compliance, schedule a periodic `fleet log --json` export and archive it yourself.
Relative `--since` windows are evaluated at query time. Two exports run minutes apart with the same `--since 24h` cover slightly different windows. For a fixed audit boundary, export once and keep that file rather than re-running the query.

When Fleet is the right tool

Fleet's audit trail is the right tool when an autonomous or semi-autonomous fleet is writing and merging code and you need a defensible record of every decision — which agent approved a PR, when it shipped, and what event chain led there. Self-hosted and local-first, the trail's source of truth is ~/.fleet/fleet.db on your own machine — your source code never goes to Fleet, which matters for teams that cannot hand their codebase to a third-party service. (A registered instance does sync decision events to the control-plane dashboard for cross-repo visibility; that is operational metadata, not source.)

It is less relevant if you run a single agent interactively and review everything by hand in real time — at that scale your own attention is the audit trail. The log earns its keep once decisions are happening faster than a human can watch them, or when you need to reconstruct what happened after the fact.