Pulse evidence & audit

Every Pulse finding must show its work. A finding is not just a headline — it carries the agent's investigation narrative, a confidence score, the exact resources involved (each with a console link), and a step-by-step audit trail of every query the agent ran, including the ones that failed. This page covers that evidence trail; for the findings lifecycle and savings model, see Pulse — findings & savings.

How it works

The audit trail. While investigating, the agent records each step in order: the tool it invoked, the exact query or arguments, whether the call succeeded, a preview of the returned rows, the row count, and the duration. Failed steps are kept, and the recovery that follows one is marked as a self-correction — so you see the real investigation, not a cleaned-up version.

Audit step field	Meaning
seq	Order of the step within the investigation
step_kind	query, tool, or reasoning
tool_name / title	Data source invoked and a short label
query_sql	The exact query/arguments executed
status / error_message	success or error, with the error text
result_preview / row_count / duration_ms	What came back, and how fast
is_self_correction	This step recovered from a prior failure
rerunnable	The step can be re-executed live from the UI

Grounded resources. Findings list the specific resources they concern, and each resource links to its own cloud console page. For FinOps findings detected from August 2026 onward, each flagged resource is also recorded with its measured size and real monthly cost; older findings may carry only the per-finding estimate. Savings totals sum each unique resource once across all active findings — a disk counts once no matter how many findings mention it. Findings with no grounded resources yet fall back to the agent's per-finding estimate, counted once per duplicate group.

Duplicate clustering. Re-scans rediscover the same issues. Semantically similar findings share a group, so the same underlying issue is counted once in dashboards and savings — the group shows its highest severity and its savings are never double-counted. Later duplicates are marked confirmed and hidden from the default findings list; they remain visible as the finding's group history and via the status=confirmed filter. Resolution operates at the cluster level too: when a fix is verified (via the resolution wizard or reinvestigation), the whole cluster is marked resolved, not just the one sighting.

Using it

Endpoint	Purpose
GET /api/pulse/findings/{id}	Full detail: reasoning, resources with links, linked recommendation, group history
GET /api/pulse/findings/{id}/audit	Ordered audit steps plus a summary (total queries, failures, self-corrections)
POST /api/pulse/findings/{id}/audit/{seq}/run	Re-execute one re-runnable step live (read-only, byte-capped)
POST /api/pulse/findings/{id}/reinvestigate	Dispatch a fresh check of the finding's current state
POST /api/pulse/recommendations/{id}/reinvestigate	Same, targeted at a recommendation
POST /api/pulse/findings/{id}/resolution-plan	Get-or-create the guided resolution plan for the finding's cluster
GET /api/pulse/plans/{id}	Plan status, steps, and verification state
POST /api/pulse/plans/{id}/steps/{seq}/verify	Run a step's read-only verification check
POST /api/pulse/plans/{id}/steps/{seq}/confirm	Mark a step done manually
POST /api/pulse/plans/{id}/steps/{seq}/skip	Skip a step with a recorded reason
POST /api/pulse/plans/{id}/finalize	Run the final detection re-run

Wizard activity is part of the same record: step verifications, manual confirmations, and skips (with their reasons) are appended to the finding's audit trail and to the organization's immutable audit log.

• Finding detail includes the finding itself, the agent that produced it and its run-level reasoning, the linked recommendation (rationale, action type, savings, effort, priority), the per-resource list, and — when the finding belongs to a group — the earlier sightings with their agent, status, and timestamps.
• Reinvestigation re-checks the resource as it is now: the agent verifies whether the issue is still present, updates the description and severity, or marks it resolved. The finding records when it was last reinvestigated, and you are notified when the run completes.
• In the web UI, open any finding from the Pulse dashboard to see the evidence trail; steps marked re-runnable have a run control that executes the recorded query live.

Configuration

The findings list (GET /api/pulse/findings) accepts:

Parameter	Values
domain	finops, security, sre
severity	critical, high, medium, low, info
status	Lifecycle statuses, or confirmed to see clustered duplicates
sort_by	severity (default), date, savings, effort, status
sort_dir	asc or desc

Troubleshooting

Symptom	Cause / fix
A finding shows no audit steps	The trail is captured at investigation time; findings recorded before capture was enabled have none.
"This step is not re-runnable."	Only steps flagged re-runnable can be executed live; others are record-only.
Two similar findings both appear in the list	Clustering is semantic and conservative. Savings are still deduplicated per resource, so totals are not inflated.
A known duplicate is "missing"	Confirmed duplicates are hidden by default; query with status=confirmed or open the primary finding's group history.

Related

• Pulse — findings & savings
• Pulse agents & schedules
• Morning Report