Nothing to migrate to

Somewhere in the middle of a policy document published on 8 October is a sentence that belongs on a sequence diagram. If model output drives hardware without a human approving each action, the equipment "must stop or hold a safe state" — not only when the supervising operator intervenes, but also "when connection to our services is lost." A few lines further on, operating limits "must be enforced by the equipment or a controller independent of model output."

That is not a rule about conduct. It is a specification for a control loop: a watchdog on the link, a defined safe state, and an interlock that sits below the model in the stack rather than beside it. Any engineer who has built a machine that can hurt someone will recognise all three, and will also know roughly what they cost. The document is Anthropic's reissued Usage Policy. It is marked "Effective November 12, 2026," and it was announced on 8 October: thirty-five days.

Compare it with the version it replaces, which is still online and marked "Effective September 15, 2025." That one already imposed high-risk requirements — human review for legal, healthcare, insurance, finance, employment, housing advice — so the idea that a vendor's policy can reach into your design is not new. What is new is the category. The 2025 text has no physical-actions section at all and nothing about equipment behaviour when the service becomes unreachable. The November text adds both, and defines the trigger by capability: hardware that moves through shared spaces such as roads or airspace, applies force that could injure, controls hazardous energy or materials, acts on a person's body, controls safety systems, or runs industrial processes.

Read the exclusions and the architectural character of the thing becomes unmistakable. You are outside the physical-actions requirements if the model produces plans or code that a qualified person reviews before execution; if it monitors without controlling; if the device enforces its own built-in safety limits. You are outside the recommendation requirements if the output is internal drafting rather than the final advice, or if a fixed formula with no model judgement produces the result. Every one of those is a line on a diagram. Whether you are in scope does not depend on what business you are in — it depends on whether a human approval gate sits between inference and actuation, and on which component holds the limits. The policy is not asking what you intend. It is asking how you wired it.

So treat it as what it is: a requirements document, issued by a supplier, binding on systems already in production. Then ask the question any architect would ask about a requirement that arrives from outside — how is it versioned, how do I diff it, and how do I find out which of my systems it breaks. The interesting part of this story is that the same vendor answers all three questions, carefully, for a different dependency.

Models are retired constantly, and the lifecycle for that is documented to a standard a platform team would recognise. There are four named states — Active, Legacy, Deprecated, Retired. Deprecation comes with "a recommended replacement" and an assigned retirement date. Notification is a commitment: "at least 60 days' notice before model retirement for publicly released models," by email and in the documentation. Active models carry a forward-looking floor, published before anything is deprecated at all: claude-opus-5-5 is listed as retiring "Not sooner than September 22, 2027." Every past deprecation since 2024 is still on the page with its dates. And there is an inventory tool — the console exports a CSV of usage by API key and model, so that you can locate "any instances where your application is still using deprecated models."

That is the full apparatus of change control: identity, state, notice, a successor, a history, and a query that tells you where you are exposed.

The protocol layer has been converging on the same discipline, and in the same months. The Model Context Protocol adopted a Feature Lifecycle and Deprecation Policy that reads like it was written by someone who has been on the receiving end of a careless removal. Deprecating anything requires a proposal that identifies the feature by name, links it to its definition in the schema, states a rationale, and documents the migration path "or state explicitly that none is required." The minimum window is "at least twelve" months, counted from the release of the revision in which the feature is marked deprecated. The schema gains a @deprecated tag; the changelog gains an entry; the feature is added to a registry page whose stated purpose is to be "the canonical answer to 'what is on its way out, and by when'" so that an implementer does not have to reconstruct it from scattered changelogs. Tier 1 SDKs must mark the corresponding API surface deprecated in their next release and should emit a runtime warning when it is exercised. Four features deprecated in the July 2026 revision — roots, sampling, logging, dynamic client registration — all carry the same earliest removal: "First revision released on or after 2027-07-28."

And the policy anticipates emergencies. The twelve-month floor can be shortened for "an active security risk," defined narrowly as a vulnerability with a published advisory or documented in-the-wild exploitation for which no in-place mitigation exists. Even then, the shortened window "must still provide at least ninety days."

Ninety days is the emergency floor for removing a protocol feature that attackers are exploiting right now. Thirty-five is what a requirement to re-engineer an interlock got.

The asymmetry is not really about the clock, though, and the clock is the least of it. A model deprecation has an identifier you can put in a ticket, a diff you can read, and a query that names the affected systems. The policy change has an effective date and prose. There is no clause number to cite in a decision record. There is no machine-readable form of "this system relies on being permitted to act without per-action human approval." The previous version is preserved — which is more than most vendors manage — but it is preserved at /legal/archive/22742366-2ef0-4c7a-a833-6523f10d3944, an opaque identifier that links back to another opaque identifier, with no published diff between them. The announcement post summarises the changes in paragraphs, well, and that is the entire change-management surface. Nothing exports a list of your deployments that just moved into scope.

The case against caring about any of this is strong, and worth stating properly. A usage policy is not an interface; it is a safety instrument. Binding a vendor to a twelve-month deprecation window would oblige it to keep permitting uses it has since learned are dangerous, which is an absurd commitment to extract. Thirty-five days with a published summary is unusually generous by the standards of cloud acceptable-use policies, which routinely change on the day they are posted. The specific clauses are correct: anyone shipping a model-driven actuator with no independent limiter and no defined behaviour on link loss was already wrong, and the policy has merely said so out loud. Being told to build the right thing, with five weeks' notice and your supplier's reasoning attached, is not an imposition. It is free advice with a deadline.

All of that is true, and none of it is the complaint. The complaint is that urgency is being used to excuse the half of change control that costs nothing. MCP's own emergency clause is the proof: faced with a feature under active exploitation, the project still requires a named feature, a recorded decision, a documented migration path and ninety days. Moving fast and being traceable are not in tension. Nobody is asking a vendor to keep permitting autonomous drone arming for a year. They are asking for a clause identifier, a published diff, per-requirement effective dates, and a scope statement structured enough that a platform team could evaluate it against a service catalogue instead of reading nine hundred words of prose and guessing.

Why the gap exists is the uncomfortable part. We version what breaks loudly. A retired model fails in your logs, at a rate you can graph, which is why it has four states and a CSV export. A withdrawn permission fails in correspondence to your legal team, months later, with no signal in between — and so it gets an effective date and a paragraph. Change control has grown exactly where failure is observable in telemetry, and the compliance surface emits none.

Which leaves it out of the one place it would be cheap to put. Architecture reviews have a slot for API versions, library versions, protocol revisions and model identifiers. They have none for the usage policy revision the design was assessed against. No decision record says "designed against the policy effective 15 September 2025," even though every system reviewed before this month was. No inventory field captures that a claims platform depends on a carve-out whose fine print specifies that "A partial approval, reduced amount, or approval with conditions is not considered 'wholly favorable'" — a conditional branch, stated in a legal document, governing when a human must look at the result. That branch exists in somebody's code right now. It is not traceable to anything.

One caveat, honestly held: this argument is built almost entirely from one vendor's record, because that vendor publishes an archive, an announcement and a model lifecycle precise enough to be checked against each other. The firms whose policies cannot be diffed at all are not thereby doing better. They are simply not examinable.

The model you depend on will be retired on a published date, with a named successor and a CSV telling you which of your keys still call it. The permission to operate the system you built around it will lapse on an effective date, in prose, and you will discover which of your systems it governed the way everyone else does — afterwards.