Durable requests and simulation boundaries

Question

Can an accepted research request survive a closed conversation window without being duplicated after an uncertain response or restart?

Evaluation method

1. Use a controlled, isolated simulation dataset and an explicit permitted mode.
2. Persist request intent before sending; retain the same request identity for a retry or receipt lookup.
3. Close the client or restart the worker after acceptance; inspect the durable receipt before permitting further execution.
4. Compare request, result and receipt identities across consumer and producer records.
5. Test invalid authentication, disallowed LIVE mode and duplicate requests; verify that operational ledgers are not changed by simulation.

Observed scope

Local engineering checks include authenticated research, restart recovery, receipt reconciliation and isolated PAPER/SHADOW outcomes. Simulation may produce NO_TRADE because inputs or strategy conditions do not permit execution. A recorded decision is not proof of an order fill, a market advantage or a financial return.

Limitations

This is not an external audit. Dataset freshness, real exchange conditions, slippage and operational failure modes require separate assessment. No private trade records, keys, raw receipts or strategy source are published. LIVE controls and risk gates are not relaxed for demonstrations.