Decision history and verification

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 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:

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 and 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.