What a request fingerprint proves

What it is

A stable digest computed from the request — the identity, the Ability, and the inputs. The same request produces the same fingerprint; any change to the inputs produces a different one.

It appears on the approval, on the activity record, and in exported evidence, which is what lets you line those three up afterwards.

What it proves

• That an approval and an execution are the same request. This is its main job.
• That two records refer to the same call, across the approval queue, the timeline, and an export.
• That a retry is or is not identical to what was reviewed.

What it does not prove

• It is not a signature of the outcome. That is the audit chain’s job.
• It does not tell you whether the request was reasonable. Only a person reading the input can decide that.
• It is not a substitute for the redacted preview. Two requests with different fingerprints may look identical to a human, and that is exactly when reading the preview matters.

Using it in practice

When an agent reports “approval not found”, compare the fingerprint on the approval you granted with the one on the new request. If they differ, the agent changed its inputs between the original request and the retry — which is the answer, and it is not a fault in the plugin.

Related guides

• ApprovalApproval not found

  The agent retried but no approval matched. Almost always the inputs changed, the approval expired, or the retry came from a different identity.

• ApprovalHow an approval works

  Approvals are input-bound, single-use and time-limited. Why an approval is a decision about one request rather than a standing permission.

• EvidenceRead the request evidence

  Identity, Ability, context, decision and outcome — the five things every evidence record carries, and how to read one without needing the agent’s source code.