You Pinned the Version, Not the Terms

1. The claim

Ask an engineer what version of a library they are on and you get an exact answer in about four seconds. Ask what happens to their system if the vendor is acquired, or what their log retention will be in six weeks, and you get a pause.

Both are properties of a dependency. Only one of them has tooling.

The claim: the non-code surface of a dependency changes more often than its code, breaks things more expensively, and is the only part of your supply chain with no review process attached to it.

2. What a lockfile actually covers

Worth drawing, because the gap is easy to state and hard to feel.

3. Three ways it breaks, from one fortnight

These happened within about two weeks of each other in August 2026. I am not claiming that density is normal. I am using it because three distinct failure modes turned up close enough together to compare.

3.1. Supply ends for reasons that have nothing to do with you

SpaceX completed its acquisition of Cursor on 14 August 2026. OpenAI then notified SpaceX that it intended to wind down the contract supplying OpenAI models to Cursor, with a proposed shutoff of 12 November, invoking a clause that gives it a limited window to end the agreement after a change of ownership. OpenAI’s stated reason was that it could not be confident the new owner would use the technology within its terms of service. Future models were named as excluded too.

Now take the position of a team that had built on Cursor. They ran no bad code, breached nothing, and shipped no regression. Their model supply was withdrawn because of who bought their vendor, under a clause in a contract they were never party to and have never read.

The mitigations that survived are worth noting because they are the shape of the general answer: users could still bring their own OpenAI API keys, and access through IDE extensions continued. What survived was the path where the customer held the relationship directly.

3.2. The thing goes away and the migration is your problem

The Assistants API shut down on 26 August 2026. Calls to /v1/assistants, /v1/threads and /v1/threads/runs stopped working. The replacement is the Responses API with Conversations for history, and the mapping is clean enough on paper.

The sentence that costs a sprint is that OpenAI said it would not provide an automated tool for migrating Threads to Conversations. So if you wanted your users’ conversation history to survive, the work was yours: iterate every thread through the old API before the deadline, convert each message into the new item format, recreate the conversations.

That is a data migration with a hard external deadline, discovered by reading a migration guide. It has the shape of an incident and it was scheduled months in advance, which means the only thing standing between a team and a bad fortnight was whether somebody read the right page.

3.3. A setting you already configured quietly changes meaning

This is the subtlest one and the one I would bet most teams miss.

On 27 August 2026 GitHub announced that from 1 October, checks, workflow runs and statuses would be governed by the same retention setting that already controls Actions artifacts and logs, with a default of 90 days. Until then, those objects were kept for over 400 days regardless of what that setting said.

Nothing in your repository changes. No API is removed. No version moves. A value you set at some point, for a reason about artifact storage, silently acquires authority over a different class of data, and history you assumed you had begins expiring. If you have a compliance obligation, an audit programme or an incident review practice that assumed a year of workflow history, the obligation did not change and your ability to meet it did.

4. Why the tooling never arrived

Code has properties that make it easy to govern, and terms have none of them.

Code is machine readable, addressable by version, diffable, and it lives in a place your CI already looks. A change to it is an event with a shape, so we built lockfiles, renovate bots and required reviews on top of that shape.

Terms are prose on a web page, unversioned, with no diff, no feed and no identifier. There is no terms.lock. Nobody can subscribe to the semantic content of a settings page. The absence of tooling follows from the artefact having no handles, and that is why fifteen years of supply chain security work has produced excellent answers about what code you are running and almost nothing about what you are permitted to keep running.

5. What to do, in ascending order of effort

Write down what you would do if each major vendor stopped selling to you tomorrow. Not a migration plan. One paragraph per vendor, listing what breaks and what the fallback is even if the fallback is “we would be down for a week”. Most teams have never written the sentence and discover during the incident that there is no answer.

Put the changelogs somewhere a human reads them. Every vendor in your critical path publishes one. Route them to a channel and give one person twenty minutes a week. Every example in Section 3 was announced in advance in public. The failure is that nobody was assigned to look.

Own the relationship where it is cheap to. The Cursor customers who kept working were the ones holding their own API key. A direct account with the party that actually supplies the capability is a different exposure from a resold one, and it usually costs an afternoon of paperwork.

Re-derive your retention assumptions annually. Not the settings, the assumptions. “We can reconstruct twelve months of CI history” is a claim about a vendor default, and Section 3.3 is what happens when a default moves under a claim you already made to an auditor.

Treat contract terms as an architecture input for anything you would not survive losing. Change of control, notice periods and successor obligations are architecture decisions with legal names, and the engineer who has to rebuild is never in the room when they are agreed. Ask for the clause. It is a five minute conversation that occasionally saves a quarter.

6. The strongest objection

You cannot defend against everything, and a team that models every vendor’s contractual surface will ship nothing. Vendor risk registers are famously a genre of document nobody opens, which is paper 5.13’s territory, and adding another one is not obviously an improvement.

That is a real cost and it is why Section 5 is ordered by effort rather than presented as a programme. The first item is one paragraph per vendor and it captures most of the value. The last item is a legal review and is only worth it for the two or three dependencies whose loss would be existential.

The honest version of this paper’s recommendation fits in one sentence: spend an hour, once, on the two vendors you could not replace, and route the changelogs somewhere a person reads them.

7. What this paper does not claim

It does not claim any of the three vendors behaved badly. OpenAI gave the maximum notice its contract allowed and published its reasoning. The Assistants sunset was announced well ahead with a detailed migration guide. GitHub published its change over a month before it took effect, with the reasoning and the action required stated plainly. All three did roughly what you would want.

It does not claim these events are frequent. Three in a fortnight is a cluster and I am using it as an illustration rather than a base rate.

And it does not claim self-hosting solves it. Paper 5.5 argues sovereignty is a design constraint with real payoffs, and it moves this exposure rather than removing it: you still depend on licences, base images and a supply chain with terms attached. The claim here is narrower, that the terms surface is ungoverned, and it is ungoverned whether you rent or run.