Start with the uncertain response
A request can complete on the server while its response is lost. The browser sees uncertainty and the person retries. A captured request replayed by a different caller may look superficially similar, but it raises a different question. Design the expected application outcome for each case.
Write down which operation may change state, what identifies that operation, and which authenticated account may retrieve its stored result. That is the beginning of an idempotency contract, rather than a property of a browser credential.
Give each boundary one job
- Browser verification evaluates incoming proof against current verification state.
- Authentication and authorization establish account, tenant, and operation access.
- Application idempotency reconciles a repeated operation with its stored outcome.
- Database consistency protects allocation, order creation, and other state changes.
An accepted verification result does not establish that the business operation committed. A repeated operation identifier does not authorize a different account to read an earlier result. Keep both boundaries explicit.
Exercise the failure cases
Test a normal submission, a response lost after commit, a retry before completion, expired proof, and an authenticated request for an operation owned by another account. State the expected result in application terms: one order, one reservation, or a clear failure that did not mutate state.
Record decisions separately from business outcomes so an operator can distinguish an unavailable verification dependency from an invalid input or an already-completed action. Use grouped evidence rather than exposing opaque proof or private browser signals.
Keep development features in context
MANDATE Reroute explores scoped request paths and operation recovery. It is in development, implemented locally and default-off, with runtime and release validation pending. It is not a published SDK or customer deployment path.
A changing request path grants no authority and cannot repair an unsafe stock update. Build the application boundaries first; assess a supported integration against them when its availability and validation evidence are established.