Signals considered

The accusation uses intent words such as "behind our back" without providing comparable samples
The client describes a change in output quality, not a failed call
The team has no mapping between model identifiers and request logs yet

The message arrived like this. Someone posted two outputs, said the same prompt produced different results last week and this week, then added: “has your gateway swapped the model behind our back?”

The most easily missed part of that sentence is “behind our back”. It moves the discussion from “why did the output change” straight to “are you lying to us”. In practice the answers to those two questions usually sit on different planes. Output changes, and most of the time nobody is hiding anything. Model identifiers simply move more easily than most people assume.

The review process below is a composite demonstration, not a record of real product operations, and it does not correspond to a named client, an actual incident or a closed deal. It shows how to turn an emotionally charged technical accusation into a record you can keep working from.

What the first hour was spent on

The easiest mistake in the first hour is replying immediately with “we never changed the model”.

The problem is not that it might be untrue. The problem is that it cannot be proven from the information available at that moment. At this point the team usually has a chat log and nothing else: no model-identifier logs, no request-level sampling, no complete side-by-side of the client’s original prompt and both outputs. Any denial issued from that position is a stance, not evidence.

A steadier approach is to spend the first hour collecting evidence: archive both outputs together with timestamps, the model identifier and the request parameters; confirm which endpoint and auth path the client used; pull the model configuration change history for that period. The act of gathering evidence is itself visible to the client, and “we are checking” lands very differently from “nothing happened”.

Separate the nouns from the verbs in the accusation

An accusation usually mixes two ingredients. One is a checkable factual claim, such as “the same prompt produced different output”. The other is a judgement of intent, such as “you deliberately hid this from us”. The two need separate records.

Factual claims can be checked. Intent cannot be checked, only influenced indirectly through later behaviour. Handling them as one produces the classic communication failure: you answer the fact with evidence and the client thinks you dodged the intent, or you explain intent while the fact that should have been settled stays open.

In a usable record the two occupy different columns. The fact column holds time, model identifier, parameters and samples. The intent column holds one line: “client believes there was deliberate concealment; currently no evidence supports or rules this out.” That second sentence reads awkwardly. Its value is that it marks what cannot be settled now as explicitly unsettled instead of pretending otherwise.

Model alias rotation: the normal behaviour that looks most like a swap

If you had to name one most likely cause, it would be the model alias.

Most providers split model identifiers into two layers. One is the undated alias, written like gpt-4o. The other is the dated snapshot, the kind carrying a -2024-08-06 suffix. The catch is that the alias points at a snapshot that can rotate. When a provider repoints the alias at a newer snapshot, not one line of your code changes, yet a different model is running the inference.

There is a public record of this. A provider announced that on a given date the default version would move to a newer snapshot, and that anyone wanting to stay on the older version had to specify the older snapshot identifier explicitly. In other words, doing nothing meant being upgraded.

An earlier study provides quantified evidence. Chen et al. compared two snapshots several months apart in 2023 (arXiv:2307.09009), running identical prompts against the same benchmarks: pass rate on code-generation tasks fell from 52 percent to 10 percent, and format compliance on math tasks requiring chain-of-thought fell from 84 percent to 51 percent. That is not minor variation, and at the time nothing was announced. Only teams maintaining their own behavioural evaluations noticed.

So when a client says last week differed from this week, one explanation must be ruled out first: their prompts are running against an alias that has already rotated. It belongs at the front of the queue because if it holds, the nature of the problem shifts from “the reseller concealed something” to “the model identifier was never pinned”. Those two land very differently on a brand.

Upstream substitution and deprecation: written down, rarely read

The second possibility comes from the upstream deprecation process.

Model snapshots get retired, and retirement comes with a substitute model. This is usually documented on a public deprecations page with shutdown dates and replacements. The problem is that the audience for that page is developers, while the people who feel the change are on the business side. Between them sits an information handoff that often belongs to nobody.

Some providers attach a deprecation notice to responses from models near end of life, in the form of a response header or a metadata field. The trait that matters: it is not an error. It does not interrupt the call, and it does not show up in business-side monitoring. Unless someone deliberately records response headers, it may as well not exist.

For brand-risk handling, the value of this layer is direction of attribution: the change comes from upstream lifecycle management, not from an action you took. You still own the communication, but the ownership takes a different form. Not denial, explanation.

Your own fallback config: the most awkward possibility

The third one is hardest to say out loud. It genuinely was your configuration, not out of concealment, but out of safety netting.

Many gateways switch to a backup model by a preset order when the primary is overloaded or rate limited. The design is correct; without it, clients would get raw errors whenever the provider hiccups. The side effect is that when fallback fires, the client still receives a successful response, just produced by a different model, and the response body may not carry a marker saying so.

The symptom is then exactly this: quality drops, no error is raised, and the client can only infer it from the difference in results. Outwardly this closely resembles a swap. In motive it is the opposite.

Checking this layer means reading your own fallback logs, not the provider status page. If fallback triggers exist inside the accusation window, the right move is to present those records alongside the trigger reason, and then discuss a marking policy so that fallback becomes visible in responses. That is more credible than repeatedly assuring clients that nothing gets swapped, because it acknowledges the mechanism exists.

Silence and clarification do not cost the same

What makes brand risk distinctive is the response window. Accusations travel faster than internal verification, and silence in a group is read as admission.

Clarifying carries its own cost, though. If your statement reaches beyond what you can prove, a later reversal costs more trust than the first incident did. That is the real trade-off here: speaking too early and speaking too late fail in different directions, and both are hard to undo.

A steadier middle line promises only what you can deliver: name the fields you are checking, give the time of the next update, and do not pre-judge motive. It does not sound forceful. Its advantage is that every sentence holds.

Replace “here is our conclusion” with “here is our scope”

Every action above converges on one thing: before verification finishes, what you can say publicly is scope, not conclusion.

Concretely, scope covers three items - which time window is being checked, which model identifiers are being compared, and what can and cannot be confirmed so far. Stating scope swaps “are you lying to me” for “we are checking the same table”, and the second one can move forward.

Tools have a limited place in this process. Across the Telegram groups a user deliberately connects and is authorised to access, TOP Prospect preserves the original wording, timing and surrounding context, and surfaces a candidate Signal awaiting human review, so the exact moment the words “behind our back” appeared is not blurred. What it does not do is equally clear: whether the model identifiers line up, whether fallback fired, and what the official line should be are still checked and decided by people.

One boundary: this piece covers only the verification order and communication line after an accusation lands. It does not cover the engineering of model version management, nor whether to change upstream provider afterwards. Those are different problems and deserve separate treatment.

Market and risk discussion is supporting evidence

Top Prospect is primarily a Telegram lead-generation product. Market and risk discussion can add context to a candidate lead, but it does not become a verified incident, trend, or sales opportunity automatically.

Review the product workflow and boundaries

Someone in the client group said "your gateway swapped models behind our back"