Practical guide

Investigate an unexpected result without compounding it

Last materially reviewed 2026-09-27

Quick answerPause dependent changes, preserve the evidence and isolate the failing stage.
What to know

Identify the stage

Was the wrong input exported, was the vendor output incomplete, did the join fail, or did reimport change an unintended field? Write the symptom before changing tools. A mismatch at one stage does not prove that the verification service is inaccurate.

What to know

Protect the source

Stop additional write-backs until the intended and observed changes are understood. Preserve the relevant snapshot and logs under appropriate access controls. Do not repeatedly upload the same private data or send test messages simply to see what happens.

What to know

An incident record

Record the known facts, uncertain outcomes and next bounded check. If the previous write may have happened, treat it as potentially consumed instead of blindly replaying. Use the documented recovery route only when authorised, and verify the resulting state rather than treating a successful button click as resolution.

What to know

Put it into practice

Use an incident table with symptom, affected stage, known evidence, uncertain outcomes and one next bounded check. A fictional operator sees fewer returned rows than expected. Before uploading again, they discover that the downloaded file was filtered to one result category. The correct repair is to obtain and reconcile the intended output through the authorised route, not to pay for another verification batch. In a different case, the result is complete but the join duplicates a key; that is a local transformation issue. Keeping stages separate prevents a broad and costly “start over” response. Preserve the original artifacts and document any actual changes. If a production write may already have happened, establish its state before replaying. The goal is to restore a known, explainable workflow, not simply to make the interface stop displaying an error.

Continue when useful

Next: Prepare the recovery record before a bulk change

A recovery plan needs an exact prior state and an authorised restoration path, not just a reassuring filename.

Open Prepare the recovery record before a bulk change →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Bouncer API introduction — Merchant documentation · docs.usebouncer.com · Merchant-controlled · checked 2026-09-27
  2. Bouncer result FAQ — Merchant documentation · usebouncer.com · Merchant-controlled · checked 2026-09-27