Evidence · bounded receipt proof

Duplicate Agent Writes: What Receipts Can Detect | Reelier

Evidence state: explained against released reelier@0.32.0 on 2026-08-12.

▸ Direct answer

Reelier 0.32.0 reports identical same-run write keys: executed writes record an unsalted key derived from tool, server, and filled arguments, and duplicateOf identifies a matching key seen earlier in that run. It does not prevent dispatch or provider effects, and it does not detect or deduplicate across runs.

Evidence note

The released approval implementation and runner contract support the same-run key and duplicateOf fields. They expose reporting, not a prevention mechanism.

Same-run identity

For an executed write, the run record can carry an unsalted key derived from the tool, server, and filled arguments. Matching that key against an earlier step identifies repeated input inside the same run.

The receipt annotation

When a prior match exists, duplicateOf points to the earlier same-run step. That makes the repetition reviewable in the receipt.

Reporting is not prevention

The annotation does not stop dispatch or reverse provider effects. Because the comparison is within one run, it is not a cross-run idempotency store and cannot deduplicate retries across separate executions.

Non-claims

This does not prove that an action was safe or semantically correct.

This does not prove that every write was observed or receipted.

Falsifier

A Reelier 0.32.0 executed write with matching tool, server, and filled arguments that lacks the earlier same-run duplicate report would falsify this claim.