Green transport can sit inside a broken journey.
An API can accept a syntactically valid request while the wrong identifier, stale field, incomplete consent state or unexpected data type sends the customer down the wrong path. The transport layer did its job. The business outcome still failed.
I troubleshoot the chain, not the tool.
I start with the expected business behaviour and one known user or record. Then I move layer by layer until expected and actual diverge. That keeps the investigation evidence-based and prevents a tool, platform or team from becoming the default suspect.
Identity is a common hidden failure.
A backend event can land successfully while contact information, attributes or consent live on a different profile. From the API's perspective, everything worked. From the customer's perspective, nothing did.
That is why I treat identity separately from data ownership. “Who is this customer?” and “which system owns this fact?” are different questions, and both need explicit answers.
What I want before calling a fix done.
The practical rule.
Do not stop at “the API returned success,” “the file landed,” or “the campaign sent.” Those are checkpoints. The outcome is the intended customer behaviour, reached through a chain the team can observe and operate.
Worked example · October 9, 2026
A concrete partial-response test.
The Waypoint mock adapter returns HTTP 200 with one accepted event and one record error. The test expects a partial result and exactly one request. It does not retry the entire accepted batch. Separately, the policy model traces an accepted search through identity, consent and the matching booking exit. Transport acceptance and customer eligibility are distinct checks.
Fictional local exercise; no live vendor or client outcome is asserted.