Represent Retries and Unknown Outcomes Without Erasing Risk
How to preserve the difference between a policy decision, an attempted execution, a confirmed result, and an outcome that is still unknown.
Separate decision from execution
A policy permit answers whether the application may attempt an action under the supplied context. It does not confirm that the tool call succeeded. Record policy disposition and execution status as separate fields so a timeout cannot be mistaken for a denial or a success.
The same separation applies to human review. A reviewer decision can provide evidence for policy to permit another attempt, but it cannot retroactively prove what a previous attempt did.
Treat the unknown state as real
When the caller loses the response after sending an action, the system may not know whether the side effect happened. Repeating the call without checking can duplicate an irreversible or externally visible action.
Preserve the request identity, attempt number, destination evidence, and resolution state. Route the unresolved case according to policy instead of converting uncertainty into a convenient success or failure.
Make retry authority explicit
A retry is a new proposed action with history. The policy boundary should receive the previous disposition, attempt evidence, and any change in identity or destination context.
The public evidence page documents the website's bounded failure model. Your application must still define idempotency, reconciliation, escalation, and operator recovery for its own tools.
What this page does not establish
- A 5D decision does not prove that a downstream system executed the action or reached the intended state.
- Retry safety depends on the side effect, idempotency design, and evidence returned by the destination system.
- An unknown outcome must stay unknown until independent evidence resolves it.