Model-Change and Version-Pinning Brief
Published in full. No email, no sign-up.
AI Sales Engineering · v1.0 · Last verified 31 August 2026
When a buyer asks what happens if your model changes under them, the honest answer is that you cannot promise identical output, and you can promise written notice, regression testing against their own criteria, rollback, and a measured quality floor. This brief is how to say that and hold it.
For "what happens when your model changes under us", the objection buyers now arrive at armed with a clause checklist, and sellers usually meet with nothing.
It gets harder the closer you sit to a foundation model, and it does not go away, because version drift is a permanent property of building on someone else's model rather than a passing news event.
1. What is the buyer actually worried about? Four risks, four owners
Buyers compress these into one question. Separating them is most of the work, and it immediately marks you as someone who has thought about it.
| Risk | Who owns it | What it actually looks like |
|---|---|---|
| Provider deprecates a model | Your provider, then you | A model you depend on gets a sunset date, sometimes a short one |
| Silent quality drift | Your provider | Same endpoint, same version string, different behaviour |
| Your own changes | You | A prompt, retrieval or orchestration change alters output with no model change at all |
| Their data changes | The buyer | The index, the documents or the traffic shifts underneath a system tuned for the old shape |
Table: The four version-drift risks and who owns each one. Source: AI Sales Engineering practitioner template, v1.0, August 2026.
The fourth row is the one nobody raises and it wins you credibility, because it is the one where the buyer is the owner. Naming a risk that lands on them is what separates a partner from a vendor.
2. What can you pin, and what can you not?
Be straight here. A vendor claiming total immunity to model change is either self-hosting or lying, and their architect knows which.
- Where the provider offers version pinning, say which versions and for how long.
- Where they do not, say so and describe what you do instead.
- If you self-host, say so. It is a genuine differentiator and this is the moment it pays.
- Distinguish pinning the model from pinning the behaviour. Prompts, retrieval and orchestration are yours, and they move too. Buyers usually mean behaviour and ask about the model.
3. What should you commit to in writing?
Six things: change notification, regression testing, rollback, a quality floor, a behaviour change log, and exit terms. This is the page the champion forwards to their architect. Fill every row or delete it, because a blank row reads worse than an absent one.
| Commitment | What we do |
|---|---|
| Change notification | [N] days written notice before any change affecting output behaviour |
| Regression testing | Your eval suite re-run before promotion, results shared including failures, not just ours |
| Rollback | Previous version available for [N] days. Trigger: [who, how, how fast] |
| Quality floor | The measured eval score below which we will not promote a new version |
| Behaviour change log | Where changes are published and how you subscribe |
| Exit | On termination you receive [data, eval suite, configuration] in [format] within [N] days |
Table: The six commitments to fill in before this document leaves your laptop. Source: AI Sales Engineering practitioner template, v1.0, August 2026.
The quality floor is the strongest row in the table. Committing to a measured floor on their criteria, rather than to a model version, is both more honest and easier to hold. It is also the row most vendors cannot fill, which is exactly why it wins.
4. How does this become a reason to buy?
This is the strongest build-vs-buy argument available and almost nobody makes it.
A buyer building directly on the raw API owns every one of these problems alone. No notice period, no regression suite, no rollback, no quality floor, and nobody to call. They will discover a behaviour change from a user complaint.
Say it plainly: "You can absolutely build this on the API. The part you would be taking on is not the build, it is owning model change forever, on your own, with no notice." That reframes the whole conversation without disparaging the option.
5. What should you refuse?
A guarantee that output never changes. You cannot hold it, and a serious architect is listening for whether you will claim it. Offer the measured quality floor instead and explain the difference in one sentence:
We cannot promise identical output. We can promise you will know before it changes, that we will have tested it against your criteria first, and that you can go back.
Refusing well here buys more trust than any commitment you could make.
6. What should you ask them?
Three questions, and they turn the objection into discovery rather than defence:
- What is your change-management process for a dependency that updates itself?
- Who signs off a version change on your side, and what would they need to see?
- Do you have an evaluation suite we would be regression-testing against, or should building one be part of this engagement?
That last question converts an objection into scope. It is the natural bridge into the Eval-Framework Template, and it is the most useful thing in this brief.
Before you use this
Every bracketed number is a commitment your business has to honour. Get the notice period and the rollback window agreed internally before this document leaves your laptop, because the champion will forward it to procurement and it will end up quoted back at you in a contract.
Sources, and what is not verified here
Last verified: 31 August 2026.
What this is: a practitioner template written by Lewis Crook from enterprise AI deals, not a survey and not a research paper. The risk taxonomy, the commitment table and the refusal line are judgement calls, and they are stated as judgement rather than measurement.
Not verified here: no vendor's actual notice periods, rollback windows or pinning terms are quoted. Check your own provider's published deprecation policy before you fill a single bracket.
Corrections welcome, and they get credited.
Use this on a live deal this week, then tell the room what happened. Not that it looked useful. What you changed, what the buyer did, whether it worked. If it didn't work, that's the more valuable post.
Get the next one when it ships, plus the benchmark at 200 responses.