# Decision history and verification

Inspect the exact action, policy, and outcome, then verify the recorded chain.

Updated: 2026-09-22

Canonical: https://docs.kastra.ai/evidence/decisions

## Find the action

Open Activity in the console and select the correct workspace, environment, source, and time range. Correlate by decision, request, or tool-use ID when available. Use the separate [governance audit log](https://docs.kastra.ai/evidence/audit) to investigate policy or administrative changes.

Review the tool and target, matched rule, policy revision, outcome, and any checkpoint resolution. Separate shadow decisions and billing-degraded decisions from enforced blocks. An expiry is a policy timeout result, not a human approval or denial.

## Explain one decision to a reviewer

Record who or what supplied the action, the integration that checked it, the target and available attributes, the rule and revision used, and the final permission. For a HOLD, include the checkpoint and human or timeout resolution. Then check the actual tool result separately: an ALLOW is permission to proceed, not proof that the operation succeeded.

## Verify recorded integrity

Use the console or operator verification command:

```sh
kastra evidence verify
```

Decision fingerprints and linked sequence records are designed to expose changes within the recorded chain. Sequencing is asynchronous; scope and completeness matter. Record the verification range and any reported gaps or failures.

## What verification does not prove

A valid chain does not prove that every action on a machine was captured, that every detected risk was prevented, or that a compliance framework is satisfied. The service's keys and recorded scope are part of the trust boundary. Missing hook events, cached decisions, and fail-open telemetry require separate investigation.

## Export responsibly

CSV/JSON decision exports and framework evidence packs are different features with different entitlements. Preserve provenance and masking in exported records. Read [evidence packs](https://docs.kastra.ai/evidence/exports) and [data handling](https://docs.kastra.ai/evidence/data-handling).

## Read verification classifications

Read `verification_depth`, `walk_complete`, `coverage`, `break_counts` and any checkpoint used by the verifier. A structural check does not establish that every payload was rehashed. A historical precision mismatch is classified only when an exact verified witness supports it; an unexplained hash mismatch stays unexplained. Do not silently subtract unexplained breaks from an integrity result.

Stored pending decisions use `PENDING_REVIEW`, even though the evaluation response calls the workflow `HOLD`. Related-session activity is a bounded correlation view, not proof of parent/child execution.