A tool trace has a request and a result

Requested is not executed

An application log often has a line for the tool name the model requested and a later line for what the application did. The first line is a request. The second is the decision and, if the tool ran, the status the tool returned. A request with no execution line means the tool did not run.

The model may then describe a result in the reply. That description is not the tool’s status line. If they disagree, cite the status line.

Arguments on the trace are what was submitted

The trace shows the arguments the application received from the model, not a wish written in the reply. If a field was replaced or dropped before the call, the executed line should say which value was used. Write the executed values. Do not reconstruct them from the reply.

If an argument may contain a secret or a customer record, do not copy it into the ticket. Write the field name and “withheld,” plus the decision and the status.

What to file

File the request id, the tool name, whether it was denied or executed, the tool status if it ran, and the time of each line. File the model’s sentence only as model text, and only when it does not carry a secret. A missing execution line is a fact: write “not executed.”

Worked case: a booking the trace denied

The model requests book_room for room B. The next log line is decision denied, reason “room id was not on the form.” The reply still says the room is booked. A reader who only has the reply would mark the board as changed.

The note cites request req-442, tool book_room, decision denied, and the reason string from the application. It quotes the reply as model text that disagrees with the trace. The board is unchanged. No one re-runs the tool from the reply.

request: req-442
tool requested: book_room  time: 2026-11-03T15:04:01Z
decision: denied  reason: room id was not on the form
tool status: not executed
model text: claims the room is booked
cite: the denied line