Evidence design
Rendering is not instruction-following
A callback proves that something requested a resource. It does not prove that an agent understood the response, followed its instructions, or performed an external action.
The core rule: assign a different observable signal to every claim in the chain.
Four behaviors that look similar in a screenshot
| Signal | What it supports | What it does not establish |
|---|---|---|
| Image callback | A renderer or preview system requested a resource. | Content consumption or reasoning. |
| Plain-link callback | A crawler or agent followed a visible URL. | Execution of an instruction inside the response. |
| Valid challenge response | The response was consumed and a required transformation was completed. | Which product identity performed the request without correlation. |
| Native product mutation | An external action persisted in the connected application. | Its causal source without a controlled timeline. |
Chronology matters more than volume
Creation, editing, sharing, preview generation, and later AI retrieval can all produce requests. A clean test records the pre-state, assigns a fresh identifier, timestamps the victim action, and separates creation-time callbacks from later activity.
Pre-register the interpretation
Before running the test, write down what each result means. A render-only hit remains a render result. A failed challenge remains evidence of retrieval only. This prevents an exciting log entry from expanding the claim after the fact.
Native state closes the loop
For connected-agent testing, server telemetry should be paired with the product’s own Activity records, version history, ownership state, and persistent data. The webhook supports the chronology; the native application establishes the action.