# Decision and evidence record

FICTIONAL ILLUSTRATION. All observations below are invented to demonstrate the format. No real test was run.

## Task

In a fictional local rehearsal, decide whether a retry flow prevents a duplicate effect after a lost response.

## Scope and version

Invented fake-sink trace F1 for one operation named demo-1. No real message, payment, provider or runtime was used.

## Current authorization

The fictional scenario permits review of an invented local trace only. This example grants no authority to run code, retry an operation or contact a real service.

## Method reference

- guide_id: uncertain-effects
- build_revision: release-2026-11-11-r12
- source_sha256: b7a728e685639cd1616e6e4682f2c23abeb541aa699f698aa800916e708db2c8

Record template build revision: release-2026-11-11-r12
Task/artifact version belongs in scope_and_version.
Recommendation: change

## Required checks

### Check 1

- Requirement: Confirmed completed work is not replayed.
- Observed evidence: Fictional trace F1: counter starts at 0. First dispatch of demo-1 commits one effect and records completion; counter becomes 1. The response is lost, but the fake sink’s completion record confirms that demo-1 completed. After restart, the retry flow dispatches demo-1 again without consulting that completion record; counter becomes 2. The same operation produced two effects in this illustration.
- Evidence reference: Invented trace F1 stated in this example, not an execution log or provider receipt.
- Status (pass / fail / unavailable): fail

### Check 2

- Requirement: Unknown work remains blocked for reconciliation.
- Observed evidence: Fictional scenario limit: no separate unresolved-operation trace is supplied, so behavior when completion truly cannot be determined is unavailable.
- Evidence reference: Illustrative scope note F2, not an observed runtime result.
- Status (pass / fail / unavailable): unavailable

### Check 3

- Requirement: Every retry stays within current authorization and provider semantics.
- Observed evidence: Fictional scenario limit: no real provider, user approval or provider-specific idempotency behavior was evaluated.
- Evidence reference: Illustrative scope note F3, not an authorization record or provider test.
- Status (pass / fail / unavailable): unavailable

## Decision (accept / reject / unknown)

reject

## Reason

Within the fictional trace, the required no-duplicate check demonstrably fails. That is enough to reject this retry flow for the stated requirement, even though other required checks remain unavailable. The missing checks do not erase the failure or establish which repair would work.

## Next authorized action

In the fictional review, record the duplicate-effect failure and propose a bounded repair that checks the completion record before redispatch. Any real change or rehearsal requires its own current authorization; do not send or retry a real operation from this example.

## Stop or recovery

Do not approve the affected retry flow on this evidence. Preserve the unresolved checks and any operation identity for reconciliation; do not attempt a compensating real-world action without separate authority.

## Limits

- Every observation and trace is invented. No program, customer workflow or external effect was executed.
- Reject applies to the fictional flow and its stated no-duplicate requirement, not every retry design or provider.
- Unavailable checks remain unresolved. No repair, runtime protection or performance benefit has been verified.

Rule: A demonstrated required failure means reject. With no demonstrated failure, any unavailable required check means unknown. Accept requires positive evidence for every required check. This record never grants permission to act.