# Original retry-trace review

This is an invented 11-event fixture, not customer work, a native Dot run or an authenticated target receipt. The synthetic requirement is one exported artifact per declared logical operation. The event identifiers, target identifiers, keys and payload digests are synthetic. A repeated observation of the same scoped artifact should count once. An operation with no effect evidence remains unknown.

The offline review found five evidence patterns:

| Pattern | Evidence | Implication |
|---|---|---|
| Two distinct artifacts reported for export-a | e01–e05; artifact-01 and artifact-02 | The trace reports two effects. Confirm both in authoritative target records before treating this as an actual duplicate. |
| A different key on export-a's second attempt | e01–e05; key-a1 and key-a2 | The attempts do not share a scoped key. A timeout did not establish that the first attempt failed. |
| Unknown outcome for export-b | e06, a timeout without any effect observation | No claim of success, failure or safe retry is justified by the supplied evidence. |
| One key associated with different payload digests | e07–e11; shared-key, payload c versus d | These requests do not represent the same declared payload. Inspect the actual target contract and retention policy. |
| One scoped key shared by export-c and export-d | e07–e11 | Clarify logical intent before assuming cross-operation deduplication. |

e08 and e09 both report artifact-03. The review counts one effect for export-c, not two. Arrival order is deliberately untrusted: e05 records an earlier attempt's effect after e04. Reversing the array preserves conclusions and evidence identities, but changes the digest of the canonical input document.

Proposed review steps: retain the unresolved operation and its original key; reconcile authoritative target records using the original operation identity; verify same-intent parameters, key scope and retention semantics before any operator decides what to do. This packet grants no permission to send, write, retry, deploy or pay. Neither a stable key nor this report guarantees exactly-once behavior.

Run the original example offline:

```sh
python3 reconcile.py trace.json
python3 -m unittest discover -s . -p 'test_*.py' -v
```

The helper accepts one JSON object with only an `events` array, 1–300 events, at most 30 operations, and a 100 KiB CLI input limit. Every event has exactly event_id, operation_id, attempt_id, target_id, kind, idempotency_key, payload_sha256, effect_id. Identifiers are redacted tokens of 1–64 ASCII letters/digits/underscore/dot/hyphen; keys may be null; digests are 64 lowercase hexadecimal characters. `kind` is attempt, timeout or effect. Only effect records carry a non-null effect_id. Unique event identities and consistent target/key/payload within a declared attempt are required. Output quotes supplied event IDs, not verified real-world execution.

No URLs, network, imports of buyer code, database, credentials or account writes are used. The tool cannot validate trace completeness, authenticity, clocks, logical grouping, provider idempotency behavior or native Dots compatibility. Do not submit private data or secrets, even encoded into allowed fields.

Primary research: [OpenAI Dots scheduled tasks](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot), [AWS retry semantics and ambiguous outcomes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/), [Stripe's specific key/parameter/retention contract](https://docs.stripe.com/api/idempotent_requests). These support the review questions; they do not establish buyer demand or make one provider's contract universal.