--- title: "Tool Calls, Execution and Signed Logs | Witnessability" description: "See why a tool call, a signed execution log and an observed external effect support different claims, and what additional evidence can connect them." canonical: "https://witnessability.io/guides/tool-call-vs-execution/" representation: "Website reading format; consult linked publications for their exact status and terms." --- [Witnessability](https://witnessability.io/) / Guide / Execution evidence # A tool call is not yet an execution finding A request, an execution record and an observed effect answer different questions. To understand an AI agent or software workflow, identify the exact boundary behind each piece of evidence. Witnessability editorial explanation ยท 30 October 2026\ Prepared with AI assistance. [Authorship and responsibility](https://witnessability.io/about/#authorship).\ Read the linked publications for their exact definitions and status. ## What crossed the observed boundary? Imagine an assistant asked to pay an invoice. It creates a payment request and sends it through a tool gateway. A gateway record may establish that this exact request crossed an invocation boundary. It does not, by that observation alone, establish that the payment service performed the requested operation. An authorization concerns what was permitted under its rules. An intention concerns what was planned or decided. Neither supplies the missing execution observation. Retries and idempotent processing also mean that an intention, request attempt and execution need not have a one-to-one relationship. A shared identifier helps refer to them but does not by itself prove their relationship. ## What does a signed log add? Suppose the operator signs a log entry that says payment complete. Signature verification can establish the relevant relationship between the bytes and the key, under the verification assumptions. It does not supply an observation of the payment network. If the operator did not observe that outcome, signing the assertion leaves that gap in place. Registering the statement with a transparency service can support a claim about registration under that service's policy. This can be useful for accountability and later inspection. It does not turn the registered statement into evidence of every event it describes. Likewise, authentic records do not establish that every relevant record was delivered. ## What could support the effect? A payment-network record may provide an observation from a boundary capable of seeing the transfer. Its evidentiary force depends on the source, the applicable control assumptions and a validated connection to the exact action claimed. Matching an amount and a nearby timestamp is not the same as establishing that connection. The claim still needs a scope. A transfer observed at a particular time is not automatically final or irreversible. It also does not establish delivery of the goods or satisfaction of the customer's goal. Each broader conclusion requires the evidence and premises relevant to it. ## Direct observation is not the only route Sometimes the record constitutes the precise action: for example, issuance of a signed order where the applicable rules make that issuance the order. The conclusion depends on those rules and any authority or acceptance conditions. It establishes the order, not that someone carried it out. A verified proof can also establish a specific predicate under its proof-system and verifier assumptions. That predicate must match the claim. A computation proof does not automatically show that its inputs match outside facts or that a physical or financial effect followed. ## Write a report that preserves the useful result A useful report might say: invocation supported by the gateway record; execution unsupported by the evidence evaluated; transfer observed in a separately identified network record, subject to the stated binding and finality assumptions. Each finding names its own grounds. This gives an investigator a next question without inflating the result into a claim about the entire workflow. ## Sources and next steps - [CBEE revision 02](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/) - [CBEE reading copy: evidence bases](https://github.com/Witnessability/cbee-spec/blob/main/review/editor-copy.md#bases) - [CBEE reading copy: when stronger claims become supportable](https://github.com/Witnessability/cbee-spec/blob/main/review/editor-copy.md#constructive) ## What this does not claim This is an illustrative payment scenario, not a result from a deployed payment service or an interoperability test. It explains evidence boundaries and does not prescribe a universal logging architecture or guarantee that an action can be determined later.